Reverse proxy vs forward proxy
Un forward proxy trabaja para el cliente. El navegador está configurado para usarlo, y él trae internet en nombre del navegador — filtrado corporativo de salida, y la mayoría de lo que la gente quiere decir cuando busca "proxy".
Un reverse proxy trabaja para el servidor. Los clientes no tienen ni idea de que existe; resuelven tu hostname, él responde, y decide qué hacer con la petición. Tu aplicación puede estar en otra máquina, en un contenedor, o repartida entre diez de ellos.
La distinción importa porque los resultados de búsqueda la difuminan. Si una página sobre "servidores proxy" habla de desbloquear sitios web, no está hablando de lo que hay delante de tu aplicación.
Qué ganas en realidad
Terminación TLS. Los certificados viven en un solo lugar en lugar de en cada servidor de aplicación. La renovación se convierte en una sola tarea.
Enrutamiento. Un hostname, varios backends: /api al servicio Node, / a WordPress, /static al almacenamiento de objetos. El cliente ve un solo sitio.
Caché. El proxy responde él mismo a las peticiones repetidas. Esta es, ella sola, la mayor ganancia de rendimiento disponible para la mayoría de los sitios, y la que más a menudo se deja apagada.
Compresión. Brotli o gzip aplicados una vez en el borde de tu stack en lugar de en cada aplicación.
Rate limiting y filtrado. Un lugar donde aplicar límites y bloquear tráfico antes de que llegue a código que cuesta dinero ejecutar.
Ocultar el origen. Si tu servidor de aplicación solo es alcanzable desde el proxy, los ataques tienen que pasar por la puerta que tú controlas.
Un lugar donde cambiar el comportamiento. Redirecciones, reescrituras de cabeceras y páginas de mantenimiento que no requieren un despliegue de la aplicación.
Una configuración de nginx que funciona
Lo mínimo que es realmente correcto — las cabeceras de abajo no son decoración opcional, son lo que hace que tu aplicación vea al cliente en lugar de al proxy:
``` server { listen 443 ssl; server_name example.com;
ssl_certificate /etc/ssl/example.com/fullchain.pem; ssl_certificate_key /etc/ssl/example.com/privkey.pem;
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;
proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } ```
Host — sin ella, el backend ve 127.0.0.1 y cualquier URL absoluta que construya está mal.
X-Forwarded-For y X-Real-IP — sin ellas, cada petición en el registro de tu aplicación viene del proxy, y cualquier lógica por IP que tengas se aplica silenciosamente al proxy en lugar de al visitante.
X-Forwarded-Proto — sin ella, una aplicación detrás de una terminación TLS cree que está en HTTP plano y genera enlaces http://, lo que produce el bucle de redirección que le cuesta a todo el mundo una tarde al menos una vez.
El par Upgrade — sin él, los WebSockets no funcionan, y el fallo parece un error de la aplicación en lugar de uno del proxy.
Caché en el proxy, en breve
nginx puede cachear las respuestas del upstream con proxy_cache. La mecánica es bastante simple: declara una ruta de caché, actívala en la location, y decide qué se almacena y durante cuánto tiempo.
``` proxy_cache_path /var/cache/nginx keys_zone=site:50m max_size=5g inactive=24h;
location / { proxy_cache site; proxy_cache_valid 200 10m; proxy_cache_key "$scheme$request_method$host$request_uri"; add_header X-Cache-Status $upstream_cache_status; proxy_pass http://127.0.0.1:3000; } ```
Dos cosas deciden si esto ayuda o perjudica.
La clave de caché. Por defecto incluye la URI completa, así que ?utm_source=twitter crea una entrada distinta de la URL limpia. Una campaña puede fragmentar tu caché en miles de copias de una sola página y hundir la tasa de aciertos a nada. Elimina los parámetros que no cambian la respuesta.
Purgar. El nginx de código abierto no tiene ningún mecanismo de purga; o esperas al TTL, o borras archivos del directorio de caché a mano, en cada máquina. Este suele ser el punto en el que "operamos nuestro propio proxy" empieza a doler, porque publicar una corrección y esperar diez minutos a que aparezca no es un flujo de trabajo que nadie disfrute.
Lo que cuesta de verdad operar el tuyo propio
Un nginx delante de una aplicación es barato y del todo razonable. El coste llega después, en piezas.
Es una sola máquina. Un reverse proxy que es la única puerta de entrada es también lo único que tiene que seguir en pie. Hacerlo redundante significa una segunda máquina, una dirección flotante o failover de DNS, y una configuración idéntica en ambas.
Certificados. La renovación automatizada es un problema resuelto hasta que el hook de renovación en el segundo nodo falla silenciosamente y te enteras por un aviso del navegador.
Invalidación de caché entre nodos. Con dos proxies tienes dos cachés, y purgar significa hacerlo en ambos, de forma fiable, desde tu pipeline de despliegue.
Está en un solo lugar. Tus visitantes no. Un proxy en un centro de datos no puede estar cerca de usuarios en otro país; eso es un problema de física, no de configuración.
El ajuste es continuo. Tamaños de búfer, timeouts, keepalive hacia los upstreams, conexiones de worker — cada uno de ellos está bien con tu tráfico actual y mal con diez veces más.
Cuándo delegar el trabajo
Un CDN es un reverse proxy que opera otra persona en muchas ubicaciones. Las funciones son las mismas — terminación TLS, caché, compresión, filtrado, enrutamiento — y las diferencias son las partes que eran difíciles: geografía, redundancia, y purga instantánea en todos los nodos.
La línea razonable es esta. Mantén tu propio proxy mientras esté haciendo trabajo local: enrutar entre servicios dentro de una máquina o un clúster, ejecutar reglas que dependen de estado interno. Delega el lado de cara al público cuando te encuentres resolviendo problemas de distribución — un segundo nodo para redundancia, purga de caché entre máquinas, visitantes en otro país esperando un viaje de ida y vuelta hasta el tuyo.
La mayoría de los equipos acaban con ambos, y ese es el arreglo sensato: un CDN de cara a internet, y un pequeño nginx dentro haciendo el enrutamiento en el que es bueno. Lo que no quieres es pasarte un trimestre reconstruyendo, mal, las partes que un CDN te da desde el primer día.
Preguntas frecuentes sobre el reverse proxy
¿Es un reverse proxy lo mismo que un balanceador de carga?
Se solapan. Un balanceador de carga distribuye peticiones entre varios backends; un reverse proxy además termina TLS, cachea, reescribe y filtra. nginx hace ambas cosas, por eso los términos se usan indistintamente. Si el único trabajo es repartir tráfico entre servidores idénticos, "balanceador de carga" es la palabra más precisa.
¿Un reverse proxy ralentiza mi sitio?
Añade un salto, medido en milisegundos de un solo dígito cuando el proxy está cerca del origen, y elimina mucho más que eso cuando la caché está activada — una respuesta cacheada nunca llega a viajar hasta tu aplicación. El caso en el que perjudica es un proxy en una región distinta tanto de tus usuarios como de tu origen.
¿Por qué mi aplicación ve la IP del proxy en lugar de la del visitante?
Porque faltan las cabeceras de reenvío, o porque la aplicación no está configurada para confiar en ellas. Hacen falta las dos mitades: el proxy envía X-Forwarded-For, y hay que decirle al framework qué direcciones de proxy puede creerse. Confiar en la cabecera venga de donde venga le permite a un cliente falsificar su propia IP.
¿Puedo cachear páginas con sesión iniciada?
No por defecto, y normalmente no deberías querer hacerlo — así es como un usuario acaba viendo el panel de otro usuario. El patrón normal es saltarse la caché cuando hay una cookie de sesión presente y cachear agresivamente para los visitantes anónimos, que son el grueso del tráfico en la mayoría de los sitios.
¿Cómo purgo una caché de proxy de nginx?
El nginx de código abierto no tiene ninguna directiva de purga. Las opciones son borrar los archivos correspondientes del directorio de caché en cada nodo, usar el módulo de purga de terceros, o esperar al TTL. La purga bajo demanda en todas las máquinas es una de las cosas concretas que obtienes al trasladar la capa de caché a un CDN.