Filtra los errores de nginx por código de estado o pista del log y obtén la causa probable y el cambio de configuración que lo soluciona. Incluye 502, 504, 403, 404 y 413.
Nginx devuelve 502 Bad Gateway cuando actúa como proxy y la aplicación que tiene detrás no da una respuesta válida: la aplicación está caída, escucha en otro puerto o socket, o falló a mitad de la respuesta. Arranca la aplicación, haz que proxy_pass apunte a la dirección en la que realmente escucha y luego lee el log de errores de nginx para ver el motivo exacto.
Hacia dónde apunta cada error de nginx
Elige el código de estado que ves o escribe una palabra de tu log de errores, y el buscador reduce la lista a las causas que coinciden. Cada tarjeta indica la causa, la comprobación que la confirma y un fragmento de configuración que puedes adaptar. Todas las tarjetas se muestran hasta que filtres.
Como visitante, nada de lo que hagas lo provoca. El proxy intentó llegar a la aplicación que tiene detrás y no obtuvo una respuesta válida. Como propietario del sitio, el problema está en tu aplicación o en la configuración del proxy, así que empieza por comprobar que el proceso upstream se está ejecutando.
Un 502 significa que el upstream respondió mal o rechazó la conexión. Un 504 significa que nginx esperó y no llegó nada a tiempo. El primero apunta a una aplicación detenida o que se cae, el segundo a un trabajo lento o a un timeout demasiado bajo.
Define client_max_body_size en el bloque http, server o location, por ejemplo client_max_body_size 20m;. El valor por defecto es 1m. Un valor de 0 desactiva la comprobación de tamaño, algo que rara vez quieres en un sitio público.
Cuando la URL termina en barra, nginx busca un archivo index como index.html. Si no existe y autoindex está desactivado, que es lo predeterminado, no hay nada que pueda servir. Añade el archivo index o enruta la petición con try_files.
Su ubicación la define la directiva error_log de tu configuración. Busca error_log en tu nginx.conf y en los archivos incluidos para encontrarlo, ya que los paquetes y los contenedores lo colocan en sitios distintos.
Un punto de partida para una aplicación en el puerto 3000. Pasa el host y el esquema originales, define timeouts explícitos y deja margen para cabeceras más grandes.
Prueba con nginx -t y luego recarga. Ajusta el puerto y los límites a tu aplicación.
La aplicación detrás de nginx no se está ejecutando, así que la conexión se rechaza.
Haz un curl a la dirección de proxy_pass desde la máquina de nginx. Una conexión rechazada lo confirma.
Arranca la aplicación con un gestor de procesos que la reinicie después de un fallo.
proxy_pass apunta a un puerto o socket en el que la aplicación no escucha.
Compara la dirección de proxy_pass con la que muestra la aplicación al arrancar.
Haz que ambas coincidan exactamente, incluida la parte del host.
La aplicación envía cabeceras de respuesta más grandes que el búfer en el que nginx las lee, por ejemplo muchas cookies.
Busca una línea del log que mencione que la cabecera es demasiado grande.
Sube proxy_buffer_size para ese location. Su valor por defecto es una página de memoria, 4k u 8k.
La aplicación tardó más que proxy_read_timeout entre dos lecturas, 60 segundos por defecto.
Mide el tiempo de la misma petición directamente contra la aplicación con curl.
Acelera el endpoint o pasa el trabajo a una tarea en segundo plano. Sube el timeout solo para ese location.
Nginx ni siquiera pudo abrir una conexión dentro de proxy_connect_timeout, 60 segundos por defecto.
Comprueba si hay un firewall o un host inaccesible desde el proxy.
Arregla la ruta de red. La documentación de nginx indica que este timeout normalmente no puede superar los 75 segundos, así que subirlo no ayuda.
Una URL que termina en barra no tiene archivo index y autoindex está desactivado.
Lista la carpeta a la que apunta root y busca index.html.
Añade el archivo index o envía la petición a tu aplicación con try_files.
El usuario del worker de nginx no puede leer el archivo o entrar en una de las carpetas superiores.
Busca en el log de errores una línea de permission denied que nombre la ruta.
Da al usuario del worker permiso de lectura en los archivos y de ejecución en cada carpeta superior.
Una regla allow o deny coincidió con el visitante. Las reglas se evalúan en orden y gana la primera que coincide.
Lee de arriba abajo todas las líneas allow y deny que se aplican al location.
Reordena las reglas para que el allow específico vaya antes del deny all general.
Se usó root donde correspondía alias, así que nginx añade dos veces el prefijo del location a la ruta.
Calcula la ruta del archivo: root añade la URI completa, alias reemplaza el prefijo que coincide.
Usa alias, con barra final en ambos lados, cuando el nombre de la carpeta no coincide con la URL.
Una ruta de una single page app como /dashboard no tiene archivo en el disco.
La página de inicio carga, pero al recargar cualquier ruta interna falla.
Vuelve a index.html con try_files para que el router de la aplicación gestione la ruta.
El cuerpo de la petición es mayor que client_max_body_size, 1m por defecto.
Las subidas de menos de un megabyte funcionan y las más grandes fallan.
Sube el límite solo para el location de subidas.
Código de estado
Todos los códigos
Palabras de tu log de errores
por ejemplo: refused, timed out, denied
Comprobación
Solución
{n} causas que coinciden
Ninguna causa coincide. Borra la búsqueda o elige otro código.
Empieza gratis · Sin tarjeta de crédito