Kiểm tra proxy WebSocket wss:// bằng Node.js và chẩn đoán lỗi

Vì sao cần kiểm tra riêng proxy WebSocket?

Proxy truy cập được website HTTPS chưa chắc duy trì tốt kết nối WebSocket bảo mật. Với ứng dụng chat, thông báo hoặc bảng điều khiển thời gian thực, yêu cầu không chỉ là kết nối thành công mà còn phải trao đổi dữ liệu ổn định trong thời gian dài.

Để kiểm tra proxy hỗ trợ WebSocket, cần xác minh đường hầm qua proxy, quá trình TLS, bắt tay WebSocket và khả năng truyền dữ liệu sau khi kết nối mở. Bài viết sử dụng Node.js để tách các giai đoạn này, giúp chẩn đoán đúng nguyên nhân thay vì quy mọi lỗi cho proxy.

Proxy xử lý kết nối wss:// như thế nào?

Với HTTP proxy, đường hầm được thiết lập trước TLS và bắt tay WebSocket.

wss:// là WebSocket chạy trên TLS. Trong luồng phổ biến qua HTTP proxy, client yêu cầu proxy thiết lập đường hầm bằng phương thức CONNECT tới máy chủ đích. Khi đường hầm được chấp nhận, client thực hiện TLS với máy chủ rồi gửi yêu cầu bắt tay WebSocket bên trong kết nối đã mã hóa.

Vì vậy, HTTP proxy không nhất thiết phải hiểu nội dung WebSocket để chuyển tiếp wss://. Tuy nhiên, chính sách đích đến, xác thực, thời gian chờ và giới hạn kết nối của proxy vẫn có thể ảnh hưởng.

• HTTP proxy: thường dùng CONNECT để tạo đường hầm tới đích wss://.
• HTTPS proxy: kết nối từ client tới proxy cũng được bảo vệ bằng TLS; đây là lớp riêng với TLS tới máy chủ đích.
• SOCKS proxy: chuyển tiếp kết nối TCP bằng giao thức SOCKS thay vì CONNECT của HTTP.
• Reverse proxy: đứng trước máy chủ ứng dụng; lỗi cấu hình chuyển tiếp WebSocket tại đây vẫn có thể xảy ra dù proxy phía client hoạt động đúng.

Chuẩn bị môi trường kiểm tra proxy wss Node.js

Cài các thư viện cần thiết bằng lệnh sau:

npm install ws https-proxy-agent socks-proxy-agent

Ví dụ sử dụng tệp check-wss.mjs, tương ứng với cú pháp ES modules. Hãy dùng một endpoint WebSocket do bạn quản lý hoặc được phép kiểm thử, có chứng chỉ hợp lệ và đáp ứng đúng giao thức của ứng dụng.

Chương trình nhận cấu hình qua biến môi trường:

• WSS_URL: địa chỉ wss://, gồm đúng đường dẫn và tham số cần thiết.
• PROXY_URL: URL proxy, gồm giao thức, máy chủ, cổng và thông tin xác thực nếu có.
• TEST_TIMEOUT_MS: thời gian chờ do người vận hành lựa chọn, tính bằng mili giây.

Không lưu mật khẩu proxy vào mã nguồn. Nếu tên đăng nhập hoặc mật khẩu chứa ký tự đặc biệt, hãy mã hóa đúng từng thành phần khi xây dựng URL. Khi ghi log, cần che thông tin xác thực, token và tham số nhạy cảm.

Mã Node.js kiểm tra kết nối và phản hồi Pong

Ví dụ dưới đây dành cho HTTP hoặc HTTPS proxy. Mỗi đoạn mã được trình bày thành một đoạn riêng; sao chép lần lượt vào cùng tệp check-wss.mjs.

import WebSocket from 'ws'; import { HttpsProxyAgent } from 'https-proxy-agent'; import { randomUUID } from 'node:crypto';

const target = new URL(process.env.WSS_URL); const proxy = new URL(process.env.PROXY_URL); const timeout = Number(process.env.TEST_TIMEOUT_MS); if (target.protocol !== 'wss:') throw new Error('WSS_URL phải sử dụng wss://'); if (!['http:', 'https:'].includes(proxy.protocol)) throw new Error('Ví dụ này yêu cầu HTTP hoặc HTTPS proxy'); if (!Number.isSafeInteger(timeout) || timeout <= 0) throw new Error('TEST_TIMEOUT_MS phải là số nguyên dương');

const agent = new HttpsProxyAgent(proxy); const token = randomUUID(); let stage = 'connecting'; let finished = false; let timer; const ws = new WebSocket(target, { agent, handshakeTimeout: timeout });

function finish(ok, message) { if (finished) return; finished = true; clearTimeout(timer); console.log(JSON.stringify({ ok, stage, message })); process.exitCode = ok ? 0 : 1; ws.terminate(); agent.destroy(); }

timer = setTimeout(() => finish(false, 'Hết thời gian chờ do người vận hành cấu hình'), timeout); ws.on('open', () => { stage = 'waiting-pong'; console.log('Đã hoàn tất bắt tay WebSocket'); ws.ping(token); }); ws.on('pong', data => { if (data.toString() === token) finish(true, 'Đã nhận Pong khớp với Ping gửi qua kết nối'); });

ws.on('unexpected-response', (request, response) => { finish(false, 'Phản hồi HTTP không hoàn tất bắt tay WebSocket: ' + response.statusCode); response.destroy(); }); ws.on('error', error => finish(false, [error.code, error.message].filter(Boolean).join(': '))); ws.on('close', (code, reason) => { if (!finished) finish(false, 'Kết nối đóng: ' + code + ' ' + reason.toString()); });

Sau khi thiết lập biến môi trường trong shell hoặc công cụ quản lý tiến trình, chạy node check-wss.mjs. Không đưa nguyên lệnh chứa mật khẩu vào lịch sử shell dùng chung.

Cách hiểu kết quả

Pong khớp với Ping xác nhận trao đổi khung điều khiển, không thay thế kiểm thử nghiệp vụ.

Sự kiện open xác nhận bắt tay WebSocket đã hoàn tất. Pong có nội dung khớp với Ping xác nhận thêm rằng khung điều khiển đã đi và về qua kết nối. Mã dùng terminate() để kết thúc phép thử ngắn, không phải mẫu đóng kết nối bình thường cho ứng dụng sản xuất.

Ping/Pong không thay thế kiểm thử nghiệp vụ. Kết quả thành công chưa chứng minh đăng nhập, đăng ký kênh hoặc nhận sự kiện hoạt động. Ngược lại, thiếu Pong chưa đủ để kết luận proxy không hỗ trợ WebSocket; cần kiểm tra máy chủ, tải hệ thống và thời gian chờ đã chọn.

Nếu sử dụng SOCKS proxy

Thay phần nhập và khởi tạo agent bằng import { SocksProxyAgent } from 'socks-proxy-agent'; và const agent = new SocksProxyAgent(proxy);. Đồng thời sửa kiểm tra giao thức để chấp nhận loại SOCKS tương ứng.

Với thư viện này, socks5:// phân giải tên đích tại client, còn socks5h:// chuyển tên đích cho proxy phân giải. Khác biệt này quan trọng khi hai môi trường có DNS hoặc khả năng truy cập mạng khác nhau.

Xác minh kết nối thực sự đi qua proxy

Không nên mặc định thư viện sẽ dùng proxy chỉ vì đã khai báo biến môi trường của hệ điều hành. Trong ví dụ trên, agent được truyền trực tiếp vào WebSocket để thể hiện rõ tuyến kết nối.

• Đối chiếu log CONNECT hoặc log phiên kết nối tại proxy nếu có quyền truy cập.
• Kiểm tra địa chỉ nguồn mà hạ tầng máy chủ đích quan sát được.
• Dùng endpoint được kiểm soát để gắn mã tương quan giữa log client và server.
• Thử cấu hình proxy không hoạt động trong môi trường kiểm thử: chương trình phải báo lỗi, không tự chuyển sang kết nối trực tiếp.

Nếu máy chủ nằm sau reverse proxy hoặc load balancer, địa chỉ nguồn tại ứng dụng có thể là địa chỉ của lớp trung gian. Khi đó, cần đối chiếu log tại đúng điểm tiếp nhận kết nối.

Chẩn đoán lỗi WebSocket qua proxy theo từng giai đoạn

Lỗi kết nối tới proxy

ENOTFOUND thường liên quan đến phân giải tên; ECONNREFUSED cho biết kết nối bị từ chối; ETIMEDOUT cho thấy một thao tác mạng hết thời gian chờ. Cần xác định lỗi thuộc chặng client–proxy hay proxy–đích trước khi xử lý.

Kiểm tra hostname, cổng, giao thức, quyền truy cập mạng và trạng thái dịch vụ proxy. Dùng sai giao thức giữa HTTP, HTTPS và SOCKS có thể khiến kết nối thất bại ngay từ đầu.

Lỗi xác thực hoặc thiết lập đường hầm

Nếu proxy yêu cầu xác thực, kiểm tra tài khoản, mật khẩu, cách mã hóa URL và phương thức xác thực mà agent hỗ trợ. Proxy trong môi trường doanh nghiệp có thể yêu cầu cơ chế không được đáp ứng bằng thông tin đăng nhập cơ bản trong URL.

Đường hầm cũng có thể bị từ chối vì chính sách đích đến hoặc giới hạn tài khoản. Hãy đối chiếu log proxy thay vì kết luận rằng toàn bộ dịch vụ không hỗ trợ wss://.

Lỗi chứng chỉ TLS

Khi dùng HTTPS proxy, cần xác định lỗi thuộc lớp TLS tới proxy hay tới máy chủ đích.

Lỗi TLS có thể xuất hiện khi kết nối tới HTTPS proxy hoặc khi xác minh máy chủ WebSocket. Nguyên nhân thường gồm chuỗi chứng chỉ thiếu, hostname không khớp, chứng chỉ hết hạn hoặc CA nội bộ chưa được tin cậy.

Không tắt xác minh chứng chỉ để coi phép thử là thành công. Cần sửa cấu hình chứng chỉ hoặc bổ sung CA được quản trị phê duyệt. Nếu dùng HTTPS proxy, hãy xác định chính xác lớp TLS đang lỗi.

Có phản hồi HTTP nhưng WebSocket không mở

Sự kiện unexpected-response cho biết nhận được phản hồi HTTP không hoàn tất bắt tay WebSocket. Kiểm tra URL, đường dẫn, chuyển hướng, phiên đăng nhập, Origin và subprotocol theo tài liệu máy chủ.

Phản hồi có thể đến từ proxy, reverse proxy hoặc ứng dụng đích. Không suy ra nguồn phát sinh chỉ từ mã trạng thái; cần đối chiếu log và thông tin phản hồi. Nếu ứng dụng yêu cầu header xác thực, hãy thêm đúng vào tùy chọn kết nối mà không ghi giá trị bí mật ra log.

Kết nối mở rồi đóng hoặc ngừng nhận dữ liệu

Nhóm lỗi này thường liên quan đến idle timeout, heartbeat, phiên xác thực hết hạn, giới hạn kết nối hoặc ứng dụng đóng phiên. Ghi lại thời điểm mở, lần nhận dữ liệu cuối, mã đóng và lý do đóng.

Mã đóng biểu thị kết thúc bất thường không xác định được thiết bị gây lỗi. Hãy đối chiếu cùng thời điểm trên client, proxy và server để tìm chặng gián đoạn.

Kiểm thử độ ổn định cho ứng dụng thời gian thực

Sau phép thử Ping/Pong, bổ sung luồng nghiệp vụ bằng tài khoản kiểm thử: xác thực, đăng ký kênh và nhận một sự kiện có mã tương quan. Không gửi thông điệp tùy ý nếu chưa biết giao thức ứng dụng.

1. Lấy kết quả đối chứng: kiểm tra trực tiếp và qua proxy trên cùng endpoint, nếu chính sách mạng cho phép.
2. Kiểm tra trạng thái nhàn rỗi: duy trì phiên theo nhu cầu thực tế để quan sát việc đóng kết nối.
3. Kiểm tra heartbeat: phân biệt Ping/Pong WebSocket với thông điệp heartbeat ở tầng ứng dụng.
4. Kiểm tra khôi phục: xác minh kết nối lại, xác thực lại và đăng ký lại kênh sau gián đoạn.
5. Thử tải có kiểm soát: chỉ tăng kết nối trong phạm vi được phép và theo dõi tài nguyên hai phía.

Không đặt chu kỳ heartbeat quá dày để giải quyết mọi lỗi. Giá trị phù hợp cần dựa trên chính sách máy chủ, timeout của các lớp trung gian và chi phí vận hành.

Kết luận

Một phép thử proxy WebSocket đáng tin cậy phải xác nhận tuyến kết nối, hoàn tất TLS, mở WebSocket và kiểm tra dữ liệu hai chiều. Với ứng dụng thực tế, cần kiểm tra thêm nghiệp vụ và khả năng duy trì phiên.

Khi gặp lỗi WebSocket qua proxy, hãy phân loại theo từng giai đoạn thay vì thay đổi nhiều cấu hình cùng lúc. Cách làm này giúp xác định đúng lỗi ở proxy, chứng chỉ, reverse proxy hay ứng dụng và giữ nguyên các yêu cầu bảo mật cần thiết.