面向 Web 运维人员的 MASQUE 与 CONNECT-UDP
了解 MASQUE、CONNECT-UDP 和 HTTP Datagram 的作用，以及需要向代理服务商确认的能力。
MASQUE 的用途
Web 应用越来越常使用无法套入传统 HTTP 请求-响应隧道的传输方式。MASQUE 汇集了通过 HTTP 代理承载流量的一类机制。对运维人员而言，它的价值在于用标准化方式描述代理功能；名称本身不能证明某个服务确实提供这些能力。
MASQUE 横跨多个协议层。HTTP 定义请求和响应语义，HTTP/2 或 HTTP/3 通常提供代理连接，而请求的功能决定流量如何继续承载。RFC 9298 规定了在 HTTP 中代理 UDP，RFC 9297 则定义相关扩展使用的 HTTP Datagram 与 Capsule Protocol。
把这些名称理解为角色而不是产品标签，更容易评估问题空间。代理可以提供 HTTP 端点、接受 CONNECT-UDP，然后根据自身策略单独授权目标。另一个服务可能支持普通 HTTPS 隧道，却没有 UDP 中继。应从应用需要的功能出发，为每项责任指定负责团队。
MASQUE 也为边界提供了共同词汇。客户端知道代理端点和本地策略，代理知道允许中继的目标以及可到达的传输方式，源站知道应用协议和访问控制。加密不会消除这些边界，因此一次成功的浏览器导航不能证明所有中间能力都具备。
运维人员可以围绕结果提出几个问题：客户端到代理使用哪个 HTTP 版本？指定账户和端点是否包含 CONNECT-UDP？服务商是否说明目标授权和区域可用性？功能不可用时允许显示什么用户状态？这样可以在不索取服务内部细节的情况下完成评估。
CONNECT-UDP 的含义
在 HTTP/2 和 HTTP/3 上，CONNECT-UDP 是 RFC 9298 定义的扩展 CONNECT 请求，使用 :protocol=connect-udp 值请求代理建立 UDP 通信上下文；在 HTTP/1.1 上，同一请求角色使用指向 connect-udp 的 HTTP Upgrade。请求发给代理，由代理根据自身策略决定是否接受所请求的目标。它不是把普通 Web 源站变成代理的指令，浏览器发出请求也不能证明代理能够访问每个目的地。
“连接”这个词可能造成误解，因为得到的上下文并不是页面拥有的端到端套接字。代理仍是拥有授权、限制和故障行为的中间方。Web 应用在允许的上下文中使用自己的应用协议，目的地也仍会决定是否接受该协议。服务商可能限制目标、区域或账户类别，这种边界需要单独记录。
CONNECT-UDP 也不是对浏览器 API 的通用承诺。页面不能只在 JavaScript 中写出请求类型就选择代理请求，浏览器也不能制造服务商未提供的中继服务。浏览器、代理和目的地必须拥有兼容的策略。评估应描述可观察流程和获批路由，而不是把协议名称当作新网络能力。
该扩展 CONNECT 请求属于更大的 HTTP 控制平面。身份验证、授权、请求生命周期和错误处理都遵循代理合同。服务商可能在 UDP 交换前拒绝请求，也可能关闭已接受的上下文或限制目标。应用应为各类故障保留清晰的恢复状态。
运维时应区分三项责任：客户端到代理的连接、代理的 UDP 中继服务，以及目的地应用的行为。连接代理成功只建立了第一段。服务商支持、账户策略、目的地可达性和应用协议兼容性是彼此独立的条件。这与QUIC 代理路由和通过 SOCKS5 使用 UDP的范围不同；后两者讲各自的路由配置与协议操作流程。
Datagram 与 Capsule
HTTP Datagram 可以将数据报数据关联到一个 HTTP 上下文；Capsule Protocol 则在 HTTP 流中承载由扩展定义的控制信息。两者相关但职责不同：Datagram 承载面向数据报的流量，Capsule 可传达上下文变更或其他控制消息。具体映射取决于扩展和传输方式，不应把它们视为同一种线格式的可互换描述。
HTTP Datagram 与 HTTP 上下文关联，因此扩展可以把数据报流量对应到请求状态。Capsule 消息通过可靠的 HTTP 流传输，并可携带扩展定义的指令或上下文信息。这样的区分让扩展为不同信息选择所需的交付属性。即使数据报通过流上的 DATAGRAM capsule 传输（如 HTTP/2），它仍保持数据报语义，应用不应依赖可靠交付；这也不会让 Capsule 成为通用控制语言。
底层传输同样重要。HTTP/3 使用 QUIC，具有自己的流和数据报机制；HTTP/2 则有不同的分帧和扩展限制。服务商可能只在某个 HTTP 版本上支持 MASQUE 功能。应询问已获批准的协议组合，不要仅凭“支持 HTTP”这类描述推断能力。
对应用负责人而言，关键是所需的语义。交互功能可能需要数据报交付并容忍丢失，而授权决定可能需要可靠的控制消息。运维人员不必在代理层重设计这些语义，只需确认服务和浏览器策略保持应用合同，并在无法满足时给出有限故障状态。
涉及 HTTP/3 时，QUIC 按相关规范承载 HTTP/3 流和数据报。但这不表示每个 HTTP/3 请求都使用 CONNECT-UDP，也不表示支持 HTTP/3 就能证明代理支持 MASQUE。关于浏览器协商和兼容性边界，参见HTTP/3 与 QUIC 浏览器兼容性。
运维评估
采用支持 UDP 的代理服务前，应确认哪些端点、账户套餐、区域、目标策略和并发条款包含 CONNECT-UDP。询问服务如何报告拒绝，以及其文档承诺的可用性预期。记录应用真正需要的结果和获批的恢复路径；普通 HTTPS 页面能够加载，并不能证明 UDP 中继可用。
资格记录应与生产决策保持同一粒度。写明浏览器版本、上下文策略、服务商端点类别、区域、账户权益和目的地类别。记录主要流程是否完成、可选功能是否不可用，以及下一步由哪位负责人处理。这样在服务商或浏览器变化后可以重复取证，同时不在公开文档中保留客户内容或密钥。
应把代理和源站视为相互独立的依赖。代理可能接受控制请求，而源站拒绝应用协议；反过来，源站可能支持该应用，而代理账户缺少所需操作。有用的事件分类应指出失败的边界，以及获批的重试或升级路径，且不得向最终用户暴露凭据、私有目的地历史或详细流量抓包。
路由策略还应说明哪些做法不被允许。如果 UDP 功能不可用，在应用允许时，已批准的 HTTP/2 流程可以继续，或者功能显示不可用状态，直到运维人员解决服务商问题。看似让页面加载成功的直连并不是隐含的回退；把它当作回退，会在没有明确决定的情况下改变网络边界。
服务商文档是必要的，但不是永久证据。在套餐变更、端点迁移、区域变更、浏览器主版本更新或源站发生重大变化后应重新检查。比较同一个应用流程，并在评估候选方案期间保留最近一次获批的策略。协议标签有助于解释结果，但验收标准是客户结果和恢复行为。
路由记录应说明浏览器上下文与代理账户的关系，但不要把密钥复制到命令、工单或页面日志。简短的路由名、负责人、区域和能力摘要通常足以选择恢复方式。详细服务协议和授权证据应留在受控系统中。
应用团队要说明 UDP 是主要任务的必需条件，还是可选增强功能。文档、表单或普通 API 可能可以通过获批的流式路由继续工作；实时功能则可以显示不可用状态并允许稍后重试。这个决定应在应用合同中提前记录。
服务商可能在不改变 :protocol=connect-udp 协议标记的情况下改变行为，例如调整区域容量、账户限制、目标策略或 HTTP 版本。发生变化后应重复代表性流程，并与最近一次获批记录比较。比较重点应是流程完成、有限故障和恢复负责人，而不是假定的传输标签。
浏览器版本评估应区分协议角色。浏览器可以选择已配置路由、与目的地协商并显示结果，但不能为代理中继策略或源站服务提供认证。将浏览器主版本、配置文件系列、路由策略和目的地类别记录在一起，才能形成有用基线。
网络运维还应记录预期故障。被拒绝的 CONNECT-UDP、不可用的代理端点和源站应用错误各有负责方，即使它们出现在同一次流程中。简短的分类与获批的下一步可帮助支持团队分派问题，无需收集私有流量或暴露凭据。
最持久的解释应保持分层：MASQUE 描述代理问题空间，CONNECT-UDP 描述标准化请求角色，HTTP Datagram 与 Capsule 描述相关传输机制，而服务商合同决定实际能力。BotBrowser 可以重复获批的客户端策略，边界之外的服务能力仍由服务商和源站负责。
应将故障作为明确且有限的能力或可用性结果处理。缺少某项操作应由服务商或部署负责人处理，应用专属的回退则由应用负责人决定。凭据和详细流量记录应保存在受控系统中。不要把未记录的直连当作恢复行为。
BotBrowser 支持为每个浏览器上下文选择获批的代理路由，因此可以在评估网络流程时重复应用同一策略。它不能实现 MASQUE 服务、替服务商增加 CONNECT-UDP，也不能控制服务商的上游 UDP 中继或源站行为。上下文路由是客户端策略边界，不能替代服务商能力。
当一个浏览器进程承载多个网络要求不同的获批流程时，按上下文路由很有帮助。上下文设置选择部署已经评估过的路由，不会创建新的服务商授权，也不会改变目的地的协议选择。应在第一次页面操作前应用策略，并把路由名与上下文负责人和可见结果关联起来。
产品边界应保持明确。BotBrowser 可以重复已批准的客户端路由，并在记录的策略下比较同一流程；它不提供 MASQUE 服务端，不实现上游中继，也不保证源站使用 HTTP/3。这些能力属于服务商、源站和周边网络策略。
如果路由尚未获批，应选择其他已批准路径、等待恢复或停止流程。不要用浏览器设置或页面脚本制造不存在的 CONNECT-UDP 能力。运维记录应让支持团队看到这个决定，而敏感的服务商证据继续留在受控系统中。
在运维手册和面向客户的状态中应使用相同词汇。“代理接受了 HTTP 请求”比“应用到达了目的地”更准确；“此账户没有 UDP 中继”也比“HTTP/3 失败”更便于处理。明确措辞可以把事件交给正确团队，并帮助选择获批的恢复方式。
验收记录不应把协议名称变成性能承诺。QUIC、HTTP/3、数据报和代理中继可能影响流程表现，但目的地、账户策略和网络条件同样重要。应测量真正关心的应用任务，保留有限结果，并在条件变化时重新检查。
这项评估可以保持轻量。路由名、匹配的浏览器和配置文件版本、代表性的目的地类别以及清晰的不可用状态，就能形成运维基线。详细服务商日志和授权材料应留在受控系统，公开状态说明只需交代角色、外部边界和获批恢复方式。
当多个团队共用一个浏览器部署时，这种分工也很有帮助。上下文负责人选择客户端路由，网络负责人评估服务商，应用负责人定义可接受回退。三方的简短交接，比假设浏览器设置可以提供缺失的代理服务更可靠。
在发布说明中，可以用普通语言描述获批结果：上下文使用了批准的代理策略，目的地流程完成或显示了已记录的不可用状态，并且明确了下一位负责人。公共标准用于解释协议角色，但不要暗示浏览器会提供服务商服务。这样运维人员能获得必要背景，同时不暴露凭据、私有目的地或详细流量记录。
这样的表述也便于支持交接。它区分浏览器策略决定与服务商服务决定，为应用负责人提供可验证的具体状态，并保留已评估的替代路由。相同记录可用于发布评估、事件更新和服务商复评，而不会暴露会话内容。公开状态页应保持在角色、结果和边界的层面；账户相关证据留在授权系统中。
执行资格检查
对每条候选路由应用这些检查，并为每一项记录通过或未通过。
- 服务商文档针对该端点类别和账户，明确列出对 CONNECT-UDP（RFC 9298）的支持。记录端点类别、账户权益和 HTTP 版本。如果文档只声称支持 HTTP/3，则未通过。
- 代表性流程通过获批的上下文路由运行。流程完成，或以有限故障结束并有明确负责人，则通过。记录所用的路由名称和上下文策略。
- 将代理环节的状态与源站结果进行比较。把“代理接受、源站拒绝”和相反情况分别归类。
- 缺少 CONNECT-UDP 的路由记录为能力不匹配。如果运行记录显示流程通过直连路径完成，而不是通过获批路由，则未通过。
- 如果应用已批准 HTTP/2 回退，应将其记录为回退。使用了回退但未记录，则未通过。
- 套餐变更、端点迁移、区域变更、浏览器主版本更新或源站发生重大变化后重复这些检查。在重复运行通过之前，保留最近一次获批的策略。