服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- GitHub 9 月 28 日更正日期：普通 GitHub Enterprise Cloud 的完整强制执行从原定 9 月 25 日移至 9 月 29 日，版本要求本身没有改变；官方未给出精确生效小时和时区。
- 低于 2.329.0 的 Runner 不能注册或重新注册；已注册 Runner 的作业执行最低版本更高，并随版本发布滚动。达到 2.329.0 不等于以后一直能执行作业。
- Enterprise Cloud with Data Residency 已在 7 月 31 日进入完整强制执行；GitHub Enterprise Server 不受本次 Enterprise Cloud 日期更正影响。
- 先盘点部署面、Runner 版本和队列状态，再查官方版本弃用信息并升级；本页没有登录任何企业账号，也不声称某个组织已经发生拒绝执行。
直接答案：9 月 29 日改变了什么
GitHub 2026 年 9 月 28 日公告把 GitHub Enterprise Cloud 自托管 Runner 的完整版本强制执行日期从 9 月 25 日移到 9 月 29 日；公告同时明确版本要求没有改变。实际开始的小时、时区和每个企业的执行结果未在公告中给出，因此不能仅凭日期断言自己的流水线已被拒绝。
这项规则可能影响 Runner 注册、重新注册和已注册 Runner 领取或执行作业。管理员应先判断组织使用的是普通 Enterprise Cloud、Enterprise Cloud with Data Residency，还是 GitHub Enterprise Server，再按不同门槛检查实际版本。
影响矩阵：普通企业云、Data Residency 与 GHES
普通 GitHub Enterprise Cloud：GitHub 写明 9 月 29 日开始完整强制执行。Enterprise Cloud with Data Residency：GitHub 写明其完整强制执行已于 7 月 31 日开始，本次更正不是为它延后截止。GitHub Enterprise Server（GHES）：GitHub 明确说本次更正不影响它；不能把企业云日期直接套到自建 Server 实例。
这里的日期来自公开公告，不代表某个企业在对应日期完成升级，也不是公开可查的账号级验收结果。混合部署团队要逐组织、逐 Runner 池保留版本和作业证据。
两个门槛：能注册不等于能执行作业
GitHub 公告写明低于 2.329.0 的 Runner 不能注册或重新注册。已注册 Runner 还有更高、持续滚动的作业执行最低版本；旧 Runner 即使仍显示在列表里，也可能不再执行作业。不要把 2.329.0 写成长期有效的统一运行下限。
GitHub 的时间线说明，Runner 应在每次新版本发布后 30 天内更新；关闭自动更新的镜像或容器需要由维护者定期升级。官方还提供按 Runner 版本查询注册与运行时弃用时间的 deprecations API。查询结果、组织设置和 Runner 日志应一起判断，单个旧注册审计事件不是完整的当前版本清单。
核查与升级步骤：先留基线再改 Runner
前提是拥有相应仓库、组织或企业的 Runner 管理权限，并能查看 Runner 主机或镜像。第一步列出部署面、Runner 池、主机或镜像中的版本、是否允许自动更新、最近一次成功作业及当前排队或失败状态。把注册失败与已注册 Runner 不接作业分开记录。
第二步按官方 9 月 3 日公告使用对应仓库、组织或企业范围的 GET /actions/runners/deprecations/{version} 查询版本弃用信息，分别查看 registration_deprecates_at 与 runtime_deprecates_at；无权限、接口不适用或结果与界面冲突时停止推断，改查该部署面的官方文档和日志。第三步依 GitHub 自托管 Runner 更新流程升级安装包或基础镜像，先在一个非关键 Runner 池验证，再逐批推广，并记录升级前后版本。
第四步让有权维护者检查 Runner 能否重新注册，以及一个代表性作业是否真正领取并完成；同时查看实际错误和队列时间。本文只给核查路径，没有访问企业账号、执行升级或取得实测成功结果。
失败判断、停止条件与适用回滚
若 Runner 无法注册，先核对部署面、版本与 registration_deprecates_at；若已注册但作业持续排队，再核对 runtime_deprecates_at、Runner 是否在线、标签匹配、权限和日志。网络、容器拉取或代理故障也会使流水线失败，不能把所有排队或失败都归因于版本门槛；相关网络排查可参考<a href="/resources/docker-proxy-build-pull-runtime-guide">Docker 代理与拉取排查</a>。
升级后如出现新故障，停止批量推广，保留旧镜像与错误日志，先在隔离池复现并向 GitHub 文档或支持核实。只有旧版本仍符合当前注册和执行门槛时才考虑回退；已被强制拒绝的旧 Runner 不能作为恢复流水线的可靠回滚目标。优先恢复到已验证的受支持版本，并验证新作业完成。PRODUCT_FIT=NONE：更换 IP 不能改变 GitHub 的 Runner 版本资格。
哪些仍需由你的企业现场确认
公开公告没有披露每个企业的 Runner 清单、当前动态执行下限在本组织的判定结果、具体强制执行小时，或队列中每项作业的失败原因。要回答“今天是否影响我”，必须把官方规则与自己的 Runner 版本、弃用接口结果和作业日志对应起来。
本指南记录的是 2026 年 9 月 29 日可核实的官方规则。后续版本最低门槛会滚动，遇到新的 GitHub 公告或运行结果与本文不符，应优先复核官方最新时间线并更新原页面，不靠修改日期维持表面新鲜。
资料来源
常见问题
GitHub 自托管 Runner 的 9 月 29 日强制执行适用于谁？
GitHub 本次把普通 GitHub Enterprise Cloud 的完整强制执行日期改为 2026 年 9 月 29 日。Enterprise Cloud with Data Residency 已于 7 月 31 日开始；GitHub Enterprise Server 不受这次日期更正影响。
Runner 达到 2.329.0 就一定能运行作业吗？
不一定。2.329.0 是公告列出的注册或重新注册最低版本；已注册 Runner 的作业执行最低版本更高且持续滚动，须查看当前弃用信息和实际作业结果。
如何核查某个 Runner 版本何时被弃用？
GitHub 公告提供按版本查询的 deprecations API。按有权管理的仓库、组织或企业范围查询，并分别核对 registration_deprecates_at 和 runtime_deprecates_at；账号级结果与日志仍要现场验证。
9 月 29 日是否意味着我的旧 Runner 已经失败？
不能仅凭公告日期判断。官方没有给出你的账号版本、精确执行小时或作业结果；应检查 Runner 在线状态、实际版本、注册错误和代表性作业日志。
升级失败后能否回退到旧 Runner？
仅当旧版本仍符合当前注册与作业执行门槛时才有适用的回退空间。若旧版本已被拒绝，停止批量推广并恢复到已验证的受支持版本，再验证新作业。