GHE.com将在10月7日调整TLS协商：仅提供X25519的客户端需要检查
GitHub在2026年9月30日公告：从10月7日起，带数据驻留的GitHub Enterprise Cloud不再接受仅提供X25519密钥协商组的TLS客户端。相关端点继续支持P-256与P-384；SSH连接不受影响。公告认为多数使用当前主流客户端的客户无需操作。 官方公告。
图：AI生成加密协商兼容检查概念配图，非真实产品界面、测量数据或官方标识。
只检查适用范围内的链路
这次调整限定于带数据驻留的Enterprise Cloud。需要关注的是明确限制为仅使用X25519的应用、代理、安全设备或TLS库配置。官方建议检查受支持的软件版本与协商配置，确保支持P-256。
核对时应读公告正文中的生效日期：本文所附官方链接的路径仍含旧日期文字，但页面标题与正文写的是2026年10月7日。本文发布时该日期尚未到来，不能把未来变更写成已经全面发生的故障。
独立分析：从真实请求路径盘点
一个虚构企业可能同时通过浏览器、构建任务和内部集成访问服务。员工浏览器正常，不能证明构建容器里的运行时也正常；本机命令成功，也不能代表经过企业代理的链路已通过验证。盘点应以实际发出请求的环境为单位。
记录每条链路的用途、软件版本、代理位置和维护人。对于容器或临时任务，还应追溯其基础镜像和创建模板，否则即使当前实例更新了，下一次启动仍可能恢复到旧配置。盘点不需要收集凭据，只需保留能解释兼容性的必要信息。
测试成功应保留可解释证据
在获准的测试环境中，使用与实际工作一致的路径验证正常业务请求，并保留时间、端点范围、客户端版本和握手结果。只看到网络端口连通还不够，因为连接建立、TLS协商与后续应用请求分别可能失败。
遇到问题时，先区分解析、连接、证书验证、协商和身份认证阶段。不要为了“先连上”而关闭证书验证或随意降低其他安全要求。应根据官方支持范围修复兼容性，再重新验证完整流程。
把维护窗口留给验证与恢复
对确实受影响的链路，安排变更前应保留现状说明和恢复方案，并找一个能代表真实任务的验证样本。变更后不仅检查交互式访问，还应检查定时集成、制品上传等平时较少被手工触发的路径。
如果组织没有使用公告涉及的产品范围，则无需因为标题包含TLS就改动所有环境。把适用范围、生效日期和责任人放在同一份维护记录里，能够减少无关操作，也更容易确保真正需要处理的链路没有遗漏。
核对时间：2026年10月1日（北京时间）。新闻事实依据所附一手来源；独立分析为本站观点，产品范围与文档以官方后续更新为准。
