本頁從開發者視角說明 WhatsApp網頁版 的長連線機制、QR Code 授權流程、端對端加密金鑰如何傳遞，以及企業網路環境下的連線排查方法。內容以協議行為與實作觀察為主，不涉及帳號隱私資料。
WebSocket 長連線與心跳機制
WhatsApp網頁版 在瀏覽器端與伺服器之間維持一條 WebSocket 連線，用於接收訊息、送達回執與在線狀態更新。連線建立後，客戶端會以固定間隔發送心跳帧，多數情況下間隔為 20 至 30 秒；若連續兩次心跳未收到伺服器回應，客戶端會主動關閉連線並進入重連流程。重連採用指數退避，初始延遲約 1 秒，上限通常落在 30 至 60 秒之間。
開發者需注意，瀏覽器分頁進入背景時，計時器可能被節流，導致心跳延遲。若應用依賴網頁版會話狀態，建議以 visibilitychange 事件監聽分頁切換，並在回到前景時主動檢查連線狀態。此外，WebSocket 握手階段會攜帶瀏覽器指紋與會話標識，伺服器據此綁定裝置。
QR Code 授權流程與金鑰協商
掃碼登入並非單純的身分驗證，而是一次裝置綁定與金鑰協商。流程大致如下：
- 網頁端向伺服器請求一組臨時授權碼，伺服器回傳 QR Code 內容，其中包含公鑰與會話 ID，有效期一般為 20 至 60 秒。
- 手機端掃描 QR Code 後，以自身私鑰對會話內容簽章，並將簽章結果經由手機與伺服器之間的既有加密通道回傳。
- 伺服器驗證簽章後，將網頁端標記為已授權裝置，並下發該會話專用的加密金鑰材料。
- 網頁端與手機端各自衍生出相同的會話金鑰，後續訊息以端對端加密方式傳輸，伺服器僅負責轉發密文。
常見錯誤是重複使用已過期的 QR Code，此時伺服器會拒絕簽章並要求重新產生。另一個常見問題是手機與網頁端時間偏差過大，導致簽章時間戳驗證失敗，建議裝置開啟自動時間同步。
端對端加密金鑰的傳遞路徑
WhatsApp 採用 Signal 協議的雙棘輪機制。在網頁版場景中，金鑰傳遞遵循以下路徑：手機端持有身分私鑰，網頁端透過授權流程取得會話金鑰；訊息發送時，發送方以會話金鑰加密明文，伺服器僅轉發密文，接收方以對應金鑰解密。金鑰材料不會以明文形式經過伺服器，伺服器也無法解密訊息內容。
需留意的是，網頁版作為已連結裝置，其會話金鑰由手機端授權衍生，因此手機端可隨時撤銷網頁版裝置，撤銷後網頁端持有的金鑰即失效。開發者若在企業環境中整合網頁版，應避免在共用裝置上長期保持授權狀態，並定期檢查已連結裝置清單。
企業網路環境下的連線排查
企業防火牆或代理伺服器常攔截 WebSocket 升級請求，導致網頁版停留在「連線中」狀態。排查時可依序檢查：
- 確認防火牆允許
Upgrade: websocket 標頭通過，部分代理僅支援 HTTP/1.1 而阻斷升級。
- 檢查 TLS 憑證鏈是否完整，中間憑證缺失會造成握手失敗，瀏覽器主控台通常顯示
ERR_CERT_AUTHORITY_INVALID。
- 確認 DNS 解析未被內部劫持，可透過
nslookup 比對公用解析結果。
- 若使用強制代理，需將 WebSocket 端點加入例外清單，否則連線會反覆中斷。
多數情況下，上述檢查可解決八成的連線問題。若問題持續，可收集瀏覽器網路日誌與伺服器回應碼，進一步分析是否為伺服器端限流或區域網路政策所致。
開發者實作注意事項
若你正在開發與 WhatsApp網頁版 互動的工具，應避免直接模擬瀏覽器行為繞過授權流程，這可能觸發伺服器風控並導致裝置被撤銷。建議使用官方提供的 Business API 或合規的整合方式。此外，網頁版的會話狀態與手機端綁定，手機端離線超過一定時間（通常為 14 天）後，網頁版可能被要求重新掃碼授權。測試時應將此因素納入考量，避免自動化腳本因會話失效而中斷。
