Qué es nginx y por qué está delante de casi todo

Publicado el 2026-09-12 por frfrand

Un proxy inverso explicado sin rodeos: qué resuelve, por qué tu app no debería hablar con Internet directamente, y los tres errores que dan 502, 504 y 413.

Tu aplicación corre en el puerto 3000. La gente entra por https://tudominio.com, que es el puerto 443. ¿Quién los conecta?

Un proxy inverso. Casi siempre, nginx.

La palabra "inverso" viene de la comparación con el proxy tradicional: aquel representa al cliente frente a los servidores; este representa a los servidores frente al cliente. Desde afuera, nginx es tu sitio. Tu aplicación no se entera de que Internet existe.

Qué resuelve concretamente

Termina el HTTPS. El certificado vive en nginx. Tu aplicación recibe HTTP plano por localhost y no tiene que saber nada de TLS, ni de renovaciones, ni de versiones de protocolo.

Permite varios sitios en un servidor. nginx mira el nombre de dominio que pidió el navegador y decide a qué aplicación mandar la petición. Tres dominios, tres aplicaciones, un solo servidor y una sola IP.

Sirve los archivos estáticos. Imágenes, CSS, JavaScript: nginx los entrega directamente desde el disco, muchísimo más rápido que tu aplicación y sin gastarle procesos.

Protege. Tu app no tiene ningún puerto expuesto a Internet. Y en el camino se pueden agregar límites de peticiones, listas de bloqueo, compresión y cabeceras de seguridad.

La configuración mínima, línea por línea

server { listen 443 ssl; server_name miapp.com;

location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; } }

Las tres cabeceras no son decorativas y olvidarlas causa problemas confusos:

• Sin Host, tu aplicación cree que el dominio es localhost, y las URLs que genere van a salir mal.
• Sin X-Real-IP, todos tus visitantes aparecen en los logs con la dirección del propio servidor.
• Sin X-Forwarded-Proto, tu framework cree que la conexión es HTTP y puede armar redirecciones infinitas al intentar forzar HTTPS.

Los tres errores que vas a ver

502 Bad Gateway. nginx no pudo hablar con tu aplicación. El problema no está en nginx: tu app no está corriendo, se cayó, o escucha en otro puerto. Mirá el log de tu app, no el de nginx.

504 Gateway Timeout. Tu aplicación respondió, pero tardó más de lo que nginx espera (60 segundos por defecto). Si es una operación legítimamente lenta, se sube proxy_read_timeout. Si no, el problema es la consulta.

413 Request Entity Too Large. Alguien intentó subir un archivo más grande que client_max_body_size, que viene en 1 MB. Este confunde mucho porque el error llega antes de que tu código se entere.

La regla que evita caídas

nginx -t && systemctl reload nginx

Siempre las dos, siempre en ese orden. nginx -t valida la configuración y te dice el archivo y la línea del error. Sin eso, un punto y coma olvidado puede dejarte el sitio abajo.

Y reload, no restart: reload aplica la configuración nueva sin cortar las conexiones que están en curso.

Dónde encaja en ArduMaker

Cada dominio que publicás queda con su bloque de nginx y su certificado, emitido y renovado solo. Se puede editar la configuración desde el panel cuando hace falta algo particular, y se valida antes de aplicar, que es exactamente el nginx -t de arriba pero sin la posibilidad de olvidarlo.