¿Qué es un proxy inverso? Una guía práctica de DNS y web

Un proxy inverso es un servidor que recibe solicitudes en nombre de uno o más servidores de backend y las reenvía al destino adecuado. Desde la perspectiva del visitante, el proxy suele ser el punto final público; el navegador no se conecta directamente al servidor de la aplicación. Un proxy inverso puede terminar HTTPS, enrutar solicitudes por nombre de host o ruta, equilibrar el tráfico, almacenar respuestas en caché, comprimir contenido y aplicar controles de seguridad. El DNS suele apuntar un nombre de host público al proxy o a una dirección gestionada por un proveedor que está delante de él. El proxy usa entonces su propia configuración de enrutamiento para llegar a la aplicación en origen.

Proxy inverso frente a proxy directo

Un proxy directo actúa en nombre de los clientes: el cliente envía solicitudes a través de él para llegar a servicios externos, a menudo por razones de política, privacidad o acceso a la red. Un proxy inverso actúa en nombre de los servidores: los clientes externos se conectan a él y este reenvía las solicitudes a los servicios de backend. Por tanto, la palabra «proxy» por sí sola es ambigua. En la arquitectura de un sitio web, un proxy inverso suele presentar el punto final público del servicio y ocultar los detalles del grupo de backend. Puede enrutar varios dominios en la misma infraestructura y dirigir rutas distintas a aplicaciones distintas manteniendo un único punto de conexión público.

El DNS y un proxy inverso resuelven partes distintas de la conexión. El DNS asigna un nombre de host a una dirección pública o a un alias. Una vez que el cliente se conecta, el proxy usa la información de host de HTTP, la indicación de nombre de servidor de TLS (SNI) y su propia configuración para elegir el servicio correcto. Esto explica por qué solicitar una IP sin más puede mostrar una página por defecto o una advertencia de certificado aunque el dominio funcione: la solicitud puede no incluir el contexto de nombre de host esperado. Asimismo, cambiar el DNS no crea automáticamente una ruta de proxy equivalente ni aprovisiona un certificado. Ambas capas deben coincidir en el nombre de host y el destino.

Formas habituales en que el proxy interviene en una caída

Un dominio puede resolverse correctamente mientras el proxy inverso apunta a un upstream caído, usa el puerto equivocado o rechaza un nombre de host que no se ha configurado para servir. Pueden producirse fallos de TLS si el borde carece de un certificado válido o si un upstream cifrado está mal configurado. Un proxy también puede devolver un tiempo de espera agotado cuando un backend está sobrecargado o es inaccesible. A la inversa, una aplicación sana puede parecer no disponible si el DNS dirige a los clientes a la dirección de proxy equivocada. Empieza anotando la respuesta DNS y luego inspecciona, por orden, la respuesta HTTP, la conexión TLS, los registros del proxy y el estado del backend.

• Confirma que el DNS apunta al punto final público del proxy previsto.
• Verifica que el proxy tiene una regla de host y un upstream sano para el dominio.
• Comprueba la configuración TLS tanto del borde como del upstream cuando falle HTTPS.
• Usa los registros del proxy para distinguir los errores de enrutamiento de los errores de la aplicación.
• Evita suponer que una consulta de IP revela el servidor de backend.

Límites de seguridad y operativos

Un proxy inverso puede reducir la exposición directa de los servicios de backend, pero no es automáticamente un límite de seguridad a menos que se configuren y mantengan reglas de acceso. El origen debería aceptar tráfico solo a través de las rutas previstas cuando la arquitectura lo permita. Las interfaces de administración no deben colocarse en rutas públicas sin la autenticación adecuada. Mantén el software del proxy parcheado, restringe el acceso de gestión y valida las cabeceras reenviadas, porque el proxy se convierte en un intérprete de confianza de la información del cliente y del upstream. Documenta qué equipo es responsable del DNS, de las reglas del proxy, de los certificados y del backend para que la respuesta ante incidentes no se bloquee mientras cada grupo supone que otra capa es la responsable.

Para la relación entre el borde público y el backend, lee qué es un servidor de origen. Para las redes de proxy globales, consulta cómo usan el DNS las CDN. Una comprobación pública de dominio a IP puede confirmar la dirección que presenta el DNS, pero la ruta del proxy inverso y el estado de la aplicación requieren sus propias comprobaciones operativas. Mantener separadas esas responsabilidades hace que la depuración sea más precisa y evita que un resultado de dirección se confunda con un diagnóstico completo de la infraestructura.

Haz explícita la propiedad de las reglas del proxy

Un proxy inverso está en un punto crítico de traspaso, así que anota quién es responsable del DNS, del enrutamiento de hosts, de los certificados, de las definiciones de upstream y de las políticas de acceso. Un cambio puede ser correcto en una capa y aun así fallar porque no se actualizó otra: el DNS apunta al proxy, pero este carece de un host virtual; la ruta existe, pero el certificado es de otro nombre; o el upstream está sano, pero un cortafuegos bloquea la subred del proxy. Mantén un diagrama sencillo del recorrido y una solicitud conocida y correcta para cada nombre de host de producción. Durante una incidencia, compara la respuesta DNS pública, el registro de acceso del proxy, el estado del upstream y el registro de la aplicación usando la misma marca de tiempo de la solicitud o el mismo ID de correlación.