Proxy inverso nginx: tutorial completo de configuración

Un proxy inverso nginx es un servidor nginx que acepta solicitudes entrantes en nombre de una o varias aplicaciones backend, después reenvía cada solicitud al backend correcto y devuelve la respuesta al cliente. Este tutorial te ofrece una configuración de proxy inverso nginx completa y lista para copiar: un bloque server completo con proxy_pass y cabeceras reenviadas, balanceo de carga upstream, terminación SSL, soporte para WebSockets, ajuste de buffering y tiempos de espera, gzip, enrutamiento basado en location y soluciones para los errores 502 y 504 que hacen tropezar a la mayoría.

Al final tendrás una configuración de proxy inverso nginx ejecutable, un modelo mental de cómo encajan las piezas y una visión honesta de dónde un proxy inverso nginx deja de ser la herramienta adecuada y un proxy forward o residencial toma el relevo.

DataImpulse es un proveedor de proxies ético que ofrece más de 90 millones de direcciones IP residenciales, móviles y de centro de datos en 195 países. Utiliza un modelo de pago por uso desde 1 dólar por GB con tráfico que no caduca, y se usa para web scraping, verificación de anuncios, monitorización de precios, investigación de mercado y gestión de múltiples cuentas.

¿Es nginx un proxy inverso y cómo funciona uno?

Sí, nginx es uno de los proxies inversos más desplegados, y el proxy inverso es una función de primera clase en lugar de un complemento. Un proxy inverso se sitúa delante de tus servidores backend, acepta conexiones de clientes en un nombre de host público y enruta cada solicitud a una aplicación interna que el cliente nunca ve directamente.

Para mantener claras las partes móviles, esta guía usa un modelo simple con nombre. Llámalo el modelo de proxy inverso nginx de 5 capas, y cada configuración funcional de abajo no es más que estas capas apiladas en orden:

• listen La directiva listen y server_name deciden qué solicitudes posee este bloque (puerto 80, puerto 443, qué nombre de host).
• Enrutamiento por location. Los bloques location dividen las rutas entrantes para que /api/, /static/ y / puedan ir cada una a un sitio diferente.
• Upstream. El bloque upstream nombra el grupo de servidores backend y el método de balanceo de carga.
• Cabeceras. Las líneas proxy_set_header preservan el Host original y la IP del cliente para que el backend vea la solicitud real, no a nginx.
• TLS. ssl_certificate en listen 443 termina HTTPS en nginx para que los backends puedan hablar HTTP plano internamente.

Si todavía estás decidiendo entre las dos direcciones de proxy, nuestra explicación sobre proxy inverso frente a proxy forward cubre el concepto por completo. Este artículo trata solo el caso inverso. Para la configuración saliente, del lado del cliente, consulta la guía complementaria de proxy forward nginx.

¿Qué necesitas antes de empezar?

Necesitas un servidor Linux con nginx instalado, al menos una aplicación backend escuchando en un puerto local y, para HTTPS, un certificado TLS. El proxy inverso usa solo la compilación estándar de nginx, por lo que no se requieren módulos personalizados ni recompilar.

Confirma que nginx está presente y que tu configuración es válida antes de editar nada:

nginx -v
sudo nginx -t

La prueba nginx -t analiza toda la configuración e informa de errores de sintaxis con un archivo y número de línea. Ejecútala después de cada cambio en este tutorial, porque nginx se negará a recargar una configuración rota y dejará la antigua en funcionamiento. Coloca tus bloques server de proxy inverso en /etc/nginx/conf.d/ o /etc/nginx/sites-available/ según tu distribución, y recarga con sudo nginx -s reload una vez que la prueba pase. Ten también lista la dirección del backend, por ejemplo una aplicación Node o Python en 127.0.0.1:3000, ya que eso es a lo que apuntará proxy_pass.

¿Cómo configurar un proxy inverso nginx paso a paso?

Empieza con un único bloque server que escuche en el puerto 80, reenvíe cada solicitud a un backend con proxy_pass y establezca las cabeceras reenviadas. Después añade balanceo de carga, TLS, WebSockets, buffering y gzip. Este primer bloque es la configuración mínima funcional de un proxy inverso nginx:

server {
    listen 80;
    server_name app.example.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-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Esas cuatro líneas proxy_set_header no son opcionales. Sin ellas el backend ve a nginx como el cliente, registra la IP equivocada y puede construir URLs de redirección incorrectas. Host preserva el nombre de host solicitado, X-Real-IP y X-Forwarded-For llevan la dirección real del cliente, y X-Forwarded-Proto le dice a la aplicación si la solicitud original fue HTTP o HTTPS.

Añade balanceo de carga upstream. Para situarte delante de varias instancias backend, define un bloque upstream y apunta proxy_pass a su nombre. El método least_conn envía cada solicitud a la instancia con menos conexiones activas:

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000 backup;
}

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

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

El servidor backup solo recibe tráfico cuando los servidores primarios están caídos. Cambia least_conn por ip_hash si necesitas fijar el mismo cliente al mismo backend para sesiones persistentes.

Termina SSL en el puerto 443. Los proxies inversos de producción deberían servir HTTPS y redirigir el HTTP plano. nginx gestiona TLS para que tus backends puedan permanecer en HTTP plano internamente:

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

Da soporte a WebSockets. Las conexiones WebSocket comienzan como HTTP y luego se actualizan, por lo que nginx necesita pasar las cabeceras Upgrade y Connection y usar HTTP/1.1. Da a las rutas en tiempo real su propia location:

location /ws/ {
    proxy_pass http://app_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host       $host;
    proxy_read_timeout 3600s;
}

El largo proxy_read_timeout evita que los sockets inactivos se cierren a mitad de sesión, una causa habitual de conexiones en vivo interrumpidas.

Ajusta buffering y tiempos de espera. Los valores por defecto son conservadores; los backends lentos se benefician de valores explícitos para que nginx no cierre una conexión antes de que la aplicación responda:

location / {
    proxy_pass http://app_backend;
    proxy_connect_timeout 5s;
    proxy_send_timeout    60s;
    proxy_read_timeout    60s;
    proxy_buffering       on;
    proxy_buffers         16 16k;
    proxy_buffer_size     32k;
}

Activa gzip. Comprimir las respuestas proxeadas reduce el ancho de banda para los recursos de texto. Pon esto en el bloque http para que se aplique en todo el sitio:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 5;

Enruta por ruta. Un solo proxy inverso puede dar servicio a varios servicios haciendo coincidir diferentes prefijos de location con diferentes upstreams, sirviendo archivos estáticos directamente desde el disco sin tocar un backend:

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
    }

    location /static/ {
        root /var/www/assets;
    }

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
    }
}

¿Cómo verificar que el proxy inverso nginx funciona?

Recarga nginx, después envía una solicitud al nombre de host público y confirma que la respuesta viene de tu backend y no de una página nginx por defecto. Prueba primero la configuración para que una errata no tire el sitio:

sudo nginx -t && sudo nginx -s reload
curl -I http://app.example.com

Un 200 o una redirección esperada en las cabeceras de respuesta significa que el enrutamiento funciona. Para demostrar que el backend está recibiendo las cabeceras reenviadas, revisa su registro de acceso o un endpoint de eco y confirma que ve la IP real del cliente desde X-Forwarded-For, no 127.0.0.1. También puedes saltarte el DNS y apuntar directamente al proxy mientras falsificas el nombre de host:

curl -H "Host: app.example.com" http://127.0.0.1

Para HTTPS, ejecuta curl -I https://app.example.com y verifica que el certificado se acepta y que la solicitud no se degrada. Si el backend genera enlaces o redirecciones con el esquema equivocado, casi siempre es una cabecera X-Forwarded-Proto ausente y no un fallo de TLS.

¿Cómo solucionar los errores 502 y 504?

Un 502 Bad Gateway significa que nginx alcanzó el upstream pero obtuvo una respuesta inválida o rechazada, mientras que un 504 Gateway Timeout significa que el upstream aceptó la conexión pero no respondió a tiempo. Ambos son problemas del upstream, no errores de nginx, y el registro de errores nombra la causa exacta. Obsérvalo en vivo mientras reproduces la solicitud:

sudo tail -f /var/log/nginx/error.log
# [error] connect() failed (111: Connection refused) while connecting to upstream

Repasa las causas habituales en orden:

• 502, conexión rechazada. El backend no se está ejecutando o está escuchando en una dirección o puerto diferente al que apunta proxy_pass. Confírmalo con curl http://127.0.0.1:3000 en el propio servidor.
• 502, SELinux o firewall. En sistemas de la familia RHEL, SELinux impide que nginx abra conexiones salientes hasta que ejecutes setsebool -P httpd_can_network_connect 1.
• 504, backend lento. La aplicación tarda más que proxy_read_timeout en responder. Aumenta el tiempo de espera para esa location, o corrige la consulta lenta, en lugar de enmascararla globalmente.
• 502, cabeceras grandes. Un backend que envía cabeceras de respuesta grandes puede desbordar los buffers del proxy. Aumenta proxy_buffer_size y proxy_buffers.
• Upstream equivocado elegido. Si un servidor de un grupo upstream está caído, nginx lo marca como no saludable y reintenta con el siguiente, así que los 502 intermitentes suelen apuntar a un único backend no saludable.

¿Qué proxy inverso encaja y cuándo necesitas un proxy diferente?

Usa un proxy inverso nginx cuando estás terminando TLS, balanceando carga o enrutando rutas delante de tus propios servidores; recurre a un proxy forward o residencial cuando el trabajo es enviar solicitudes salientes desde muchas IPs. nginx es excelente en el trabajo entrante y no está diseñado para el saliente. Aquí está la matriz de decisión:

• Usa un proxy inverso nginx cuando alojas el backend, quieres un único endpoint HTTPS público sobre varios servicios internos, necesitas balanceo de carga entre instancias o quieres caché y gzip en el borde.
• Evita nginx como tu proxy cuando el objetivo son solicitudes salientes que deben parecer venir de muchas IPs o países diferentes, porque un proxy inverso sale desde la IP de tu único servidor y no puede rotar direcciones.

Entre los proxies inversos en concreto, nginx, Caddy y HAProxy hacen distintos compromisos:

Para automatización saliente intensiva, nuestra guía de mejores prácticas de web scraping cubre la rotación y el control de tasa, y los proxies de centro de datos o proxies móviles se adaptan a trabajos donde el coste o las IPs de operador importan más que la fidelidad residencial.

¿Cuáles son las limitaciones y los riesgos de un proxy inverso nginx?

Un proxy inverso nginx es potente para el tráfico entrante pero tiene límites reales: no puede rotar IPs salientes, unas cabeceras mal configuradas filtran u ocultan al cliente, y añade un componente operativo que debes parchear y monitorizar. Conocer esto mantiene las expectativas honestas.

• IP de salida única. Cada solicitud saliente del proxy sale a través de la propia IP del servidor, así que un proxy inverso no puede ayudar con tareas que necesitan muchas direcciones de origen.
• Los errores de cabecera son silenciosos. Olvidar X-Forwarded-For oculta la IP real del cliente a tu aplicación y su limitación de tasa; olvidar X-Forwarded-Proto rompe las redirecciones HTTPS. nginx no te avisará.
• Mantenimiento de TLS y certificados. Los certificados caducan, así que la renovación y las recargas son tuyas, normalmente mediante certbot y un cron job o un temporizador de systemd.
• Un nuevo punto de fallo. El proxy está ahora en la ruta crítica; si se cae, todos los backends detrás de él quedan inalcanzables, por lo que las comprobaciones de salud y la monitorización importan.
• No es una herramienta de anonimato saliente. Un proxy inverso no está construido para disfrazar de dónde vienen las solicitudes. Ese es el trabajo de un proxy forward.

nginx no es un producto de DataImpulse, y DataImpulse no vende una API de scraping gestionada ni un proxy web gratuito. Ejecuta nginx tú mismo donde encaje; donde necesites escala saliente, DataImpulse obtiene sus IPs como proxies éticos de usuarios que dan su consentimiento y son compensados. Última actualización: 2026-07-22.

Preguntas frecuentes

Guías relacionadas

• Proxy forward NGINX
• Proxy inverso Cloudflare
• Proxy inverso Docker

¿Necesitas IPs salientes que nginx no puede rotar?

Un proxy inverso gestiona el tráfico entrante, pero cuando tu trabajo necesita solicitudes salientes desde muchas IPs reales, DataImpulse añade más de 90 millones de IPs residenciales, móviles y de centro de datos rotativas en 195 países, con pago por uso desde un dólar por GB y tráfico que no caduca. Crea una cuenta para obtener credenciales de gateway y enrutar tu cliente hacia el grupo.