有网友翻出旧版对比 ｜ 91网 - 关于浏览器拦截的说法｜我把过程完整复盘了一遍。不排除还有后续

有网友翻出旧版对比 | 91网 - 关于浏览器拦截的说法｜我把过程完整复盘了一遍。不排除还有后续

前言 最近有网友把91网的旧版页面翻出来，对比新版后提出“浏览器拦截”的质疑。为了把事情说清楚，我把整个复现与排查过程做了完整复盘，保留关键证据（网络请求、控制台日志、HAR 文件截图等），并把可能的原因与可行的解决方案列出来，方便站方和用户参考。文末会说明下一步我计划做的跟进动作。

一、我复盘的目标与范围

• 目标：判断浏览器“拦截”说法是否成立，找出拦截发生的触发条件与责任方（浏览器、安全软件、第三方脚本或站点本身）。
• 范围：以桌面 Chrome、Firefox 与 Edge 为主，覆盖普通用户环境与开发者模式下的调试复现；同时在移动端（Android Chrome）做简要验证。
• 工具：浏览器开发者工具、HAR 捕获、Fiddler/Wireshark（做必要的包抓取）、不同网络环境（家用 NAT、企业代理、手机热点）、关闭/开启主流扩展（Adblock、隐私类插件）、清空缓存与无痕模式。

二、复现步骤（可直接复现或供站方检测）

1. 在同一台机器上准备两套测试：一套为“清洁环境”（无扩展、无登录、清除缓存），一套为“用户环境”（装了常见拦截扩展、登录状态）。
2. 打开目标页面，记录加载时间线（Network）、Console 错误、页面渲染顺序（Performance）。
3. 捕获完整 HAR 文件并保存。若出现资源无法加载或被阻止，查看对应请求的响应头与状态码。
4. 逐步启用/禁用扩展、切换到无痕模式、使用不同浏览器以及移动端，观察是否有一致性触发条件。
5. 若怀疑是服务器端或第三方脚本行为，把页面中的外部脚本（CDN、第三方广告/统计/跳转脚本）暂时移除或替换为本地静态资源，重复测试。
6. 在怀疑被“拦截”时截取 DevTools 中的“Security”面板和控制台的 CSP、Mixed Content 报错截图。

三、我得到的关键发现（结论导向）

• 多数“被拦截”现象与浏览器的安全规则或用户端扩展有关，而非浏览器无差别封杀整个站点。典型触发条件包括：
• Mixed Content（HTTPS 页面请求 HTTP 资源）导致资源被浏览器默认阻止；
• CSP（内容安全策略）或浏览器内置的拦截策略拒绝加载被标记为不安全的脚本/iframe；
• 第三方脚本（广告、自动跳转、统计）使用了可疑行为（频繁重定向、隐蔽弹窗），被浏览器或扩展识别并阻止；
• 用户端的广告拦截或隐私插件根据 URL 模式或脚本签名拦截资源。
• 在清洁环境下，页面大多数资源能正常加载，说明站点基础服务并未被统一封禁；但在带扩展或特定浏览器安全策略下，确实有资源被阻止，造成页面功能受限或体验异常。
• 旧版与新版的对比显示：新版在某些第三方依赖或跳转逻辑上做了变化，这些变化可能把某些请求暴露给浏览器的拦截规则（例如把跳转从同源变为跨域、或引入了新域名的脚本），从而触发拦截。

四、给站方的技术建议（优先级从高到低）

• 统一使用 HTTPS，移除或替换任何 HTTP 资源，消除 Mixed Content 的根源。
• 检查并合理配置 Content-Security-Policy（CSP），避免使用过于宽泛或含有不安全来源的策略；在调试期开启 CSP 报告以便收集被阻止的条目。
• 审核第三方脚本与广告代码，尤其是自动跳转、弹窗或频繁重定向的逻辑；对外部依赖做健康检测与降级方案（本地缓存或替换）。
• 减少跨域复杂度，确保必要的跨域请求有正确的 CORS 返回头，并避免在首屏加载中引入大量第三方请求。
• 对于确需用到的行为（例如弹窗、外部跳转），给出明确的用户交互与提示，降低被浏览器判定为“恶意”或“扰乱体验”的风险。
• 为技术支持准备复现包（HAR、控制台日志、环境信息），提高与用户或厂商沟通的效率。

五、给普通用户的排查建议（快速定位）

• 先在无痕/隐身窗口打开页面，以排除扩展干扰。
• 临时禁用广告拦截与隐私类扩展，确认是否为其导致。
• 清理浏览器缓存并重启浏览器，或换个浏览器尝试。
• 若使用企业网络或带有中间件（代理/防火墙），换成手机热点测试，以确认网络层是否介入。
• 如需提交给站方，请一并附上浏览器版本、操作系统、网络环境截图与 HAR 文件，便于快速定位问题。

六、我下一步计划（不排除后续）

• 整理并公开我的 HAR 文件与关键截图（隐私信息做脱敏处理），让站方或有兴趣的技术同好复查。
• 针对可复现的问题向站方提出修复建议，并在修复后再次复测验证。
• 如有必要，会尝试与主流浏览器安全团队或第三方脚本提供方沟通，确认是否存在被误判或需要白名单的情形。

结语 把旧版和新版做对比有助于发现问题的起点，但判断“浏览器拦截”是否成立，需要把复现环境、开发者工具证据和第三方组件都纳入考量。我这次的复盘把证据链尽量完整地留了下来，偏向技术与事实而非简单下结论。如果你是站方，希望这份复盘能当作排障的路线图；如果你是普通用户，按上面的快速排查流程操作，大多数情况下能找到问题所在或者临时绕过。后续我会把进一步的检测结果同步出来，欢迎有补充证据或不同结论的朋友交流。