GitHub 更新 Actions 存储网络信息，防火墙配置需要关注什么

如果组织通过防火墙、代理或 DNS 允许列表访问 GitHub Actions 的 blob storage，这次更新最需要关注的不是“要不要把 GitHub 全部放开”，而是允许列表是否覆盖了新的对象存储主机。GitHub 在 2026 年 10 月 22 日的公告中说明，Actions 的 Meta API 增加了新的 blob storage 端点；逐主机放行的组织需要补规则，否则作业摘要和日志可能出现中断。

官方地址：https://github.blog/changelog/2026-10-22-meta-api-endpoints-updated-for-actions-blob-storage/

Meta API 文档：https://docs.github.com/en/rest/meta/meta

先检查现有规则是否已经允许 productionresultssa*.blob.core.windows.net。如果是通配符，公告中的新增范围通常已经覆盖；如果是逐个主机维护，就补上 productionresultssa30 到 productionresultssa49，以及 productionresultssa100 到 productionresultssa199，再用 Meta API 把后续变化纳入维护流程。

先判断现有规则是否已经覆盖

这次公告给出了两段新的主机范围，且范围两端都包含在内：

• productionresultssa30.blob.core.windows.net 至 productionresultssa49.blob.core.windows.net
• productionresultssa100.blob.core.windows.net 至 productionresultssa199.blob.core.windows.net

检查时先把规则分成两类。第一类是类似 productionresultssa*.blob.core.windows.net 的通配符；第二类是把每个主机逐条写进防火墙、代理或 DNS 策略。GitHub 的说明是：已经允许这个通配符时，不需要因为本次新增范围再改一次；逐主机放行时，才需要新增这些主机，避免作业摘要和日志受影响。

可以先导出当前策略，再做字符串级判断。下面的命令只读取本地规则文件，不会替你修改防火墙：

# 读取规则快照，先判断是通配符还是逐主机维护
grep -E 'productionresultssa(\*|[0-9]+)\.blob\.core\.windows\.net' firewall-allowlist.txt

# 若看到通配符，记录为“已覆盖”；否则把公告的两段范围纳入变更单
grep -F 'productionresultssa*.blob.core.windows.net' firewall-allowlist.txt

如果企业产品不支持通配符，不能把星号原样填进去。此时应由策略生成器展开主机名，或把此次两段范围作为明确的变更输入，并保留生成前后的差异。

把两段新主机范围放进变更单

不要直接在生产策略里手工敲几十个名字。更稳妥的做法是先在变更单中记录来源、范围、负责人和回滚方式，再由现有的防火墙配置系统生成规则。示例 YAML 只表达配置数据，不代表任何特定厂商的导入格式：

# 这份清单描述本次公告带来的最小域名变化
change_id: actions-blob-storage-2026-10-22
source: https://github.blog/changelog/2026-10-22-meta-api-endpoints-updated-for-actions-blob-storage/
hosts:
  - productionresultssa30.blob.core.windows.net
  - productionresultssa31.blob.core.windows.net
  - productionresultssa32.blob.core.windows.net
  # 中间主机按同一规则展开到 productionresultssa49
  - productionresultssa100.blob.core.windows.net
  # 中间主机按同一规则展开到 productionresultssa199
protocol: https
rollback: 保留上一版规则，确认作业恢复后再关闭旧变更单

实际生成时要注意两点：一是范围是闭区间，不要遗漏 49 或 199；二是这项变更针对 Actions blob storage，不等于把任意 Azure Blob 域名都加入允许列表。最小范围更容易审计，也更容易回滚。

用 Meta API 维护动态输入

这次公告同时说明，GitHub 的 Meta API 会提供相关端点信息。GitHub 文档提醒，Meta API 返回的值会变化，文档里的示例值不是最新值，应该在需要时直接查询 API。对于 GitHub-hosted runner，文档还指出其地址是动态分配的，可通过 Meta API 的 actions 等键读取。

因此，自动化脚本的职责应该是“拉取、比较、生成待审变更”，而不是每次拉到结果就直接覆盖生产规则。下面的 Python 示例只生成差异报告，便于接入已有审批流水线：

import json
from urllib.request import Request, urlopen

# 只取官方 Meta API 的当前数据，不把一次响应永久写死在代码里
request = Request(
    "https://api.github.com/meta",
    headers={
        "Accept": "application/vnd.github+json",
        "X-GitHub-Api-Version": "2026-03-10",
        "User-Agent": "actions-allowlist-audit",
    },
)

with urlopen(request, timeout=20) as response:
    # 解析失败或网络异常应让流水线失败，不能用空集合覆盖旧规则
    payload = json.load(response)

actions_ranges = set(payload.get("actions", []))
if not actions_ranges:
    raise RuntimeError("Meta API 未返回 actions 地址，停止生成空规则")

print(json.dumps({"actions_ranges": sorted(actions_ranges)}, ensure_ascii=False, indent=2))

这个脚本拿到的是 IP 地址集合，而公告中的 blob storage 变化是主机名集合，两者不要混成一份规则。可把它们分成两个数据源：域名允许列表负责名称解析和 HTTPS 访问，Meta API 的 actions 集合负责需要按 IP 管理的 Runner 流量。无论哪一类，都先生成差异，再由审批或发布流程落地。

用三组指标验收规则

防火墙变更不能只看“配置提交成功”。建议把验收拆成域名、传输和作业结果三层，并记录每层的目标值。以下指标是可复用的验收模板，不是 GitHub 对外公布的线上统计：

不要只测试一个固定主机。至少从两段范围各选一个边界值和一个中间值，例如 30、35、49、100、150、199，并把查询时间、解析结果、出口策略版本和作业运行编号写入变更记录。这样即使后续出现“偶发日志空白”，也能判断是名称范围未覆盖，还是代理层超时。

别把动态清单当成完整服务清单

GitHub 的 IP 文档明确提醒，Meta API 返回的 IP 地址列表并不保证穷举所有 GitHub 服务；例如某些服务可能不在列表中。受限网络文档也提醒，域名列表不是完整清单，选择性放行可能导致 GitHub 或相关服务无法正常工作。因此，Meta API 适合做动态输入和变更提醒，不适合被当成“拿到列表就能覆盖一切”的安全承诺。

如果本次规则上线后仍有失败，按以下顺序排查：

1. 确认实际失败的主机名是否落在本次两段范围内，避免只看入口域名。
2. 确认 DNS 解析是在企业网络内完成，还是被代理改写。
3. 确认出口日志中的目标端口是 HTTPS 的 443，并检查代理是否要求额外认证。
4. 把失败的运行编号与出口日志关联，区分“规则拒绝”与“上游临时不可用”。
5. 保留旧规则和本次差异，必要时回滚变更版本，而不是临时放开整个云存储域。

最后的维护清单

• 已有 productionresultssa*.blob.core.windows.net：记录“已覆盖”，不重复扩大范围。
• 逐主机允许列表：补齐 30–49 与 100–199 两个闭区间。
• 周期任务：查询 https://api.github.com/meta，生成差异并走审批，不直接覆盖生产。
• 验收证据：保存 DNS、443 连接、Actions 日志/摘要三层结果。
• 边界意识：Meta API 和域名列表都不是全部 GitHub 服务的永久穷举清单。

这次更新的工程动作很小，但它提醒我们把“公告中的新主机”放进已有的网络变更生命周期：先判断当前覆盖，再补最小范围，最后用动态资料和可量化指标维持它。

相关问题

已有通配符时还要逐个添加 30 到 49 吗？

如果通配符确实覆盖 productionresultssa*.blob.core.windows.net，按 GitHub 公告不需要为这次新增范围再逐个添加；仍应在变更记录里注明检查结果。

Meta API 返回的 IP 能替代 blob storage 域名规则吗？

不能直接替代。公告针对的是存储主机名，Meta API 的 actions 等字段主要用于动态地址信息；应按企业策略把域名和 IP 作为不同规则源管理。

为什么允许了 GitHub 域名，日志仍可能不可用？

因为 GitHub 服务使用多个域名和基础设施，且文档明确说明公开列表并非所有服务的穷举。应从实际失败主机、DNS、代理和出口日志继续定位。