GitHub Actions 停用 Node 20：代理 CI 迁移至 Node 24 的实战方案
GitHub 于 2026 年 9 月 23 日宣布，GitHub Actions runner 已不再提供 Node 20。JavaScript Action 现在使用 Node 24 执行，临时的 ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION 退出开关也已移除。Action 维护者需要把 runs.using 更新为 node24 并发布新版本，工作流使用者则应升级到支持 Node 24 的 Action 版本。
对在 CI 中执行代理连通性、DNS、TLS、网页采集或区域验证的团队来说，这不只是版本标签变化。JavaScript Action 可能在业务任务启动前就失败，也可能因为 Action 运行时、内置依赖或 runner 系统环境变化而出现新的网络表现。正确迁移的关键，是把这些问题与真正的代理故障分开。
先弄清楚变更边界
GitHub Actions 的 JavaScript Action 运行时，是 GitHub 用来执行 runs.using 所指定 Action 的 Node 进程。它不一定等于项目测试代码通过 setup 步骤安装的 Node 版本。
因此要注意：
- 即使仓库仍测试 Node 20 应用，第三方 JavaScript Action 也可能已经运行在 Node 24；
- shell、Docker 与 composite Action 有不同的执行边界；
- 应用测试矩阵仍可显式安装组织支持的 Node 版本；
- Action 运行时变化并不能证明代理服务、出口 IP 或目标站点发生了变化。
作业失败时，应定位在 Action 启动、凭据准备、代理连接、隧道协商、TLS、目标处理还是结果校验阶段，而不是把迁移后的所有异常都归咎于代理。
修改前先盘点所有 Action
检查可复用工作流、组织模板与仓库工作流中的每个 uses: 项，记录 Action 所有者、精确版本、类型、用途、密钥权限和网络角色。优先检查以下 Action：
- 读取代理端点或认证信息；
- 准备浏览器或数据采集环境；
- 配置证书、DNS 或网络路由；
- 上传诊断产物或缓存；
- 运行组织内部维护的 JavaScript 网络检查。
对于内部 JavaScript Action，检查 action.yml 或 action.yaml，将 runs.using 改为 node24，按项目规则重新构建提交到仓库的分发文件，并发布新的不可变版本。除非发布策略明确允许，否则不要悄悄移动已有标签。
核查自托管 runner 兼容性
GitHub 指出，Node 24 不兼容 macOS 13.4 及更早版本，也没有 ARM32 的官方支持。因此，这些环境中的自托管 runner 不属于 Node 24 JavaScript Action 的受支持路径。
建立 runner 清单，至少记录操作系统、版本、架构、runner 版本、网络位置和标签。在修改工作流前，将不受支持的机器移出相关标签组。若作业偶尔调度到一台过旧 runner 并失败，很容易被误判为区域代理不稳定。
还要确认出站策略允许 runner 访问经批准的 Action 与依赖来源。代理例外列表必须尽量小，并使用 NO_PROXY 策略测试 验证。
迁移期间保护代理凭据
运行时迁移常常伴随临时调试日志，而这正是凭据最容易泄漏到作业输出、产物或问题报告中的时候。
CI 应使用独立、最小权限的代理身份；任何诊断输出前先做脱敏；不要打印完整代理 URL；不受信任的拉取请求不得接触生产密钥。在给 fork 或外部可控事件开放网络测试前，先执行 GitHub Actions 触发保护方案。
优先使用短期或易轮换的凭据。一旦怀疑密钥进入日志，应立即吊销并轮换；删掉日志行不能让已经暴露的密钥重新安全。
运行代理专项金丝雀矩阵
先建立一条低频金丝雀工作流，再逐步推广。仅测试自有或明确获得授权的目标，在对比旧的有效证据与 Node 24 Action 路径时，保持目标、载荷和代理账号不变。
至少覆盖：
| 层级 | 应记录的证据 |
|---|---|
| Action 启动 | Action 版本、runner 标签、明确启动标记 |
| DNS | 解析模式、预期主机结果、无静默直连回退 |
| 代理连接 | 网关是否到达、认证结果、有界连接时间 |
| 隧道与 TLS | CONNECT 结果、证书校验、TLS 与 ALPN 摘要 |
| 路由 | 预期市场与地址族、不暴露凭据的线路标识 |
| 响应 | 确定性正文标记、长度或摘要、必需响应头 |
| 失败处理 | 稳定错误类别、重试次数、总截止时间、取消结果 |
如果生产同时需要 IPv4 与 IPv6，应分别验证。对实际使用的 HTTP 代理、HTTPS CONNECT 与 SOCKS 模式分别测试。绝不能通过关闭证书验证让金丝雀“通过”。
区分运行时回归和代理回归
使用一组小而清晰的证据矩阵：
- 将直连作为诊断对照执行受控请求；
- 使用同一目标和载荷通过代理执行；
- 对比托管 runner 与受支持的自托管 runner；
- 对比升级后的 Action 与作业直接调用的最小客户端；
- 检查第一个失败阶段，而不只看最终状态码。
若直连与代理路径都在建立连接前失败，应调查 Action 或 runner。若直连成功但代理认证失败，应检查密钥注入与编码。若隧道已建立但 TLS 失败，应核对证书、SNI 和信任库。若只有响应标记变化，应检查客户端解析和内容处理。
curl 8.23 代理回归窗口提供了另一套区分客户端变更与代理行为的方法。
控制重试与取消
运行时错误不应触发出口轮换。启动、模块加载和平台不受支持等错误应归类为本地、不可重试。网络错误必须服从单一端到端截止时间，并按失败阶段限制重试。
还要显式验证取消行为。作业取消后必须关闭套接字、终止子进程并释放浏览器会话，否则 GitHub 显示作业结束后，隐藏流量仍可能继续。代理请求取消测试提供了完整检查清单。
分阶段上线
建议顺序：
- 更新内部 Action，在非生产 runner 组验证；
- 按稳定版本或提交固定策略锁定经审核的第三方 Action；
- 在一个区域运行代理金丝雀矩阵；
- 扩展到所需市场与地址族；
- 更新共享工作流模板；
- 监控有效结果率、耗时、重试以及每次有效结果的成本；
- 移除过期变通方案和不受支持的 runner。
不要用非官方补丁恢复已移除的 Node 20 退出开关。回滚应选择仍运行在受支持平台上的已验证工作流或 Action 版本，而不是重新引入不受支持的运行时。
迁移检查清单
- 已盘点每个 JavaScript Action 与可复用工作流。
- 内部 Action 已声明
node24并发布经审核的新版本。 - 第三方 Action 已升级到支持 Node 24 的版本。
- 应用 Node 版本与 Action 运行时分别记录。
- 自托管 runner 满足操作系统和架构要求。
- 代理密钥与不受信任事件隔离，日志已脱敏。
- 必须走代理的测试禁用了直连回退。
- 已覆盖 DNS、认证、CONNECT、TLS、IPv4、IPv6 和响应完整性。
- 启动失败不会轮换出口或消耗网络重试预算。
- 取消操作会关闭套接字和子进程。
- 上线门槛使用有效结果率，而非只看状态码。
- 已移除不受支持的 runner 与临时变通方案。
常见问题
这是否意味着工作流不能再测试 Node 20 应用？
不一定。公告针对 JavaScript Action 的执行运行时。应用测试版本仍可单独安装，但需要遵循应用与平台的支持策略。
每个工作流都要直接改成 Node 24 吗？
通常是升级 Action 版本。runs.using 位于 Action 自身的元数据中；内部自定义 Action 则需要重新构建并发布。
迁移后出现代理错误，是否说明代理坏了？
不能直接下结论。先定位失败阶段。runner 兼容性、Action 启动、密钥注入、DNS、信任库或客户端行为都可能在代理服务参与前失败。
还能继续使用环境变量退出开关吗？
GitHub 表示临时 Node 20 退出开关已不可用。应完成受支持的迁移，而不是依赖绕过方式。
哪些情况应阻止上线？
如果受控金丝雀发现凭据泄漏、静默直连、不受支持的 runner、TLS 校验变化、有效结果率明显下降或无界重试放大，应阻止上线。
合规说明
仅对自有或明确获准的系统、账号、数据和市场执行网络与代理测试。遵守访问控制、隐私义务、目标条款和速率限制。不得使用代理隐藏违规采集或绕过限制。保持证书验证开启，保护凭据，并只保留最少的诊断证据。
来源说明：GitHub，《Node 20 is no longer available in GitHub Actions》，2026 年 9 月 23 日。外部研究位置仅保存在内部运营记录中。
