Cómo configurar PHP en Caddy Server

Caddy Server es una plataforma de servidor web modular y moderna que soporta certificados HTTPS automáticos, QUIC y HTTP/2, compresión Zstd y Brotli, y varias características modernas, así como características clásicas de servidor web como hosts virtuales configurables, reescritura y redireccionamiento de URL, proxy inverso, y más.

Caddy 2, la versión actual que fue lanzada en mayo de 2020 introdujo mejoras significativas en su sintaxis de configuración, automatización, plugins, y más.

Este artículo explica cómo integrar PHP con la serie de servidores web Caddy versión 2, y la configuración avanzada. También compara configuraciones similares con configuraciones de Apache y Nginx para facilitar la migración de Apache y Nginx a Caddy.

Configuración inicial del servidor

Caddy está disponible en muchos sistemas operativos y distribuciones basadas en Linux. La documentación de Caddy explica cómo instalar Caddy, y configurarlo como un servicio/demonio que se ejecuta automáticamente con el arranque del servidor.

Una vez que Caddy está instalado, Caddy puede ser configurado con una configuración mínima que sirve archivos estáticos si están presentes, y pasa otras peticiones a PHP-FPM.

example.com es el nombre de dominio del ejemplo que se utiliza en el resto de este artículo, y sus archivos fuente se colocan en /var/www/example.com , con un /var/www/example.com/public/index.php que actúa como punto de entrada de la aplicación web. Todos los activos de la aplicación web se almacenan también en el directorio /var/www/example.com/public pero el resto de la aplicación (incluidos los archivos fuente, el directorio de proveedores de Composer, las pruebas, el archivo composer.json, el directorio node_modules de NPM, etc.) se encuentra en /var/www/example.com .

Caddy Server viene con una configuración por defecto segura y de alto rendimiento, lo que hace que sea fácil de configurar con una configuración mínima.

Cuando Caddy se instala y configura como un servicio del sistema, se puede utilizar un /etc/caddy/Caddyfile predeterminado como archivo de configuración global, y un subdirectorio con un nombre sugerido /etc/caddy/sites para contener los archivos de configuración para sitios individuales, similar a la configuración de Apache y Nginx.

/etc/caddy
├── Caddyfile
├── config/
│     └── php-fpm.conf
└── sites/
└── example.com.conf

El Caddyfile global puede especificar la configuración global, e incluir los directorios config/* y sites/* para incluir la configuración adicional.

Caddyfile

{  
log default {  
format console  
output file /var/log/caddy/system.log  
exclude http.log.access  
}
}
import config/*  
import sites/*

Esto configura Caddy para escribir los registros del sistema en el archivo /var/log/caddy/system.log (pero no los registros de peticiones HTTP), así como para cargar archivos de configuración adicionales de los directorios config y sites .

Ejecutar, Iniciar, Detener y Recargar el Servidor Caddy

Si Caddy está instalado como un servicio systemd , se puede utilizar el comando systemctl para iniciar, detener, recargar y reiniciar el servidor Caddy.

Para una configuración ad-hoc, el servidor puede controlarse con el comando caddy :

systemctl start caddy
caddy start
caddy run # Starts server and blocks indefinitely
systemctl stop caddy
caddy stop
systemctl reload caddy
caddy reload
systemctl restart caddy
caddy stop && caddy start

Integrar Caddy con PHP-FPM

De forma similar a como el servidor web Apache y Nginx se integran con PHP, Caddy también se integra con PHP usando el proxy inverso FastCGI de Caddy.

La idea básica es que cuando Caddy recibe una petición que debe ser procesada con PHP (por ejemplo, una petición a un nombre de archivo con extensión .php), la petición es enviada a PHP-FPM, donde se ejecuta la aplicación PHP, y la respuesta es enviada de vuelta a Caddy para devolverla al usuario.

En su forma más simple, la siguiente es una definición de sitio Caddy completamente funcional:

/etc/caddy/sites/example.com.conf

example.com {
root * /var/www/example.com/public
log {
output file /var/log/caddy/example.access.log
format console
}
# Encode responses in zstd or gzip, depending on the
# availability indicated by the browser.
encode zstd gzip
# Configures multiple PHP-related settings
php_fastcgi unix//run/php/php-fpm.sock
# Prevent access to dot-files, except .well-known
@dotFiles {  
path */.*  
not path /.well-known/*  
}
}

El archivo de configuración anterior es un archivo de configuración mínimo sí completo que se encarga de varios aspectos de seguridad y rendimiento.

Para una explicación completa de la lista completa de directivas, así como la información detallada sobre las directivas utilizadas aquí, consulte la excelente documentación de Caddy.

La ayuda extra de Caddy para PHP: php_fastcgi

Caddy hace un esfuerzo extra para facilitar la integración de Caddy con PHP. La práctica directiva php_fastcgi es una abreviatura para múltiples opciones de configuración que pasa las peticiones a PHP-FPM, intenta cargar un index.php desde el directorio inmediato, y finalmente reescribe todas las peticiones al index.php raíz. Este patrón es comúnmente llamado el «patrón de controlador frontal», y puede ser usado para una vasta mayoría de frameworks PHP y CMSs incluyendo Laravel, Drupal, WordPress, Slim PHP, etc.

En su forma más simple, php_fastcgi toma un argumento para el servidor PHP-FPM. Puede ser una dirección de servidor y un puerto (como 127.0.0.1:9000 ) o una dirección de socket de dominio Unix. En Debian/Ubuntu/derivados y RHEL/Fedora/derivados, esto está casi siempre disponible como un socket Unix, a menudo tomando el patrón de ruta /run/php/php[VERSION]-fpm.sock . Por ejemplo, para PHP 8.2, la dirección del socket sería /run/php/php8.2-fpm.sock , y la de PHP 8.3 en /run/php/php8.3-fpm.sock .

Si usar un socket de dominio Unix no es factible, use la dirección IP y el nombre del puerto.

La dirección del socket de dominio Unix o la IP/puerto que escucha PHP-FPM es configurable desde los archivos de configuración de PHP-FPM.

URL Rewriting a index.php

Por defecto, el php_fastcgi implica tres reescrituras de URL importantes:

1. Reescribir peticiones al archivo ./index.php si existe

Si una petición llega a example.com/test , y si existe un archivo en test/index.php , Caddy reescribe esta petición al archivo test/index.php Esto resuelve el «problema de la barra diagonal final», en el que una aplicación PHP existe dentro de un subdirectorio de la raíz del documento.

2. Reescritura a index.php si no existe un archivo

La segunda cosa configurada con el php_fastcgi es que Caddy intenta servir la petición con un fichero si existe. Por ejemplo, si el usuario solicita example.com/image.png , si un archivo llamado image.png existe en la raíz del documento, Caddy lo sirve como un archivo sin invocar PHP en absoluto.

Luego, si un archivo no existe, intenta buscar un archivo index.php en la ruta como un directorio, seguido de un intento de reescribirlo al archivo raíz index.php .

Este paso es similar a la siguiente configuración de Apache:

RewriteCond %{REQUEST_FILENAME} !-f  
RewriteCond %{REQUEST_FILENAME} !-d  
RewriteRule ^ index.php [QSA,L]

... and the following Nginx configuration:

try_files $uri $uri/ /index.php?$query_string;

3. Pasar archivos .php a PHP-FPM

Finalmente, la directiva php_fastcgi dirige los archivos .php a la dirección del servidor FPM especificada. Caddy sabe cómo configurar correctamente los parámetros de FPM, dividir la ruta y realizar varias otras "tareas de traspaso" con valores predeterminados bien pensados.

La directiva php_fastcgi es una abreviatura para varias opciones de configuración. Es posible sobrescribir ciertos parámetros o, si no se adapta a un caso de uso particular, usar la Forma Expandida para una configuración más detallada.

Servir archivos PHP individuales sin reescrituras

Si no es necesario o no se desea reescribir todas las solicitudes al archivo raíz index.php , Caddy puede configurarse para pasar todos los archivos .php a PHP-FPM sin realizar reescrituras:

route {
# Add trailing slash for directory requests
@canonicalPath {
file {path}/index.php
not path */
}
redir @canonicalPath {http.request.orig_uri.path}/ 308
# If the requested file does not exist, try index files
@indexFiles file {
try_files {path} {path}/index.php
split_path .php
}
rewrite @indexFiles {file_match.relative}
# Proxy PHP files to the FastCGI responder
@phpFiles path *.php
reverse_proxy @phpFiles <php-fpm_gateway> {
transport fastcgi {
split .php
}
}
}

Esta configuración es casi idéntica a la Forma Expandida, pero no reescribe al archivo base index.php :

    # Si el archivo solicitado no existe, intenta archivos index
    @indexFiles file {
-       try_files {path} {path}/index.php index.php
+       try_files {path} {path}/index.php
        split_path .php
    }
    rewrite @indexFiles {file_match.relative}

Ajustes de Rendimiento

Caddy incluye varias mejoras de rendimiento integradas y ajustadas de manera predeterminada.

Por ejemplo, la directiva encode zstd gzip hace que Caddy codifique las respuestas en zstd o gzip si el navegador lo indica en su encabezado de solicitud. Caddy también envía el encabezado Vary: Accept-encoding de forma predeterminada, para que los CDN y otras cachés sepan no segmentar la caché por el valor de Accept-encoding . Son pequeños detalles como este los que hacen de Caddy un servidor moderno y con configuraciones predeterminadas convenientes.

Además, Caddy v2.7 tiene varias características de rendimiento y seguridad habilitadas por defecto, incluyendo soporte para HTTP/3 y TLS 1.3, soporte para OCSP stapling (evitando que los navegadores consulten un servidor OCSP para verificar la validez del certificado), encabezados automáticos Alt-Svc, certificados duales RSA+ECC, y más.

Realizar solicitudes HTTP/3 con la extensión Curl de PHP Cómo realizar solicitudes HTTP/3 utilizando la extensión Curl de PHP, junto con cómo compilar Curl con soporte para HTTP/3 en PHP.

Para PHP, se pueden aplicar algunos ajustes adicionales de rendimiento si corresponde:

Páginas 404 Rápidas

En lugar de reescribir todas las solicitudes al archivo index.php , a veces tiene sentido interrumpir y finalizar inmediatamente la respuesta si la URI de solicitud es para un archivo estático que la aplicación PHP no maneja.

El siguiente es un ejemplo de fragmento que coincide con solicitudes entrantes para ciertas extensiones (como .jpg , .png , .woff2 , etc.), y devuelve inmediatamente una respuesta de página no encontrada si dicho archivo no existe. Esto evita invocar innecesariamente PHP (potencialmente más costoso y que a menudo requiere una conexión a la base de datos) solo para generar un error de página no encontrada desde la aplicación.

@static_404 {  
path_regexp .(jpg|jpeg|png|webp|gif|avif|ico|svg|css|js|gz|eot|ttf|otf|woff|woff2|pdf)$  
not file  
}  
respond @static_404 "No Encontrado" 404 {  
close  
}

Encabezados de Caché

El servidor web Apache incluye un módulo llamado Expires ( mod_expires ) que proporciona varias directivas para servir fácilmente encabezados Cache-Control y Expires . El encabezado Expires está obsoleto, lo que deja al encabezado Cache-Control como el que los navegadores usan para controlar su caché para la solicitud.

Aunque Caddy no proporciona un módulo dedicado o un conjunto de directivas para esto, es posible usar la directiva existente header para enviar encabezados Cache-Control :

@static {  
path_regexp .(jpg|jpeg|png|webp|gif|avif|ico|svg|css|js|gz|eot|ttf|otf|woff|woff2|pdf)$  
}  
header @static Cache-Control "max-age=31536000,public,immutable"

Este fragmento envía Cache-Control: max-age=31536000,public,immutable a todas las solicitudes que terminan con jpg/jpeg/png/etc , u otros tipos de archivos estáticos. Combinado con Páginas 404 Rápidas, estos ajustes pueden hacer que Caddy sirva archivos estáticos rápida y eficientemente mientras utiliza cachés de navegadores/CDN.

La directiva match La directiva match de Caddy puede usarse para configurar encabezados según los encabezados de respuesta.

Ajustes de Seguridad

Una de las principales características de Caddy es que admite HTTPS automático. Esto incluye obtener un certificado válido (usando el protocolo ACME) de Autoridades Certificadoras como LetsEncrypt y ZeroSSL, así como redirecciones HTTPS automáticas.

También establece un conjunto altamente equilibrado y seguro de valores de configuración para curvas de intercambio TLS y conjuntos de cifrado, asegurándose de que la configuración predeterminada siempre sea segura.

Es posible desactivar el certificado TLS automático y los redireccionamientos si se desea obtener, validar y renovar certificados por otros medios. Debido a que Caddy siempre está configurado con valores predeterminados sensatos y seguros, PHP.Watch no recomienda cambiar las opciones de configuración predeterminadas relacionadas con TLS/HTTPS.

Janeth Kent

Licenciada en Bellas Artes y programadora por pasión. Cuando tengo un rato retoco fotos, edito vídeos y diseño cosas. El resto del tiempo escribo en MA-NO WEB DESIGN AND DEVELOPMENT.