如何测试加密客户端问候通过代理的兼容性
Encrypted Client Hello（ECH，加密客户端问候）会保护 TLS ClientHello 中包括 SNI 目标名称在内的敏感字段。它改变了被动网络观察者能看到的信息，但不代表所有代理路径都天然私密、兼容或配置正确。
浏览器可能从 DNS HTTPS 记录发现 ECH 配置，也可能只发送 GREASE 占位、在配置不匹配后重试、关闭 ECH 回退，或直接复用现有连接。因此，页面加载成功不能证明 ECH 已被接受。
本文面向获授权设施建立验收测试，覆盖 HTTP CONNECT、HTTPS 代理、受管 TLS 检查与直连控制路径，不用于绕过组织策略或向代理运营方隐瞒流量。
先定义可见性边界
| 路由组件 | 可能看到的信息 |
|---|---|
| 本地 DNS 解析器 | HTTPS 记录查询及返回的 ECH 配置 |
| 被动网络路径 | 目标地址、时间、外层 ClientHello 与公开名称 |
| 显式代理 | 代理认证及客户端请求的 CONNECT authority |
| 透明隧道 | 外层 TLS 握手，通常看不到加密后的内层 ClientHello |
| 获批准的 TLS 检查网关 | 其依组织策略终止的流量 |
| 目标边缘 | 内层 ClientHello 及 ECH 是否被接受 |
如果客户端在 CONNECT 请求中发送主机名，ECH 不会向显式代理隐藏该主机名。隐私声明与兼容声明必须分开测试。评估前先用代理 TLS 检查审计确认每个终止点。
建立小型受控矩阵
使用自己控制的目标与 DNS 区域，或提供商支持的测试端点。准备：当前 ECH 配置、无 ECH 配置、隔离区中的过期测试配置、只返回 A/AAAA 而不返回 HTTPS 记录的解析路径，以及直连、HTTP CONNECT、HTTPS 代理和明确获批的检查路径。
保持应用内容、账号状态、客户端版本与地区不变，每次只改变一个变量。不要修改第三方 DNS 或生产检查策略。
先验证 DNS 责任方
ECH 依赖客户端取得可用配置，通常来自 DNS HTTPS 服务绑定。记录解析器类别、响应码、HTTPS 记录是否存在、配置标识或哈希、TTL 与响应年龄。
比较每条路由上客户端实际看到的答案。代理可能完全不承载 DNS；操作系统、浏览器安全 DNS 或 SOCKS 远程解析模式可能选择不同解析器。SVCB 与 HTTPS DNS 兼容测试可用于建立记录发现和别名处理基线。
不要记录完整浏览历史或客户主机名，应使用自有样例、匿名路由别名和配置哈希。
证明“接受”，而不是只看到扩展
出现 encrypted_client_hello 扩展不代表 ECH 成功。客户端即使没有可用配置，也可能发送 GREASE 值。证据应区分：未尝试、仅 GREASE、使用预期配置的真实 ECH、服务端接受、认证重试配置、明确失败，以及未使用 ECH 的回退或重试。
优先使用能明确报告接受状态的客户端或服务端诊断。若获准抓包，只把它当辅助证据并缩短留存。不能仅凭 HTTP 成功响应推断 ECH 被接受。
隔离代理跳点
依次运行冷启动测试：获批准直连控制、HTTP CONNECT、单独验证客户端侧 TLS 的 HTTPS 代理，以及适用时的受管检查路径。冷测试之间关闭可复用连接池，记录代理协商、CONNECT 结果、目标 TLS 结果、ECH 状态、ALPN、地址族与总耗时。
HTTPS 代理的客户端到代理 TLS，与 CONNECT 内部的目标 TLS 是两条不同连接。目标 ECH 不负责验证代理证书。ALPN 协商审计可将协议协商失败与 ECH 失败分开。
识别重试与回退
配置轮换可能导致服务端拒绝旧配置并提供重试信息，客户端随后用新传输连接再次尝试。这不同于静默关闭 ECH 后继续。
建议记录：路由别名、客户端版本、解析器类别、HTTPS 记录哈希、ECH 提议类别、接受状态、重试次数、回退类别、连接/TLS/总耗时及结果类别。用无敏感信息的请求标记关联客户端、代理和目标证据，绝不记录代理密码、Cookie、私钥或原始客户目标。
代理失败后客户端若意外直连，ECH 测试应判定失败。应把代理绕过审计应用于每次重试，而不只是第一次请求。
测试冷热状态
DNS TTL、ECH 配置缓存、TLS 会话恢复与连接复用都可能掩盖变化。至少测试：空 DNS/连接状态的冷进程、TTL 内第二次请求、受控配置轮换后、缓存到期后、允许会话恢复的暖请求，以及路由变更后的新连接。
如果请求复用了现有连接，既没有新 DNS 也没有新 TLS 握手，就不能把结果归因于配置轮换。每个样本都要记录是否真正建立了新传输。
验收门槛
- 预期 DNS HTTPS 记录抵达正确客户端。
- 能区分真实 ECH 与仅 GREASE。
- 目标侧证据在预期时确认接受。
- 过期配置按文档执行重试。
- 没有未经批准的直连回退。
- 代理与目标 TLS 故障可分别归因。
- 准确描述显式代理可见性。
- 受管检查行为符合组织策略。
- 缓存与连接复用不会伪装成新成功。
- 日志只保留别名和哈希，不含秘密或浏览历史。
排错对照
| 现象 | 优先检查 |
|---|---|
| 只有一个客户端缺少 HTTPS 记录 | 解析器责任方、安全 DNS 策略与缓存 |
| 有扩展但服务端报告未使用 ECH | GREASE、过期配置或不支持的套件 |
| 直连成功但 CONNECT 失败 | 代理协议支持、目标可达性与策略 |
| 首次握手重试、第二次成功 | 配置轮换及认证重试证据 |
| 页面加载但没有新 TLS 事件 | 连接复用或会话恢复 |
| 代理失败后直连成功 | 绕过或回退策略违规 |
| 检查路径行为不同 | 检查兼容性和受管客户端策略 |
GeoDNS 一致性测试可帮助区分地区答案漂移和 ECH 配置问题。
常见问题
ECH 会让显式代理看不到目标吗？
不一定。即使后续 TLS ClientHello 的 SNI 被保护，显式代理仍可能在 CONNECT authority 中收到目标主机名，必须依据实际应用到代理协议判断。
抓包看到 ECH 扩展足以证明成功吗？
不足。它可能只是 GREASE。应确认使用了真实配置，并取得客户端或服务端接受证据。
为隔离 ECH 错误可以关闭证书验证吗？
不可以。证书、主机名与 ECH 检查保护不同属性，应保持验证开启并使用受控证书。
更换代理出口能修复过期 ECH 配置吗？
只有当路由确实改变了解析器或目标边缘证据时才可能影响结果，而且必须解释原因。随机轮换不是修复，应直接诊断 DNS、配置年龄与重试。
合规说明
只测试自己拥有或获授权评估的目标、DNS 区域、客户端与代理设施。遵守网络策略、隐私义务和提供商条款。不得利用 ECH 测试绕过访问控制、隐藏被禁止活动，或在未获授权时削弱合规检查。
