Meta API 新增 GitHub Webhook 投递 IP 段

我们正在为 github.com 上的 GitHub webhook 投递添加 IP 段。Meta API 现在把这些额外的段包含在 hooks 字段中。

如果你为传入的 webhook 投递维护静态网络白名单，请把这些 CIDR 前缀与现有的 webhook IP 段一起加入，以避免拒绝投递：

如果你已经使用 Meta API 保持白名单更新，则这些新增内容不需要做任何更改。

这些段适用于 github.com 上所有方案（包括 GitHub Enterprise Cloud）的 webhook 投递。

你可以使用 Meta API 获取当前的 webhook IP 段，并遵循 webhook 投递最佳实践。

GitHub 在 Meta API 的 hooks 字段中补充了 github.com 上 Webhook 投递所用的 IP 段。仍在使用静态网络白名单的团队需把这些 CIDR 前缀加入现有列表，否则可能拒收投递；已通过 Meta API 自动同步白名单的团队无需改动。

• GitHub 在 Meta API 的 hooks 字段中补充了 github.com 上 Webhook 投递所用的 IP 段。仍在使用静态网络白名单的团队需把这些 CIDR 前缀加入现有列表，否则可能拒收投递；已通过 Meta API 自动同步白名单的团队无需改动。
• 原贴提到：We’re adding IP ranges for GitHub webhook deliveries on github.com. The
• 来源：github.blog

这是什么信号

GitHub 把一批新的 IP 段写进了 Meta API 的 hooks 字段，用来覆盖 github.com 上 Webhook 投递的出口地址。它的含义很具体：Webhook 的源地址池发生了扩容，而官方把这份地址池当作可机读的元数据公开出来，供下游系统消费。它不是一个新产品，也不是一次功能发布，而是基础设施层的地址清单更新。原文同时明确了适用范围：github.com 上所有方案，包含 GitHub Enterprise Cloud。

为什么重要

Webhook 是 CI 触发、代码扫描、部署流水线、工单同步等链路的入口。很多团队为了安全，会在网关、WAF 或防火墙层配置静态 IP 白名单，只放行已知来源。这种做法的隐含前提是“来源地址是固定的”，而这次更新恰好打破了该前提：如果白名单不同步，新地址段发来的请求会被直接拒绝，表现为投递失败、事件丢失、流水线不触发。更麻烦的是这类故障通常不报“配置错误”，只表现为“没收到”，排查成本高。GitHub 同时给出了两条路径：静态白名单需要手工补 CIDR 前缀；已经用 Meta API 动态同步白名单的团队则无需改动。这实际上是在提示：把 IP 清单当作可以自动拉取的配置项，而不是写死在配置里的常量。

对谁有价值

最直接相关的是负责网络边界与 CI/CD 平台稳定性的平台工程、SRE、安全运维同学；其次是依赖 GitHub Webhook 做自动化的团队，比如用 Webhook 驱动构建、代码审查机器人、发布审批、安全告警聚合的系统负责人。对使用 GitHub Enterprise Cloud 的组织同样适用，因为原文明确该变更覆盖所有方案。

可以怎么行动

第一步，盘点你有哪些地方配置了 GitHub Webhook 的来源 IP 白名单，包括 API 网关、WAF、防火墙、服务网格入口，以及自建的反向代理。第二步，判断这些配置是静态写死的，还是从 Meta API 的 hooks 字段拉取的。第三步，静态配置的，从 Meta API 取回当前 IP 段，把新增的 CIDR 前缀与已有段合并后更新，注意新老段并存而不是替换。第四步，动态同步的，确认同步任务本身还在正常跑、有失败告警，并核对最近一次拉取时间。第五步，更新后在入口侧观察一段时间，确认 Webhook 投递成功率没有下滑，再清理遗留的手工条目。

风险与限制

原文只给出了“加入这些 CIDR 前缀”的动作，摘要里并未列出具体的前缀清单，实际取值必须从 Meta API 的 hooks 字段获取，不要凭猜测或第三方转载填写。静态白名单本质上是持续维护负债：地址池会继续变化，本次更新只是其中一次，若不改造成自动同步，下一次仍会遇到同样的问题。反过来，自动同步也带来新风险——同步任务失败或权限失效时，白名单会静默过期，因此需要为同步链路本身配置监控。此外，放行一段 IP 只解决了“来源可信”的一部分，不等于请求一定合法，签名校验等应用层验证不应因为白名单存在而被省略。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《Meta API 新增 GitHub Webhook 投递 IP 段》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖