用 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)》。外部研究地址仅保存在内部运营记录中。
