Pourquoi un échec de proxy SockJS peut n'apparaître qu'après le repli
Le chemin WebSocket et un repli XHR peuvent utiliser des clients HTTP différents. Identifiez le transport défaillant avant de modifier ses paramètres de proxy.
Lorsque WebSocket fonctionne sur un réseau mais que SockJS échoue sur un autre, le second réseau a peut-être déclenché le repli XHR. Cela peut changer l'implémentation HTTP qui émet les requêtes — et donc la configuration de proxy utilisée.
Localisez la première URL en échec et le transport qu'elle a choisi. SockJS peut effectuer une requête HTTP d'information avant de choisir un transport ; la poignée de main WebSocket et les requêtes d'interrogation suivantes sont des opérations distinctes. Une configuration de poignée de main fonctionnelle ne prouve pas la route utilisée pour chacune d'elles.
Dans le client Java de Spring, RestTemplateXhrTransport accepte un RestTemplate configuré. Sa fabrique de requêtes et le client HTTP sous-jacent fournissent la route de proxy et l'authentification prises en charge par le repli. Pour Spring 6 avec HttpClient 5, configurez la fabrique de requêtes réelle de ce RestTemplate. Si cette implémentation utilise des composants Apache HTTP, sa génération doit correspondre à l'intégration.
Le client WebSocket a ses propres paramètres de connexion documentés. Les propriétés de proxy de la JVM n'affectent une route que si son client concret les lit. Comparez les environnements fonctionnel et défaillant selon le transport, l'implémentation du client, le proxy choisi et la première erreur. Si seul XHR échoue, suivez sa route, son authentification et ses réponses de longue durée au lieu de modifier à répétition les paramètres du client WebSocket qui fonctionne.