Чаму збой проксі 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.