Por que uma falha do proxy SockJS pode aparecer só depois do fallback
O caminho WebSocket e o fallback XHR podem usar clientes HTTP diferentes. Identifique o transporte que falha antes de alterar as configurações de proxy dele.
Quando o WebSocket funciona em uma rede mas o SockJS falha em outra, a segunda rede pode ter acionado o fallback XHR. Isso pode mudar a implementação HTTP que faz as solicitações — e, portanto, a configuração de proxy usada.
Localize a primeira URL que falhou e o transporte escolhido por ela. O SockJS pode fazer uma solicitação HTTP informativa antes de escolher um transporte; o handshake WebSocket e as solicitações de sondagem seguintes são operações separadas. Uma configuração de handshake que funciona não comprova o caminho usado para cada uma delas.
No cliente Java do Spring, RestTemplateXhrTransport aceita um RestTemplate configurado. Sua fábrica de solicitações e o cliente HTTP subjacente fornecem a rota de proxy e a autenticação suportadas pelo fallback. Para Spring 6 com HttpClient 5, configure a fábrica de solicitações real desse RestTemplate. Se essa implementação usa componentes Apache HTTP, sua geração deve corresponder à integração.
O cliente WebSocket tem suas próprias configurações de conexão documentadas. As propriedades de proxy da JVM afetam um caminho somente se o cliente concreto dele as ler. Compare os ambientes que funcionam e os que falham por transporte, implementação do cliente, proxy escolhido e primeiro erro. Se apenas o XHR falha, siga sua rota, autenticação e respostas de longa duração em vez de alterar repetidamente as configurações do cliente WebSocket que funciona.