使用 QUIC 代理路由 HTTPS 与 HTTP/3
了解 BotBrowser 154 的认证 QUIC 代理路由，以及 HTTPS 隧道和兼容 HTTP/3 流量。
为现代网页流量选择明确的路由
许多部署仍然只把代理理解为 TCP 设置，但 HTTP/3 通过 UDP 上的 QUIC 工作。BotBrowser 154 新增认证的 quic:// 代理路由，通过标准 --proxy-server 配置 HTTPS 隧道，并在代理支持时通过 MASQUE CONNECT-UDP 承载兼容的 HTTP/3 流量。
这是一项浏览器级网络能力，不需要页面脚本或额外的应用隧道。代理服务仍必须提供所需的操作。URL 本身不会让普通服务自动变成 QUIC 代理。
快速启动
使用与 BotBrowser major version 匹配的 Profile 包。当前公开入口从 BotBrowser 154.0.8037.17 开始：
chromium-browser \
--bot-profile="/path/to/profile.enc" \
--proxy-server="quic://user:pass@proxy.example.com:443"
真实凭据应放在受控的 secret 系统中。用户名或密码包含 @、# 等保留字符时，先进行 URL 编码。不要把生产凭据写入公开脚本或提交记录。
QUIC 代理需要支持标准 CONNECT。兼容的 HTTP/3 流量还需要 MASQUE CONNECT-UDP。代理只支持前者时，HTTPS 仍可用，但不能据此宣称 HTTP/3 一定可用。
Per-context 路由
ENT Tier3 工作流可以为单独的 BrowserContext 设置路由。必须在创建页面和开始导航前发送设置命令：
await client.send("BotBrowser.setBrowserContextFlags", {
browserContextId: context._contextId,
botbrowserFlags: [
"--bot-profile=/path/to/profile.enc",
"--proxy-server=quic://user:pass@proxy.example.com:443",
],
});
不同上下文可以使用不同的已批准路由。这个设置只选择已有权限的代理策略，不会授予新的套餐、区域或服务权限。
HTTP/3 与失败策略
HTTP/3 是否使用取决于目标站点、浏览器策略和代理能力。一个站点可能使用 HTTP/3，另一个站点可能使用 HTTP/2，这属于正常的协议选择。需要 HTTP/3 的工作流应记录预期结果和代理不可用时的恢复动作。
QUIC 代理不可用时，BotBrowser 不会静默回落到直连。这能避免页面继续加载，却绕过组织批准的网络边界。运维人员应选择受批准的备用路由、重试，或停止工作流等待检查，而不是默认允许直连。
与 SOCKS5 UDP 的区别
SOCKS5 UDP 使用 UDP ASSOCIATE，quic:// 使用 QUIC 代理和 MASQUE 操作。两者都可能承载 HTTP/3，但配置语法、服务能力和提供商合同不同。不能仅把 SOCKS5 地址改成 quic:// 就获得 QUIC 代理能力。
上线检查
- 使用 154.0.8037.17 或更新版本，以及匹配的 Profile。
- 确认服务支持 QUIC、CONNECT 和所需的 CONNECT-UDP。
- 在受控 secret 路径保存凭据。
- 在第一个页面创建前完成 per-context 设置。
- 记录 HTTP/3 预期结果和不直连的恢复策略。
详细参数请查看 QUIC Proxy Routing 文档。已有 SOCKS5 UDP 部署请查看 UDP over SOCKS5 文档。