SockJS 프록시 실패가 폴백 이후에만 나타날 수 있는 이유
WebSocket 경로와 XHR 폴백은 서로 다른 HTTP 클라이언트를 사용할 수 있습니다. 프록시 설정을 바꾸기 전에 실패하는 전송을 식별하십시오.
한 네트워크에서는 WebSocket이 동작하지만 다른 네트워크에서는 SockJS가 실패한다면, 두 번째 네트워크가 XHR 폴백을 촉발했을 수 있습니다. 그러면 요청을 수행하는 HTTP 구현이 바뀌고, 따라서 사용되는 프록시 구성도 바뀝니다.
처음 실패한 URL과 그 URL이 선택한 전송을 찾으십시오. SockJS는 전송을 선택하기 전에 HTTP 정보 요청을 보낼 수 있습니다. WebSocket 핸드셰이크와 이후의 폴링 요청은 별개의 작업입니다. 핸드셰이크 구성이 동작한다고 해서 각각에 사용되는 경로가 같다는 것이 증명되지는 않습니다.
Spring의 Java 클라이언트에서 RestTemplateXhrTransport는 구성된 RestTemplate을 받습니다. 그 요청 팩터리와 기반 HTTP 클라이언트가 폴백에서 지원하는 프록시 경로와 인증을 제공합니다. Spring 6과 HttpClient 5의 경우 해당 RestTemplate의 실제 요청 팩터리를 구성하십시오. 그 구현이 Apache HTTP 구성 요소를 사용한다면 세대가 통합 환경과 일치해야 합니다.
WebSocket 클라이언트에는 자체 문서화된 연결 설정이 있습니다. JVM 프록시 속성은 구체 클라이언트가 이를 읽을 때만 경로에 영향을 줍니다. 동작하는 환경과 실패하는 환경을 전송, 클라이언트 구현, 선택된 프록시, 첫 오류 기준으로 비교하십시오. XHR만 실패한다면 동작하는 WebSocket 클라이언트의 설정을 반복해서 바꾸는 대신 그 경로, 인증, 오래 유지되는 응답을 추적하십시오.