有人在评论区提醒；91网 ｜ 关于浏览器拦截的说法，我把过程完整复盘了一遍…我不下结论，但信号很明显
有人在评论区提醒；91网 | 关于浏览器拦截的说法，我把过程完整复盘了一遍…我不下结论，但信号很明显
前言 最近有人在评论区说我的网站被“浏览器拦截”了。作为做站多年的人，我把整个排查过程从头到尾复盘了一遍，记录下可复现的步骤、每一处证据与观察结果，方便大家判断和复现。我不会在文末下结论，但把所有关键信号列清楚，留给有兴趣的人去读与判断。
测试环境与准备
- 平台：Windows 11（Chrome 116/Edge 116）、macOS 13（Safari 16/Chrome 116）、Android 13（Chrome）。
- 网络：家庭宽带（ISP A）、公司内网（ISP B）、手机数据（运营商 C）。
- 工具：浏览器开发者工具（Network/Console）、curl、openssl s_client、dig/nslookup、traceroute、Fiddler/Wireshark（抓包）、无痕/扩展禁用模式。
- 清单：先在浏览器禁用所有扩展（包括广告拦截、隐私插件），并在不同网络与不同设备上重复测试，排除单一环境导致的误判。
排查步骤与观测记录（可复现） 1) 直接访问与浏览器控制台
- 在Chrome打开目标页面，观察Network与Console。
- 现象A：页面在加载过程中出现“net::ERRBLOCKEDBY_CLIENT”若干条，资源多为第三方脚本/广告资源。
- 现象B：控制台显示“Blocked a frame with origin … from accessing a cross-origin frame.”或“Refused to display '…' in a frame because it set 'X-Frame-Options' to 'DENY'。”（与嵌入/iframe相关）。
- 现象C：个别请求返回403/451，或直接被浏览器中断。
2) 在无扩展的无痕窗口重复
- 通过无痕/禁用扩展重试后，大部分 net::ERRBLOCKEDBY_CLIENT 消失，说明这类被拦截是由浏览器扩展（或内置广告拦截）导致，而非服务器直接返回。
- 但仍有少量请求在不同设备上都被阻断，提示问题可能不止扩展。
3) curl 与 openssl 检查
- curl -I/get/ 页面头部得到 200 OK，并能拿到完整 HTML；用 --location 跟随重定向同样能拿到资源。
- openssl s_client -connect domain:443 显示证书链正常、主机名匹配，无明显证书错误。
- 在某些网络（公司内网）curl 返回的响应被替换为公司网关页面（HTTP 200，但内容为“安全提示/访问受限”），说明网络层或中间代理会修改内容。
4) DNS 与路由
- dig/ nslookup 显示不同网络下域名解析结果一致，但 traceroute 显示在到达服务器前存在不同的中间节点（ISP 的透明代理/缓存节点）。
- 在手机数据网络上能正常访问，而在某些公司网络上被改写或拦截，提示可能存在网络策略或设备级过滤。
5) 第三方安全/云防护（Cloudflare/WAF）与响应头
- 检查响应头：存在 Cloudflare/fastly/其他 CDN 的标识时，返回的安全页面或挑战页面会出现 503/403 或 JavaScript 验证。
- 部分用户看到的“拦截页面”与 CDN 的挑战样式一致，但同一时间我在另一网络并未触发挑战，暗示触发条件与访问路径/请求头有关（IP、UA、Referer、Cookie）。
6) CORS 与 CSP
- 控制台中出现“Access to fetch at '…' from origin '…' has been blocked by CORS policy”的提示时，通常是资源端未允许跨域或请求方式不匹配；这类错误由服务器配置决定，不属于浏览器“自动拦截”。
- Content-Security-Policy 生效时会阻止特定脚本/样式注入，控制台会有对应的阻止日志。
综合信号（不下结论，只列事实）
- 信号一：net::ERRBLOCKEDBY_CLIENT 在大多数案例对应扩展或广告过滤器，禁用扩展后消失。
- 信号二：个别网络出现内容被替换或返回安全提示，这指向网络层（ISP/公司网关/防火墙）或中间代理进行的拦截或替换。
- 信号三：CORS/CSP/X-Frame-Options 等浏览器策略会在控制台留下明确错误，这些是站点或资源的配置问题，而非浏览器“神秘地”把页面挡住。
- 信号四：Cloudflare 或其它 WAF/CDN 在特定条件下会发起挑战页面或返回拦截页面，不同访问路径（IP/UA/Cookie）会导致体验差异。
- 信号五：证书与 TLS 层面在我的测试中没有普遍异常，排除了大规模证书问题的可能性。
给技术同好和普通用户的可复现步骤（简化）
- 普通用户：用浏览器的无痕模式打开页面，关闭所有扩展，换用手机数据或另一网络看是否正常。
- 技术人员：用 curl -v/openssl s_client/dig/traceroute 分别检查 HTTP 响应、证书链、DNS 和路由；在不同网络重复以找出是否为网络层面的问题；查看响应头里的 CDN/WAF 标识与 CSP/CORS 相关头部。
最后的话（不做结论） 我把每一步记录下来，让任何有兴趣的人可以按步骤复现。结论我先不下，但从以上事实可以看出，所谓“浏览器拦截”并非一个单一的、统一的原因：有的是浏览器扩展在做广告拦截，有的是网络层的透明代理或安全网关在替换响应，还有的是服务器配置（CORS/CSP/X-Frame-Options）导致浏览器按规范阻止资源加载。信号指向多种可能性并存，关键在于把握复现条件：设备、网络、扩展、请求头都可能改变结果。