Varför ett SockJS-proxyfel kan visas först efter återfallet
WebSocket-vägen och en XHR-återfallsväg kan använda olika HTTP-klienter. Identifiera transporten som misslyckas innan du ändrar dess proxyinställningar.
När WebSocket fungerar i ett nätverk men SockJS misslyckas i ett annat kan det andra nätverket ha utlöst XHR-återfallet. Det kan ändra den HTTP-implementering som utför förfrågningarna — och därmed den proxykonfiguration som används.
Hitta den första misslyckade URL:en och den transport den valde. SockJS kan skicka en HTTP-informationsförfrågan innan den väljer en transport; WebSocket-handskakningen och efterföljande pollningsförfrågningar är separata operationer. En fungerande handskakningskonfiguration bevisar inte vägen som används för var och en av dem.
I Springs Java-klient accepterar RestTemplateXhrTransport en konfigurerad RestTemplate. Dess förfrågningsfabrik och underliggande HTTP-klient tillhandahåller den proxyväg och autentisering som återfallet stöder. För Spring 6 med HttpClient 5, konfigurera den RestTemplate:ens faktiska förfrågningsfabrik. Om den implementationen använder Apache HTTP-komponenter måste dess generation matcha integrationen.
WebSocket-klienten har sina egna dokumenterade anslutningsinställningar. JVM-proxyegenskaper påverkar en väg bara om dess konkreta klient läser dem. Jämför den fungerande och den misslyckade miljön efter transport, klientimplementation, vald proxy och första fel. Om bara XHR misslyckas, följ dess väg, autentisering och långvariga svar i stället för att upprepade gånger ändra inställningarna för den fungerande WebSocket-klienten.