Cloudflare新增后量子TLS可见性：访问端与回源连接要分别检查
Cloudflare于2026年9月29日增加后量子TLS可见性：HTTP Traffic Analytics展示访问者到Cloudflare的密钥交换组，日志提供ClientTLSKeyExchangeGroup；回源连接则可通过Logpush中的OriginTLSKeyExchangeGroup观察。两段连接应分别核对。 一手来源。
图：AI生成两段连接加密观测概念配图，不是产品截图、实测结果或真实设备设计图。
TLS版本之外，多了一层协商信息
官方指出，仅知道连接使用TLS 1.3，还不能据此判断采用了哪种密钥协商组。这次更新把相关信息放到域名分析和日志中，便于查看实际流量；仪表盘统计范围与具体日志字段的范围并不完全相同。
文章还区分了后量子加密与后量子身份认证。看到某类密钥交换已被使用，不等于整套证书和签名流程也已完成迁移。本文没有调整任何加密设置，也不依据单个字段给网站作全面安全认证。
独立分析：先画出你实际观察的链路
一个使用代理服务的网站通常涉及访问端、代理层和源站。浏览器到代理的一次协商结果，只能说明这一段连接；要理解后面的路径，还需要回源侧证据。将不同段落的数据混成一个总比例，容易掩盖真正需要调查的地方。
建议先把每份图表旁边写上采集位置、时间范围和计数单位。按请求统计与按连接统计可能回答不同问题；同一连接承载多个请求时，解释比例尤其需要清楚。没有明确单位的“覆盖率”，很难与下一次观测可靠比较。
低比例先找原因，不直接下结论
某个域名的比例较低，可能与访问端软件、连接路径或所选时间窗口有关。应先挑选获准的代表样本，核对实际协商结果和配置，再判断是预期的兼容性情况还是值得处理的缺口。不要只为了让图表数字变好，就突然拒绝一批合法客户端。
还要把空值、旧算法和未知状态分别解释。字段未出现可能来自采集或日志配置，并不能直接推导为没有加密。观测系统本身也需要验收：确认字段确实进入了目标记录、解析没有丢失，并且仪表盘筛选条件符合当前问题。
让观测结果进入可执行的维护记录
发现需要处理的链路后，记录具体环境、责任人、兼容要求与验证方式。更改前先保留现状，在测试范围内验证相关客户端和业务请求，再按既有流程安排实施。安全设置的变化应有明确理由，不能由一张概念图或一条聚合统计直接决定。
这次更新有助于把抽象的迁移讨论转成实际连接证据。读者最先可以做的是整理自己的观测范围，并确认两段路径分别由谁负责。只有数据含义与责任范围都清楚，后续迁移计划才有可复查的起点。
资料核对：2026年10月1日（北京时间）。本文事实与独立分析已分别标明，后续可用范围请以所附官方资料为准。
