開啟 3 天免費試用
註冊即可免費體驗全部高級功能。
*只限新用戶；每位用戶只可獲得一次試用。
網頁正常但 WebSocket 連接失敗：握手、逾時與代理檢查
Ryan Foster
2026年10月7日· 7 分鐘讀完
WebSocket 連接失敗而 HTTPS 網頁仍能開啟，首先要判斷是握手未完成，還是連接建立後才關閉。網頁載入成功，不能證明另一個即時端點的認證、路由與長連接也正常。
關鍵要點：
- 調整網絡前先記下實際端點與失敗階段。
- HTTP/1.1 的 101 代表協議升級，並非應用任務成功。
- 認證拒絕與伺服器錯誤須各自處理。
- 核對端點及代理後，才用同一獲准連接比較其他路徑。
步驟 1：WebSocket 連接失敗發生在哪個階段？
只診斷你擁有或已明確獲准測試的服務。請營運方提供無敏感內容的測試頻道與預期訊息，不開啟別人的訂閱或截取私人通訊。記錄瀏覽器版本、作業系統、已脫敏端點、連接時間與可見錯誤；多個應用一同失敗時，先使用裝置層面的排障流程。
重現問題前開啟瀏覽器開發者工具，在網絡面板找出實際 WebSocket 請求。Chrome 提供 WS 篩選，其他瀏覽器的名稱可能不同。查看請求的主機與路徑，不只看網頁地址；即時服務可能位於另一個域名，使用不同認證及路由要求。
本文涵蓋傳統 HTTP/1.1 升級：有效開場回應使用 101 及相應握手標頭，其他狀態表示這次交換尚未成為所需連接。現代部署亦可採用其他標準傳輸；若服務明確採用 HTTP/2 機制，就不能一律要求 101。［1］［4］
圖中分開開場被拒與建立後關閉。有回應時保存其狀態，不以控制台的籠統錯誤代替。收到回應代表某個伺服器或中介已作答，與請求一直未完成連接是兩種證據。
步驟 2：回應能證明甚麼？
對照服務文檔列出的端點 URL 和協議。安全網頁通常需要安全 WebSocket，不改用不安全端點來掩蓋錯誤。應用需要子協議時，查看實際協商結果；RFC 定義的子協議及瀏覽器 Origin 屬應用決策，不是選擇國家的問題。［1］
| 觀察 | 接着調查 | 安全做法 |
|---|---|---|
| 沒有開場回應 | 名稱解析、TLS、網絡或瀏覽器限制 | 保留錯誤並確認目標端點 |
| 401 或明確認證拒絕 | 工作階段或 API 憑據 | 經獲准的應用流程重新認證 |
| 403 並明示 Origin 或權限拒絕 | 應用存取政策 | 請營運方核對允許來源及權限 |
| 404 或非預期 HTML | 路徑或上游映射 | 向負責人確認即時服務路徑 |
| 502 或其他上游錯誤 | 反向代理與上游 | 提供時間及脫敏請求編號 |
| 101 後關閉 | 已建立通道、計時器或應用行為 | 檢查訊息、關閉資訊及閒置時長 |
403 不能單憑數字判作 Origin 問題，應保存服務方的實際說明。回傳登入頁面的 200 亦不表示升級完成。公開重現資料不包含 Cookie 或 Bearer token，改用營運方提供的測試帳戶或本地無敏感內容示例。
一般命令列請求亦失敗時，另查瀏覽器與 curl 的請求環境差異。curl 下載成功並不驗證 WebSocket 握手、子協議或已認證訂閱。憑證問題按憑證警告調查步驟處理，保留憑證和主機名稱驗證。
步驟 3：WebSocket 代理有轉送升級標頭嗎？
若你管理反向代理，檢查真正處理該即時路徑的設定。HTTP/1.1 的 Upgrade、Connection 是逐跳標頭，NGINX 需要明確轉送才可向上游建立隧道。官方示例同時依賴客戶端提出升級及上游回傳 101，使用預設設定前須核對已安裝版本。［2］
反向代理、瀏覽器前向代理與 VPN 隧道位於不同位置。更改電腦出口不會改寫營運方的 location、建立缺失上游或修正認證檢查。
請負責人在原有信任邊界內，對照直接上游與公開代理上的小型獲准請求。不要為了測試公開內部後端或繞過組織強制控制。沒有管理權時，交付端點、時間、狀態和連接階段供營運方核對。
本文的本地示例實際連接 loopback WebSocket 服務，接收無害訊息並記錄關閉事件。截圖是即時診斷報告，不是正式環境流量、應用登入畫面或任何 VPN 的效能證據。
報告將開場、接收訊息與關閉各自列出，診斷記錄亦應如此。本地回環沒有可比較的互聯網路徑，不能由此認定現實事件的外部中介有問題。
如果這條 WebSocket 路由承載的是經 CDN 的自建代理，VLESS 的 WebSocket 與 XHTTP 教學列出了源站代理需要的 Upgrade 標頭，並說明如何證明流量確實經過邊緣節點。
步驟 4：WebSocket 閒置逾時是否有固定模式？
保存建立連接、最後收到訊息及關閉的時間。只重複足以區分固定間隔和偶發中斷的無害測試，並分開活躍與閒置工作階段。沒有流量後關閉，與持續傳輸期間中斷是不同情況。
NGINX 文檔的預設行為是在 60 秒未收到上游數據後關閉代理連接。這不是每條連接剛好維持一分鐘的保證，其他環節可能設定不同限制。固定間隔只提示應查部署中的計時器，並非 NGINX 的唯一特徵。［2］
協議 Ping／Pong 與應用 JSON 心跳不同。瀏覽器 JavaScript 不提供通用介面直接送出協議 Ping，通常由伺服器或適合的非瀏覽器客戶端處理。增加訊息或調整頻率前，先向應用負責人確認心跳格式。［1］［3］
可取得關閉碼與原因時應保存。未收到關閉幀的異常結束，不能定位哪個環節出錯；正常關閉則可能只是結束測試訂閱。實際接收單向 HTTP 事件時，使用事件串流交付檢查。
步驟 5：另一條獲准路徑會改變這個頻道嗎？
端點及存取條件正確、傳輸仍失敗時，路徑比較才有用。確認替代路徑獲准，保留必要代理。若桌面應用與瀏覽器表現不同，先記錄執行環境，不預設兩者同路。
在已連接 AethoVPN 的受支援電腦上執行瀏覽器，從 App 目前提供的位置選本國或鄰近出口，開啟全局模式，再開啟同一無害頻道。比較握手回應、首個預期訊息及關閉前持續時間，而非只看網頁是否載入。
Windows 使用官方安裝程式，Debian／Ubuntu x64 使用 .deb。Mac 按網站設定指南取得客戶端配置，需要 Pro 或 Premium。先核對目前公網出口，再保存 WebSocket 證據；單一 IP 頁面不能證明這次請求的路徑。
這改變的是本地路線，不會取得訂閱權限、修正 Origin 政策或上游逾時。需要新帳戶作獲准比較時，可開始 3 天免費 Pro 試用，每人一次，註冊時開始計算。
依WebSocket 測試前的線路核對確認準備。兩條路徑都沒有改變症狀時，恢復原路線並請營運方檢查伺服器證據。明確權限拒絕後不再換位置，亦不把一次成功描述為日後可用保證。
若直連與獲准代理路徑表現不同，而你確需覆蓋這個本地應用，先弄清 TUN 與系統代理分別涵蓋哪些程式再選擇接管方式。這改變本地流量覆蓋，不會改動服務的升級設定或計時器。
步驟 6：如何恢復設定及交付問題？
還原臨時客戶端設定，關閉測試訂閱並停止診斷日誌。保存簡短個案記錄：執行環境、脫敏主機及路徑、握手狀態、子協議、訊息到達、閒置時間、關閉資訊、使用路線及測試時間。不要附 token、私人訊息、帳戶識別資料或簽署 URL。
API 測試工具的代理及執行方式有別，另行失敗時按Postman 執行位置與逾時檢查調查。不用有業務後果的訊息作探針，重試前先向應用負責人確認原操作狀態。
認證拒絕交應用負責人、固定代理時間問題交基礎設施負責人、憑證錯誤交信任設定管理員。重複測試不再帶來證據就停止。準確的失敗階段，比一堆來自無關主機的截圖更有用。
總結
- 分開開場交換、訊息交付及最後關閉。
- 保留認證、Origin 政策與憑證驗證。
- 固定閒置時間只提示計時器問題，不證明某個中介故障。
- 比較同一獲准頻道後，還原設定並交付剩餘問題。
常見問題
網頁載入成功，為何 WebSocket 失敗？
兩者可能使用不同主機、路徑及認證。HTML 載入成功既不代表有權使用即時端點，也不代表長連接的處理正常。
101 是否表示應用運作正常？
握手有效時，101 確認傳統 HTTP/1.1 協議升級。仍須收到預期訊息並建立可用工作階段，才能視為任務成功。
一分鐘斷線是否能確定代理逾時？
固定間隔值得檢查閒置計時器，但不能單憑它定位元件。先比較最後上游數據時間與部署限制，再判斷反向代理角色。
應用瀏覽器 JavaScript 發送心跳嗎？
只使用應用文檔說明的心跳格式。JSON 訊息不等於協議 Ping，任意訊息可能產生應用錯誤或非預期操作。
測試握手時可以關閉 Origin 檢查嗎？
保留 Origin 檢查，請負責人授權正確測試來源。刪除安全檢查會改變受測系統，也可能暴露其他用戶工作階段。
VPN 能處理訂閱被拒嗎？
訂閱拒絕要循服務流程修正認證或權限。網絡比較只適用於傳輸階段，並不賦予應用存取資格。
可向支援人員提供哪些資料？
提供已脫敏端點、時間、失敗階段、狀態及關閉資訊。先移除 Cookie、token、私人訊息、簽署參數和個人或帳戶識別資料。
免責聲明： 本文只說明獲准診斷，不保證服務可用。使用時須遵守當地法律、組織政策和服務存取規則。
來源：
- RFC 6455 — The WebSocket Protocol — https://www.rfc-editor.org/rfc/rfc6455
- NGINX — WebSocket proxying — https://nginx.org/en/docs/http/websocket.html
- WHATWG — WebSockets — https://websockets.spec.whatwg.org/#ping-and-pong-frames
- RFC 8441 — Bootstrapping WebSockets with HTTP/2 — https://www.rfc-editor.org/rfc/rfc8441
Sources checked 2026 年 10 月 7 日。
延伸閱讀：
