Redirecciones que degradan la conexión detrás de un proxy

Lo que ocurre paso a paso

1. El navegador pide una ruta sin barra final, por HTTPS, al dominio público.
2. El proxy termina el cifrado y reenvía en claro al contenedor, con su nombre interno como destino.
3. El contenedor decide redirigir agregando la barra y construye una dirección absoluta con el esquema y el host que él ve: sin cifrar, con el nombre interno.
4. El navegador recibe esa redirección e intenta seguirla. Falla, o degrada la conexión.

Dónde más se manifiesta

1. Enlaces en correos generados por la aplicación, que apuntan al nombre interno y no funcionan fuera del servidor.
2. Redirecciones después de autenticarse, que mandan a una dirección sin cifrar y pierden la sesión en el camino.
3. Direcciones canónicas y mapas del sitio generados con el host equivocado, que afectan al posicionamiento.
4. Cookies marcadas como seguras que la aplicación no manda porque cree estar en una conexión sin cifrar.

Qué comprobar

1. Pedir sin seguir redirecciones y leer el código y el destino. Ahí se ve si apunta al dominio público o al nombre interno.
2. Probar con y sin barra final en cada ruta que corresponda a una sección.
3. Comprobar el esquema del destino: tiene que ser el mismo por el que se entró.
4. Revisar los enlaces de los correos que genera el sistema, que es donde el error sobrevive más tiempo sin que nadie lo note.