Почему сбой прокси SockJS может проявляться только после перехода на резервный путь
Путь WebSocket и резервный путь XHR могут использовать разные HTTP-клиенты. Определите, какой транспорт сбоит, прежде чем менять его настройки прокси.
Когда WebSocket работает в одной сети, а SockJS сбоит в другой, вторая сеть могла включить резервный путь XHR. Это может изменить реализацию HTTP, выполняющую запросы, — и, следовательно, используемую конфигурацию прокси.
Найдите первый сбойный URL и выбранный им транспорт. SockJS может отправить информационный HTTP-запрос перед выбором транспорта; рукопожатие WebSocket и последующие запросы опроса — отдельные операции. Работающая конфигурация рукопожатия не доказывает путь, используемый для каждого из них.
В Java-клиенте Spring RestTemplateXhrTransport принимает настроенный RestTemplate. Его фабрика запросов и базовый HTTP-клиент обеспечивают поддерживаемый резервным путём маршрут прокси и аутентификацию. Для Spring 6 с HttpClient 5 настройте фактическую фабрику запросов этого RestTemplate. Если эта реализация использует компоненты Apache HTTP, её поколение должно соответствовать интеграции.
У клиента WebSocket есть собственные документированные параметры подключения. Свойства прокси JVM влияют на путь только тогда, когда его конкретный клиент их читает. Сравните работающую и сбойную среды по транспорту, реализации клиента, выбранному прокси и первой ошибке. Если сбоит только XHR, следуйте его маршруту, аутентификации и долго удерживаемым ответам, вместо того чтобы раз за разом менять настройки работающего клиента WebSocket.