Bir SockJS proxy hatası neden yalnızca yedek yola geçildikten sonra görülebilir

WebSocket bir ağda çalışıp SockJS başka bir ağda başarısız olduğunda, ikinci ağ XHR yedek yolunu tetiklemiş olabilir. Bu, istekleri yapan HTTP uygulamasını — ve dolayısıyla kullanılan proxy yapılandırmasını — değiştirebilir.

İlk başarısız URL'yi ve onun seçtiği taşımayı bulun. SockJS bir taşıma seçmeden önce bir HTTP bilgi isteği gönderebilir; WebSocket el sıkışması ve sonraki yoklama istekleri ayrı işlemlerdir. Çalışan bir el sıkışması yapılandırması, her biri için kullanılan yolu kanıtlamaz.

Spring'in Java istemcisinde RestTemplateXhrTransport yapılandırılmış bir RestTemplate kabul eder. İstek fabrikası ve altındaki HTTP istemcisi, yedek yolun desteklediği proxy yolunu ve kimlik doğrulamayı sağlar. Spring 6 ve HttpClient 5 için o RestTemplate'in gerçek istek fabrikasını yapılandırın. Bu uygulama Apache HTTP bileşenleri kullanıyorsa, sürümü entegrasyonla eşleşmelidir.

WebSocket istemcisinin kendi belgelenmiş bağlantı ayarları vardır. JVM proxy özellikleri bir yolu yalnızca somut istemcisi bunları okursa etkiler. Çalışan ve başarısız ortamları taşıma, istemci uygulaması, seçilen proxy ve ilk hata açısından karşılaştırın. Yalnızca XHR başarısız oluyorsa, çalışan WebSocket istemcisinin ayarlarını tekrar tekrar değiştirmek yerine onun yolunu, kimlik doğrulamasını ve uzun süre tutulan yanıtlarını izleyin.