Nginx para Laravel: configuracion basica y errores comunes

Si estas buscando una configuracion solida de Nginx para Laravel, empieza por una idea: Nginx debe exponer la app con limpieza, no esconder confusion backend. Una buena configuracion da routing predecible, entrega correcta de estaticos, manejo razonable de PHP y logs suficientes para depurar incidencias rapido.

Eso importa todavia mas cuando la app Laravel tambien alimenta APIs, colas o paneles operativos como los que describo en APIs limpias en Laravel para apps moviles. Si peticiones web, jobs y despliegues comparten un host fragil, cada atajo de configuracion se convierte en un riesgo de produccion.

La base de Nginx para Laravel

Laravel espera que Nginx apunte a public, sirva archivos estaticos de forma directa y pase las peticiones PHP a PHP-FPM. Lo demas deberia ser explicito.

server {
    listen 80;
    server_name example.com;
    root /var/www/app/current/public;
    index index.php;

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

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_read_timeout 60;
    }

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

Puede que necesites otro socket, SSL o reglas de cache, pero la estructura deberia seguir siendo aburrida. Aqui aburrido es bueno.

De que se ocupa Nginx y de que no

Nginx se ocupa de routing, estaticos, headers, buffering, terminacion TLS y visibilidad de logs. No se ocupa de arreglar SQL lento, jobs de cola rotos o un despliegue sin rollback.

Esta distincion importa porque muchos equipos intentan resolver inestabilidad de aplicacion dentro de la configuracion web. Si la app se bloquea porque una cola corre en sync, o si un endpoint de informes hace timeout porque deberia ir en cola, la solucion pertenece a la arquitectura de la app, no a subir timeouts.

Errores comunes

El primer error es apuntar root al directorio del proyecto en vez de a public. Eso expone archivos que nunca deberian ser accesibles por web.

El segundo error es usar rutas de despliegue fragiles. Si SCRIPT_FILENAME apunta mal a un symlink, los releases sin downtime acaban en 502 aleatorios.

El tercer error es confundir problemas de permisos con problemas de Nginx. Si storage o bootstrap/cache estan mal, el error parece del servidor web cuando la causa real es la propiedad de archivos en despliegue.

El cuarto error es apagar logs o dejarlos sin detalle util. Necesitas suficiente informacion de access y error logs para correlacionar latencia, fallos upstream y despliegues defectuosos.

El quinto error es pensar que endpoints publicos significan endpoints descuidados. Si Laravel expone feeds publicos, formularios de leads o flujos de ingesta, siguen importando rate limits, trazabilidad de requests y reglas de retencion.

Checklist practico para Laravel + Nginx

• configura root solo al directorio public de Laravel
• usa try_files para que los faltantes entren en index.php con limpieza
• apunta FastCGI al socket o upstream correcto de PHP-FPM
• guarda logs por sitio y revisa access y error logs
• deniega acceso a archivos ocultos y rutas sensibles
• sirve estaticos directos con cache razonable
• documenta usuario de despliegue, permisos y rutas escribibles
• separa timeouts web de decisiones de arquitectura de colas
• prueba reloads y rollbacks antes de depender del trafico real
• anota que endpoints publicos existen y bajo que limites operan

Cache, headers y estabilidad

Nginx ayuda mas cuando mantiene lo simple como simple. CSS, JS e imagenes no deberian tocar PHP. Los headers de seguridad deben ser explicitos. Los request IDs y la IP real del cliente deben ser consistentes si hay Cloudflare u otro proxy delante.

Si usas Cloudflare, reverse proxies o VPNs de equipo, conviene documentar esas fronteras de confianza. Es la misma mentalidad operativa que hay detras de dar acceso SSH sin exponer el servidor y acceso remoto sin abrir puertos: la estabilidad mejora cuando las suposiciones de red son visibles.

Haz que los problemas de despliegue sean trazables

La mayor parte del dolor de Nginx en proyectos Laravel en realidad es dolor de despliegue. Una configuracion sana deja claro que release esta sirviendo, que pool de PHP-FPM atendio la peticion y si un 502 viene de mala config, malos permisos o upstream caido.

{
  "request_id": "web-7d21",
  "release": "2026-07-06-01",
  "vhost": "app.example.com",
  "upstream": "php8.3-fpm",
  "status": 502,
  "path": "/admin/reports"
}

Esa evidencia evita que una incidencia termine en intuicion simultanea sobre Nginx, PHP-FPM y Laravel.

Cuando tiene sentido contratar a alguien tecnico

Si tu app Laravel ya esta en produccion, los despliegues dan miedo, los cambios en Nginx se hacen por prueba y error y nadie puede explicar donde acaba el problema web y donde empieza el problema de aplicacion, el cuello de botella no es una directiva concreta. Es propiedad operativa.

Ahi es donde servicios tecnicos o ayuda directa mediante CTO tecnico fractional tiene sentido. El valor rara vez esta en rehacer todo. Suele estar en cerrar despliegue, limites entre Nginx y codigo, logs, reglas sobre endpoints publicos y disciplina de rollback.

Conclusion

Una buena configuracion de Nginx para Laravel es simple, explicita y observable. Sirve el directorio correcto, entrega PHP al upstream correcto, mantiene archivos sensibles cerrados y deja evidencia suficiente cuando produccion se comporta mal.

Si tu configuracion actual sigue generando 404, 502 o problemas de permisos tras cada despliegue, usa contacto y trae el vhost actual, el flujo de despliegue y el ultimo patron de fallo. Con eso ya se puede ver si el problema real es Nginx, PHP-FPM o el proceso de release.