Chrome 152 擴展請求重送：代理故障重現方式有何改變

SEO 標題： Chrome 152 請求重送與代理故障診斷

SEO 關鍵字： Chrome 152, 請求重送, 代理排錯, DevTools Network, 代理故障重現

SEO 描述： Chrome 152 將 Replay XHR 擴展成適用於可擷取請求的 Resend。本文說明它如何改善代理故障重現，以及不能取代哪些測試。

Chrome 152 為 Network 面板帶來一項實用更新：原本的「Replay XHR」改名為「Resend」，並擴展到所有可擷取的網路請求。Chrome 會把重送轉換成 fetch()，盡量保留原始請求，並顯示執行環境與主控台發起來源。

對代理維運、網頁測試、廣告驗證和獲授權的資料收集而言，團隊可以不重跑整段自動化流程，直接重現單一失敗請求。但瀏覽器側重送並不等同完整端到端重現。

Chrome 152 更新內容

重送不再只涵蓋 XHR。Network 面板中的可擷取請求能轉換為 fetch() 再次送出，並提供更清楚的執行環境與發起者資訊。

同版還加入二進位負載的 Base64、十六進位和 UTF-8 解碼、固定請求編號欄、改善同站主機篩選，以及自動解碼查詢與表單參數。這些能力可降低多主機、大量相似請求或編碼負載的比對錯誤。

為何代理團隊應關注

完整瀏覽器流程包含導覽、預載、分析、圖片、背景呼叫、重試與工作階段更新。單一 API 回傳 403、429 或異常內容後，重跑全流程可能同時改變 Cookie、時間、出口 IP 與目標狀態。

請求重送可形成較窄的診斷迴圈：保留失敗請求；記錄編號、發起者、時序、回應類別與出口；先在相同路由重送一次；再只改變一個獲允許變數；最後比較傳輸、HTTP 和業務結果。

Resend 無法重現什麼

兩次實驗仍不會完全相同。重送發生得更晚，Cookie、CSRF 權杖、一次性 nonce、限流時間窗和代理工作階段出口都可能改變。

重送成功不代表原故障一定來自代理，也可能只是目標暫時性錯誤已恢復；失敗則可能是權杖已過期。串流請求本文、瀏覽器管理的安全狀態、非 fetch 協定或依賴精確導覽順序的請求，仍需完整瀏覽器回放。

安全的代理比較流程

1. 固定證據

重送前保存請求編號、時間、方法、目標主機、狀態、首位元組時間、總耗時、代理出口、位址族與脫敏執行 ID。截圖和匯出記錄不得包含密碼、Cookie、權杖或個人資料。

2. 判斷冪等性

GET 與 HEAD 通常較適合重現，但 URL 仍可能改變狀態。POST、PATCH、PUT、DELETE 可能建立重複任務、產生費用或修改資料。沒有明確授權與隔離環境時，不得重送有副作用的請求。

3. 建立基線配對

先透過目前路徑重送，再在允許條件下保持工作階段與內容穩定，改由已知健康路徑比較。只有待測路徑失敗時，檢查驗證、DNS、TLS、出口、地區與 ASN；兩條路徑都失敗時，檢查目標、工作階段、負載和應用狀態。

4. 保留目標訊號

記錄 Retry-After、挑戰回應、重新導向與內容結構差異。HTTP 200 不一定代表業務成功，挑戰頁或空結果也可能回傳成功狀態。

5. 必要時才擴大

單次重送仍無法歸因時，應改用小規模、交錯執行的對照矩陣，不要連續重送。過多重複會製造新的限流訊號。

證據判讀表

維運檢查清單

• 區分單一請求重送與完整流程回放；
• 只重送安全且獲授權的請求；
• 對驗證資訊和個人資料脫敏；
• 同時保存出口、工作階段、時序與業務結果；
• 每次只改一個變數並限制樣本；
• 遵守 Retry-After、robots 指示、目標條款和合約限制；
• 不得以重送或代理輪換繞過存取控制。

常見問題

Chrome 152 會完全複製原請求嗎？

它會轉換為 fetch() 並盡量保留請求，但時間、應用狀態、權杖、Cookie 和代理工作階段可能改變。

POST 可以安全重送嗎？

技術上可行不代表營運上安全。應使用隔離測試環境或明確冪等鍵，取得授權並避免重複或計費操作。

它能取代自動代理測試嗎？

不能。Resend 適合互動診斷；迴歸測試仍需受控腳本、穩定測試資料、明確逾時、結構化指標和安全取消。

來源與合規說明

來源：Chrome for Developers，《What’s new in DevTools (Chrome 152)》，2026 年 8 月 25 日。

只在獲授權的系統和資料上使用，遵守法律、合約、隱私義務、robots 指示、公開限速與目標條款。

可搭配代理與目標站對照路由方案及可取消的瀏覽器代理測試建立可重現流程。