Configuración de Nginx que mantiene los sitios rápidos

Publicado el 19 de septiembre de 2026

Un sitio puede parecer perfectamente saludable hasta que un pequeño error en la configuración de Nginx convierte un despliegue rutinario en un error 502, una advertencia de SSL o un bucle de redirección que no lleva a los visitantes a ningún lugar útil. Nginx es rápido y fiable, pero también es exigente: una directiva en el lugar incorrecto puede cambiar el comportamiento de un sitio entero. La buena noticia es que un enfoque limpio hace que la configuración de Nginx sea mucho menos misteriosa.

Esta guía se centra en los ajustes que más importan al alojar sitios web: bloques de servidor, manejo de PHP, HTTPS, redirecciones, archivos estáticos, caché y pruebas seguras. No necesita memorizar cada directiva de Nginx. Necesita entender qué decisiones afectan a su sitio y cómo verificarlas antes de que afecten a sus visitantes.

Empiece con un diseño claro de la configuración de Nginx

La mayoría de las instalaciones de Linux separan los ajustes globales de los ajustes de sitios web individuales. El archivo principal de configuración, que normalmente se encuentra en /etc/nginx/nginx.conf, controla los procesos worker, el registro, la compresión y los directorios de configuración incluidos. Los sitios individuales suelen estar en un directorio como sites-available, sites-enabled o conf.d.

Esta separación es útil por una razón práctica: los ajustes globales deben cambiarse con cuidado y rara vez, mientras que los ajustes a nivel de sitio web necesitan atención regular. Un dominio nuevo, un sitio de staging o una regla de redirección pertenecen al bloque de servidor de ese sitio, no al archivo principal.

Antes de cambiar nada, identifique la configuración activa y pruébela:

bash nginx -t

Si la prueba se realiza correctamente, recargue Nginx sin interrumpir las conexiones activas:

bash systemctl reload nginx

Use reload para los cambios normales de configuración. A veces es necesario un reinicio completo, pero no es el primer paso cuando está actualizando un host virtual. Pequeños hábitos como este evitan que una tarea de cinco minutos se convierta en un trabajo de recuperación nocturno.

Cree un bloque de servidor por sitio web

Un bloque de servidor le indica a Nginx qué dominio sirve, dónde se almacenan los archivos del sitio web y cómo deben manejarse las solicitudes. Piense en él como la recepción de un sitio web. Cuando varios dominios comparten un servidor, un bloque de servidor ordenado es lo que mantiene el tráfico yendo al lugar correcto.

Un sitio HTTP básico podría verse así:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

El server_name debe enumerar todos los nombres de host que pretende servir. Si los visitantes pueden acceder tanto al dominio raíz como a www, incluya ambos y luego decida cuál debe convertirse en canónico mediante una redirección.

La ruta root debe apuntar al directorio que contiene los archivos web públicos, no necesariamente a la carpeta de nivel superior del proyecto. En WordPress, esta suele ser la carpeta donde existen wp-admin, wp-content y wp-includes. En Laravel y frameworks similares, normalmente es el directorio public. Apuntar Nginx a la carpeta equivocada puede exponer archivos que nunca deberían estar disponibles públicamente.

La regla try_files merece atención. Comprueba si existe un archivo o directorio solicitado antes de pasar las solicitudes no coincidentes a la aplicación. Esto es esencial para los enlaces permanentes de WordPress y muchas aplicaciones PHP modernas. Sin ella, puede que las páginas funcionen solo cuando los visitantes usen la URL completa con index.php añadido. No es lo ideal, ni un problema del que quiera que los clientes informen primero.

Evite la trampa del servidor predeterminado

Nginx necesita un servidor predeterminado para las solicitudes que no coinciden con un nombre de host configurado. Si el sitio equivocado está configurado como predeterminado, un dominio desconocido o una solicitud directa a la IP puede mostrar el sitio web de otra persona. Eso es, en el mejor de los casos, confuso y, en el peor, arriesgado.

Para servidores con varios sitios, use un servidor predeterminado simple que no devuelva contenido útil, como una respuesta 404. Mantenga los sitios web reales en bloques de servidor explícitos con sus propios valores de server\_name. Es un pequeño límite que facilita la gestión de un servidor compartido.

Configure PHP sin conjeturas

Nginx no procesa PHP por sí solo. Pasa las solicitudes PHP a PHP-FPM, que ejecuta el código. La conexión normalmente es un socket Unix o un puerto TCP local.

Un bloque location común para PHP se ve así:

location ~ \.php$ {
    try_files $uri =404;

    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

La versión de PHP y la ruta del socket varían según el servidor. Si Nginx devuelve un error 502 Bad Gateway después de una actualización de PHP, la ruta del socket es uno de los primeros lugares que debe revisar. Puede que PHP-FPM esté detenido, ejecutando una versión diferente o escuchando en algún lugar distinto de la ruta definida en Nginx.

También vale la pena mantener la línea try_files $uri =404;. Evita que Nginx envíe al procesador PHP solicitudes de archivos PHP que no existen. Eso mejora tanto la seguridad como el manejo de errores.

Para WordPress, evite añadir reglas amplias copiadas de publicaciones aleatorias en foros, a menos que sepa por qué son necesarias. WordPress ya funciona bien con una configuración limpia de try_files, un manejo adecuado de PHP y permisos de escritura solo donde WordPress los necesita. Más reglas no significan automáticamente una mejor configuración.

Haga de HTTPS la ruta predeterminada

Todo sitio web público debería servir HTTPS y redirigir el tráfico HTTP a la versión segura. El patrón habitual es un bloque de servidor HTTP que realiza solo la redirección, más un bloque HTTPS independiente que sirve el sitio.

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://example.com$request_uri;
}

El bloque de servidor HTTPS luego escucha en el puerto 443 e incluye las rutas del certificado y de la clave privada. Los archivos de certificado dependen de cómo se aprovisione SSL, pero el principio sigue siendo el mismo: mantenga la configuración del certificado dentro del sitio que lo usa.

Una redirección permanente 301 es adecuada una vez que esté seguro del destino. Durante una migración activa o una prueba a corto plazo, una redirección 302 puede ser más segura porque los navegadores no la almacenan en caché de forma tan agresiva. Este es uno de esos casos en los que la opción que parece técnicamente más sólida no siempre es la elección operativa correcta.

Elija también un nombre de host preferido. Redirija www al dominio raíz o el dominio raíz a www. Servir ambos sin una redirección consistente puede dividir la analítica, crear páginas duplicadas para los motores de búsqueda y dificultar el diagnóstico del comportamiento de las cookies.

Sirva archivos estáticos de forma eficiente y segura

Las imágenes, CSS, JavaScript, fuentes y archivos descargables no deberían consumir recursos de PHP cuando Nginx puede entregarlos directamente. Establezca una caché razonable del navegador para los archivos que rara vez cambian:

location ~* \.(css|js|jpg|jpeg|png|gif|svg|webp|ico|woff2)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Treinta días es un punto de partida sensato, no una ley. Si sus nombres de archivo incluyen números de versión o nombres de archivo con hash, una caché más larga puede funcionar muy bien. Si el mismo nombre de archivo se reemplaza con frecuencia, una caché larga puede hacer que los visitantes vean un diseño o script anterior. La caché siempre es un acuerdo entre la velocidad y la rapidez con la que deben aparecer los cambios.

No exponga archivos ocultos por accidente. Una regla simple puede bloquear solicitudes de archivos ocultos mientras permite el directorio .well-known usado por la validación de certificados:

location ~ /\.(?!well-known(?:/|$)) {
    deny all;
}

Según su configuración de certificados, puede que necesite una excepción específica para .well-known. Pruebe el comportamiento de la renovación después de hacer más estrictas las reglas de acceso. Las reglas de seguridad deben reducir la exposición, no romper silenciosamente servicios de los que depende.

Use encabezados de seguridad con contexto

Los encabezados de respuesta pueden mejorar la protección del lado del navegador, pero necesitan pruebas. Los ejemplos comunes incluyen X-Content-Type-Options nosniff, Referrer-Policy y Content-Security-Policy. El último es potente y fácil de configurar mal. Una política estricta puede bloquear scripts, fuentes, widgets de pago, analítica o contenido incrustado si se introduce sin comprender las dependencias del sitio.

Empiece con encabezados que tengan un propósito claro y bajo riesgo, y luego añada una política de seguridad de contenido en modo report-only si su aplicación lo admite. El objetivo no es reunir una impresionante pila de directivas. El objetivo es reducir el riesgo real sin romper las páginas que la gente necesita usar.

La limitación de tasa también puede ayudar con el tráfico abusivo y los ataques de inicio de sesión, especialmente para los endpoints de inicio de sesión de WordPress. Pero unos límites agresivos pueden bloquear a usuarios legítimos detrás de redes de oficina compartidas u operadores móviles. Revise los registros y ajuste en función de los patrones reales de tráfico en lugar de elegir números que simplemente suenen estrictos.

Pruebe los cambios como si importaran

Cada cambio en Nginx debe seguir la misma rutina breve: hacer una copia de seguridad o copiar el archivo actual, hacer un cambio específico, ejecutar nginx -t, recargar Nginx y probar el sitio web desde un navegador y la línea de comandos. Compruebe el dominio previsto, el dominio no canónico, HTTP, HTTPS y una página manejada por PHP.

Cuando algo falle, lea los registros de errores antes de reescribir la configuración. Los registros de acceso y errores de Nginx a menudo revelan si el problema es un archivo ausente, un permiso incorrecto, una conexión upstream fallida o una redirección errónea. Adivinar puede crear tres problemas nuevos sin resolver ninguno.

Un panel de control puede eliminar gran parte de este trabajo manual al crear y organizar en un solo lugar los ajustes a nivel de sitio web, los certificados, las versiones de PHP y los registros. FASTPANEL está diseñado para ese punto medio práctico: usted mantiene el control de su entorno de hosting sin convertir cada cambio de dominio en un proyecto de arqueología de configuración.

Una buena configuración de Nginx no consiste en construir el archivo más largo ni en usar cada directiva disponible. Consiste en hacer que cada sitio sea predecible: el dominio correcto llega a los archivos correctos, PHP tiene un upstream saludable, HTTPS se aplica, el contenido estático es eficiente y los cambios se prueban antes de que los visitantes se encuentren con ellos. Una vez que esa base está en su lugar, gestionar un servidor en crecimiento se vuelve mucho menos dramático, exactamente como debería ser.