这个坑最近特别多人踩；91大事件——91网；关于浏览器拦截的说法｜我把过程完整复盘了一遍…大家自己判断
前言 最近看到很多人在讨论“91大事件”，随之而来的是大量关于浏览器拦截、网站被标记为危险或遭遇重定向的说法。网上信息混杂，我亲自把整个过程从发现到复盘、排查、复现路线都走了一遍，把发现写成可操作的复盘记录和技术判断，供大家参考，最后结论留给你们自己判断。
一、我为什么要复盘
- 好奇：看到大量用户报告相似问题，想弄清到底是同一个问题还是不同原因混合在一起。
- 可验证：把信息从听说变成可复现的步骤，降低假设与传言的误差。
- 给受影响者参考：如果你的网站或浏览时遇到类似问题，复盘中的检查点能帮你快速定位。
二、时间线（简要）
- T0：社交平台出现大量截图，显示“网站被浏览器拦截”或“可能包含恶意软件”的提示。
- T1：我在不同网络环境（家庭、公司、移动）和不同浏览器（Chrome、Firefox、Edge）进行了访问测试。
- T2：抓包、查看控制台、安全面板，使用命令行工具和第三方检测服务进行核验。
- T3：定位到若干可能触发拦截的技术点（证书问题、第三方脚本、恶意重定向等）。
- T4：针对性修复与再次检测（如果你是站点管理者，这一步是你需要做的）。
三、浏览器拦截常见的几类触发原因（我在复盘中遇到或验证过）
- TLS/证书错误：例如证书过期、证书链不完整、域名与证书不匹配。浏览器安全提示通常会比较明确（ERRCERT*）。
- 被列入安全数据库：Google Safe Browsing、Microsoft SmartScreen 等会基于举报或扫描把 URL 标记为钓鱼/恶意。
- 恶意或侵入式重定向：站点被注入脚本，访问时会跳转到广告或欺骗页面，浏览器或安全软件可能拦截。
- 第三方资源问题：页面加载的第三方 JS/广告/CDN 链接被标记或被注入恶意内容，导致主站被连带拦截。
- 被误报或缓存滞后：安全服务的历史数据或缓存可能在问题已解决后仍然标记网站。
- 非安全混合内容：HTTPS 页面加载 HTTP 资源（尤其是脚本/iframe）时，安全策略可能导致警告或阻止加载。
四：我用过的排查工具与具体方法（可复现步骤）
- 浏览器开发者工具（Network/Console/Security）
- 打开 DevTools → Console 查看是否有混合内容、脚本错误或安全错误。
- Security 面板可查看证书链与 TLS 信息。
- curl 与 openssl（命令行）
- curl -I https://example.com 查看响应头与重定向。
- openssl s_client -connect example.com:443 -servername example.com 查看证书链和协商信息。
- 抓包工具（Fiddler/Wireshark/Charles）
- 观察请求与响应，寻找可疑的重定向（302/307）或外部脚本请求。
- WHOIS 与 DNS 检查
- 核验域名到期、解析是否被篡改（DNS 劫持常会导致突然大量误报）。
- 第三方检测
- VirusTotal/Google Transparency Report/URLVoid 等，查看是否有多引擎标记。
- 日志与文件校验（站点管理员）
- 查看服务器访问日志、错误日志、最近的文件改动、cron 任务、SSH 登录记录。
- 本地隔离测试
- 在无扩展、无登录状态的无痕窗口及不同网络进行对比测试，排除浏览器扩展或本地代理导致的问题。
五：我复盘中发现的几个典型场景（客观陈述）
- 场景 A：证书链不完整，某些浏览器提示“有问题的证书”，用户在微博/论坛传播截图，引发大量关注。修复证书链后问题消失，但安全服务缓存滞后，仍需申请解除标记。
- 场景 B：站点嵌入的第三方广告脚本被黑或被其供应商误判为恶意，触发 Safe Browsing 列表。删除或替换该资源后逐步恢复。
- 场景 C：域名曾短时间被用于钓鱼或恶意跳转，随后恢复正常，但安全数据库里的历史记录导致持续误报，需要向平台提交复核。
- 场景 D：个别用户的浏览器扩展或本地代理将正常页面误判为危险（误报），该类情况在集中讨论中经常被误认为是服务器端问题。
六：给站长和普通用户的可操作建议（简短、直接）
- 站长（我做这些排查并复测通过）
- 检查并修复 TLS/证书问题；确保证书链完整、加密套件合理。
- 审计页面中所有第三方脚本，临时移除可疑广告/资源，观察是否恢复。
- 检查服务器文件变更、未授权的脚本或上传目录权限，排查被入侵证据。
- 使用 Google Search Console / Bing Webmaster 报告安全问题并申请人工复核。
- 加强账号与服务器口令、关闭不必要的服务，启用日志告警。
- 普通访问者
- 遇到浏览器警告不要贸然忽略；可在另外的网络或设备上再次验证。
- 用 VirusTotal 等工具批量检查可疑链接，或在沙箱/虚拟机中做进一步测试。
- 若你是站点常用者，联系站点管理员并把浏览器控制台/警告截图发给对方，方便定位。
七：结论（我自己的判断） 在我复盘的样本里，“浏览器拦截”并不是单一成因。确实有因站点被注入或被利用而引发的拦截，也存在证书与第三方资源导致的误报，以及本地或扩展引发的误判。看到群体性传播时，倾向于先做技术核验再下结论：有时是站点问题，有时只是连带影响或滞后记录。
大家自己判断：如果你关心某个站点是否“被封”或“恶意”，把本文的检查点作为第一轮核验清单；若确认是站点端问题，上述修复步骤能较快恢复；若判断为误报，则通过官方申诉途径更为稳妥。