一句话看懂：GitHub 宣布，2026 年 10 月 7 日起，带数据驻留能力的 GitHub Enterprise Cloud（GHE.com）将不再接受仅提供 X25519 密钥协商算法的 TLS 客户端。绝大多数用户无需改动，只有把加密套件写死成“只支持 X25519”的应用、代理或安全设备会连不上。
事件核心：发生了什么
根据 GitHub Changelog 的公告，从 2026 年 10 月 7 日开始，GitHub Enterprise Cloud with data residency 将停止接受仅使用 X25519 进行密钥协商的 TLS 连接。受影响的端点会继续支持 FIPS 认可的 P-256（secp256r1）和 P-384（secp384r1）椭圆曲线组。
GitHub 明确表示，主流浏览器、操作系统、GitHub CLI 版本以及常用 TLS 库都已支持 P-256，因此大多数客户不需要采取任何行动。可能受影响的，是那些被显式配置为“只提供 X25519”的应用程序、代理服务器、安全设备或 TLS 库。GitHub 建议在截止日期前更新操作系统、运行时、GitHub CLI、代理和 TLS 库，移除仅 X25519 的配置，并确保启用 P-256。此次调整仅针对带数据驻留的 GitHub Enterprise Cloud，SSH 连接不受影响。
为什么重要
TLS 握手中的密钥协商算法，是加密通信能否建立的地基。X25519 因为性能好、实现简洁，近年来在不少现代客户端和库中成为默认首选，但部分内部系统为了“统一配置”把它写成了唯一选项。一旦服务端不再接受这种单一算法，问题不会表现为“速度变慢”，而是直接握手失败、HTTPS 连接建立不起来。
这次变更的方向也值得留意：GitHub 选择保留 FIPS 认可的 P-256 和 P-384，而不是继续兼容所有曲线组合。对同时服务金融、政企、云原生等多类客户的平台来说，把加密基线往合规标准上靠，正在成为一种更常见的运维选择。目前公开信息显示，GitHub 没有给出更技术化的解释，但“FIPS-approved”这一措辞本身已经说明了取舍逻辑。
对用户/开发者/创作者的影响
对绝大多数开发者来说，这次变更几乎没有存在感：Chrome、Safari、Edge、主流 Linux 发行版和常见编程语言的 TLS 栈都已经默认启用 P-256。换言之，只要你不主动把客户端配置裁剪成只剩 X25519，就不会受影响。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
真正需要动手的是维护内网代理、企业级安全网关、自建 CI/CD 出网链路或私有 TLS 配置的团队。这类系统往往集中管理加密套件，改动一次会影响大量下游服务。建议在截止日期前做一次探测：用受影响端点的域名跑一遍握手测试，确认客户端实际提供的曲线列表里包含 secp256r1。如果只看到 X25519，就需要更新组件或补上 P-256。GitHub 也提示可以联系官方支持来协助验证 TLS 配置。
对依赖 GitHub 做代码托管、Actions 流水线或企业协作的团队而言，还有一个隐性动作：把这次变更纳入证书与加密配置的例行巡检清单。类似的服务端加密策略收紧，未来可能出现在更多平台上，提前建立验证流程比临时排障更省成本。
值得关注的后续
一是看是否会有更多 GitHub 产品线或云服务跟进同一策略，把 FIPS 认可的曲线组作为默认底线；二是观察依赖旧配置的工具链和自建代理是否在 10 月 7 日前后集中暴露兼容问题；三是留意 GitHub 是否提供更细的诊断工具或错误提示，帮助管理员快速定位握手失败的具体原因。SSH 不受影响这一点目前可以放心，但 HTTPS 相关的自动化脚本仍值得提前自查。
