Warum ein SockJS-Proxyfehler erst nach dem Fallback auftreten kann
Der WebSocket-Pfad und ein XHR-Fallback können unterschiedliche HTTP-Clients verwenden. Ermitteln Sie den fehlschlagenden Transport, bevor Sie dessen Proxy-Einstellungen ändern.
Wenn WebSocket in einem Netzwerk funktioniert, SockJS aber in einem anderen fehlschlägt, hat das zweite Netzwerk möglicherweise den XHR-Fallback ausgelöst. Das kann die HTTP-Implementierung ändern, die die Anfragen ausführt — und damit die verwendete Proxy-Konfiguration.
Ermitteln Sie die erste fehlgeschlagene URL und den dafür gewählten Transport. SockJS kann eine HTTP-Informationsanfrage senden, bevor es einen Transport wählt; der WebSocket-Handshake und nachfolgende Polling-Anfragen sind getrennte Vorgänge. Eine funktionierende Handshake-Konfiguration belegt nicht den für jeden von ihnen verwendeten Pfad.
Im Java-Client von Spring nimmt RestTemplateXhrTransport ein konfiguriertes RestTemplate entgegen. Dessen Request-Factory und zugrunde liegender HTTP-Client liefern die vom Fallback unterstützte Proxy-Route und Authentifizierung. Für Spring 6 mit HttpClient 5 konfigurieren Sie die tatsächliche Request-Factory dieses RestTemplate. Verwendet diese Implementierung Apache-HTTP-Komponenten, muss deren Generation zur Integration passen.
Der WebSocket-Client hat eigene dokumentierte Verbindungseinstellungen. JVM-Proxy-Eigenschaften wirken sich nur dann auf einen Pfad aus, wenn sein konkreter Client sie liest. Vergleichen Sie die funktionierende und die fehlschlagende Umgebung nach Transport, Client-Implementierung, gewähltem Proxy und erstem Fehler. Schlägt nur XHR fehl, folgen Sie dessen Route, Authentifizierung und lang gehaltenen Antworten, statt wiederholt die Einstellungen des funktionierenden WebSocket-Clients zu ändern.