Nginx, Reverse Proxy y DNS

Un poco de contexto

Cada vez que escribes una dirección en el navegador y aparece una página, en realidad ocurrieron varias cosas antes de que veas un solo píxel:

• Primero alguien tradujo ese nombre a una dirección numérica.
• Y en segundo lugar, otra entidad decidió qué máquina real iba a responder esa petición.

Estos dos organismos son, respectivamente, el DNS y, muy frecuentemente, un reverse proxy como Nginx.

Para una buena comprensión se espera que tengas nociones generales de informática, sin embargo, todo concepto de redes será abordado desde su base elemental o en su defecto con una vision general.

Donde nuestros principales focos de atención serán:

• DNS (Domain Name System): Es el sistema que traduce nombres legibles por humanos (Dominios como:ejemplo.com) en direcciones IP que las máquinas necesitan para conectarse entre sí. En esencia, una agenda de contactos en internet.

• Reverse proxy: Servidor intermediario que recibe el tráfico en nombre de uno o varios servidores reales, y decide internamente a cuál de ellos reenviar cada petición. El cliente nunca sabe qué hay detrás, solo ve al intermediario.

• Nginx: Software de código abierto más usado del mundo para cumplir ese rol de reverse proxy, además de poder funcionar como servidor web, balanceador de carga y servidor de caché.

Antes de entrar en detalle, conviene tener clara la idea general del recorrido completo, porque cada pieza solo tiene sentido en relación con las demás:

1. Sin DNS, tu navegador no sabría a qué dirección conectarse cuando escribes un nombre de dominio.
2. Sin un reverse proxy, cada servidor tendría que exponerse directamente a internet, sin nadie que reparta la carga, filtre el tráfico o maneje el cifrado de forma centralizada.
3. Nginx es la herramienta concreta que, en la práctica, casi siempre aparece resolviendo ese segundo problema.

Y adicionalmente los siguientes conceptos puede que te resuelvan algunas dudas o te sean de utilidad más adelante:

• Toda comunicación en internet ocurre entre un cliente y un servidor, donde el cliente pide, el servidor responde.

• Cada dispositivo en una red se identifica con una dirección IP unica, y cada servicio dentro de ese dispositivo se identifica además con un puerto (por ejemplo, 80 para HTTP y 443 para HTTPS).

• Los nombres de dominio existen solo para las personas, las máquinas siempre terminan hablando en términos de IP y puerto.

• Un mismo servidor físico o virtual puede atender múltiples dominios y aplicaciones a la vez, y es justamente el reverse proxy quien ordena ese tráfico.

• HTTP y HTTPS (versión cifrada de HTTP) son los protocolos con los que un navegador conversa con un servidor web.

Comencemos

Recorreremos los tres conceptos en el mismo orden en que ocurren cuando visitas un sitio web.

DNS: de un nombre a una dirección IP

Cuando escribes www.ejemplo.com, ese nombre no sirve por sí solo para conectar nada, es solo una etiqueta pensada para humanos. El proceso de convertir esa etiqueta en una IP real se llama resolución DNS, y ocurre en varios pasos:

Una de las mejores analogías es considerar el DNS como los contactos de tu teléfono:

Tú marcas un nombre → El teléfono busca el número real en la lista → El telefono llama por ti.

¡NUNCA NECESITAS MEMORIZAR EL NUMERO!

El DNS solo resuelve a qué IP conectarse, no sabe nada de lo que ocurre después de eso. Como cuántos servidores hay detrás, si hay balanceo de carga, ni cómo se cifra el tráfico. Todo eso es responsabilidad de lo que reciba la conexión en esa IP, y ahí es donde entra el reverse proxy.

El rol de un reverse proxy

Supón que una aplicación no corre en un solo servidor, sino en varios (para soportar más tráfico), y que además quieres manejar el cifrado HTTPS en un solo lugar, sin exponer directamente cada servidor interno a internet. Ahí aparece la necesidad de un intermediario.

Un proxy, en general, es cualquier intermediario entre dos partes que se comunican. Existen dos direcciones posibles:

• Forward proxy: Actúa en representación del cliente, comúnmente usado en redes corporativas para filtrar o controlar la salida a internet de los empleados. El servidor de destino ve al proxy, no al cliente real.

• Reverse proxy: Actúa en representación del servidor, aca el cliente cree hablar directamente con "el sitio", pero en realidad habla con el reverse proxy, que decide internamente a qué servidor real reenviar cada petición.

Para este ultimo, imaginemos el mesón de recepción de un edificio de oficinas. El visitante solo le dice al recepcionista qué necesita, y es el recepcionista quien conoce la distribución interna y dirige la solicitud al piso correcto.

El visitante nunca necesita saber ni se enteró en qué piso exacto está cada oficina. Un reverse proxy hace exactamente eso con el tráfico web. Entre las diferentes necesidades que cubren, resultan de nuestro interés las siguientes:

• Ocultar la infraestructura real: Los servidores internos nunca quedan expuestos directamente a internet.
• Balanceo de carga: Reparte el tráfico entrante entre varios servidores que hacen lo mismo, evitando que uno solo se sature.
• Terminación SSL/TLS: Centraliza el manejo de certificados y el cifrado HTTPS, hablando en HTTP simple con los servidores internos.
• Enrutamiento por dominio o ruta: Puede decidir, por ejemplo, que /api vaya a un servidor y /imagenes a otro, todo bajo la misma entrada pública.
• Caché de respuestas: Puede guardar copias de respuestas frecuentes para responder más rápido.
• Seguridad adicional: Puede limitar peticiones por segundo (rate limiting), filtrar tráfico malicioso o comprimir respuestas antes de que lleguen a los servidores reales.

Nginx: la herramienta que hace todo esto en la práctica

Nginx nació en 2004, creado por Igor Sysoev, con un objetivo muy concreto:

"Manejar una enorme cantidad de conexiones simultáneas usando pocos recursos de hardware"

Con el tiempo se volvió uno de los servidores web y reverse proxy más usados del mundo, junto con Apache. Nginx puede cumplir varios roles, muchas veces al mismo tiempo:

Es muy común que Nginx no sirva el contenido final él mismo, sino que actúe como puerta de entrada pública de una aplicación, mientras el trabajo real lo hace un backend (Node.js, Python, Java, etc.).

Configuración básica como reverse proxy

server {
    listen 80;
    server_name www.ejemplo.com;

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

Balanceo de carga entre varios servidores

upstream mi_aplicacion {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
}

server {
    listen 80;
    server_name www.ejemplo.com;

    location / {
        proxy_pass http://mi_aplicacion;
    }
}

El bloque upstream define un grupo de servidores backend equivalentes. Por defecto, Nginx reparte las peticiones entrantes entre ellos de forma rotativa (round robin), aunque existen otras estrategias (comoleast_conn y ip_hash) para casos más específicos.

Terminación SSL/TLS (HTTPS) en Nginx

server {
    listen 443 ssl;
    server_name www.ejemplo.com;

    ssl_certificate     /etc/nginx/ssl/ejemplo.crt;
    ssl_certificate_key /etc/nginx/ssl/ejemplo.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

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

Aquí Nginx recibe el tráfico cifrado en el puerto 443, se encarga él mismo de todo el trabajo de descifrado usando el certificado configurado, y habla en HTTP simple con el backend interno (que puede estar en una red privada, sin necesidad de manejar certificados). El segundo bloque server redirige cualquier visita por HTTP (puerto 80) hacia la versión HTTPS.

Comandos básicos para administrar Nginx

Antes de reiniciar Nginx en un servidor en producción, corre siempre sudo nginx -t primero. Si la configuración tiene un error de sintaxis, este comando te avisa sin cortar el servicio, si se reiniciara directamente con una configuración inválida sí puede dejar el sitio caído.

Ahora podemos comprender un recorrido completo

Juntando todo lo anterior, así es el camino real que sigue una visita a https://www.ejemplo.com:

1. DNS: El navegador consulta el sistema DNS y obtiene una IP pública, por ejemplo 203.0.113.50.
2. Conexión: El navegador abre una conexión HTTPS hacia esa IP, en el puerto 443.
3. Nginx recibe la conexión: En esa IP corre un Nginx configurado como reverse proxy, no la aplicación directamente.
4. Nginx decide: Descifra el HTTPS (terminación SSL), revisa la ruta solicitada, y decide a qué servidor interno reenviar la petición (posiblemente eligiendo entre varios, según alguna regla de balanceo de carga).
5. El backend responde: Genera la respuesta real (por ejemplo, consultando una base de datos) y se la entrega a Nginx.
6. Nginx responde al cliente: Entrega esa respuesta al navegador, como si él mismo la hubiese generado.

El usuario nunca se entera de que, detrás de una sola visita, hubo una resolución DNS y un reenvío interno hacia uno de varios servidores posibles.

Buenas Prácticas Y Errores Comunes

Al igual que con cualquier pieza de infraestructura expuesta a internet, hay hábitos que conviene mantener y otros que conviene evitar.

Buenas prácticas:

• Usa nginx -t antes de cada reload: Esto evita dejar el sitio caído por un error de sintaxis.

• Centraliza el TLS en el reverse proxy: Maneja los certificados en un solo lugar (Nginx) en vez de en cada servidor backend, es más simple de mantener y de renovar.

• No expongas los backends directamente a internet: Solo el reverse proxy debería tener un puerto público abierto, los servidores de aplicación deberían escuchar únicamente en la red interna.

• Configura TTL de DNS razonables: Un TTL muy alto retrasa la propagación de cambios (por ejemplo, si migras de servidor), uno demasiado bajo aumenta la carga sobre tus servidores DNS.

• Revisa los logs ante cualquier síntoma extraño: access.log y error.log casi siempre tienen la respuesta antes de que tengas que adivinar nada.

• Limita las peticiones por segundo en rutas sensibles: Como formularios de login, para mitigar ataques de fuerza bruta.

• Define explícitamente los encabezados X-Forwarded-*: Esto es de utilidad al reenviar tráfico, para que el backend sepa la IP real del cliente y el protocolo original (HTTP o HTTPS).

Errores comunes:

• Usar direcciones IP en vez de dominios "a mano" en el código de una aplicación: Si el servidor cambia de IP, hay que modificar código en vez de solo actualizar un registro DNS.

• Dejar puertos de bases de datos o servicios internos expuestos públicamente: Porque puede sonar más fácil, en vez de restringirlos a la red interna detrás del reverse proxy.

• Reiniciar Nginx sin validar la configuración primero: Esto puede arriesgar una caída completa del sitio por un error tipográfico.

• No renovar certificados a tiempo: Esto puede dejar el sitio con advertencias de seguridad o directamente inaccesible por HTTPS.

• Mezclar responsabilidades sin orden: Por ejemplo dejando que cada servidor backend maneje su propio certificado TLS en vez de centralizarlo en el reverse proxy.

Glosario Rápido

Extras

Documentación oficial y enlaces útiles para seguir profundizando.

Nginx

• Documentación oficial de Nginx: https://nginx.org/en/docs
• Guía de Nginx como reverse proxy (nginx.com): https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy

DNS

• IANA (autoridad de números asignados de internet): https://www.iana.org
• Cloudflare, ¿Qué es el DNS?: https://www.cloudflare.com/learning/dns/what-is-dns
• DNS público de Google (8.8.8.8): https://developers.google.com/speed/public-dns
• DNS público de Cloudflare (1.1.1.1): https://1.1.1.1

Certificados y HTTPS

• Let's Encrypt (certificados TLS gratuitos): https://letsencrypt.org
• Certbot (automatiza la emisión y renovación de certificados): https://certbot.eff.org

Referencias

• Nginx, Inc. (n.d.). NGINX Documentation. https://nginx.org/en/docs
• Internet Assigned Numbers Authority. (n.d.). IANA. https://www.iana.org
• Cloudflare. (n.d.). What is DNS?. https://www.cloudflare.com/learning/dns/what-is-dns
• Internet Engineering Task Force. (1987). RFC 1035 - Domain Names, Implementation and Specification. https://www.ietf.org/rfc/rfc1035.txt
• Electronic Frontier Foundation. (n.d.). Certbot. https://certbot.eff.org