Chrome 152 改进同站请求过滤：更准确地定位代理故障
现代网页很少只访问一个主机。一次用户操作可能同时连接主应用、API、身份认证、静态资源 CDN 和备用端口，而这些请求仍属于同一个站点。使用代理访问时，一旦页面失败，共享的站点关系会让 Network 面板看起来“都差不多”，真正的首个故障点反而容易被淹没。
Chrome 152 改进了 DevTools Network 面板的同站过滤，使其能够更准确地区分域、主机名和端口。这个变化看似细小，却解决了实际排错中的一个关键问题：调查者既能保留完整的一方请求链，又能隔离真正失败的主机或端口。
Chrome 152 具体改变了什么
Network 面板的同站选项用于保留共享站点边界的请求。Chrome 152 改善了以下场景中的过滤准确性：
- 可注册域与其子域之间的关系；
- 同一站点下不同主机名的请求；
- 同一主机名通过不同端口提供的服务；
- 一方请求与真正跨站依赖混合的页面。
Chrome 152 还允许固定 Request # 列。遇到重定向、认证刷新、重试或跨多个同站主机的应用调用时，这个稳定的序号可以保持浏览器观察到的顺序。截图负责展示先后关系，脱敏后的表格或导出则承载技术细节。
需要强调：这只是开发者工具的改进，并不能单独证明代理链路健康。出口地理验证、网关日志、路由核对和阻止直连回退仍是独立控制项。
公开来源说明： Chrome for Developers，《What’s new in DevTools (Chrome 152)》，2026 年 8 月 25 日。
为什么代理事故经常归因到错误主机
假设一个已获授权的市场研究流程先打开应用页面，再读取本地化库存。页面上的报错出现在应用主机，但真实链路可能是：
- 文档通过预期代理出口正常加载；
- 身份认证主机刷新短期会话；
- API 主机拒绝该会话，或者它走了不同路由；
- 应用只显示笼统错误；
- 静态资源主机仍不断返回成功响应。
如果只用宽泛的域名文本过滤，失败的 API 请求会被图片和脚本淹没；如果条件过窄，能够解释故障的认证重定向又会消失。端口也会制造误判：即便主机名相同，443 和获准使用的备用 TLS 端口也可能连接不同的上游服务。
因此，正确的问题不是“这个网站是否失败”，而是：同站请求链中，哪一个请求最先偏离了预期路由、身份状态、响应类型或耗时预算？
可重复执行的 Network 排错流程
1. 固定测试条件
记录浏览器版本、测试市场、代理会话模式、目标操作、获准测试时段和预期主机清单。在客户端或网络层阻止直连回退。如果 Cookie 或 Service Worker 可能改变请求路径，应使用干净配置文件。
不要一开始就反复刷新失败的生产页面。重复操作可能触发目标站限流，也会破坏最初的因果顺序。
2. 保存完整用户旅程
在导航前打开 DevTools，启用 Preserve log，并清除旧记录。从第一个文档请求开始，只捕获一次获准的用户旅程，直到出现可见结果。对照测试必须保持一致的缓存策略。
固定 Request #，同时保留以下列：
- 域或主机；
- 请求方法；
- 状态；
- 类型；
- 发起方；
- 时间与瀑布图；
- 在安全且确有必要时显示远端地址。
序号应作为截图、笔记和脱敏导出的主关联键。不要只依赖时间戳，因为并发请求的时间常常极其接近。
3. 先建立同站边界
使用同站过滤排除无关第三方流量，同时保留完整的一方链路。确认结果中包含预期的应用、API、认证和静态资源主机。
如果某个预期主机消失，先确认它是否实际上属于跨站服务，不要立即认定过滤器出错。身份平台和外包 API 可能在技术上位于站点边界之外，即使用户把它们视为同一产品。
4. 再按主机名和端口缩小范围
按以下顺序从上下文走向证据：
- 查看全部同站请求；
- 隔离应用主机；
- 隔离 API 或认证主机；
- 比较标准端口与备用端口；
- 返回完整同站视图，确认因果顺序没有被切断。
一个主机成功，不代表全部主机都走了相同上游路径。代理绕过列表、浏览器策略、DNS 行为和特定应用传输都可能分裂路由。
5. 标记第一个有意义的差异
找出失败运行与有效对照最早发生差异的请求，逐项比较：
- 请求是否真的发出；
- 重定向目标和状态类别；
- 认证质询或同意状态；
- 连接与 TLS 耗时；
- 首字节时间；
- 响应内容类别，而不是直接保存正文；
- 主机名、端口和发起方；
- 预期代理路由是否由独立证据验证。
后续出现的 500 可能只是症状，真正的首个差异可能是更早的 401、被阻止的预检请求、特定端口的隧道错误，或者根本没有离开浏览器的调用。
6. 只导出最小安全证据
只收集事故处理人确实需要的信息。在共享 HAR、表格或截图前，删除：
- 代理用户名与密码；
Proxy-Authorization和Authorization请求头；- Cookie、令牌、API 密钥和签名查询参数；
- 个人信息与账户标识符；
- 路径或查询包含敏感内容的完整 URL；
- 与故障分类无关的响应正文。
任何交接前都应执行HAR 凭证脱敏检查清单。过滤只减少噪声，不会自动删除秘密信息。
建立证据索引，而不是堆积截图
为每个有意义的请求建立一行：
| 字段 | 用途 |
|---|---|
case_id | 关联整次复现 |
request_number | 保留浏览器观察顺序 |
site_relation | 标记同站或跨站 |
hostname 与 port | 确定真实上游服务 |
initiator_class | 文档、脚本、fetch、重定向或 Service Worker |
route_verified | 区分浏览器观察与路由证明 |
status_class | 避免保存敏感响应内容 |
failure_layer | 浏览器、DNS、代理网关、出口、TLS、目标站或应用 |
ttfb_ms 与 total_ms | 确定延迟出现在哪一层 |
evidence_ref | 指向已脱敏的本地证据 |
failure_layer 必须使用统一词表，否则“代理错误”“网络问题”和“API 失败”可能描述同一事件，后续无法比较。
与有效对照进行比较
一次只改变一个变量。合理的对照包括：
- 同一获准代理会话在两个时段的结果；
- 同一市场的两个代理出口；
- 只有在明确获准时才比较代理与直连；
- 标准端口与备用端口；
- 其他条件不变时比较轮换会话与粘性会话。
应按请求角色和顺序比较，而不是机械地对齐行号。静态资源加载可能不稳定，两次运行中的第 12 个请求未必是同一个资源。
如果目标站对两条路线同时限流，更换代理供应商可能无效。可以使用区分代理故障与目标站限流的流程分别检查网关、出口和目标站信号。
请求重放应放在什么位置
Chrome 152 也支持编辑并重新发送 Network 请求。在理解原始请求链后，这项能力有助于进行控制变量测试。只能重放安全、幂等的请求；不能为了取证而重复购买、账户变更、密码重置或其他会改变状态的操作。
Chrome DevTools 请求重放流程介绍了如何保留基线并一次只改一个变量。同站过滤应先执行，因为它决定哪个请求值得进入受控重放。
必须记录的限制
- 同站是浏览器安全边界，不代表业务所有权。
- 可见的远端地址不能单独证明完整代理路径。
- HTTP 成功不代表内容、地理位置或合规检查成功。
- Service Worker 可能在没有新上游请求的情况下返回响应。
- 浏览器扩展和企业策略可能改变路由。
- 加密应用载荷可能隐藏内容层故障。
- 干净的 Network 记录不会使违反目标站规则的数据收集合法化。
如果必须证明路由，应把浏览器记录与脱敏的代理会话标识、独立获准的出口检查相关联，绝不能把凭证写入事故记录。
采用检查清单
- [ ] 记录 Chrome 与 DevTools 版本。
- [ ] 记录目标操作和全部预期同站主机。
- [ ] 测试前阻止直连回退。
- [ ] 首次导航前启用 Preserve log。
- [ ] 固定
Request #并将其作为顺序键。 - [ ] 先查看同站上下文，再按主机名和端口缩小范围。
- [ ] 标记第一个有意义的差异。
- [ ] 将路由证明与浏览器观察分开记录。
- [ ] 共享前脱敏 HAR、截图和表格。
- [ ] 只重放安全、获准且幂等的请求。
- [ ] 遵守限流、同意、访问规则和数据最小化要求。
常见问题
同站是否等于同一主机名？
不是。多个主机名可以属于同站；用户认为属于同一产品的两个服务也可能是跨站。应检查真实主机清单，而不是依赖品牌名称。
按端口过滤能否证明使用了不同代理路由？
不能。它只能证明浏览器访问了不同的源端点。路由必须通过获准的代理与网络证据独立验证。
是否应该把完整 HAR 附在支持工单里？
通常不应。先提供脱敏证据索引和最少必要请求。完整 HAR 可能包含凭证、Cookie、个人信息和签名 URL。
收到 200 是否可以结束事故？
只有当内容、地理位置、会话行为、延迟和合规检查也通过时才可以。拦截模板或通用回退页面同样可能返回 200。
调试时请求重放是否总是安全？
不是。重放可能重复副作用。必须先理解原始同站链路、删除秘密信息，并且只处理获准的幂等请求。
合规说明
本流程仅适用于已获授权的系统与账户。应遵守目标站条款、适用的 robots 指引、同意要求、隐私义务和限流规则；只收集解决问题所需的最小证据。当服务发出限制信号时立即停止，不得利用代理绕过访问控制或掩盖被禁止的活动。
