Защо при 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.