HTTP/3 与 QUIC 浏览器兼容性基础
了解 HTTP/3 如何使用 QUIC、浏览器如何协商与回退，以及如何在不假定网络路径统一的情况下审查兼容性。
HTTP/3 是运行在 QUIC 之上的 HTTP 版本。QUIC 在 UDP 之上提供加密、多路复用的传输，HTTP/3 则定义请求和响应如何使用该传输。兼容的浏览器与源站可以使用 HTTP/3，但浏览器仍会根据目的端和当前网络选择可用协议。QUIC 不可用时，只要策略允许，浏览器可以通过其他传输继续使用 HTTP/2。因此 HTTP/3 扩大了可用路径范围，并不保证每个请求都使用同一种协议。
HTTP/3 与 QUIC 的职责不同
RFC 9114 规定 HTTP/3，将方法、标头、流和状态码等 HTTP 概念映射到 QUIC。RFC 9000 规定 QUIC 的连接、流、丢包恢复和安全行为。区分两者有助于兼容性审查：即使浏览器正确实现了 HTTP/3，路由、防火墙或源站仍可能阻止 QUIC。
QUIC 使用 UDP，但并不等同于发送任意应用 UDP 数据包。浏览器与服务器会执行协议握手，协商版本和传输参数，并加密应用数据。网页不能用 JavaScript 替代这一协商；一次成功的 HTTPS 导航也不能说明每个子请求使用了哪个 HTTP 版本。
理解这一差别也有助于阅读运行日志。HTTP/3 指请求协议，QUIC 指承载其数据流的传输。一个连接可以承载多个独立数据流，因此某个流受到丢包影响时，网页未必会看到整个连接失败。HTTP 的语义仍然熟悉：应用依然收到响应、状态码、标头和正文，变化的是底层传输行为。
QUIC 包含自己的版本协商和连接标识符。这些标识符有助于连接应对部分网络路径变化，但不会让网站控制网络路径，也不保证服务不中断。NAT 重新绑定、防火墙超时或供应商策略仍可能使连接失败。连接标识符是协议状态，不是稳定的用户或网络身份。
QUIC 数据包及其承载的 HTTP/3 数据受到加密保护，但仍须执行常规 TLS 证书和端点信任验证。HTTP/3 并未取消证书校验、凭据保护或检查代理在哪里终止连接的必要性。它也不会向所有网络观察方隐藏客户端正连接哪个目的端。协议加密和隐私策略解决的是不同问题。
HTTP/3 的数据流模型可能改善丢包时的应用表现，但应用不应假定延迟会固定降低。网络拥塞、服务器调度、请求大小、缓存状态以及浏览器到源站的路径都会影响结果。版本审查应测量客户真正关心的流程，不应仅凭协议名称承诺某个百分比的性能提升。
浏览器如何协商及切换协议
浏览器通过自身网络实现以及 HTTP Alt-Svc 等信号了解源站支持的协议。它可能在后续连接尝试 HTTP/3、复用已有连接，或继续使用 HTTP/2。尝试时机、缓存期限、并行竞速策略和偏好顺序都属于具体实现细节。MDN 的 HTTP/3 概览 可作背景参考，但不保证不同浏览器版本行为相同。
回退是可用性规则。未选用 HTTP/3 时，网页仍应保障任务完成：显示响应、保留表单数据，并在必要请求失败时提供有界重试。不要仅因应用代码看不到浏览器内部尝试，就再发起不受控的第二个请求。如果某项服务硬性要求 HTTP/3，应在部署契约中写明该要求，并定义用户容易理解的恢复路径。
首次请求与后续请求可能采用不同决策。如果缓存中尚无源站支持 HTTP/3 的记录，首次访问时浏览器可能先用 HTTP/2，之后再从 Alt-Svc 响应获知偏好。缓存可能过期，配置文件可能被替换，访问间隔中网络也可能变化。环境改变后，浏览器还可能继续复用已有连接。因此单次页面加载不足以完成兼容性验证。
协议选择针对具体源站和连接。文档可能通过 HTTP/2 加载，而来自另一源站的图片、字体、API 或分析请求使用 HTTP/3。重定向会将请求带到策略不同的源站。Service Worker 和连接池也会增加生命周期状态。测试应用真正依赖的请求，不要用一个协议标签概括整页流量。
请求失败时，要区分传输失败与 HTTP 响应。收到响应前超时、连接被拒绝和 HTTP 503 是应用面对的不同情况。适当时，网页可以显示相同的无障碍恢复操作，但运维人员应保留能指向负责方的简短分类。不要为了证明发生了回退，就在用户可见错误中暴露数据包详情、原始地址或凭据。
可接受的替代路径属于产品设计。文档或表单可以在不改变含义的情况下通过 HTTP/2 继续。实时功能可能需要支持 UDP 的路径；若无法建立，应说明该功能暂不可用。主要任务仍可运行时，可以跳过可选增强。应在发布前决定这些情况，避免超时意外导致未经批准的直连。
浏览器更新可能改变尝试其他协议的顺序、协议声明的缓存时间或连接复用条件。因此应用契约应说明结果和恢复方式，而不是内部计时器。比较两个浏览器版本时，应记录主版本和配置文件包，并在两者上运行同一流程。
中间网络设备会改变结果
防火墙、企业网关、NAT 行为、代理和目的端策略都可能影响 UDP 可达性。网络可以允许普通 HTTPS，同时阻止或限制 QUIC。代理可能支持 HTTPS 隧道，却不支持 HTTP/3 所需的 UDP 操作。目的端也可能偏好 HTTP/2 或暂时关闭 HTTP/3。这些是不同的兼容性条件，并不证明浏览器行为不一致。
使用自有控制端点测试。记录浏览器版本、配置文件、主机环境、路由策略、目的端能力和用户可见结果。覆盖 HTTP/3 成功、HTTP/2 替代、UDP 被阻断以及不声明 HTTP/3 的目的端。数据包捕获、凭据和目的端历史应保存在受控系统中，公开指南不需要这些资料。
先区分连接的两个区段。浏览器可能通过一种传输连接代理，而代理通过另一种传输连接源站。企业网关可能终止 TLS、转发 HTTPS 隧道，或应用禁用 UDP 的策略。负载均衡器可能为一个主机名声明 HTTP/3，而相邻主机名只提供 HTTP/2。记录测试使用的端点和路由策略，避免将回退错误归因到其他层。
UDP 可达性不只是端口开放。NAT 映射可能在空闲期间过期；防火墙可能设置空闲超时；网络也可能放行小数据报却丢弃较大的数据报。QUIC 的路径验证和数据包大小发现会处理这些情况，但浏览器无法修复所有中间设备。长连接应用应有重连状态；在未检查自身状态规则前，不要把重连当成新用户会话。
代理需要明确的能力契约。HTTP 代理可以承载普通请求和 HTTPS CONNECT 隧道，但未必承载 QUIC 数据包。SOCKS5 服务可能提供 UDP 中继，但这一能力和策略与 HTTP/3 支持是两回事。支持 QUIC 的代理也可能有账户、区域、并发或端点限制。不要凭协议方案字符串或产品名称推断能力，应确认实际账户和端点支持哪些操作。
TLS 和证书校验仍由终止 TLS 的端点执行。如果受管网关检查流量，其信任配置与证书策略就是部署边界的一部分。浏览器警告不能作为关闭校验的理由。应将故障归类为信任或策略问题，恢复获批准的证书路径，再重试 HTTP/3 流程。诊断传输问题不应削弱连接安全。
可观测数据应有意保持精简。版本记录可以保存浏览器主版本、配置文件类别、主机类别、路由名称、目的端分类、协议结果和恢复操作。简短请求标识可关联浏览器与服务日志，而无需长期保存完整 URL、数据包捕获或原始地址。详细追踪仅应留在受控系统中，并只保留处理事故所需的最短期限。
中间设备兼容性可能随地点和时间变化。应在生产所用区域和账户等级测试，并在供应商、防火墙、浏览器或配置文件变更后重测。一个办公室的成功结果不能代表所有远程网络。公开说明应陈述注明条件的已测试组合，而不应宣称 HTTP/3 随处可用。
安全地审查浏览器版本
在浏览器或网络变化前后比较同一个应用流程。确认浏览器使用预期配置文件启动，到达预期页面状态，并在 QUIC 不可用时遵循记录的替代策略。衡量应用关心的结果，不要把协议标签当成质量分数。
BotBrowser 支持按浏览器上下文配置代理路由，因此团队可以在审查 HTTP/3 流程时重复获批准的网络策略。但它不能强制源站协商 HTTP/3，也不能控制每个中间设备、供应商路由或协议选择。浏览器可能按配置使用 HTTP/2 或失败；应在版本记录中保留获批准的替代路径和清晰的恢复操作。参见按上下文配置代理、浏览器版本验证和 QUIC 代理路由。
如果同一浏览器进程中的不同获批流程需要不同路由，应使用上下文级策略。创建上下文，在打开第一个页面前应用路由，并在上下文负责人旁记录路由名称。这样有助于区分回退来自浏览器、所选路由还是目的端。上下文设置并不保证源站会选择某种协议。
为了让发布审查可重复，应把五项信息放在一起：浏览器版本、对应的配置文件包、主机与显示环境、网络策略以及应用流程。尽可能一次只改变其中一项。如果候选版本失败，应先恢复已接受的组合并确认流程，再调查变更项。若同时更改浏览器、代理、配置文件和应用，就没有可靠基线可供比较。
小型测试矩阵也有价值。包含无预热缓存的首次访问、后续访问、支持 HTTP/3 的源站、仅支持 HTTP/2 的源站、可控 UDP 阻断以及预期的用户恢复操作。逐项记录成功或有界失败，不要从页面标题猜测协议。浏览器主版本升级或代理供应商变化后重跑这些项；测试期间保留已批准的替代路径。
支持指南应指出下一步。代理凭据无效、供应商缺少所需操作、源站未声明 HTTP/3、UDP 路径被阻断，分别属于不同负责人。通常用简短分类和路由名称即可分派。工单不要包含代理 URL、密钥、完整目的端历史或原始数据包内容。
性能结论也应遵守相同原则。用相同配置文件、主机、区域和应用版本比较首次可用页面、API 完成、媒体就绪或下载完成时间。测量候选方案时保留已接受路由。如果结果变化，先恢复已接受配置，再更改其他变量。这样得到的结果才可用于决策，也不会把协议行为变成指纹或普遍承诺。
推广前应判断应用是否确实需要 HTTP/3，还是只需可靠的安全请求。如果 HTTP/2 满足流程，就把它记录为正常替代路径。如果某项功能确实需要支持 UDP 的路径，应定义清晰的不可用状态和获批准的恢复方式。发布记录应说明接受的结果、已测试的路由，以及无法使用 QUIC 时的负责人和行动。
兼容性检查清单。
从应用需求开始。如果应用只需要加密请求和响应迅速的页面，经获批准的路径使用 HTTP/2 可能已足够。如果它依赖 QUIC 特有的属性，应明确该属性，并定义属性不可用时用户会看到什么。
分别确认源站接受 HTTP/3，并通过浏览器使用的机制声明支持。DNS 记录、成功的 TCP 连接或加载成功的 HTTPS 页面，都不能证明源站已接受 HTTP/3。使用自有控制端点，或使用能报告协议结果且不暴露客户内容的服务报告。
然后确认路径。检查主机、防火墙、企业网关、代理、NAT 和供应商账户是否允许流程所需的 QUIC 流量。测试与生产路径应在端点、区域、账户等级、认证和并发方面保持一致。通过不受限制的家庭网络测试，不能证明受管理的生产路径兼容。
最后确认浏览器：记录主版本、配置文件包、操作系统类别，以及有界面或无界面模式。执行一次没有预热缓存的首次访问，再执行后续访问，因为协议声明和连接复用会改变第一次请求的结果。验收应看流程是否达到预期状态，而不是页面看起来是否正常。
如果某项失败，采取最窄范围的修正。源站未声明协议由服务负责人处理；UDP 被阻断由网络负责人处理；代理能力缺失由供应商或部署负责人处理；浏览器或配置文件回归由版本验证负责人处理。不要削弱证书验证、忽略路由策略或强制直连以通过测试。
用读者能理解的方式写明替代路径。内容页面可以通过 HTTP/2 继续；可选的实时功能可以显示暂不可用，并在路径恢复后重试。说明重试上限、需保留的状态以及后续审查的负责人。
设定重新运行矩阵的触发条件：浏览器主版本升级、配置文件变更、供应商迁移、防火墙策略变化、区域变化或源站重大改动。过去的成功不是永久保证；结论应绑定到具体浏览器版本、路由、目的端和测试结果。