WebSocket 經由代理的長連線驗收與疑難排解指南

能穩定完成短 HTTP 請求的代理，仍可能無法承載 WebSocket。WebSocket 的運作方式不同：同一連線可能持續數小時，資料雙向流動，中間設備可能設定閒置上限，而對無狀態請求有用的出口輪換可能直接破壞工作階段連續性。

本指南適用於經由 HTTP、HTTPS、SOCKS5、住宅、輪換或靜態代理執行安全 WebSocket。只能在已獲授權的端點與流量範圍內測試。

驗證完整生命週期

有效 WebSocket 結果至少包含七個階段：解析代理閘道、連線並驗證、建立目標通道、完成 TLS、完成開啟交握、在要求時長交換有效訊息，以及正常關閉或依政策復原。

不要把這些階段壓成單一成功欄位。若預期協定切換卻只得到一般 HTTP 頁面，即使狀態看似正常，也應判定失敗。

先定義工作負載合約

採購前明確記錄：

• 安全或明文 WebSocket；
• HTTP/1.1 Upgrade、HTTP/2 Extended CONNECT 或 HTTP/3 路徑；
• DNS 在本機或代理端解析；
• 典型與最長工作階段時間；
• 訊息速率及最大訊框或訊息；
• 心跳責任端與間隔；
• 可接受靜默時段；
• 重連預算和重新訂閱；
• 出口地區以及 IP 是否須穩定；
• 對重複、遺失與亂序的容忍度。

沒有合約，五秒回聲測試很容易通過，卻無法代表真實業務。

建立控制矩陣

同時測試已授權直連控制組與每條候選代理路徑，涵蓋所需地區與位址家族。對輪換服務比較逐次輪換、多種黏性時長、靜態或專用控制路線，以及低流量與實際流量訊息模型。

保持目標、用戶端版本、驗證、標頭、子協定、壓縮、心跳政策與測試時長一致。

八步驗收流程

1. 驗證 DNS 與代理可達性

記錄閘道與目標解析位置、位址家族、查詢延遲、TCP 連線時間與代理驗證。SOCKS5 必須區分本機解析與遠端 DNS。紀錄不得包含使用者名稱、密碼、權杖或完整授權標頭。

2. 驗證開啟交握

記錄協定、主機、路徑、適用的 Origin、WebSocket 版本、子協定與延伸功能。確認結果是真正的協定升級或正確的 Extended CONNECT，而不是登入頁、阻擋頁或一般成功頁面。

安全 WebSocket 必須在通道中依主機名稱驗證目標憑證，不能關閉憑證檢查來取得成功。

3. 測量雙向訊息完整性

使用匿名序號與時間戳記傳送已授權測試訊息，在應用層驗證雜湊或固定內容標記。分別統計傳送、確認、接收、重複、遺失、損壞與亂序。

同時涵蓋小型控制訊息、典型負載與最大業務訊息。訊框邊界不一定等於應用訊息邊界，應在應用實際消費層驗證。

4. 找出有效閒置逾時

以逐步延長的靜默時段執行多組工作階段。有證據時，區分關閉來自用戶端、代理閘道、上游中間設備、出口網路或目標。

不要以高頻心跳掩蓋未知上限。先量測邊界，再選擇有餘裕且成本可控的間隔。

5. 驗證 ping、pong 與應用心跳

協定 ping/pong 可顯示對端仍回應，應用心跳則驗證業務迴圈。若兩者都使用，應分開測試並記錄往返延遲、漏答及斷線規則。一般資料流量不能自動視為心跳。

6. 測試黏性到期與輪換

對輪換住宅代理，讓連線跨過標稱黏性時長，觀察既有 socket 是持續、正常關閉或重設；再建立新連線驗證輪換。

不要假設已建立的 WebSocket 能在內部順利更換 IP。中途替換路徑通常會中斷傳輸，並可能在重連後產生重複訂閱。

7. 測試安全重連

分別在用戶端、代理與目標層注入受控關閉，採用帶抖動的有界指數退避。重連後驗證身分、工作階段、訂閱復原、續傳游標、重播時段與去重。

開啟新 socket 不等於復原成功；業務必須從已知位置繼續，不能靜默遺失或重複處理事件。

8. 驗證正常關閉

發起 WebSocket 關閉交握，記錄關閉碼、原因類別、對端回應時間與底層連線關閉。正常結束、逾時、政策拒絕、協定錯誤與傳輸突斷必須分開統計。

應關注的指標

按代理產品、閘道、請求地區、觀察出口、位址家族與工作階段政策報告：

• 交握成功率與有效工作階段成功率；
• 開啟時間與首個有效訊息時間；
• 1、5、15、30、60 分鐘或業務時點的存活率；
• ping/pong 與應用心跳延遲分位數；
• 有效訊息率、重複、缺口與亂序；
• 閒置逾時分布；
• 重連成功率及訂閱復原時間；
• 每個有效工作階段流量；
• 每個完整有效工作階段成本。

最後一項可避免每 GB 看似便宜、卻因頻繁重連與重播而更昂貴的方案勝出。

故障分類

交握回傳一般網頁： 檢查代理驗證、目標政策、重新導向，以及 Upgrade 或 Extended CONNECT 是否保留。

連線總在相同靜默時間中斷： 先調查閒置逾時，不要直接歸因出口品質。

只有輪換路線失敗： 使用黏性或靜態控制組，並確認有效期涵蓋業務時長。

Pong 正常但沒有業務訊息： 傳輸仍活躍，但訂閱或應用迴圈可能失效。

重連產生重複事件： 保存續傳游標與冪等鍵，不要盲目丟棄所有重複資料。

大型訊息失敗： 分開檢查訊框、訊息大小、壓縮、中間設備限制、記憶體與解析。

上線清單

• [ ] 驗證真正 WebSocket 交握，不只看 HTTP 狀態。
• [ ] TLS 憑證驗證保持啟用。
• [ ] 本機與遠端 DNS 模式已標示。
• [ ] 雙向訊息依序號與內容標記驗證。
• [ ] 已量測有效閒置逾時。
• [ ] 心跳間隔有明確餘裕。
• [ ] 黏性時長涵蓋業務工作階段。
• [ ] 重連採有界退避並安全復原訂閱。
• [ ] 已統計重複與遺失訊息。
• [ ] 正常與異常關閉分開分類。
• [ ] 紀錄不含憑證和客戶負載。

常見問題

輪換住宅代理適合 WebSocket 嗎？

若供應商支援通道，且黏性時長超過連線需求，就可能適合。需要長期連續性時，靜態或專用路線通常更容易控制。

CONNECT 成功是否證明支援 WebSocket？

不能。CONNECT 只建立通道，之後仍需驗證 TLS、開啟交握、子協定、訊息流、心跳與生命週期。

心跳應多頻繁？

依實測閒置上限、目標規則、供應商政策與流量成本決定，不應套用固定數字。

每次斷線都應立即輪換嗎？

不應。先分類原因；立即輪換可能抹除證據、放大重連流量並破壞連續性。

合規與安全

只使用獲授權的 WebSocket 端點、帳戶、市場和資料，遵守服務條款、存取控制、隱私要求、訂閱上限與速率規則。減少網路識別資料留存，絕不記錄代理憑證、工作階段權杖、Cookie 或客戶訊息內容。

繼續閱讀SOCKS5 與 HTTP 代理選擇指南、住宅代理工作階段黏性測試和代理重試風暴防護指南。

資料說明：網際網路工程任務組 RFC 6455，2011 年 12 月；RFC 8441，2018 年 9 月；RFC 9220，2022 年 6 月。curl 專案《WebSocket with curl》，2026 年 9 月 11 日複核。