AdGuard Windows 版十月事件报告：事后分析
近期，部分 AdGuard Windows 版用户遇到了应用程序运行问题。在发布 7.22 版本后，我们发现该更新会导致浏览器出现间歇性页面加载故障。虽然 Chrome 浏览器的问题很快得到了缓解。但 Firefox 的修复耗时较长，因为该漏洞由测试阶段未发现的特殊因素组合引发，其重现难度较高且发生频率较低。
截至本文原文发布时，我们已推出热修复补丁，即 AdGuard Windows 版 v7.22.1，将彻底解决该问题。请确保您的应用程序更新至最新版本以获得稳定体验。若有用户在其它平台使用 AdGuard，无需任何操作，各项功能均运行正常。
此次疏忽给大家带来不便，我们深表歉意。这属于偶发性技术事件，我们将通过流程优化杜绝此类情况再次发生。在解决技术问题之余，我们已同步完成内部流程审查，并实施多项改进措施以预防类似情况。
下文将完整呈现事件时间轴，随后我们将提供技术细节说明及已采取的防范措施。
事件时间轴
10月2日
我们发布了 AdGuard Windows 版 v7.22
10月4日
一位用户提交了 GitHub 问题报告 ，反映升级至 v7.22 版本后出现页面加载异常，最终触发超时错误。
10月6日
质量检测团队启动问题排查但未能重现该错误。当日已将问题升级至开发部门，并启动内部技术研讨。
10月16日
随着更多用户加入 GitHub 讨论，问题报告与关注度持续累积。遗憾的是，质量检测团队此时未按规范执行该级别问题的升级流程。由于用户反馈存在不一致性，且漏洞重现面临严峻技术挑战，团队误判该问题源于早期版本迭代，认为无需热修复补丁。尽管任务标记为「P1：紧急级别」，但因未能及时升级处置，导致错失关键处理窗口，最终被推迟至后续计划版本解决。
10月30日
经过24天后，该问题在内部环境中复现，使我们得以全面评估其影响范围。在成功重现漏洞后，我们立即启动热修复补丁（v7.22.1）开发工作。期间主要精力投入于稳定重现漏洞与定位根本原因，期间多个技术假设被逐一验证排除。
调查过程中，我们还发现 Firefox 浏览器存在的 QUIC 连接相关漏洞，该漏洞会进一步延缓页面加载并增加调试复杂度。同时发现在 AdGuard VPN 兼容模式（Wintun 禁用）与 AdGuard 并行运行时，存在 QUIC 连接过滤失效问题 。
11月1日
我们部分确定了问题成因并找到重现方法。在 DnsLibs（我们的 DNS 过滤引擎）中实施了修复，并发布了 Nightly 夜间构建版本进行测试。
11月5日
根本原因被精确定位，位于 CoreLibs（AdGuard 过滤引擎）的路由循环检测组件漏洞。问题被迅速修复，随后发布了第二个 Nightly 夜间构建版本。
11月6日
夜间构建版测试表明，初始修复解决了大部分 TCP 连接问题，但部分 UDP 相关异常仍然存在。为最大限度减少对用户的影响，我们决定分两个阶段部署修复：首先通过第三个 Nightly 夜间构建版本处理这些遗留问题（包括最终库修复和驱动程序指令更新），随后我们于当日完成 v7.22.1 补丁版的准备与全面测试并发布该版本。
技术细节
漏洞说明
AdGuard Windows v7.22 版中的该漏洞会导致 Firefox 加载特定页面时出现偶发性、不可预测的卡顿现象。它对 Chrome 用户的影响相对较轻。该问题始于 CoreLibs v1.19 引入的路由循环防护功能，该机制本用于防止流量循环返回自身。
该漏洞主要有两个成因。首先，编程错误导致某个端口被排除在路由循环检查之外，这意味着部分合法的过滤连接（例如浏览器请求）可能被阻塞。这种情况由 AdGuard 发起的某些服务请求（如 OCSP 请求）触发。在此类请求之后，下一个浏览器连接将被中断。
其次，该检查被错误地应用于已建立的连接，导致产生不必要的连接阻塞。
为何需要路由循环防护？
当流量循环返回其源应用程序时，就会发生路由循环。此类循环可能导致连接速度变慢和 CPU 使用率升高。正常情况下，这些情况不会发生，但由于与其他软件的交互，路由循环仍可能出现。为防止这种情况，AdGuard 会按源地址跟踪外出连接，并终止任何返回同一地址的连接。
为何对 Chrome 影响较轻？
由于仅影响服务请求之后的首次连接，Chrome 用户较难察觉该问题。这是因为 Chrome 在连接重置后会自动重试相同网络请求。
而 Firefox 用户受到的影响更大是因为该浏览器在设计上不包含网络错误后的自动重试机制，使得问题表现更为明显。
AdGuard Linux 版与 Android 版是否受影响？
该问题未在 CLI 版本的 v1.19 中发现，尽管新功能始终优先通过 AdGuard CLI 部署，旨在集成至图形界面应用前发现并修复主要问题。此次漏洞仅在 Linux 自动模式下触发，且主要影响 Firefox 浏览器。符合该使用场景的用户基数较小，因此未收到相关问题报告。
同样使用 CoreLibs 1.19 的 AdGuard Android 版 v4.12 也未出现该问题，因为其进出连接地址不同，无法满足触发此漏洞的必要条件。
问题诊断过程
该问题的诊断异常困难。由于 AdGuard 开启的服务连接相对较少，且多次复现尝试常因 OCSP 请求缓存机制导致漏洞无法显现。此外，该问题每次仅影响单个下游连接。Chrome 用户基本未受影响得益于其自动重试机制，而 Firefox 则因不进行网络错误重连，导致用户直接受到冲击。
同步发现的 Firefox 相关漏洞
在追踪该隐蔽漏洞的过程中，我们发现半数问题报告呈现不同症状，且描述的问题在旧版AdGuard中同样重现。由此我们另发现一个影响 Windows 版 Firefox 的 HTTP/3 连接漏洞。
简言之，当网站声明支持 HTTP/3 时，Firefox 会立即尝试建立连接，即使该连接尚未就绪。由于 AdGuard 默认不过滤 HTTP/3 流量，启用 HTTPS 过滤的应用程序会直接阻断 HTTP/3 连接。
通常浏览器会采用「Happy Eyeballs」等算法选择最优协议，但 Windows 版 Firefox 在获知网站支持 HTTP/3（例如通过 HTTPS 类 DNS 记录）时，会立即尝试建立 HTTP/3 连接，并将请求分配至尚未建立的 HTTP/3 通道，无视当前存活的 HTTP/2 连接。若 HTTP/3 不可用，将导致网站加载停滞 20-30 秒，之后请求才会被「重新分配」至存活的 HTTP/2 连接。
目前本错误已通过错误报告提交好了。作为预防措施，AdGuard 已修改 HTTPS 类 DNS 记录，在禁用 HTTP/3 过滤时排除 h3 ALPN 参数。这样可以在 HTTP/3 被 AdGuard 阻断时，向浏览器隐藏其可用状态。
修复方案
本次修复分两个阶段实施。
第一阶段修正了连接匹配逻辑，确保端口被正确纳入检测范围。此举解决了大部分问题，但由于 Windows 会复用近期关闭连接的端口，仍存在少量误判情况。11月5日晚发布的 Nightly 夜间构建版已帮助大多数用户恢复正常使用。
然而，在 AdGuard 日志中仍能观察到该问题的残留痕迹。我们发现这仅是局部解决方案，仅修复连接匹配算法并不足够，因为 Windows 在套接字释放后一秒内即可复用外出连接端口。这导致具有相同地址和端口的无关连接被错误判定为循环连接，引发新型误判。
虽无明确的新故障报告（用户均反馈运行正常），但潜在受影响用户范围可能仍很广。由此我们启动第二阶段修复：针对上述场景进行优化，最终形成彻底解决问题的 v7.22.1 热修复补丁。
预防措施
该问题未能及早发现，主要源于常规测试环境下复现难度较高，以及这次对用户反馈的疏忽。
我们正在更新质量保障与开发流程，重点加强三方面：实施更严格的过程监控、提升自动化测试水平、强化团队内部测试与沟通机制。通过这些措施，我们致力于杜绝类似事件再次发生，确保为所有用户提供可靠的 AdGuard 使用体验。
质量保障团队工作流程优化
质量保障团队将更密切追踪 GitHub 工单的评论量与赞同数。为最大限度降低人为因素影响，相关监控将不再仅依赖人工审核，我们将引入自动化机制来跟踪公共工单的活动热度与赞同数量。若该方法验证有效，后续将推广至所有 AdGuard 项目的质量保障团队。
基于现有问题分诊指南开展专项培训，并在 Jira 系统内建立内部问题评估的强制规范。该流程要求依据结构化分诊指南提供决策依据，确保优先级判定的规范性与透明度。
团队还将编制用户诊断问题清单，以便根据用户反馈更高效定位与分析过滤相关问题。
最后，我们将新增多项自动化测试防止类似问题重现。目前正在开发基准测试脚本，用于评估不同浏览器间的页面过滤速度。待性能基准确立后，所有后续发行版本均需通过该基准测试。当前自动化测试仅覆盖 Google Chrome，我们计划将其扩展至Firefox浏览器。此外，将针对已知问题网站清单（包括本次事件调查中发现的 discord.com 等站点）建立专项测试方案，持续监测这些「问题页面」在浏览器中的加载速度。
开发团队工作流程改进
开发团队将更注重为新功能增补测试用例（含集成测试），以降低未来版本出现错误的概率。同时将加强技术实现文档的编写规范，确保各相关团队能充分认知新功能测试的必要性，全面排查潜在问题与边界案例。
在将 CoreLibs 新版本集成至产品时，开发团队须获得 CoreLibs 团队的明确核准后方可推进。当前相对独立的集成流程存在风险盲区，此项调整将有效提升协作质量。
总结
我们再次向受此事件影响的用户深表歉意，并向所有提供反馈、协助我们突破困境的用户致以衷心感谢。未来面对可能产生重大影响的关键问题时，我们承诺以更迅速的响应和更透明的沟通与用户保持同步。
