Dlaczego błąd proxy SockJS może pojawić się dopiero po przejściu na ścieżkę zapasową
Ścieżka WebSocket i ścieżka zapasowa XHR mogą używać różnych klientów HTTP. Zanim zmienisz ustawienia proxy, ustal, który transport zawodzi.
Gdy WebSocket działa w jednej sieci, ale SockJS zawodzi w innej, druga sieć mogła uruchomić ścieżkę zapasową XHR. To może zmienić implementację HTTP wykonującą żądania — a więc także używaną konfigurację proxy.
Znajdź pierwszy nieudany URL i wybrany przez niego transport. SockJS może wysłać informacyjne żądanie HTTP przed wybraniem transportu; uzgadnianie WebSocket i kolejne żądania odpytywania to osobne operacje. Działająca konfiguracja uzgadniania nie dowodzi ścieżki używanej dla każdej z nich.
W kliencie Java Springa RestTemplateXhrTransport przyjmuje skonfigurowany RestTemplate. Jego fabryka żądań i bazowy klient HTTP zapewniają obsługiwaną przez ścieżkę zapasową trasę proxy i uwierzytelnianie. W przypadku Spring 6 z HttpClient 5 skonfiguruj rzeczywistą fabrykę żądań tego RestTemplate. Jeśli ta implementacja używa komponentów Apache HTTP, jej generacja musi odpowiadać integracji.
Klient WebSocket ma własne udokumentowane ustawienia połączenia. Właściwości proxy JVM wpływają na ścieżkę tylko wtedy, gdy konkretny klient je odczytuje. Porównaj środowisko działające i zawodzące według transportu, implementacji klienta, wybranego proxy i pierwszego błędu. Jeśli zawodzi tylko XHR, podążaj jego trasą, uwierzytelnianiem i długotrwałymi odpowiedziami, zamiast wielokrotnie zmieniać ustawienia działającego klienta WebSocket.