Perché un errore del proxy SockJS può comparire solo dopo il fallback
Il percorso WebSocket e il fallback XHR possono usare client HTTP diversi. Identifica il trasporto che non funziona prima di modificarne le impostazioni proxy.
Quando WebSocket funziona su una rete ma SockJS non funziona su un'altra, la seconda rete potrebbe aver attivato il fallback XHR. Ciò può cambiare l'implementazione HTTP che esegue le richieste — e quindi la configurazione proxy utilizzata.
Individua il primo URL non riuscito e il trasporto scelto. SockJS può effettuare una richiesta HTTP informativa prima di scegliere un trasporto; l'handshake WebSocket e le successive richieste di polling sono operazioni separate. Una configurazione dell'handshake funzionante non dimostra il percorso usato per ciascuna di esse.
Nel client Java di Spring, RestTemplateXhrTransport accetta un RestTemplate configurato. La sua factory di richieste e il client HTTP sottostante forniscono il percorso proxy e l'autenticazione supportati dal fallback. Per Spring 6 con HttpClient 5, configura la factory di richieste effettiva di quel RestTemplate. Se tale implementazione usa componenti Apache HTTP, la sua generazione deve corrispondere all'integrazione.
Il client WebSocket ha le proprie impostazioni di connessione documentate. Le proprietà proxy della JVM influiscono su un percorso solo se il suo client concreto le legge. Confronta gli ambienti funzionante e non funzionante per trasporto, implementazione del client, proxy scelto e primo errore. Se fallisce solo XHR, segui il suo percorso, la sua autenticazione e le sue risposte di lunga durata invece di modificare ripetutamente le impostazioni del client WebSocket funzionante.