GitHub Runner 熔断演练开始：先检查代理出口再排查任务停滞

GitHub 公布的计划显示，GitHub Enterprise Cloud 自托管 Runner 于 2026 年 9 月 14 日进入新的熔断演练阶段，9 月 16 日和 18 日还有配置与执行联合演练，9 月 25 日计划全面执行最低版本要求。对于在自托管基础设施上运行合规数据采集、浏览器测试、广告验证或市场研究任务的团队，风险不只来自旧 Runner。代理、防火墙或企业证书链也可能让原本在线的 Runner 无法更新、重新注册或保持服务连接。

GitHub 还在 9 月 3 日发布了 Runner 弃用信息 REST API，返回 Runner 版本、注册停止时间和执行停止时间，便于平台团队在任务长期排队前自动识别风险。

这不是代理产品变更，而是一次运维就绪事件。正确做法是盘点版本、验证现有网络政策下的控制面链路，并在下一窗口前运行一项有代表性的灰度任务。

GitHub 公布了什么

官方计划给出了两个不同要求：重新配置或注册 GitHub Enterprise Cloud 自托管 Runner 时，版本至少为 2.329.0；继续执行任务时，则需要在每个新版本发布后的 30 天内保持更新。

注册最低版本不是永久的执行最低版本。固定在旧镜像里的 Runner 会随着执行门槛移动而失去资格。GitHub 还说明，关键安全更新发布时，旧 Runner 的任务排队可能被暂停，直到完成升级。

9 月 14、16、18 日的演练窗口为美国东部时间上午 11 点至下午 3 点。期间不受支持的 Runner 可能间歇性无法注册或执行任务。GitHub Enterprise Cloud 计划在 9 月 25 日全面执行；本计划不包含 GitHub Enterprise Server。

为什么使用代理的 Runner 要单独检查

自动更新只有在 Runner 能通过批准的网络路径访问所需服务时才有效。常见断点包括：

• 白名单允许仓库流量，却遗漏 Runner 更新流量；
• 代理凭证过期或作用域错误；
• Runner 镜像缺少企业 TLS 检查证书；
• 服务账号与交互式终端读取不同的代理环境变量；
• 代理网关或服务端点在 Runner 网络中解析不同；
• 虚拟机、容器或扩容模板缓存了旧 Runner；
• 长任务中粘性出口意外变化；
• 重试策略把短暂拒绝放大为连接风暴。

不要通过绕过企业代理或未经审核扩大出口权限来“修复”。目标是证明批准链路，并记录最小必要规则。

立即执行五步检查

1. 盘点全部 Runner

记录名称、操作系统、版本、镜像来源、自动更新设置、负责人、代理路由和最近一次成功任务。必须包括临时池和自动扩容模板，因为当前在线机器正常，并不代表以后新建的镜像是新的。

在权限允许的仓库、组织或企业范围调用弃用信息接口，同时比较注册和执行时间。无法解析的响应应视为盘点失败，不能假设仍受支持。

2. 使用真实服务账号测试

诊断必须使用启动 Runner 的同一身份、环境和服务管理器。管理员终端可能拥有不同的代理变量、证书库和 DNS。

确认 Runner 报告预期版本；代理变量指向批准网关且日志不含秘密；HTTPS 隧道和证书链可用；内部敏感主机没有被错误送入代理；更新检查不会反复要求认证。代理用户名、密码、令牌、Cookie 和完整请求头都应脱敏。

3. 先分类失败再重试

不要通过轮换出口 IP 处理版本政策拒绝。版本问题不是线路质量问题。

4. 更新源镜像

若 Runner 来自黄金镜像、容器或启动脚本，应更新源头，而不是只修补在线机器。创建完成后读取实际二进制版本，不能只相信构建日志中的包版本。

保留回滚能力，但不得回退到已不受支持的 Runner。将网络和代理配置单独版本化，便于区分 Runner 升级回归与出口政策变化。

5. 灰度一项生产形态任务

选择小规模、已授权且不会给外部目标制造负载的工作流，覆盖代码或制品访问、代理认证、DNS、TLS、一次轻量目标请求、结果验证和日志脱敏。

先在一个新 Runner 上运行，并保留旧容量。比较排队、注册、连接建立、首次成功率、407、TLS 失败和清理结果，再逐步扩大新池。

可用代理出口证明指南记录预期路径；若出口属于白名单，应按代理出口白名单切换流程保留重叠验证。

为演练窗口增加专用监控

按 Runner 池和镜像版本观察注册失败、无合格 Runner 的排队任务、任务启动与完成率、代理认证、隧道和 TLS 失败、更新检查失败、每个逻辑任务的重试量、出口路由或 ASN 突变、取消后的清理情况。

使用关联 ID 连接 Runner 生命周期、任务、代理路由与最终结果，但不得暴露凭证。保留窗口前、中、后的证据，四小时平均值可能掩盖 20 分钟尖锐故障。

同时改进工作流身份观察

GitHub 9 月 3 日的更新还为可复用工作流增加了定义工作流的引用、提交、仓库和文件路径上下文。在可用范围内，这些字段能帮助确认究竟是哪一个复用工作流定义了任务。

它们是可观察性信号，不是单独的授权依据。不得把不可信事件数据直接拼入命令、代理配置或目标 URL。保持最小权限，并通过平台秘密控制保护网络凭证。可参考GitHub Actions 代理缓存检查指南验证 CI 网络行为。

就绪检查清单

• [ ] 所有固定与临时 Runner 来源都已盘点。
• [ ] 已收集版本和两个弃用时间。
• [ ] 测试在真实 Runner 服务账号下执行。
• [ ] 镜像与日志中没有嵌入代理凭证。
• [ ] HTTPS 隧道、DNS 和 TLS 信任通过。
• [ ] 黄金镜像和启动脚本生成受支持版本。
• [ ] 生产形态灰度任务在新池通过。
• [ ] 407、TLS、DNS、超时与版本拒绝已分开。
• [ ] 重试有上限并加入抖动。
• [ ] 演练监控按 Runner 与镜像版本分组。
• [ ] 回滚目标仍受支持且符合网络政策。
• [ ] 没有混淆 Enterprise Cloud 与 Enterprise Server 范围。

常见问题

2.329.0 会永久够用吗？

不会。它是新架构的注册最低版本，执行资格会随新版本发布而移动。

本计划影响 GitHub Enterprise Server 吗？

GitHub 说明这次 Enterprise Cloud 计划不影响 Enterprise Server，但后者仍需遵循自身版本支持政策。

代理会让合格 Runner 看起来过旧吗？

代理不会改变本地版本，但可能阻断更新、注册或服务通信。版本和网络可达性必须分层诊断。

演练期间是否应绕过代理？

不应作为常规修复。先验证批准路径，确有必需端点被阻止时，再申请最小且经审核的规则变更。

何时应该回滚？

只有新镜像出现已验证回归、且旧镜像仍受支持时才回滚。不得回退到服务将拒绝的版本。

合规说明

自托管 Runner 与代理仅用于合法、已授权的工作流。遵守目标条款、访问政策、速率限制、隐私义务和组织网络控制。不得使用替代路线或地址轮换规避 GitHub 执行规则或目标限制。保护秘密、最小化日志，并在改变出口政策前获得审核。

内部核对来源：GitHub Changelog《GitHub Actions: Early September 2026 updates》，2026 年 9 月 3 日；GitHub Changelog《GitHub Actions: Minimum version enforcement timeline for self-hosted runners》，2026 年 6 月 12 日。