同一个 GitHub Actions 标签，现在也可能跑在 AWS 上
YAML 没改，任务却在外部服务登录时失败，线索可能在执行基础设施。GitHub 于10月28日宣布，Linux 算力从 Azure 扩展到 AWS。任务标签相同，外部看到的来源地址却可能改变。
熟悉的标签背后有了更大的机器池
范围包括标准2核、4核 Linux runner，以及相同规模、无特殊配置的兼容 larger runner。不包括 Windows 和私有网络等特殊配置。Free、Pro、Team 自动适用，Enterprise Cloud 可在 Actions > Hosted compute cloud providers 中启用 AWS。
GitHub 保留标签和工作流语法，在可用提供商之间分配合适任务。目标是减少容量不足造成的排队并增强韧性，并非保证每个任务提速，也没有承诺在两朵云重复执行。
为什么会像间歇性故障
假设部署 API 只允许 Azure 地址，同一工作流从 Azure 可以通过，换个出口就可能被拒。GitHub 也提醒关注 Microsoft Entra Conditional Access 的网络条件。这是解释用的假设，并非我们经历的事故。
更换令牌之前，可以对照失败时间、目的地、来源 IP 和实际策略。启动前等机器与启动后认证被拒是不同阶段。算力扩容不会自动修好访问规则。
把 IP 当范围，而不是普通字符串
官方起点是 GET https://api.github.com/meta 的 actions 数组。REST 文档要求查询当前值，不要复制示例。我们本地运行 Python ipaddress，以文档专用网段192.0.2.0/24说明：.10和.200在范围内，198.51.100.10不在。这些并非真实 runner 地址。
允许所有网段不适合每个系统。runner 文档不建议用数量众多的标准网段作为内部资源允许列表，而是列出静态 IP 的 larger runner 或自托管方案。来源网络也不能替代身份认证与最小权限。
标签不变，前提可能已变
先判断失败发生在启动前还是启动后，再核对当前网段和实际限制。需要固定出口，就选择符合要求的 runner。不要把 runner 标签默认当成云提供商身份。