症状：Mac CI 构建成功，但日志、摘要或产物无法读取；最快解法：先判断防火墙是逐个放行主机，还是已覆盖相应通配域名。
GitHub 于 2026 年 10 月 22 日公布两组新增 blob storage 主机范围：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 的组织，通常不必为这次新增主机另加规则，但仍要以防火墙策略和工作流实测确认。GitHub 官方公告
负责企业防火墙、代理或 DNS 过滤的管理员：判断现有规则是否覆盖新增主机。 维护自托管 Mac Runner 的平台工程师：确认网络没有阻断日志、摘要、产物或缓存传输。 负责发布与研发效能的 IT 负责人：建立端点复核、工作流验收和变更留档机制。
最后更新于 2026 年 10 月 27 日；端点范围与适用条件核对自 GitHub 官方变更公告、Meta API 文档及自托管 Runner 网络要求。
端点覆盖与适用范围
这次变更针对 GitHub.com 上的 GitHub Actions blob storage 端点，不是 Runner 标签或工作流文件变更。公告列出两组主机范围，并明确：已覆盖相应通配域名的组织无需因这次新增项另行修改；逐条列出主机的组织应检查并更新。
| 核验项 | 官方公告内容 | 你的检查动作 |
|---|---|---|
| 第一组新增主机 | 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 | 检查防火墙实际匹配行为及组织安全策略 |
| 适用边界 | 公告讨论 GitHub.com 上的 Actions blob storage | 不要据此推断 GitHub Enterprise Server 也有同一变更 |
规则精度与变更条件
判断时看规则的实际匹配范围，不要只看配置文件中有没有一个星号。不同防火墙、代理或 DNS 过滤器对通配符的匹配语义可能不同；同一条文本规则可能覆盖子域名，也可能因策略语法、CNAME 处理或代理解析方式而没有按预期生效。
- 若策略逐条列举主机，且新范围尚未覆盖，则按当前官方清单复核、审批并补齐；否则回退为先收集命中日志，不要扩大到无关域名。
- 若策略明确覆盖
productionresultssa*.blob.core.windows.net，并且目标网络的匹配测试证明规则生效，则通常保持规则不变，再做工作流验收；若规则只存在于模板、尚未部署，则不能视为已覆盖。 - 若网络设备只接受 IP 地址，则先确认地址映射和更新责任，再评估合规的策略调整；不要把主机名范围直接粘贴成 IP 规则。
- 若使用的环境是 GitHub Enterprise Server，则先查对应产品和版本的官方网络文档；不要把 GitHub.com 的这则公告外推为其变更。
数据来源与清单复核
不要把旧工单、静态配置样例或公告截图当成永久有效的端点清单。GitHub 公告说明新增端点已纳入 Meta API；你可以读取当前响应，再对照防火墙规则，而不是只复制这次公告里的主机范围。Meta API 文档提供接口说明，当前响应可从 GitHub Meta API 获取。
在有 curl 和 jq 的管理终端执行：
curl -fsSL https://api.github.com/meta |
jq -r '.domains.actions[]?'这会筛出 domains.actions 中的域名，供你检查当前清单。若组织采用更精确的主机控制，还应确认策略对应的是哪一组域名；不要仅凭命令成功返回，就认为规则已部署或 Runner 已能访问。Meta API 文档说明该接口用于获取 GitHub 元信息；具体子字段与防火墙映射仍应结合当前响应、策略类型和企业实际配置核验。
| 策略现状 | 判断 | 下一步 |
|---|---|---|
| 逐条列出 blob storage 主机 | 可能漏掉新增主机 | 按公告范围与当前 API 清单复核，补齐符合组织策略的规则 |
| 已允许匹配的通配域名 | 通常不需为新增主机单独加条目 | 核对通配符匹配范围、DNS 过滤和代理行为，再跑工作流 |
| 只按 IP 地址放行 | 不能由主机名公告直接判定覆盖 | 查设备解析与 IP 策略来源，不要未经评估扩大出站范围 |
| 规则状态不清楚 | 暂不能判断是否覆盖 | 查策略配置、变更记录和网络日志；确认前不要宣称已完成更新 |
功能映射与受影响链路
GitHub 将 *.blob.core.windows.net 列为自托管 Runner 上传或下载作业摘要、日志、工作流产物和缓存所需的域名之一，同时单独列出 results-receiver.actions.githubusercontent.com。因此，blob storage 白名单问题可能表现为日志、摘要或文件传输异常，但它不能单独解释所有 CI 故障。
| 可观察功能 | 与存储端点的关系 | 验收时核对 |
|---|---|---|
| 运行日志与工作流摘要 | 属于公告提及的受影响数据链路 | 打开运行记录，确认日志可读取、摘要可显示 |
| 构建产物 | 产物上传或下载会用到工作流产物链路 | 上传后从实际发布流程下载并检查文件 |
| 缓存 | 自托管 Runner 的缓存存储在 GitHub 云端存储 | 执行团队实际使用的缓存写入或读取步骤 |
| Runner 注册、领取作业、下载 Action | 还依赖其他 GitHub 域名 | 单独核对 Runner 通信与 Action 下载依赖 |
工作流验收与网络证据
不要用一次“Runner 在线”作为验收完成的证据：Runner 能领取作业，不代表日志、摘要、产物和缓存路径都已通过。选一条代表性 macOS 工作流，在目标网络、目标代理和实际 Runner 上执行，保留运行结果与网络侧证据。
- 固定测试环境。 记录 Runner 所在网络、适用防火墙或代理策略、DNS 解析路径及当前规则版本；确认测试用的是你准备放行的那组规则。
- 让工作流产生可观察结果。 确保本次运行有可查看的日志，并按团队实际方式生成摘要；
GITHUB_STEP_SUMMARY是 Runner 上写入作业摘要的环境变量，可用来设计摘要验收步骤。相关字段定义见 GitHub Actions 变量参考。 - 实测产物链路。 上传团队发布流程中的代表性构建文件，再从工作流运行页面或后续作业下载；不要只凭“上传步骤显示成功”就跳过读取验证。
- 实测缓存链路。 运行团队实际使用的缓存步骤，区分缓存读取、写入和缓存未命中；不要把缓存未命中直接判作存储端点被阻断。
- 对照网络证据。 在防火墙、代理或 DNS 日志中确认请求的主机、策略命中和拒绝原因；把 DNS 解析失败、代理拦截、防火墙拒绝与权限或令牌错误分开调查。
- 保存结果。 将工作流运行链接、日志片段、规则版本、审批记录和网络命中信息归入同一变更记录，便于回退或下次复核。
注意：日志或摘要不可见，并不自动证明本次 blob storage 主机变更就是原因。先看实际拒绝记录和失败步骤；如果 Runner 领取作业、代码检出或身份权限也有异常，应分别按相应网络依赖与权限路径排查。
变更治理与复核记录
把清单来源、规则所有者和验收证据放在同一变更流程里。Meta API 负责提供当前数据，公告解释这次变化的范围，企业自身的规则与网络日志则证明变更是否真正部署并生效；三者不能互相替代。
建议在维护记录中留出这些字段：清单获取时间、API 响应快照或差异、适用网络边界、规则变更编号、审批人与部署结果、Mac 工作流运行记录，以及失败时的回退方式。每当 GitHub 更新相关公告或 Runner 网络要求、组织调整代理和 DNS 策略，或新增独立 Mac CI 网络边界时，重新核对适用范围；公告没有给出统一截止日期，不要自行编造期限或把复核写成紧急强制变更。
如果你的团队正在搭建或调整 Mac CI 承载，先判断现有网络策略是否能覆盖 Runner 的真实出站需求，再决定本地自建、采购设备或采用远程主机。独立承载的 Mac 环境也要经过同样的规则核验与工作流验收；网络边界、运维责任和实际工作流不匹配时，仅换一种主机来源并不会自动解决问题。你可以先查看 MACGPU 的远程 Mac 服务入口，把网络访问方式和验收责任作为评估条件；若仍在比较自建硬件，也可参考 Mac 主机选购页面。