El proxy que mandaba la ruta equivocada

La secuencia

1. El documento se pide bajo el prefijo y llega bien.
2. Adentro hay referencias a recursos que empiezan con barra: sin el prefijo.
3. El navegador las pide desde la raíz del dominio.
4. Ahí no hay nada, o hay otra aplicación. Los recursos dan 404 y la página se ve sin estilos ni comportamiento.

Lo que hay que reenviar

1. El host original. Sin él, la aplicación arma enlaces con el nombre interno del contenedor.
2. El esquema original. El proxy habla en claro con la aplicación; si ésta no sabe que afuera es cifrado, genera redirecciones que degradan la conexión.
3. La IP del cliente. Lo que ve la aplicación es la IP del proxy: sin esta cabecera, todos los registros y los límites por origen apuntan al mismo lugar.
4. El prefijo, cuando el framework lo soporta, para que genere las rutas correctas por sí mismo.

Cuatro pasos, en orden

1. Pedirle directo al contenedor, desde el mismo servidor, la misma ruta que falla. Si responde bien, el problema es del proxy.
2. Mirar qué ruta recibe la aplicación, en sus propios registros. Ahí se ve si el prefijo se recortó o no.
3. Mirar la respuesta cruda, con encabezados, en vez de la página renderizada. Un 301 hacia un destino inesperado se ve ahí y no en el navegador.
4. Recién entonces, cambiar una sola cosa. Con dos cambios a la vez no se sabe cuál funcionó.