Meta API 新增 Webhook IP 段

2026-10-30

我们正在为 github.com 上的 GitHub webhook 投递增加 IP 段。

Meta API 现在将这些新增段包含在 hooks 字段中。

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

如果你已经使用 Meta API 保持白名单更新，则这些新增无需做任何变更。

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

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

GitHub 在 github.com 的 webhook 投递 IP 段中新增了若干 CIDR 前缀，并通过 Meta API 的 hooks 字段对外公布；维护静态白名单的团队需要手工补入，否则可能拒收投递。

这是什么信号

GitHub 在 github.com 的 webhook 出站 IP 池中加入了新的 CIDR 前缀，并把它们写进 Meta API 的 hooks 字段。表面看只是一次基础设施扩容公告，实质是平台在提示：webhook 的来源地址集合是动态的、会随容量和网络架构调整而变动，而“固定 IP 列表”从来不是一个可长期依赖的契约。

为什么重要

大量团队的安全模型仍然建立在“只放行已知来源 IP”之上——防火墙、WAF、API 网关、私有化部署的接收端都可能有静态白名单。这类变更不会报错提醒你，它只会在某一天表现为：投递被静默拒绝、事件丢失、重试耗尽、下游流水线或数据同步莫名其妙断流。而排查时大家通常先怀疑业务代码，最后才想到网络层。GitHub 同时给出一条明确分流：静态白名单要人工补，自动化拉取 Meta API 的则无需动作——这句话本身就是在告诉你哪种做法更可持续。

对谁有价值

第一类是需要接收 GitHub webhook 的自建服务方：CI/CD 触发端、代码扫描与合规审计系统、IM 与工单机器人、私有化代码平台同步服务。第二类是平台与 SRE 团队，他们往往同时维护多条出入站白名单，是这类变更的实际承接者。第三类是安全团队——他们需要判断“静态白名单 + 定期人工核对”这套流程还剩多少剩余风险。

可以怎么行动

建议按三步走。第一，盘点：列出所有依赖 GitHub webhook 来源 IP 的白名单位置，包括云端安全组、机房防火墙、Nginx/网关层 ACL，以及应用内自研的 IP 校验逻辑——最后一处最容易被漏掉。第二，改造：把白名单从人工维护切换为定时任务拉取 Meta API 的 hooks 字段并自动下发，同时保留一份人工兜底流程，防止拉取任务本身失效时无人察觉。第三，验证：在变更窗口内做一次受控投递测试，确认新前缀可通、旧前缀无副作用，并把“webhook 投递成功率/拒绝数”做成可观测指标，而不是等业务方报障。

风险或限制

需要清醒的是：把来源 IP 当成唯一信任凭据本身就不够。IP 可能被共享或复用，正确的做法是 IP 白名单与签名校验（如 HMAC 密钥验证）叠加，IP 层只作为收敛面而非认证面。另外，自动化拉取也会带来新风险——Meta API 不可用时的降级策略、拉取到空列表或异常列表时的熔断、以及缓存过期后的默认放行还是默认拒绝，都需要事先定好。本次公告没有给出具体 CIDR 值和生效时间，任何实施动作都应以 Meta API 的实际返回为准，不要凭记忆或旧文档配置。

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

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