¿Funcionará esta aplicación autoalojada detrás de un proxy inverso? Lista de verificación de compatibilidad
Que una aplicación Docker sea accesible en un puerto no demuestra que vaya a comportarse correctamente en un dominio HTTPS público. Utiliza esta lista de verificación basada en evidencias para comprobar las URL canónicas, las cabeceras reenviadas, las cookies, las cargas, las conexiones en tiempo real y las devoluciones de llamada antes del lanzamiento.
Por qué la compatibilidad con proxy inverso es un criterio para elegir una aplicación
Un proxy inverso se sitúa entre un visitante y una aplicación. Puede dirigir un dominio público a un servicio interno y terminar TLS, por lo que la aplicación no tiene necesariamente que escuchar directamente en Internet. Este patrón de infraestructura es habitual, pero no garantiza que todas las aplicaciones autoalojadas funcionen correctamente detrás de él.
La cuestión importante no es simplemente si el contenedor se inicia o si su puerto interno responde a una solicitud. La aplicación debe comprender la dirección pública que ven los usuarios, el esquema HTTPS original y, cuando corresponda, la dirección del cliente de origen. También debe funcionar con los límites y el comportamiento de conexión del proxy para las funciones que tu equipo pretende utilizar.
Considera la compatibilidad con proxy inverso como un criterio de selección y aceptación. Antes de comprometerte con una aplicación, busca su documentación oficial de despliegue y procura encontrar indicaciones explícitas sobre ajustes de URL externa, proxies inversos, proxies de confianza, cabeceras reenviadas, cargas, conexiones en tiempo real y autenticación externa. Cuando la documentación no mencione algo, registra esa incertidumbre y prueba el flujo de trabajo exacto que necesitas.
- No equipares «se ejecuta en Docker» con «está lista para un dominio HTTPS público».
- Da preferencia a una aplicación con configuración documentada para su URL externa o canónica.
- Exige evidencias de un despliegue de prueba, no solo una comprobación de estado correcta del contenedor.
- Para las pruebas de aceptación, utiliza únicamente el dominio público y las rutas normales de los usuarios; un puerto interno directo puede ocultar fallos relacionados con el proxy.
Traza la ruta de la solicitud antes de cambiar ajustes
Anota la ruta completa que sigue una solicitud normal: navegador, nombre DNS público, proxy inverso, aplicación y cualquier servicio de apoyo, como una base de datos, un servicio de correo, un proveedor de identidad, un servicio de almacenamiento de objetos o un destino de webhook. Esto transforma un problema impreciso de proxy en un conjunto de límites que se pueden comprobar.
El proxy recibe la solicitud pública y envía una solicitud ascendente a la aplicación. En ese proceso, es posible que la aplicación deje de ver los detalles de conexión originales, salvo que esté diseñada para usar las cabeceras de solicitud proporcionadas por el proxy. Traefik, por ejemplo, añade automáticamente X-Forwarded-For, X-Real-Ip, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto y X-Forwarded-Server al actuar como proxy de las solicitudes.
Documenta también qué puertos son públicos de forma intencionada. Docker indica que los puertos de los contenedores no son accesibles externamente de forma predeterminada; publicar un puerto lo hace disponible fuera del host. Cuando la aplicación ascendente y el proxy comparten un host, publicar solo en localhost puede restringir el acceso al host de Docker en lugar de exponer remotamente el servicio ascendente.
- Nombre de host o nombres de host públicos, incluido cualquier dominio alternativo.
- Esquema externo esperado: normalmente HTTPS para un despliegue público.
- Puntos de entrada del proxy para HTTP y HTTPS.
- Nombre de host y puerto del servicio ascendente interno.
- La ubicación del límite TLS.
- Cualquier proxy adicional, equilibrador de carga, CDN, VPN o túnel delante del proxy inverso.
- Qué puertos ascendentes deben seguir siendo privados y cuáles deben ser accesibles públicamente.
Comprobación 1: Configura y demuestra la URL externa canónica
Muchas aplicaciones necesitan un ajuste explícito para la dirección mediante la cual los usuarios acceden a ellas. La documentación oficial puede denominarlo URL base, URL del sitio, URL pública, URL externa, URL del servidor, URL raíz o algo similar. Configúralo con la dirección HTTPS pública definitiva, incluido cualquier prefijo de ruta necesario, en lugar de un nombre interno de contenedor, una dirección IP privada o una URL HTTP.
Este ajuste influye habitualmente en los enlaces de la interfaz, los enlaces enviados por correo electrónico, los destinos de restablecimiento de contraseña, las cargas útiles de webhook y la construcción de devoluciones de llamada OAuth. Una discrepancia aparentemente menor puede provocar redirecciones a un nombre de host interno, enlaces HTTP desde un sitio HTTPS o un flujo de inicio de sesión que vuelve a la ubicación equivocada.
Utiliza el nombre de host definitivo antes de probar integraciones. Cambiar una URL pública más adelante puede requerir cambios en la aplicación, el proveedor de identidad, los proveedores de webhook y los marcadores. Si la documentación oficial no explica el ajuste ni indica si se admite una subruta, no supongas que es seguro desplegarla bajo una ruta como ejemplo.com/app.
- Configura la URL canónica documentada con la URL HTTPS pública exacta.
- Abre páginas desde una sesión limpia del navegador e inspecciona las redirecciones.
- Envía un correo de restablecimiento de contraseña o de invitación, si la aplicación lo admite, y comprueba que el enlace utiliza la dirección pública.
- Crea un enlace para compartir o un recurso público, cuando corresponda, y ábrelo desde una sesión distinta.
- Prueba tanto el nombre de host sin subdominio como cualquier nombre de host alternativo previsto y, después, elige una dirección canónica.
Comprobación 2: Establece el límite de confianza de proxy y cabeceras reenviadas
Un proxy inverso necesita una forma de transmitir información sobre la solicitud que recibió. RFC 7239 define la cabecera estandarizada Forwarded para información modificada o perdida al pasar por proxies, incluida la dirección de origen, el host y el protocolo. En la práctica, las aplicaciones también pueden utilizar cabeceras X-Forwarded-*. La documentación de la propia aplicación debe indicarte qué cabeceras lee y cómo declarar los proxies de confianza.
La confianza es la parte crítica. Un cliente no debe poder proporcionar una cabecera que la aplicación trate como identidad, host o esquema autorizados del cliente. RFC 7239 señala que las conclusiones basadas en datos reenviados dependen de confiar en los proxies que los añadieron. Traefik puede configurarse para confiar en datos de cabeceras reenviadas solo desde direcciones IP o CIDR especificados; su documentación desaconseja un modo de confianza permanente en producción.
Registra el rango de direcciones del proxy o el límite de red en el que la aplicación está configurada para confiar, si la aplicación dispone de dicho ajuste. Si hay más de una capa de proxy, determina qué capa elimina, sobrescribe o conserva las cabeceras reenviadas. Esta es una decisión de seguridad, no solo una comodidad de enrutamiento.
- Busca la documentación oficial de la aplicación sobre proxy inverso o proxies de confianza.
- Identifica si utiliza Forwarded, X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-For u otras cabeceras.
- Limita la confianza en las cabeceras al límite de proxy conocido siempre que el componente pertinente lo permita.
- Evita exponer directamente la aplicación ascendente junto con el proxy, salvo que exista una necesidad específica y controlada.
- Prueba una solicitud pública normal y confirma que la aplicación informa del esquema externo y el host previstos.
Comprobación 4: Verifica las direcciones IP de cliente y los eventos de auditoría
El manejo de direcciones de cliente importa cuando una aplicación muestra historial de inicios de sesión, escribe eventos de auditoría, aplica controles de acceso basados en IP, limita solicitudes o toma decisiones de seguridad a partir de una dirección de origen. Detrás de un proxy, el par inmediato que ve la aplicación puede ser el proxy en lugar del navegador de la persona.
Crea una prueba controlada con al menos dos redes de cliente distintas cuando sea práctico. Realiza una acción que deba registrarse y, después, examina la vista de auditoría o los registros de la aplicación conforme a su comportamiento documentado. El objetivo no es necesariamente exponer direcciones IP sin procesar a todos los administradores; consiste en garantizar que el contexto registrado por la aplicación y los controles basados en IP se comporten según lo que espera tu política.
Si la aplicación no documenta un manejo de direcciones de cliente compatible con proxy, evita suponer que sus registros de actividad identifican la red del usuario de origen. Conserva esta limitación en el registro de compatibilidad y evalúa si afecta a tus requisitos de seguridad, cumplimiento o soporte.
- Identifica las funciones que dependen de información sobre la dirección del cliente.
- Verifica si los registros de auditoría muestran la dirección del proxy o el contexto de cliente esperado.
- Prueba mediante la ruta pública cualquier función documentada de lista de permitidos por IP, lista de bloqueo, límite de velocidad o inicio de sesión sospechoso.
- Confirma que solo se acepta información de reenvío proporcionada por proxies de confianza.
- Decide quién puede acceder a la información de auditoría y durante cuánto tiempo debe conservarse.
Comprobación 5: Prueba las cargas, los límites de solicitudes y las solicitudes de larga duración
Las cargas grandes y las solicitudes lentas cruzan más de un límite. La aplicación puede imponer su propio límite de tamaño, mientras que el proxy puede imponer otro. Con el middleware de almacenamiento en búfer de Traefik, una solicitud mayor que maxRequestBodyBytes no se reenvía al servicio y recibe HTTP 413. Un valor de cero significa sin límite, pero que no haya límite no es automáticamente la decisión operativa adecuada.
El almacenamiento en búfer cambia el comportamiento además de los límites. Traefik documenta que, cuando su middleware de almacenamiento en búfer está asociado, lee el cuerpo completo de la solicitud antes de reenviarlo y puede almacenar en búfer cuerpos grandes en disco según el umbral configurado. Evalúa esto respecto al tipo y tamaño de archivos que tus usuarios realmente necesitan enviar, en lugar de utilizar un archivo de muestra diminuto como única prueba.
Las operaciones de larga duración necesitan sus propias evidencias. Prueba el flujo de trabajo visible para el usuario durante una duración esperada y observa si se producen fallos en la capa del navegador, del proxy y de la aplicación. Una carga pequeña correcta no demuestra que una importación, exportación u otra solicitud extensa de tamaño considerable vaya a funcionar de forma fiable.
- Define el archivo o solicitud normal más grande para el servicio, además de un caso de rechazo ligeramente mayor.
- Prueba mediante el dominio público un archivo cercano al límite que se pretende aceptar.
- Confirma dónde se rechaza una solicitud demasiado grande: en el proxy o en la aplicación, y si el mensaje es comprensible.
- Revisa las implicaciones de espacio en disco si los cuerpos de solicitud pueden almacenarse en búfer en disco.
- Prueba de extremo a extremo una acción de usuario de larga duración prevista.
- Registra juntos los límites configurados y observados para que cambios futuros no creen regresiones accidentales.
Comprobación 6: Verifica de extremo a extremo los requisitos de tiempo real y transmisión
No supongas que todas las aplicaciones usan WebSockets, eventos enviados por el servidor, respuestas en streaming o sondeo prolongado de la misma manera. Primero identifica la función real que necesita una conexión persistente o de transmisión: notificaciones en directo, edición colaborativa, acceso a terminal, actualizaciones de paneles, chat o una respuesta generada. Después, prueba esa función a través del dominio público definitivo.
Traefik documenta compatibilidad con WebSocket y WebSocket seguro mediante el enrutamiento HTTP normal, incluida la gestión automática de la actualización y la conservación de cabeceras WebSocket como Origin, Sec-WebSocket-Key y Sec-WebSocket-Version. Esta capacidad es útil, pero no elimina la necesidad de probar las propias comprobaciones de origen, autenticación, gestión de sesiones y comportamiento de reconexión de la aplicación.
Para funciones de transmisión y basadas en eventos que no utilizan WebSockets, consulta tanto la documentación de la aplicación como la del proxy sobre el comportamiento de conexión pertinente. Prueba con el mismo navegador, nombre de host, configuración HTTPS y permisos de usuario que tendrán los usuarios de producción.
- Identifica la función específica en tiempo real que necesita tu equipo.
- Pruébala después de iniciar sesión mediante el nombre de host HTTPS público.
- Mantén la función activa el tiempo suficiente para observar el comportamiento normal de reconexión o actualización.
- Prueba con más de una sesión de navegador si la función implica actualizaciones compartidas.
- Comprueba que los errores del navegador, los registros de la aplicación y los registros del proxy señalan la misma ruta de solicitud cuando se produce un fallo.
- No etiquetes una función como compatible hasta que haya superado su flujo de trabajo real de usuario.
Preguntas frecuentes
¿Puede cualquier aplicación Docker ejecutarse detrás de un proxy inverso?
No. La publicación de puertos de Docker puede hacer que un contenedor sea accesible, pero la aplicación también debe gestionar correctamente su URL pública, el esquema HTTPS, los detalles de solicitud reenviados, las sesiones y cualquier carga, devolución de llamada o conexión en tiempo real necesaria. Verifica estos comportamientos con la documentación oficial de la aplicación y un despliegue de prueba mediante la ruta pública.
¿Por qué una aplicación redirige a HTTP o a un nombre de host interno detrás de un proxy?
Esto suele indicar que su URL externa canónica falta o es incorrecta, o que no está utilizando correctamente información de proxies de confianza sobre el host original y el esquema HTTPS. Configura la URL pública documentada, establece el comportamiento de proxy de confianza cuando la aplicación lo admita y vuelve a probar mediante el dominio público definitivo.
¿Qué cabeceras reenviadas debo comprobar?
Comprueba las cabeceras documentadas por la aplicación. Traefik añade automáticamente X-Forwarded-For, X-Real-Ip, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto y X-Forwarded-Server al actuar como proxy. RFC 7239 también define la cabecera estandarizada Forwarded. Confía en esa información solo cuando proceda de límites de proxy conocidos.
¿Cómo debo probar la compatibilidad de cargas?
Carga, mediante la dirección HTTPS pública, un archivo realista cercano al límite de producción previsto y, después, prueba un archivo más grande que deba rechazarse. Identifica si el rechazo ocurre en la capa del proxy o de la aplicación. Si se usa el almacenamiento en búfer de Traefik, revisa su ajuste máximo de cuerpo de solicitud y su comportamiento de almacenamiento en búfer en disco.
¿Los WebSockets necesitan una configuración especial del proxy?
La respuesta depende del proxy y de la aplicación. Traefik documenta compatibilidad con WebSocket mediante el enrutamiento HTTP normal con gestión automática de actualización. Aun así, prueba la función exacta de la aplicación que necesita comunicación en tiempo real mediante el dominio definitivo, porque la autenticación, la validación de origen, el comportamiento de reconexión y los requisitos de la aplicación difieren.
¿Por qué se deben probar las URL de redirección OAuth después de elegir el dominio definitivo?
OAuth 2.0 exige que los extremos de redirección sean URI absolutas, y los servidores de autorización validan las URI de redirección proporcionadas frente a los valores registrados. En los flujos de código de autorización, la redirect_uri utilizada en la solicitud de token debe coincidir con la utilizada en la solicitud de autorización cuando se incluyó. Registra y prueba la URL exacta de devolución de llamada HTTPS pública.
Fuentes y lecturas adicionales
- Port publishing and mapping — Docker
- EntryPoints Documentation — Traefik Labs
- Headers Documentation — Traefik Labs
- Buffering Documentation — Traefik Labs
- WebSocket User Guide — Traefik Labs
- Challenge Types — Internet Security Research Group / Let’s Encrypt
- RFC 7239: Forwarded HTTP Extension — RFC Editor / IETF
- RFC 6749: The OAuth 2.0 Authorization Framework — RFC Editor / IETF