问题一：分数随场景变
同一个维度「网络可达性」，在企业可控出口里 DoT 可以给 5 分，在公共 Wi-Fi 为主的移动场景里只能给 2 分。维度不变、分数却变了 —— 固定表无法表达这一点。
选型手册
协议选型手册
先说一件容易被跳过的事：没有任何一张固定的分数表能替你选协议。同一组分数换个场景就会得出相反结论。本页给的是流程与评分标准 —— 分数得由你的环境填。
为什么本页不给「标准答案分数表」
很多选型文档会给一张填好分数的表，看着专业，但那些分数几乎都来自作者的假设，而不是你的环境。
问题二：权重由目标决定
「需要自己看得见（审计）」和「只要能用得上（可达性）」是两种目标，权重差异足以颠覆排序。权重不该由文档规定。
问题三：分数若无标准就不可复现
若没写清「5 分和 3 分差在哪」，不同人打分结果不同，算出来的排序自然也不可信 —— 这一项是最容易被忽略、却最影响结论的。
所以本页的做法是：先给收窄流程（逐步排除显然不合适的候选，不依赖打分），
再给评分标准（把 1 / 3 / 5 各代表什么写清楚，让打分可复现），
最后用两个假设场景走一遍完整算例，并展示它们的结论如何相反。
第一步：先用约束收窄候选，而不是先打分
顺序很重要。打分是用来在「都可用」的候选之间做取舍的；如果先打分，容易把一个在目标网络里根本用不了的协议排到前面。
① 网络约束 —— 先问「能不能通」
把目标网络里实际可达的传输列出来。这一步不做主观判断，只做事实核对：
- 出口是否允许
853/tcp（DoT、DoQ 的 TCP 侧） - 是否允许
853/udp（DoQ） - 是否允许
443/udp（DoH3；部分网络整段封 UDP） - 是否有 TLS 中间盒会干扰证书校验
结论若是「853 封禁」，后面三步就不用考虑了 —— 这正是先做这一步的价值。
② 治理目标 —— 排除掉看不见的
若你的目标包含「自己要看得到」（企业审计、故障定位、策略追溯）， DoH 与 DoH3 会带来根本冲突：它们的可达性正来自「与普通网页流量无法区分」， 而这同时意味着你的管理方也看不清。
这一步通常排除 DNSCrypt（非 IETF 规范，缺少统一的审计与运维接口）。
反过来，若你的目标是「尽量不被看见」，这一步的结论会完全不同 —— 那正说明权重该由你定。
③ 客户端生态 —— 排除掉支持面过窄的
候选协议要能在你的实际终端上落地。这一步查三件事：
- 操作系统是否原生支持（Windows 11 / Android 9+ 支持 DoH / DoT，iOS 需描述文件）
- 网关或代理设备是否支持该协议（DoQ 的支持面普遍较窄）
- 出问题时的排障工具是否完备（DoQ 需要能解析 QUIC）
把「生态成熟度」放在打分阶段之前，是因为它常常是硬约束而非偏好 —— 终端不支持，分数再高也落不了地。
④ 失败回退 —— 定主用与备用
最后一步不是选出唯一的赢家，而是确定主用 + 备用的组合，并写清触发条件：
- 主用协议不可达时的切换条件（超时阈值、连续失败次数）
- 回落目标不应是明文 —— 那会让整条链路的意义归零
- 回落过程要可观测（否则你只会看到「变慢了」，不知道原因）
本例的结论是 DoT 主 + DoH 备：主用选可治理的那个，备用选可达性最好的那个 —— 两者恰好互补。
第二步：把评分标准写清楚
下面每一档都给了明确判据。没有这份判据，同一张表由不同人打分必然得出不同结论 —— 那样的排序没有参考价值。
| 维度 | 1 分 | 3 分 | 5 分 |
|---|---|---|---|
| 网络可达性 | 目标网络中该传输被明确封禁 | 部分网络可用，需要回落机制 | 目标网络中普遍可用，无需回落 |
| 治理可观测性 | 管理方完全看不到 DNS 行为 | 能看到元数据（如连接存在），但看不到查询内容 | 可逐域名审计并施加策略 |
| 弱网性能 | 高丢包时明显劣化（如队头阻塞） | 与明文解析相当 | 高丢包下仍稳定，连接可迁移 |
| 生态成熟度 | 主流终端普遍不支持，需专用客户端 | 主流客户端支持，但需手动配置 | 操作系统或浏览器原生支持 |
| 运维复杂度 | 需专门人力维护与排障 | 有标准工具链，偶发问题可查 | 基本无需额外运维 |
注意「网络可达性」与「治理可观测性」这两项常常互相牵制： 越难被识别（可达性高）往往意味着越难被审计（可观测性低）。 认清这一点，就不会期待找到「两项都满分」的协议 —— 那不存在。
第三步：两个假设场景，结论相反
下面两组分数都明确声明了假设。请重点看它们如何得出不同结论 —— 而不是照抄分数。
场景 A某企业内网 · 200 台终端 · 出口可管控 · 目标：审计可见 + 稳定
| 维度（权重） | DoT | DoH | DoH3 | DoQ | ODoH |
|---|---|---|---|---|---|
| 治理可观测性（30%） | 5 | 2 | 2 | 3 | 1 |
| 网络可达性（25%） | 5 | 4 | 3 | 3 | 3 |
| 生态成熟度（20%） | 4 | 5 | 3 | 2 | 1 |
| 弱网性能（15%） | 3 | 3 | 5 | 5 | 3 |
| 运维复杂度（10%） | 4 | 3 | 3 | 2 | 2 |
| 加权总分 | 88 | 67 | 60 | 60 | 38 |
场景 B个人设备为主 · 常连公共 Wi-Fi · 目标：可达性优先，不需要企业审计
| 维度（权重） | DoT | DoH | DoH3 | DoQ | ODoH |
|---|---|---|---|---|---|
| 网络可达性（40%） | 2 | 5 | 4 | 3 | 4 |
| 生态成熟度（30%） | 4 | 5 | 3 | 2 | 1 |
| 弱网性能（20%） | 3 | 3 | 5 | 5 | 3 |
| 治理可观测性（5%） | 5 | 2 | 2 | 3 | 1 |
| 运维复杂度（5%） | 4 | 3 | 3 | 2 | 2 |
| 加权总分 | 61 | 87 | 75 | 61 | 53 |
请注意这里「可达性」的得分变化不是随意调的：在公共 Wi-Fi 场景下， 853 被策略限制是常见情况，而 443 几乎总是可用的 —— 这属于事实差异，不是偏好。
如果只看到上面任何一个场景，很容易以为「就该选那个」。两个场景放在一起，
才是这张表真正的用法：把权重和得分换成你自己的，然后看排序是否稳健。
若换几组合理假设后第一名不变，这个结论才值得信任。
第四步：迁移路径（附适用判据）
每条路径都给了「什么条件下选它」—— 没有判据的路径建议等于没有建议。
路径 A：DoT 起步
适用判据：组织有可控出口，且需要审计或合规留痕；终端以桌面与内网设备为主。
先落地治理边界与监控，再按场景引入 DoH 作为对外的补充通道。这样做的原因是：治理能力一旦缺位，后面补齐的成本远高于一开始就建。
路径 B：DoH 起步
适用判据：终端分散、网络环境不可控（移动办公、公共网络），治理不是首要目标。
先保证可达性，再通过网关或终端策略补治理。但要接受一个代价：一旦走这条路，你自己对 DNS 的可观测性会显著下降，事后想补往往需要改动架构。
路径 C：DoQ / DoH3 试点
适用判据：目标网络存在明显丢包或高时延；且有精力把 QUIC 的排障工具链建起来。
建议只在部分区域灰度。在 QUIC 排障能力跟不上之前扩大范围，出问题时你只能看到「变慢」，定位不到原因。
路径 D：存量兼容
适用判据：已有 DNSCrypt 部署，且短期内无法替换。
要点是不要长期双栈：明确迁移时间表与退出条件，否则两套体系会一直并存，运维与排障成本叠加。
选型时最常见的四个错误
都来自实际的评审场合，且都会让结论偏离可用性。
| 错误做法 | 为什么会出问题 |
|---|---|
| 照抄别人的分数表 | 分数依赖对方的环境假设。若不声明假设，这组数字对你的场景可能完全无效 —— 甚至误导。 |
| 先打分再排可行性 | 会把「在目标网络里用不了」的协议排到前面，返工成本很高。正确顺序是先收窄候选，再在候选内打分。 |
| 只评主用协议，不定回退 | 主用不可用时往往临时切回明文，安全性归零，而且没人及时发现。回退方案必须与主用一起定。 |
| 把「协议」当成全部决策 | 真正决定隐私水平的是解析器是谁与它的日志政策 —— 协议只决定链路上是否可见。这一点在基础与威胁模型里已经说明。 |
接下来
选型定下来之后，是把它安全地上线并长期维护。