Khi WebSocket hoạt động trên một mạng nhưng SockJS thất bại trên mạng khác, mạng thứ hai có thể đã kích hoạt đường dự phòng XHR. Điều đó có thể thay đổi phần triển khai HTTP thực hiện các yêu cầu — và do đó thay đổi cấu hình proxy đang được dùng.

Xác định URL thất bại đầu tiên và phương thức vận chuyển mà nó chọn. SockJS có thể gửi một yêu cầu thông tin HTTP trước khi chọn phương thức vận chuyển; bắt tay WebSocket và các yêu cầu thăm dò tiếp theo là những thao tác riêng biệt. Một cấu hình bắt tay hoạt động không chứng minh đường đi được dùng cho từng thao tác trong số đó.

Trong ứng dụng khách Java của Spring, RestTemplateXhrTransport chấp nhận một RestTemplate đã được cấu hình. Nhà máy yêu cầu và ứng dụng khách HTTP bên dưới cung cấp tuyến proxy và xác thực mà đường dự phòng hỗ trợ. Với Spring 6 dùng HttpClient 5, hãy cấu hình nhà máy yêu cầu thực tế của RestTemplate đó. Nếu phần triển khai đó dùng các thành phần Apache HTTP, thế hệ của nó phải khớp với tích hợp.

Ứng dụng khách WebSocket có cài đặt kết nối được ghi chép riêng. Thuộc tính proxy của JVM chỉ ảnh hưởng đến một đường đi nếu ứng dụng khách cụ thể của nó đọc chúng. Hãy so sánh môi trường hoạt động và môi trường lỗi theo phương thức vận chuyển, phần triển khai ứng dụng khách, proxy được chọn và lỗi đầu tiên. Nếu chỉ XHR lỗi, hãy theo dõi tuyến, xác thực và các phản hồi giữ lâu của nó thay vì liên tục thay đổi cài đặt của ứng dụng khách WebSocket đang hoạt động.

Bài viết liên quan