Trang chat tải được nhưng kết nối trực tiếp thất bại: nên xem ở đâu

Mở bảng mạng trước khi tải trang chat, rồi tìm yêu cầu mang tin nhắn chứ không phải yêu cầu vẽ khung trang. Tài liệu, script, trao đổi lúc đăng nhập và đường truyền chat đều có thể đi tới các máy chủ khác nhau. Phần lớn báo cáo rằng VPN làm hỏng chat thực ra mô tả một trong bốn yêu cầu đó thất bại. Quan sát theo thứ tự và câu trả lời thường hiện ra trong hai phút đầu.

Tìm yêu cầu mang tin nhắn

Lọc theo loại khi trang đã ổn định: WebSocket hiện thành mục riêng, luồng sự kiện giữ mở với phản hồi lớn dần, và thăm dò dài lặp lại theo chu kỳ đều. Ghi lại scheme, máy chủ, cổng và trạng thái của mục mang các bản cập nhật. Ghi nhận nó bắt đầu trước hay sau khi đăng nhập, vì đường truyền mở trước khi xác thực thường là thiết kế khác với đường truyền mở sau đó. Đọc tiêu đề yêu cầu nâng cấp hoặc loại nội dung được chấp nhận, vì chúng chỉ ra đường truyền mà trang đã triển khai thực sự chọn.

Các bài đăng diễn đàn cũ mô tả những đường truyền mà sản phẩm đã bỏ từ nhiều năm trước, nên hãy tin điều trình duyệt ghi lại chứ không phải bài viết. Nếu mục đó hoàn toàn không có, mã phía máy khách có thể chưa từng thử kết nối, điều này chỉ về một lỗi script hoặc cấu hình trước đó. Trang tải được chỉ chứng minh tài liệu đã tới, và chính sự khác biệt đó quyết định bạn có thực sự đang gỡ lỗi mạng hay không.

Thiết lập, phân phối và vòng đời hỏng theo cách khác nhau

WebSocket mở bằng một lần nâng cấp HTTP được trả lời bằng trạng thái 101, và mọi thứ sau đó là tin nhắn đóng khung chứ không phải tải trang, hai giai đoạn mà RFC 6455 tách riêng rõ ràng. Luồng sự kiện trả lời bằng một loại nội dung dạng luồng và giữ phần thân phản hồi mở. Cả hai đều có thể không mở được, mở mà không phân phối gì, hoặc mở, phân phối rồi chết âm thầm.

wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events

Bắt lấy thất bại có ý nghĩa đầu tiên trước khi chạm vào hồ sơ, vì ba mốc thời gian chỉ về các lớp khác nhau. Nếu bắt tay không bao giờ hoàn tất, hãy so với một yêu cầu HTTPS thường tới cùng máy chủ để xem có gì tới được đó không. Nếu hoàn tất mà không có tin nhắn, hãy xem khung hoặc phần thân luồng trong khi ai đó gửi tin nhắn thử từ tài khoản khác. Nếu chạy được rồi dừng, hãy ghi thời điểm chính xác và mã đóng, vì cặp đó chỉ ra phía nào đã bỏ cuộc.

Mã 1006 nghĩa là socket đóng mà không có khung đóng, và đó là hình ảnh của một thiết bị trung gian hoặc hết thời gian nhàn rỗi khi nhìn từ bên trong trình duyệt. Nhịp tim VPN không chứng minh phiên ứng dụng bên trong còn sống.

Máy chủ trực tiếp là một đích riêng

Phần phía sau của chat thường sống trên tên máy chủ riêng, đôi khi ở cổng khác hoặc sau một chứng chỉ riêng. Đích đó cần phân giải, tuyến và cách xử lý proxy riêng, và đường hầm chia tách có thể gồm trang nhưng loại socket. Phân giải tên máy chủ trực tiếp từ máy khách và xác nhận nó trả lời bằng địa chỉ bạn mong đợi trên mạng đó. Kiểm tra chuỗi chứng chỉ riêng cho tên máy chủ đó, vì ký tự đại diện phủ trang không phải lúc nào cũng phủ điểm cuối socket.

Nếu có proxy trên đường đi, xác nhận nó cho phép nâng cấp hoặc phản hồi dài thay vì đệm lại. Proxy doanh nghiệp viết lại HTML thường xử lý nâng cấp WebSocket kém, dẫn tới trang vẫn vẽ được còn chat thì không bao giờ kết nối. Vì thế hai yêu cầu tới cùng một sản phẩm không phải hai yêu cầu tới cùng một máy chủ.

Sửa danh sách đích, không phải các bước kiểm tra bảo mật

Sửa danh sách đích là thay đổi định tuyến và thuộc về người sở hữu tuyến. Nới lỏng việc kiểm tra chứng chỉ hoặc bỏ tiêu đề Origin là thay đổi bảo mật và thuộc về người sở hữu chính sách, mà hiếm khi là người đang gỡ lỗi phiếu. Cách nhanh nhất để kết nối trông như đã chạy thường cũng là cách nhanh nhất để một sự cố trở nên khả thi.

Hỏi người sở hữu ứng dụng xem phía sau chấp nhận những nguồn gốc nào trước khi thay đổi bất cứ điều gì, và chuyển câu trả lời đó cho người kiểm soát proxy. Nếu lỗi chứng chỉ chỉ xuất hiện qua đường hầm, hãy kiểm tra thiết bị chặn thay vì cài một đường vòng.

Ghi đủ để bàn giao

Vật phẩm hữu ích rất ngắn: URL trang, điểm cuối trực tiếp, kết quả bắt tay, thời điểm thất bại đầu tiên và việc có thử kết nối lại hay không. Thêm tên hồ sơ VPN và mạng bạn đã dùng, và bất kỳ ai đọc đều tái hiện được bài kiểm tra mà không phải hỏi sáu câu. Che cookie, tiêu đề cấp quyền và phần thân tin nhắn, và ưu tiên ảnh chụp cột thời gian hơn là xuất toàn bộ kho lưu. Khung và kho lưu mạng có thể chứa tin nhắn riêng tư và token phiên, nên hãy kiểm tra trước khi đính kèm bất cứ thứ gì.

Nếu thất bại là đóng âm thầm, hãy kèm mã đóng và khoảng nhàn rỗi trước đó, vì cặp này thường chỉ ra chủ của thời gian chờ. Bàn giao bản ghi cho người sở hữu ứng dụng hoặc cổng nối thay vì tự đoán một giá trị thời gian chờ. Câu trả lời của họ về hành vi keepalive được hỗ trợ là câu trả lời đóng phiếu.