用于 HTTPS 和 HTTP/3 的 QUIC 代理路由
BotBrowser QUIC 代理实用指南，说明 CONNECT 选择、HTTP/3 限制、隐私边界和上线检查。
BotBrowser Team
BotBrowser 154.0.8037.44 或更高版本，并配套匹配的配置文件包，可以让 HTTPS 与兼容的 HTTP/3 请求留在同一条获批准的浏览器路由中，但代理服务仍必须实现所需操作。选择操作时要区分 HTTPS 隧道与 UDP 转发，并记录服务商能力和失败时的处理方式。
要点
- 普通 HTTPS 隧道使用 QUIC 代理的
CONNECT。 - 需要通过 QUIC 转发 HTTP/3 时，使用 MASQUE
CONNECT-UDP，前提是服务商支持。 quic://地址不等于 HTTP/3 一定成功，站点、浏览器策略和服务商都会影响协商。- QUIC 代理不可用时，BotBrowser 不会静默改走直连，可以重试、使用已批准的备用路由或停止。
内容导航
选择传输操作
CONNECT 为 HTTPS 目标建立隧道。若工作负载是普通浏览器 HTTPS，且服务商声明支持 QUIC 代理上的 CONNECT，应选择它。MASQUE CONNECT-UDP 转发 UDP 流，是兼容 HTTP/3 流量所需的操作。两者相关但不能互换。关于 CONNECT-UDP 的含义以及 HTTP Datagrams 如何配合，请参阅 面向 Web 运维人员的 MASQUE 与 CONNECT-UDP，其中还列出了运维人员应向代理服务商确认的事项。
| 工作负载 | 所需操作 | 选择依据 |
|---|---|---|
| HTTPS 页面和 API | CONNECT | 服务商合同明确支持 CONNECT |
| 允许 QUIC 的 HTTP/3 | CONNECT-UDP | 服务商支持 MASQUE 和 UDP 转发 |
| 混合流量 | 两者都支持或使用批准的备用路由 | 记录预期协议和备用行为 |
配置受控路由
使用 BotBrowser 154.0.8037.44 或更高版本及匹配的配置文件包，并在发布记录中关联二进制、配置文件、主机策略和代理端点。以下是进程级 CLI 示例：
chromium-browser \
--bot-profile="/path/to/profile.enc" \
--proxy-server="quic://user:[email protected]:443"
对凭据中的保留 URL 字符进行编码，并把真实密钥放在受控的密钥系统中。上下文集成应在创建首个页面前应用相同的批准参数。参阅 QUIC Proxy Routing 文档 和 代理配置指南。
按上下文路由仅适用于 BotBrowser ENT Tier3，并使用 BotBrowser.setBrowserContextFlags；创建页面前应用批准的参数。这个 API 与层级限制不同于上面的进程级 CLI 示例。
验证限制和失败行为
HTTP/3 按请求协商。站点可能选择 HTTP/2，浏览器策略可能禁用 QUIC，服务商也可能只提供 CONNECT 而没有 CONNECT-UDP。应测试真实旅程并记录实际协议，不能把端点宣称支持 HTTP/3 当成成功证明。关于浏览器如何协商 HTTP/3 并回退到其他协议，请参阅 HTTP/3 与 QUIC 浏览器兼容性基础，其中说明了为什么不能假定某一条网络路径适用于所有场景。
QUIC 代理不可用时，BotBrowser 不会静默改为直连。受控重试、预先批准的备用路由或明确停止，都能让隐私、一致性和防护边界可复核。BotBrowser 提供配置能力和上下文隔离，但不保证服务商可用性、HTTP/3 协商成功或直连备用。关于如何规划有序的已批准路由并设定有限的重试预算，请参阅 代理故障切换与用户可见的连续性，其中说明了如何区分代理链路故障与目标站点故障。
QUIC 代理也不同于 SOCKS5 UDP。SOCKS5 使用 UDP ASSOCIATE，QUIC 代理使用自己的 CONNECT 和 MASQUE 合同；只改 URL 前缀不会补上服务商缺失的能力。
用记录上线
上线前记录 BotBrowser 版本、配置文件标识、服务商对 CONNECT 和 CONNECT-UDP 的支持、凭据负责人、预期 HTTP/3 结果以及代理不可用时的批准动作。这样可以在不暴露凭据、不依赖页面脚本的情况下复核隐私和一致性。
常见问题
quic:// 会强制所有站点使用 HTTP/3 吗？
不会。协商取决于目标站点、浏览器策略和服务商，HTTPS 仍可能通过 CONNECT 使用 HTTP/2。
普通 HTTPS 需要 CONNECT-UDP 吗？
不需要。普通 HTTPS 使用 CONNECT，CONNECT-UDP 用于 UDP 转发，例如兼容的 HTTP/3 流量。
QUIC 失败时会发生什么？
BotBrowser 支持在获批准的上下文中应用配置好的 QUIC 代理路由，但不保证服务商可用性、HTTP/3 协商成功或直连备用。它会保持配置的防护边界，由操作员重试、选择批准的路由或停止。
有关其他代理选择，请阅读 代理配置 指南。将 SOCKS5 UDP 视为提供商的独立能力。
运行与协议边界
运行边界.
HTTP/3 将 HTTP 请求和响应映射到 QUIC streams，这与访问目标时使用的代理操作是不同层次。CONNECT 建立隧道，浏览器和站点在隧道中进行应用通信。CONNECT-UDP 允许代理承载 UDP 数据报，浏览器与站点仍需在该路径上协商自己的协议。因此，“QUIC 代理”不表示代理会终止或理解目标站点的 HTTP/3 通信。
HTTP/3 协商使用其在 QUIC 上运行时定义的协议标识，包括应用协议协商中的 h3。支持 HTTP/3 的站点在某次连接中仍可能协商其他协议。浏览器提供的协议、网络路径、代理能力和站点响应都会影响结果。应区分产品宣称支持与实际观察到的协议。RFC 9114 定义了 HTTP/3 行为，但不保证每个请求都会选用它。
QUIC 在一个连接中提供相互独立、有序的字节 streams。HTTP/3 用这种模型承载请求 streams，但这不意味着请求完成不受拥塞、主机资源或应用依赖影响。页面仍可能等待关键响应。这些协议特性可以解释 HTTP/3 与 HTTP/2 在某些网络条件下的差异，却不能保证代理路由一定更快。
CONNECT-UDP 属于另一层。它标识目标，并在 HTTP 代理上下文中承载 UDP 数据报。RFC 9298 定义了客户端和代理如何通过 HTTP Datagrams 或 Capsule Protocol 传输数据。这不会把代理变成通用 UDP 隧道，也不会取消服务商策略。目标、端口、账户层级和数据报限制仍由服务合同决定。
通过 CONNECT 使用 HTTPS 时，隧道不代表代理成为目标站点的 TLS 端点；通常由浏览器穿过隧道与站点建立受保护的通信。HTTP/3 经 UDP 代理路径承载时，浏览器与站点的 QUIC/TLS 协商也不同于浏览器连接代理时使用的 QUIC。加密隧道不代表没有元数据：服务商仍可能获知目标和连接时间，BotBrowser 不控制其日志策略。
每种验证结果回答不同问题。代理连接成功表示服务可达；CONNECT 或 CONNECT-UDP 被接受表示该代理操作获准；HTTPS 请求完成表示应用交换完成；观察到 HTTP/3 才表示目标协议协商成功。某一步成功不能自动证明其他层也成功。
如果工作负载只需要 HTTPS，HTTP/2 可能是正常的兼容结果；如果它明确要求 HTTP/3，则 HTTP/2 也可能意味着验收条件未满足。协议本身不能决定哪种解释正确，必须看预先声明的工作负载要求。测试前写明是否接受 HTTP/2；要求 HTTP/3 时，分别记录代理操作支持与目标协商结果。
标准描述的是协议行为，而不是某家代理服务的商业条件。RFC 9114 说明 QUIC 上的 HTTP/3，RFC 9298 定义 HTTP 代理的 CONNECT-UDP。服务商负责 endpoint、认证、目标策略、可用性和账户限制。BotBrowser 可以应用文档说明的路由能力，但不能替服务商开通功能，也不能保证站点选择 HTTP/3。
把观察到的协议视为单条连接的证据，不要给整页贴标签。页面可能访问多个站点，各连接使用的协议也可能不同。主文档使用 HTTP/2，不代表 API 或媒体请求也使用 HTTP/2；一个站点返回 HTTP/3，也不代表所有资源都走 HTTP/3。明确验收关注的站点和请求，并按这个范围记录结果。
性能比较要保持变量一致：目标、地区、浏览器版本、配置文件包、账户等级和工作负载。QUIC 可能改变连接建立和丢包处理，但页面更快不能证明差异由代理路由造成。说明测量的是新连接还是复用连接，并比较相同的用户可见节点，例如 API 响应完成或页面可用。进行多次获准测试以体现正常网络波动，报告范围而不是单个异常快的结果。
连接复用也会影响测试结论。多个请求可能共享已建立的连接，因此后续 HTTP/3 响应不一定代表重新协商了代理。新连接则可能产生重复请求中没有的建立成本。若应用关心冷启动与重复请求，应分别记录。使用生命周期明确的测试上下文，不要为了得到期望协议而更改无关数据或隐私设置。
QUIC 代理能力由服务商合同定义，而不是由 URL 写法定义。确认 HTTPS 隧道需要 CONNECT，兼容 HTTP/3 的 UDP 数据报需要 CONNECT-UDP，同时确认认证、目标限制、UDP 限制、可用性和服务等级。服务商描述支持 QUIC，不代表具体套餐支持 CONNECT-UDP。
记录 endpoint、服务商账户、凭据和配置文件包的负责人。把 endpoint 标识与 BotBrowser 版本和配置文件修订放在同一发布记录中，才能区分服务商迁移和浏览器变更。共享 hostname 不能证明所有权。
凭据属于发布数据。编码保留字符，从批准的密钥系统注入真实值，不要把凭据放进代码、shell 历史、工单或诊断。轮换后用同一操作和 endpoint 重测。认证失败应保持为可见的认证失败，而不是换到未经审查的 endpoint。
CLI 路由作用于进程。按上下文路由仅适用于 BotBrowser ENT Tier3，并在创建页面前调用 BotBrowser.setBrowserContextFlags。上下文记录应包含负责人、路由和预期目标。导航开始后更换路由会使旅程难以解释。
代理不可用是策略事件。BotBrowser 不会静默改走直连。批准的处理可以是有限重试、已审查的备用路由或停止。备用路由必须预先审查服务商、地理位置、日志、凭据和目标策略，不能在事故中临时假定直连可接受。
按层区分失败：endpoint 解析、QUIC 传输、认证、CONNECT 或 CONNECT-UDP 被拒绝，以及目标协商。目标选择 HTTP/2 不等于认证失败，每种状态都有不同负责人。
在非生产上下文用批准的 endpoint 和少量目标做有界验证。记录所需操作、预期和观察到的协议、路由标识、状态类别和失败动作。普通 HTTPS 可以接受 HTTP/2；要求 HTTP/3 时要分别记录 CONNECT-UDP 支持和目标协商。
只保留决策所需证据：时间、路由、操作和结果。不要保存凭据、Cookie、敏感 URL 或页面内容。服务商可能按自身条款保留连接元数据，BotBrowser 不能控制该保留期限，发布负责人需另行确认访问和留存规则。
浏览器到代理的 QUIC 连接只证明第一跳，不证明目标选择 HTTP/3。浏览器策略可能禁用 QUIC，服务商也可能按账户或目标限制 UDP。发布记录应说明 HTTP/2 是否可接受；若必须 HTTP/3，则记录两项检查结果。
服务商、凭据、配置文件或浏览器变更后，用 BotBrowser 154.0.8037.44 或更高版本、匹配配置文件包、进程或 ENT Tier3 范围、endpoint 和操作重新验证。这样隐私和一致性决定始终对应已审查的配置。
结论
HTTPS 选择 CONNECT，只有在服务商和工作负载都需要时才加入 CONNECT-UDP，并验证真实浏览器旅程。简洁的发布记录可以保护隐私和运行一致性，同时明确 BotBrowser 的能力及其对服务商的依赖。
来源
本文属于指南： 代理配置总览：浏览器网络决策图