Por que un fallo do proxy SockJS pode aparecer só despois do fallback
A ruta WebSocket e o fallback XHR poden usar clientes HTTP distintos. Identifica o transporte que falla antes de cambiar a súa configuración de proxy.
Cando WebSocket funciona nunha rede pero SockJS falla noutra, pode que a segunda rede activase o fallback XHR. Iso pode cambiar a implementación HTTP que fai as solicitudes — e, polo tanto, a configuración de proxy utilizada.
Localiza o primeiro URL fallido e o transporte que escolleu. SockJS pode facer unha solicitude HTTP informativa antes de escollecer un transporte; o handshake de WebSocket e as solicitudes de sondeo posteriores son operacións separadas. Unha configuración de handshake que funciona non demostra a ruta usada para cada unha delas.
No cliente Java de Spring, RestTemplateXhrTransport acepta un RestTemplate configurado. A súa fábrica de solicitudes e o cliente HTTP subxacente fornecen a ruta de proxy e a autenticación admitidas polo fallback. Para Spring 6 con HttpClient 5, configura a fábrica de solicitudes real dese RestTemplate. Se esa implementación usa compoñentes Apache HTTP, a súa xeración debe coincidir coa integración.
O cliente WebSocket ten a súa propia configuración de conexión documentada. As propiedades de proxy da JVM afectan unha ruta só se o seu cliente concreto as le. Compara os ambientes que funcionan e os que fallan por transporte, implementación do cliente, proxy escollido e primeiro erro. Se só falla XHR, segue a súa ruta, a súa autenticación e as súas respostas de longa duración en lugar de cambiar repetidamente a configuración do cliente WebSocket que funciona.