IPv6-only 網路中的代理 NAT64 與 DNS64 相容性測試
代理在辦公室雙棧網路上全部通過，不代表它能在 IPv6-only 的行動或企業網路穩定運作。閘道網域可能解析異常，應用程式可能寫死 IPv4 位址，本機 DNS 與代理端 DNS 可能混淆，甚至通道建立後才在協定轉換或目標擷取階段失敗。
本指南把這些風險轉成可重複的驗收流程，適用於住宅代理、輪換代理、靜態代理閘道，以及合規的網頁擷取、廣告驗證、市場研究與資料蒐集。
先拆開兩段路徑
DNS64 為只有 IPv4 位址的名稱合成 IPv6 回覆；NAT64 在 IPv6 用戶端與 IPv4 目標間轉換流量。兩者都無法自動修復應用程式內部的 IPv4 假設。
代理流程必須分開測試：用戶端到代理閘道的解析、連線與驗證；代理閘道到目標的遠端解析、出口選擇、TLS 與內容驗證。代理交握成功只能證明第一段可達。
建立四格驗收矩陣
在同一組已授權目標測試：
- 雙棧用戶端存取雙棧目標；
- IPv6-only 用戶端經 DNS64/NAT64 存取 IPv4-only 目標；
- IPv6-only 用戶端存取支援 IPv6 的目標；
- 經核准的 IPv4 控制路徑存取同一個 IPv4-only 目標。
保持方法、標頭、驗證方式、工作階段策略、並行量與內容驗證規則一致。樣本要能暴露間歇問題，但重試必須有限制。
七步驗證流程
1. 在實際測試網路解析
從 IPv6-only 環境解析代理閘道與目標名稱，記錄 A、AAAA、解析器、TTL、查詢延遲及是否疑似合成。不要以另一個網路的查詢結果替代。
優先使用主機名稱，不要嵌入 IPv4 字面值，也不要自行把熟悉的前綴接到 IPv4 位址；實際網路可能使用專屬轉換前綴。
2. 區分本機 DNS 與代理 DNS
若協定支援，分別測試用戶端解析目標與代理端遠端解析。SOCKS5 遠端 DNS、HTTP CONNECT 與應用層代理設定可能走不同路徑。每筆資料都要清楚標示解析位置。
3. 驗證閘道傳輸
記錄位址家族、連線時間、驗證結果、代理協定與通道建立。TLS 代理閘道必須依主機名稱驗證憑證；直接換成 IP 會破壞驗證並掩蓋真正問題。
4. 同時涵蓋 IPv4-only 與 IPv6 目標
只使用自有或明確獲授權的目標。除了狀態碼，還要驗證預期內容標記、回應大小範圍及目標端可觀察的出口屬性，避免把攔截頁或轉換錯誤頁當成成功。
5. 測試輪換與黏性工作階段
對輪換住宅代理分別執行逐次輪換與限定時間的黏性工作階段。確認協定轉換沒有改變預期工作階段鍵，也沒有造成特定位址家族的異常抖動。比較有效結果率，而非只看 IP 變化。
6. 注入受控失敗
在隔離測試帳戶與授權端點測試無效網域、關閉的連接埠、過期測試憑證與不可達端點。DNS、傳輸、驗證及目標錯誤必須回傳不同類別。不要對無關公共系統做故障注入。
7. 驗證復原與快取
修正條件後繼續觀察 DNS TTL 與連線池重用。過期的合成位址或舊連線可能讓已復原路徑仍看似故障。分別記錄第一個復原請求與穩定階段。
驗收指標
只有 IPv6-only 單元達到業務門檻時才核准上線：
- 閘道 DNS 與連線成功率；
- 代理驗證與通道成功率；
- IPv4-only 與 IPv6 目標的有效內容率；
- 有效結果的 p50、p95、p99 延遲；
- 請求地區與觀察出口地區的一致性；
- 重試放大受控；
- 黏性工作階段穩定；
- 錯誤分類清楚且可操作。
同時比較 IPv6-only 與雙棧控制組的絕對差距，不要脫離基準只看單一成功率。
常見故障判斷
閘道名稱可用，但 IPv4 字面值失敗： 應用程式繞過 DNS64，改用名稱及位址家族無關的 API。
HTTP 代理正常但 SOCKS 失敗： SOCKS 用戶端可能在本機解析或使用單一位址家族呼叫，檢查遠端 DNS 模式。
通道成功但內容無效： 檢查代理到目標的路徑、TLS 主機名稱、出口家族、目標政策與攔截頁辨識。
切換網路後第一個請求失敗： 排查過期 DNS、快取的轉換前綴、舊連線及重試時機。
出口地區異常： NAT64 可達性與代理地理定位是兩個問題，重新核對請求地區、觀察證據及回退政策。
發布檢查清單
- [ ] 閘道及目標未寫死 IPv4 位址。
- [ ] 已在真實 IPv6-only 網路內完成解析。
- [ ] 本機 DNS 與代理 DNS 分開標示。
- [ ] IPv4-only 與 IPv6 目標皆回傳有效內容。
- [ ] 驗證、通道、TLS、HTTP 與內容錯誤可區分。
- [ ] 輪換與黏性工作階段達到有效結果目標。
- [ ] 已觀察 TTL 與連線池復原。
- [ ] 重試有上限、有退避且可計量。
- [ ] 紀錄不含密碼、權杖、Cookie 或不必要的完整 IP。
常見問題
代理出口支援 IPv6，是否代表 IPv6-only 用戶端相容？
不是。用戶端可能在抵達代理閘道前就因解析或傳輸失敗，必須分兩段驗證。
所有請求都應使用用戶端網路的 DNS64 嗎？
不一定。解析位置取決於代理協定以及隱私與路由目標，重點是明確知道解析位置並分別測試。
公共 IPv6 測試頁能取代本流程嗎？
不能。它無法驗證代理驗證、遠端 DNS、出口輪換、目標內容與真實工作負載。
合規與安全
只測試自有或已授權的目標與帳戶，遵守 robots 規則、服務條款、速率限制、隱私義務和適用法律。減少網路識別資料留存，診斷紀錄不得保存代理憑證或客戶資料。
下一步可執行多區域路由政策測試、代理地理定位共識測試與DNS TTL 容錯移轉驗證。
資料說明：網際網路工程任務組 RFC 7050，2013 年 11 月；RFC 8880，2020 年 8 月；RFC 9872，2025 年 9 月。Apple Developer《Supporting IPv6 DNS64/NAT64 Networks》，2026 年 9 月複核。
