用 Chrome DevTools 152 安全重送代理請求
Chrome for Developers 於 2026 年 8 月 25 日公布：Chrome 152 DevTools 的網路面板把原本的 Replay XHR 改為 Resend。新功能不只支援 XHR，也能重送其他可擷取的網路請求，並將一般請求轉換成 fetch() 呼叫，同時保留較完整的重放語意。請求 Payload 面板也新增 Base64、Hex 與 UTF-8 三種二進位或壓縮載荷檢視方式。
這些能力可以縮短代理除錯時間，但「按一下重送」也可能重複建立訂單、沿用失效的瀏覽器憑證，或把敏感請求本文送進除錯環境。因此，專業測試必須在保留網路證據的同時嚴格控制副作用。
請求重送能夠證明什麼
當原始瀏覽器請求出現以下代理相關現象時，受控重送特別有用：
- 回傳
407 Proxy Authentication Required； - 目標站尚未回應，連線或 TLS 階段已失敗；
- 出口地區、ASN 或出口 IP 與預期不符；
- 收到
403、429或5xx，但尚未確定來自代理還是目標站； - 二進位或壓縮請求本文格式異常，上游服務無法解析；
- 同一請求在瀏覽器外成功，卻因瀏覽器標頭、Cookie 或來源規則而失敗。
重送可驗證同一個瀏覽器脈絡是否再次出現相同結果，但不能單獨證明代理有問題。DevTools 位於多個傳輸決策之上，重送的 fetch() 仍可能繼承目前頁面的 Cookie、Service Worker、連線重用、DNS 狀態及瀏覽器政策。
先建立安全測試邊界
開啟網路面板前，先寫明允許存取的目標、測試帳號、代理閘道、地區及最大請求次數。優先使用預備環境端點或無副作用的唯讀請求。
重送前依請求類型判斷：
| 請求類型 | 預設決定 | 必要控制 |
|---|---|---|
無副作用的 GET 或 HEAD | 授權環境通常可重送 | 確認查詢參數不含一次性動作 |
搜尋、預覽或驗證類 POST | 先人工複核 | 使用測試資料並限制次數 |
| 建立、購買、付款、訊息或上傳 | 不得原樣重送 | 改用沙箱端點或明確具備防重複機制的測試路徑 |
| 登入、權杖更新、密碼或同意操作 | 高風險 | 使用專用測試身分，並輪替任何暴露的密鑰 |
| 二進位或壓縮上傳 | 高風險 | 只檢查結構，不匯出含有秘密的原始載荷 |
如果無法說明請求的副作用，就不要點選 Resend。
在不暴露秘密的情況下記錄原請求
開啟 DevTools 的 Network，只有在必須跨頁導覽時才啟用 Preserve log，然後只重現一次已獲授權的失敗。記錄請求編號、UTC 時間、方法、目標主機、狀態、發起者、代理地區及瀏覽器版本。
檢查標頭與載荷時，複製或分享前必須移除：
Authorization與Proxy-Authorization；- Cookie 與防 CSRF 權杖；
- API Key、簽章 URL、工作階段 ID 與 Bearer Token；
- 電子郵件、客戶識別碼及其他個人資料；
- 多部分上傳檔案內容及二進位本文；
- 與診斷無關的內部主機名稱。
若需證明兩次請求使用同一憑證，可保存加鹽指紋，不得把憑證本身放入工單、聊天、截圖或 Airtable。
準備三個對照組
一次重送不是診斷。至少準備三個可比較的嘗試：
- 原始對照： 原瀏覽器脈絡中的失敗請求。
- 不變重送： 不主動修改任何內容，只重送一次。
- 單一變數測試： 只調整一個已核准因素，例如代理地區、代理憑證參照、逾時或非敏感應用程式標頭。
除非它本身就是測試變數，否則目標、方法、本文、瀏覽器設定及測試帳號必須保持不變。若同時更換代理、User-Agent、Cookie 與載荷，即使成功也無法定位真正原因。
在 Chrome 152 中重送
先確認目前 DevTools 的網路請求右鍵選單已出現 Resend。不同 Chrome 頻道及企業發布政策可能使功能到達時間不同。
- 依準確主機與方法篩選網路面板。
- 選取原請求，記錄請求編號與執行脈絡。
- 再次確認請求方法與副作用等級。
- 按右鍵選擇 Resend，只執行一次。
- 不要平行重送，等待回應或預設逾時。
- 比較狀態、遠端位址、各階段耗時、發起者、回應標頭與回應大小。
- 記錄不變重送後，再執行單一變數測試。
如果原請求不是 XHR，Chrome 152 可能把重送呈現為 fetch() 呼叫。執行脈絡與主控台發起來源都是證據，必須一併記錄。
檢查二進位載荷而不是猜測
Chrome 152 在請求 Payload 中為二進位與壓縮本文提供 Base64、Hex 與 UTF-8 解碼。應依問題選擇檢視方式：
- Hex： 檢查魔術位元組、分隔符號、長度與異常位元組變化；
- Base64： 進行適合傳輸的比較或產生指紋；
- UTF-8： 僅在預期內容確實為文字時使用。
能顯示 UTF-8 不代表整個本文都是文字。除非應用程式團隊提供準確編碼器及可防重複的端點，否則不要修改壓縮位元組後直接重送。比較時可在本機計算原始與重送載荷的雜湊，只記錄雜湊、位元組長度、內容類型及編碼。
區分代理故障與目標站故障
| 觀察結果 | 可能層級 | 下一項檢查 |
|---|---|---|
目標站標頭出現前回傳 407 | 代理驗證 | 憑證範圍、驗證方式、閘道政策 |
| 代理 TLS 或憑證錯誤 | 瀏覽器到代理的傳輸 | 信任鏈、主機名稱、檢查政策、系統時間 |
| 沒有目標回應便連線逾時 | 網路或代理路徑 | DNS、閘道可達性、IPv4/IPv6、飽和度 |
帶有目標站回應標頭的 403 | 目標政策或應用程式 | 授權、瀏覽器狀態、目標規則 |
帶有限流標頭的 429 | 目標站限流 | 停止重送、遵守等待時間、降低速率 |
| 直連與代理對照結果相同 | 大多不是代理特有問題 | 應用程式載荷、帳號、來源、Service Worker |
| 只有已預熱分頁的重送成功 | 依賴瀏覽器狀態 | Cookie、連線快取、Service Worker、權杖時效 |
收到 429 後不得加快輪換 IP。限流回應是控制訊號，不是繞過目標限制的許可。
驗證請求確實走了目標路徑
只看到 200 還不夠，還要確認：
- 使用預期的代理閘道與地區；
- 遠端位址或合規出口證據符合預期；
- 代理失敗後沒有靜默直連；
- DNS 政策符合工作流程要求；
- 沒有意外的 Service Worker 攔截；
- 憑證與 TLS 證據一致；
- 憑證沒有進入頁面或主控台輸出。
若瀏覽器工具無法展示完整代理跳點，可用請求時間戳與去識別化後的代理端日誌關聯。關聯 ID 必須是新產生且不包含客戶資料的值。
定義通過、失敗與無法判斷
只有在請求透過已驗證的代理路徑取得預期回應，且負面測試能夠安全失敗時，才能標記為通過。相同授權請求持續在已識別層級失敗時標記為失敗。如果瀏覽器狀態改變、目標不可用、路徑無法核實，或重送機制改變了關鍵行為，應標記為無法判斷。
證據紀錄應包含：
- 瀏覽器與 DevTools 版本；
- 請求編號與 UTC 時間；
- 去識別化後的方法、主機、狀態與耗時摘要；
- 代理閘道標籤、地區及路徑驗證結果；
- 原請求、不變重送及單一變數測試結果；
- 必要時的載荷雜湊與位元組長度；
- 副作用複核、負責人、結論及下一步。
發布前檢查清單
- [ ] 目標、測試身分、代理、地區與請求上限均已獲授權。
- [ ] 請求無副作用，或已轉入具備防重複機制的沙箱。
- [ ] 憑證、Cookie、權杖、個人資料及檔案本文均已去識別化。
- [ ] 修改任何變數前已記錄原請求。
- [ ] 先完成不變重送，再進行單一變數測試。
- [ ] 沒有建立並行重送或自動重試迴圈。
- [ ]
407、TLS、逾時、403、429與應用程式錯誤已依層級歸因。 - [ ] 已驗證代理路徑，且不存在直連回退。
- [ ] 二進位比較只保留雜湊與長度，不保留敏感本文。
- [ ] 通過、失敗或無法判斷都有可重現證據支援。
相關除錯可繼續閱讀 98IP 的代理 407 驗證故障指南、代理診斷檔案去識別化指南，以及區分代理故障與目標限流的方法。
常見問題
Resend 會逐位元組還原線上請求嗎？
不一定。Chrome 152 會把可擷取請求轉換成 fetch() 呼叫。連線重用、自動產生的標頭、Cookie、Service Worker 及瀏覽器政策仍可能改變線上位元組表現，所以它是受控瀏覽器證據，不是逐封包產生器。
可以重送一次失敗的付款或訂單請求嗎？
除非應用程式具備明確的冪等機制且測試已獲授權，否則不要對正式環境端點這樣做。應優先使用沙箱測試身分，並在重送前核實冪等鍵。
為什麼沒有修改代理，重送卻成功了？
第一次可能受到失效連線、冷 DNS、過期權杖、Service Worker 切換或目標短暫異常影響。只能在受控次數內繼續驗證，並比較耗時與執行脈絡，不能直接宣告故障已修復。
應該把二進位載荷匯出給其他工程師嗎？
只有在政策允許且內容完成審核與去識別化時才可以。通常提供雜湊、位元組長度、內容類型、編碼及最小去識別化片段就足夠。
合規說明
只重送已獲授權的請求、帳號、代理、目標與資料。遵守目標條款、隱私要求、速率限制、同意規則、資料最小化政策及地區法律。不得重送可能製造重複交易、洩漏憑證、形成無效流量或繞過存取控制的操作。
研究說明：Chrome for Developers 於 2026 年 8 月 25 日發布《What's new in DevTools (Chrome 152)》。外部研究地址只保存在內部營運紀錄中。
