SockJS プロキシ障害がフォールバック後にだけ現れる理由
WebSocket の経路と XHR フォールバックでは、異なる HTTP クライアントが使われる場合があります。プロキシ設定を変更する前に、失敗しているトランスポートを特定してください。
あるネットワークでは WebSocket が動作するのに別のネットワークでは SockJS が失敗する場合、2 番目のネットワークが XHR フォールバックを起動した可能性があります。これにより、リクエストを行う HTTP 実装が変わり、ひいては使用されるプロキシ設定も変わります。
最初に失敗した URL と、そこで選択されたトランスポートを特定します。SockJS はトランスポートを選ぶ前に HTTP 情報リクエストを行うことがあります。WebSocket のハンドシェイクとその後のポーリングリクエストは別の操作です。ハンドシェイクの設定が機能していても、それぞれに使われる経路が同じであることは証明されません。
Spring の Java クライアントでは、RestTemplateXhrTransport が設定済みの RestTemplate を受け取ります。そのリクエストファクトリと基盤の HTTP クライアントが、フォールバックがサポートするプロキシ経路と認証を提供します。Spring 6 と HttpClient 5 では、その RestTemplate の実際のリクエストファクトリを設定してください。その実装が Apache HTTP コンポーネントを使う場合、世代を統合環境に合わせる必要があります。
WebSocket クライアントには独自の文書化された接続設定があります。JVM のプロキシプロパティは、その具象クライアントが読む場合にだけ経路に影響します。動作する環境と失敗する環境を、トランスポート、クライアント実装、選択されたプロキシ、最初のエラーで比較してください。XHR だけが失敗する場合は、動作している WebSocket クライアントの設定を繰り返し変えるのではなく、その経路、認証、長時間保持される応答を追跡してください。