UDP over SOCKS5：QUIC 与 WebRTC 隐私路由

从一份完整的网络计划开始

一个浏览器会话可能使用多种传输方式。普通网页请求通常使用 TCP，HTTP/3 和部分实时通信则可能使用 UDP。因此，批准网页浏览使用某个代理，并不等于该应用产生的所有连接都自动受到同一政策约束。部署记录需要明确允许哪些传输、由哪个代理服务承载，以及已批准的路径不可用时浏览器和应用应该采取什么行为。

检查启动配置里是否出现代理地址并不能证明整体合规。真正需要确认的是，获授权应用的完整用户流程是否遵循组织选定的网络政策。登录、页面导航、媒体准备、文件传输、后台活动和退出可能触发不同的浏览器能力。发布审查应覆盖完整流程，不能用某一个页面成功加载来代表所有网络路径都已通过验证。

当 SOCKS5 服务提供兼容的 UDP 中继能力时，BotBrowser 可以执行面向隐私保护的路由政策。在服务能力、浏览器政策和应用需求一致的前提下，TCP 与受支持的 UDP 流量可以纳入同一份批准计划。发布前必须向服务提供方确认实际购买的服务能力，因为支持 SOCKS5 并不必然表示套餐、区域和接入点都包含 UDP。

网络计划应便于审计。记录预期的 TCP 路径、UDP 路径、WebRTC 政策、HTTP/3 决策、DNS 政策和批准的回退方式，并为每一项指定负责人。应用发生变化或代理服务商调整服务时，产品、安全、隐私和运维团队可以依据同一份记录作出判断，而不是依赖零散的配置说明。

不要把 UDP 当作次要备注。应用不需要 UDP 时，应明确记录限制；确实需要时，应批准兼容路径，并通过该路径验证正常业务流程。主动限制比未经审查的直连路径更安全，明确的中继政策也比假设所有流量采用相同传输方式更可靠。

分别决定每一种传输方式

即使 TCP 和 UDP 来自同一个代理服务商，也需要分别作出决定。两者在可用性、回退行为和对应用的影响上并不相同。组织可以同时允许两者，可以允许 TCP 而限制 UDP，也可以在审查后仅允许特定的 UDP 相关功能。选择应来自业务需求和隐私控制，不能直接沿用浏览器的一般默认行为。

QUIC 与 HTTP/3 相关，并使用 UDP。存在已批准的 UDP 路径时，获授权应用可以在该路径内使用 HTTP/3。如果部署选择仅使用 TCP 的政策，网页访问可以继续使用已批准的 TCP 传输。这样，HTTP 传输方式就成为可记录、可审查的部署决定，并在浏览器或基础设施升级时重新确认。

WebRTC 需要独立决定。实时音频、视频和参与者之间的通信可能依赖不同于普通页面请求的网络连接。一个可用的 TCP 网页代理，不能证明这些活动也处于相同的隐私边界内。发布负责人应根据工作负载，决定实时通信是允许、受限还是不可用，并把用户界面上的预期结果写清楚。

DNS 也属于同一轮审查。部署可能拥有已批准的网页路径，但如果名称解析采用另一条未经审查的路径，整体隐私行为仍然可能不一致。记录应明确 DNS 的管理责任，不能假设 UDP 中继会自动解决名称解析问题。传输、名称解析和实时通信彼此相关，但必须作为独立控制项分别验证。

单个成功结果不能推导其他路径。一个页面通过 TCP 打开，并不能说明媒体连接符合政策；一次视频通话正常，也不能证明随后导航使用的 DNS 政策正确。每一种获批准的行为都需要与应用流程和部署政策对应的证据。

按上下文确定策略

整个会话只给一个传输答案，往往过于粗糙。同一套部署里可能既有需要走已批准 HTTP/3 路由的业务，也有必须留在 TCP 的业务，而两者可能属于同一个配置文件家族。强行统一，只能在多余的路由和多余的限制之间二选一。

当前版本把这个决定下放到上下文级别。--bot-udp-proxy 控制单个上下文是否使用 UDP 代理和 HTTP/3。主命令行上的取值成为会话默认值，Per-Context 指纹可以为单个上下文覆盖该值。未设置自身取值的上下文沿用默认值，创建之后仍可调整该策略。

两个特性让结果可审查：策略只作用于设置它的上下文，对某个业务施加的限制不会让同一会话中的其他上下文失去 HTTP/3；策略只对已具备 UDP 权限的配置文件生效，因此它是在已批准的行为之间做选择，而不是开启部署尚未审核的路由。

按上下文记录这项选择，而不是按部署记录。每个上下文都应有明确负责人、已批准的传输方式清单，以及中继不可用时的预期结果。几个月后要说明为什么一个业务使用了 HTTP/3、相邻业务没有，靠的就是这份记录。

保护实时媒体通信

实时媒体需要特别审查。用户可能在允许麦克风或摄像头时，默认周围的网络政策仍然有效。隐私审查应在授予权限之前开始。先确定应用是否真的需要实时通信、哪些用户角色可以使用，以及这些会话允许出现什么网络结果。

对于已批准的用途，应把浏览器政策与能够承载所需流量的代理服务结合。服务商应以适合客户审查的方式说明 UDP 服务范围、区域覆盖、认证模式、服务限制和运维支持。组织再依据数据处理、访问控制和区域要求，判断该服务是否适合生产环境。

应用测试应关注正常用户行为。确认获授权的通话能够开始、保持可用、在普通网络变化后恢复，并能正常结束。权限提示、静音、设备选择和会话终止也应符合产品预期。这些检查能够在整个批准流程中保护隐私与可靠性。

如果工作负载不需要实时通信，应采用限制政策，避免不必要的网络路径进入运行环境。产品负责人要记录预期用户体验，防止有意限制被误认为服务故障。页面提供了未获批准的媒体功能时，支持团队也需要一段简明说明，帮助用户理解该环境的可用范围。

更换媒体供应商、会议组件或嵌入式通信工具后，应重新审查。即使可见的用户流程没有明显变化，新的组件也可能带来不同的网络要求。把这类变化当作网络变更处理，重新运行获授权流程，并将结果附到发布记录中。

审核代理服务能力

代理审核属于采购和运维工作，不只是一个浏览器设置。应请服务商书面确认，实际购买的套餐是否在部署使用的区域、认证方式和接入点上提供 UDP 中继能力。产品名称可能含糊，不同套餐或节点也可能具有不同能力。书面确认可以降低发布时的不确定性。

同时审查服务商如何通知维护和服务降级。团队需要知道 UDP 可用性是否与 TCP 分开报告、接入点变更如何通知，以及故障期间能获得哪些支持信息。笼统的“代理在线”状态，不一定能说明实时应用所需的批准路径是否可用。

商业和治理要求同样重要。数据处理条款、日志保留、访问控制、凭据轮换、区域路由和事件响应都会影响服务能否进入隐私敏感的部署。只有当整个服务达到组织对 TCP 路径的同等标准时，UDP 能力才具有实际价值。

代理凭据不应写入页面内容，也不应放入受版本控制的公开示例。只允许确实需要的系统和操作人员访问，并按照其他网络密钥的政策轮换。还要确认替换凭据时不需要改变已经批准的网络设计。

审核最终应形成一份简洁的服务记录：批准的服务商和套餐、覆盖环境、负责人、预期传输方式、支持联系人、审查日期和回退决定。服务商材料可以链接到内部变更记录。这样的记录比安装便笺或口头沟通更适合长期维护。

合同、区域、接入点或认证方式发生变化后，需要重新审核。浏览器配置看起来可能完全相同，但购买到的底层服务能力已经改变。基础服务发生实质变化时，新版本不能直接沿用旧批准。

预先定义允许的结果

在测试之前先写下可接受结果。对于确实需要 HTTP/3 的应用，批准结果可以是在经过审核、具备 UDP 能力的服务上正常运行。对于不需要 HTTP/3 的应用，批准结果可以是通过 TCP 继续完成网页访问。对于 WebRTC 工作负载，则可以规定只有经过审核的实时媒体路径可用时才允许相关功能。

路径不可用时的结果也要提前写明。如果中继服务无法承载已批准的 UDP 相关功能，应决定应用使用批准的替代传输、停用该功能、显示受控错误，还是暂停工作负载。没有定义的回退很容易变成意外网络路径，也可能导致不同环境出现不一致的用户体验。

运维人员应能识别当前结果。服务状态、应用日志和服务商状态可以说明所选政策是否可用。运维需要足够的信息来选择已批准的响应，并执行文档规定的恢复流程。

隐私验收和性能偏好必须分开。更快的传输并不自动合规，速度较慢但已批准的回退也不自动代表故障。先确认路径仍在政策范围内，再衡量用户体验和性能。这个顺序可以防止性能优化削弱隐私决定。

开发、预发布和生产环境应尽量使用相同的结果定义。如果较低环境使用不同的代理能力，就在测试结论旁明确标注。否则，预发布环境中的成功可能会让团队错误地推断生产环境也具备相同条件。

还要明确谁可以批准例外。服务暂时变化时可能需要进入受限模式，但运维人员不应在故障期间自行创造新路径。文档化的批准流程可以保持责任清晰，并为后续复盘提供依据。

验证获授权的应用

验证应使用组织有权测试的应用和账号。选择能够代表正常用户活动的流程，包括首次导航、登录后的业务操作、后台请求、获批准的实时媒体以及正常退出。测试既要确认产品行为，也要确认网络政策得到遵守。

从干净环境开始，使用计划发布的浏览器版本、Profile 家族、代理服务和网络政策，并把这些输入写入测试记录。输入条件保持一致，浏览器、Profile、应用或服务商版本变化后，结果才具有可比性。

观察用户可见结果和经过批准的运维信息。页面应按预期加载，受保护的操作应正常完成，媒体功能应遵循既定的可用性决定，受限功能也应以预期方式结束。服务商状态和组织自有的网络记录可以作为辅助证据，但其使用必须符合内部隐私政策。

测试还应包含常见运维中断。凭据轮换、接入点维护、浏览器重启或短暂网络中断，都应进入文档规定的回退或恢复状态。应用不能在发布负责人未批准的模式下静默继续运行。

发生实质变更后重新执行流程。浏览器家族升级、代理套餐变化、WebRTC 组件变化、DNS 政策变化和应用网络行为变化，都可能影响结果。之前通过的记录只是历史证据，不是永久批准。

控制单次测试的变更范围，使结果可以解释。如果同时合并许多基础设施变化，失败时很难定位责任，成功时也无法证明每项变化都正确。尽量分阶段修改，并保留上一份已接受配置，便于比较和恢复。

在中继不可用时按计划响应

UDP 中继不可用是一种需要预案的正常运维状态。正确响应取决于应用。网页访问可能通过批准的 TCP 路径继续，而实时媒体功能可能需要保持不可用。政策应优先选择明确限制，而不是未经批准的主机直连。

在部署设计阶段定义响应。说明哪些工作负载可以继续、哪些必须停止、用户会看到什么，以及谁会收到告警。如果组织准备了多个已批准的服务商或接入点，应记录切换条件，并确认备用服务完成了同样的审核。

避免未经审查就自动扩大网络访问。回退不能为了维持某项功能，把受限网络政策替换成一般主机连接。业务连续性很重要，但仍必须处于批准的隐私边界之内。

恢复也需要验证。服务恢复后，确认应用重新使用预期路径，并以受控方式解除临时限制。不能假设故障期间启动的浏览器进程会自动采用恢复后的政策，应遵循部署定义的正常生命周期步骤。

支持团队需要区分服务回退和产品缺陷。如果 HTTP/3 暂时不可用，但批准的网页访问通过 TCP 继续，这可能是允许的传输变化。如果实时通话因为缺少所需路径而无法开始，这可能是有意的隐私保护。清晰说明可以减少故障期间放宽政策的压力。

恢复后，把事件结果加入服务记录。写明受影响的应用行为、批准的响应、恢复动作，以及分配给服务商或内部负责人的后续事项。这样，故障可以成为下一轮审查的证据。

保留发布证据

审核人员应能根据证据还原发布决定。保存浏览器版本、Profile 家族、应用版本、代理服务、所选区域、网络政策、测试日期、负责人和结果，并记录已执行或确认的回退方式。这些信息能说明当时到底批准了什么。

优先保存简洁记录，而不是大量未经筛选的原始数据。签署的测试结果、变更单、服务能力声明和经过选择的运维日志，通常比无限制收集网络数据更适合审计。网络记录可能包含敏感信息，因此必须遵循组织的访问和保留规则。

证据应关联到具体版本。服务商声明可以支持服务审核，但不能证明某个应用流程已经通过。应用测试可以证明用户行为，但不能代替对服务商治理条件的审核。两类材料应归入同一发布决定，并注明各自用途。

受限和未通过的结果也要记录。如果某项功能在仅 TCP 政策下有意不可用，通过的测试应明确说明这一点。这样，后续团队不会把功能缺失误解成测试覆盖不足，进而在没有批准的情况下启用新路径。

不同环境使用可比较的政策名称。同一个标签在预发布和生产环境中应表达同一种传输决定；环境确有差异时，就在结果旁明确写出。统一命名可以加快审计，并减少部署错误。

重要假设发生变化后，证据就需要更新。为浏览器升级、代理服务变化、应用网络变化、区域调整和安全政策修订设置重新审查条件。明确的触发条件比承诺一次测试永久有效更可靠。

在清晰的运维边界内工作

明确职责有助于长期维持网络隐私控制。应用团队了解哪些功能需要实时通信；平台团队负责浏览器和代理配置；安全与隐私团队定义可接受路径；运维处理服务变化；支持团队向用户解释有意限制。把这些职责写入部署记录。

代理接入点、服务套餐、WebRTC 政策、HTTP/3 决定、DNS 政策和浏览器版本变化都需要变更控制。一处看似很小的配置编辑可能改变实际网络计划。同行审查和分阶段发布可以减少意外偏移。

监控运维能够采取行动的结果，包括服务可用性、应用成功状态、批准回退的使用、认证健康和服务商通知。不要收集超过运维决定所需的用户或网络数据。隐私控制不应产生新的、不必要的遥测数据。

生产凭据和证据访问必须受到限制。测试账号只获得运行授权流程所需的权限。发布记录应向审核和响应人员开放，而不应广泛暴露。调查或发布完成后，继续执行既定的保留政策。

支持边界也要写清楚。兼容中继取决于服务商、区域、账号和应用要求。BotBrowser 可以执行选定的浏览器政策，但不能把仅支持 TCP 的服务变成具备 UDP 能力的服务。明确这一区别，有助于把问题交给正确的负责人。

事件响应人员应熟悉批准的回退方案。他们需要知道何时允许 TCP 继续、何时实时功能必须保持受限，以及谁能批准替代方案。故障发生时，一份简短的操作流程比冗长的协议说明更有用。

在每次实质变更前重新审查

首次进入生产环境前以及每次实质变更后，都应重新审查网络计划。确认应用仍然需要获批准的 UDP 相关功能，实际购买的代理服务仍具备所需能力，并确认 TCP、UDP、WebRTC、HTTP/3 和 DNS 仍作为独立控制项记录。

在目标环境中执行获授权的应用流程，把结果与允许结果进行比较。验证文档规定的回退，但不要引入新的网络路径。保存发布证据，并取得部署记录中各负责人的批准。

发布期间观察应用健康和服务商状态。先从可控范围开始，确保可以恢复到上一份已接受配置。只有在用户行为和隐私政策保持稳定后才扩大范围。结果出现差异时，暂停发布，并使用已记录的限制或恢复方案。

移除功能时也需要同样审查。应用不再需要某条 UDP 路径后，应更新政策，避免旧权限继续保留。移除无用的网络访问可以降低运维复杂度，并缩小隐私边界。

支持的部署选项见 UDP over SOCKS5 文档。产品规划还可以查看 BotBrowser 功能、价格和下载。环境凭据、服务商记录和测试证据应保存在组织控制的系统内。

可靠的发布不会假设所有浏览器连接都使用同一路径。它会识别应用需要的传输方式，为每一种方式指定批准路径或限制，验证正常用户行为，并为下一次变更保留足够证据。这样，性能、可用性和隐私决定都能被相应负责人清楚理解和持续维护。