Proč se selhání proxy SockJS může projevit až po přepnutí na záložní cestu
Cesta WebSocket a záložní cesta přes XHR mohou používat různé HTTP klienty. Než změníte nastavení proxy, zjistěte, který přenos selhává.
Když WebSocket funguje v jedné síti, ale SockJS v jiné selhává, mohla druhá síť aktivovat záložní cestu přes XHR. To může změnit implementaci HTTP, která požadavky provádí — a tím i používanou konfiguraci proxy.
Najděte první neúspěšnou URL a přenos, který zvolila. SockJS může před volbou přenosu provést informační HTTP požadavek; handshake WebSocket a následné dotazovací požadavky jsou samostatné operace. Fungující konfigurace handshake neprokazuje cestu použitou pro každou z nich.
V Java klientovi Springu přijímá RestTemplateXhrTransport nakonfigurovaný RestTemplate. Jeho továrna požadavků a podkladový HTTP klient zajišťují záložní cestou podporovanou trasu proxy a ověřování. Pro Spring 6 s HttpClient 5 nakonfigurujte skutečnou továrnu požadavků tohoto RestTemplate. Pokud tato implementace používá komponenty Apache HTTP, její generace musí odpovídat integraci.
Klient WebSocket má vlastní dokumentované nastavení připojení. Vlastnosti proxy JVM ovlivňují cestu jen tehdy, když je jeho konkrétní klient čte. Porovnejte funkční a selhávající prostředí podle přenosu, implementace klienta, zvolené proxy a první chyby. Pokud selhává jen XHR, sledujte jeho trasu, ověřování a dlouho držené odpovědi, místo abyste opakovaně měnili nastavení funkčního klienta WebSocket.