Per què una fallada del proxy SockJS pot aparèixer només després del fallback
La ruta WebSocket i el fallback XHR poden fer servir clients HTTP diferents. Identifiqueu el transport que falla abans de canviar-ne la configuració de proxy.
Quan WebSocket funciona en una xarxa però SockJS falla en una altra, pot ser que la segona xarxa hagi activat el fallback XHR. Això pot canviar la implementació HTTP que fa les peticions — i, per tant, la configuració de proxy que s'utilitza.
Localitzeu la primera URL fallida i el transport que ha triat. SockJS pot fer una petició HTTP informativa abans de triar un transport; l'apretada de mans WebSocket i les peticions d'enquestació posteriors són operacions separades. Una configuració d'apretada de mans que funciona no demostra la ruta utilitzada per a cadascuna.
Al client Java de Spring, RestTemplateXhrTransport accepta un RestTemplate configurat. La seva fàbrica de peticions i el client HTTP subjacent proporcionen la ruta de proxy i l'autenticació admeses pel fallback. Per a Spring 6 amb HttpClient 5, configureu la fàbrica de peticions real d'aquest RestTemplate. Si aquesta implementació fa servir components Apache HTTP, la seva generació ha de coincidir amb la integració.
El client WebSocket té la seva pròpia configuració de connexió documentada. Les propietats de proxy de la JVM afecten una ruta només si el seu client concret les llegeix. Compareu els entorns que funcionen i els que fallen per transport, implementació del client, proxy triat i primera errada. Si només falla XHR, seguiu-ne la ruta, l'autenticació i les respostes de llarga durada en lloc de canviar repetidament la configuració del client WebSocket que funciona.