IETF 推進 Happy Eyeballs v3：雙棧代理客戶端應如何測試路徑選擇

IETF HAPPY 工作組於 2026 年 7 月發布 Happy Eyeballs v3 工作組草案第 04 版。它延續一個核心目標：當 IPv6 與 IPv4 同時可用時，應用既要快速建立連線，也要避免單一路徑故障造成長時間等待。

這是仍在演進的 Internet-Draft，不是最終標準。對代理團隊而言，其方向已值得關注：直接連線只需在目標位址間選擇；加入 HTTP CONNECT 或 SOCKS 閘道後，系統實際擁有「客戶端到代理閘道」與「代理閘道到目標」兩段獨立路徑。

先分清兩段位址族

客戶端可能透過 IPv6 連接代理閘道，而閘道透過 IPv4 存取目標；也可能透過 IPv4 閘道，由閘道遠端解析並選擇 IPv6 目標。只記錄「本次是 IPv6」會隱藏真正的決策位置。

HTTP CONNECT 客戶端通常選擇閘道位址族，目標連線由閘道建立。SOCKS 請求可攜帶已解析位址或主機名稱；主機名稱模式會把目標 DNS 與位址族選擇交給閘道。因此測試紀錄必須明確 DNS 在哪裡發生。

最先成功的通訊端不等於最佳路線

Happy Eyeballs 最佳化可感知的連線延遲，不負責證明代理品質。最快握手之後仍可能出現：

• IPv6 路徑在回應中途重設；
• IPv4 建連穩定，但目標首位元組很慢；
• 客戶端與閘道使用不同地區的 DNS；
• 閘道接受 IPv6，卻在上游回退至 IPv4；
• 連線池重用暖連線，使冷啟動結果不可比；
• 目標回傳與傳輸無關的 403、429 或政策拒絕。

只有完成授權請求並取得可用結果才算成功。握手勝出後隧道失敗、正文不完整或路線不符，都不應計入代理成功率。

四層觀測模型

DNS

記錄閘道與目標分別由誰解析、A/AAAA 結果集、順序、解析器地區、快取狀態與時間。敏感內部主機名稱可改用不含秘密的路線標籤。

閘道連線

記錄客戶端位址族、閘道位址、嘗試開始時間、握手完成、TLS、代理驗證，以及另一條嘗試是否仍在進行。這一層通常由本地 Happy Eyeballs 實作控制。

隧道或 SOCKS 結果

記錄 CONNECT/SOCKS 狀態、遠端 DNS 模式、可觀測的目標位址族、隧道耗時與結構化錯誤。至少分開 proxy_auth_failed、gateway_unreachable、target_connect_failed 與 tunnel_timeout。

應用結果

記錄首位元組、完整回應、位元組量、有效結果，以及任務是否遵守授權、robots、條款與速率限制。目標 403/429 不應自動進入代理傳輸評分。

六組受控測試

在自有或明確獲准的閘道與目標上執行有限樣本：

1. 僅 IPv6 閘道，由閘道遠端解析目標；
2. 僅 IPv4 閘道，作為控制組；
3. 雙棧閘道競速，觀察啟動順序與取消；
4. 客戶端解析目標，分離本地選擇與閘道行為；
5. 對優先位址族注入延遲或丟包，驗證有限回退；
6. 兩族都健康，檢查偏好、穩定性與多餘連線。

保持憑證、閘道地區、目標、方法、載荷、逾時和業務目的不變，一次只改變一個變數。需要冷啟動結論時，使用新程序或明確清空連線池。

應記錄的指標

• 閘道 DNS 耗時與位址族分布；
• 第一、第二次連線嘗試的開始時間；
• 勝出閘道位址族與取消延遲；
• 閘道握手、代理驗證與隧道成功率；
• 可觀測的目標位址族；
• 首位元組 p50/p95；
• 完整回應與有效結果率；
• 工作階段中途重設率；
• 回退率與回退成功率；
• 每個有效請求產生的額外連線數；
• 每個授權有效結果的流量與成本。

正確目標不是「IPv6 永遠獲勝」，而是在 IPv6 表現良好時保留 IPv6 偏好，並在異常時有限、快速、可解釋地回退。

採購雙棧代理前要問什麼

• 閘道網域是否雙棧，是否同時提供 IPv4-only 與 IPv6-only 控制端點？
• HTTP CONNECT 能否在脫敏日誌顯示目標位址族？
• SOCKS 主機名稱模式在哪裡解析 DNS？
• 能否固定閘道位址族而不改變目標存取政策？
• 兩種位址族的驗證、白名單、並行與計費是否一致？
• 閘道失敗時是否保證不會直連回退？
• 是否能匯出不含憑證與客戶資料的路線證據？
• 如何區分工作階段重設、目標連線失敗與閘道失敗？

只報告公開出口 IP 的服務商，無法解釋完整的路徑選擇。

發布檢查清單

• 明確 v3 是活躍草案而非最終標準；
• 記錄閘道與目標各自由誰解析；
• 分開記錄兩段位址族；
• 僅使用自有或明確授權測試環境；
• 每次比較只改變一個變數；
• 同時測試冷、暖連線池；
• 對 IPv4/IPv6 進行有限故障注入；
• 確認落敗通訊端、計時器與頁面被清理；
• 連線競速不能複製有副作用的業務請求；
• 目標政策拒絕不進入代理傳輸評分；
• 以穩定性與有效結果衡量，而非只看握手速度。

相關流程可繼續閱讀 98IP 的 IPv6 作用域重試測試、代理池 ASN 集中度稽核和住宅代理工作階段黏著性測試。

FAQ

Happy Eyeballs 會選擇代理出口 IP 嗎？

不一定。本地客戶端通常只決定如何連接代理閘道；閘道可能獨立解析和連接目標，因此出口位址族必須單獨觀測。

IPv6 閘道連線成功能證明端到端 IPv6 嗎？

不能。閘道仍可能透過 IPv4 存取目標。端到端結論需要兩段路線證據。

競速失敗後應該快速輪換代理嗎？

不應該。先區分 DNS、閘道傳輸、代理驗證、隧道建立與目標政策。只有取得傳輸證據且輪換符合授權時才調整路線。

合規說明

只對有權測試的閘道、目標、帳號與資料執行連線實驗。遵守網站條款、robots、隱私義務與速率限制。不得利用位址族競速或代理輪換繞過發布者決定、規避限速或複製有副作用的請求。

來源說明：IETF HAPPY 工作組，《Happy Eyeballs Version 3: Better Connectivity Using Concurrency》工作組 Internet-Draft 第 04 版，2026 年 7 月發布。外部資料位址僅保存在 98IP 內部營運記錄中。