Por qué un fallo del proxy SockJS puede aparecer solo tras el fallback
La ruta WebSocket y el fallback XHR pueden usar clientes HTTP distintos. Identifica el transporte que falla antes de cambiar su configuración de proxy.
Cuando WebSocket funciona en una red pero SockJS falla en otra, es posible que la segunda red haya activado el fallback XHR. Eso puede cambiar la implementación HTTP que realiza las solicitudes —y, por tanto, la configuración de proxy utilizada.
Localiza la primera URL fallida y el transporte que eligió. SockJS puede hacer una solicitud HTTP informativa antes de elegir un transporte; el handshake de WebSocket y las solicitudes de sondeo posteriores son operaciones distintas. Una configuración de handshake que funciona no demuestra la ruta usada para cada una de ellas.
En el cliente Java de Spring, RestTemplateXhrTransport acepta un RestTemplate configurado. Su fábrica de solicitudes y el cliente HTTP subyacente proporcionan la ruta de proxy y la autenticación admitidas por el fallback. Para Spring 6 con HttpClient 5, configura la fábrica de solicitudes real de ese RestTemplate. Si esa implementación usa componentes Apache HTTP, su generación debe coincidir con la integración.
El cliente WebSocket tiene su propia configuración de conexión documentada. Las propiedades de proxy de la JVM afectan a una ruta solo si su cliente concreto las lee. Compara los entornos que funcionan y los que fallan por transporte, implementación del cliente, proxy elegido y primer error. Si solo falla XHR, sigue su ruta, su autenticación y sus respuestas de larga duración en lugar de cambiar repetidamente la configuración del cliente WebSocket que funciona.