Why a SockJS Proxy Failure Can Appear Only After Fallback
The WebSocket path and an XHR fallback may use different HTTP clients. Identify the failing transport before changing its proxy settings.
When WebSocket works on one network but SockJS fails on another, the second network may have triggered XHR fallback. That can change the HTTP implementation making the requests—and therefore the proxy configuration being used.
Locate the first failed URL and its selected transport. SockJS can make an HTTP information request before choosing a transport; the WebSocket handshake and subsequent polling requests are separate operations. A working handshake configuration does not establish the route used for each of them.
In Spring's Java client, RestTemplateXhrTransport accepts a configured RestTemplate. Its request factory and underlying HTTP client supply the fallback's supported proxy route and authentication. For Spring 6 with HttpClient 5, configure that RestTemplate’s actual request factory. If that implementation uses Apache HTTP components, its generation must match the integration.
The WebSocket client has its own documented connection settings. JVM proxy properties affect a path only if its concrete client reads them. Compare the working and failing environments by transport, client implementation, selected proxy and first error. If only XHR fails, follow its route, authentication and long-held responses instead of repeatedly changing the working WebSocket client's settings.