GitHub 新增 3 段 webhook IP：静态白名单没补可能会被拒

如果你用 GitHub webhook 触发 CI、部署流水线，或者接给自己的 agent 做 issue 事件监听，防火墙白名单一旦少放一个 IP 段，失败往往不是立刻报错，而是隔一段时间才发现任务根本没跑。10 月 29 日 GitHub 在 Changelog 里更新了一条：为 github.com 的 webhook 投递新增 IP 段，Meta API 的 hooks 字段同时带上这三段。这对维护静态 allowlist 的人来说是一次手动更新；对已经定时拉取 Meta API 做同步的人来说，基本无感。

三个新 CIDR：这次到底多了什么

根据 GitHub Changelog 原文，新加入的 IP range 是三个 /28 段：

9.234.98.160/28
9.234.98.176/28
9.234.106.48/28

一个 /28 段只有 16 个地址，三段加起来 48 个地址。比起“一段 /24”那种大规模放行，这个变化量级很小，更像是 GitHub webhook 投递池的正常扩容，不是安全策略调整。官方明确写：这些范围适用于 github.com 上所有 plan 的 webhook 投递，包括 GitHub Enterprise Cloud（来源）。

有一点要划清边界：官方原文写的是 these ranges apply to webhook deliveries on github.com，并明确 including GitHub Enterprise Cloud。至于 GitHub Enterprise Server（GHES）——自建实例的 webhook 出口取决于你自己的网络，官方这句公告没有覆盖它（这一点是我的推断，不是原文结论），所以不能把这两段 CIDR 直接套到 GHES 的防火墙规则上。这类变更容易被基础设施团队忽略 —— 官方公告只有一分钟阅读量，不主动订阅 changelog 的话基本会错过。

Meta API 里的 hooks：一个命令查当前完整列表

这次变更的关键不只是“新增三段”本身，而是它们已经进了 Meta API 的 hooks 字段。对自动化比较成熟的团队来说，正确姿态不是记住这三个数字，而是把查询接口接到自己的安全组更新流程里。最简单的查法：

curl -s https://api.github.com/meta | jq -r '.hooks[]'

返回的就是当前 github.com webhook 投递可能使用的全部 IP 段。如果你的 jq 输出里能看到上面三个 CIDR，说明你的数据源已经更新。GitHub 在 Meta API 文档 里说明，这个端点返回 GitHub 服务使用的 IP ranges，hooks 是其中一类。官方 Changelog 这次也写明：Meta API 现在在 hooks 字段里包含了这些新增 ranges（来源）。

如果你的自动化脚本只取了 git、packages、actions 这些字段，而没有把 hooks 写进防火墙规则，那么以前可能一直没事，这次就会漏。实践中常见的一个坑是：定时同步任务跑了，但它只更新了部分 IP 列表，没把 webhook 来源 IP 纳管。检查方式就是先看上面这条命令是否被你的脚本调用。

静态白名单 vs 自动同步：两种运维姿势

维护 webhook 来源 IP 白名单，团队大致分两派（这是我的经验判断，不是官方说法）：一派把 CIDR 写死在安全组、VPN 或 WAF 规则里，有变更时手工加；另一派用脚本周期拉取 Meta API，和现有规则做 diff，检测到新段就自动补。官方在公告里直接说：如果你已经用 Meta API 保持 allowlist 更新，这次新增不需要任何改动（来源）。直白一点：自动同步的人这次不用管。

手工维护的团队则需要把这三段加到现有列表旁边。官方用的词是 “add these CIDR prefixes alongside your existing webhook IP ranges”（来源）。这句话容易漏：不是替换旧段，也不是把旧段全删了只留三个新段。GitHub 的 webhook 投递池一直是多段并行，旧段还会继续用。正确的是增量添加。

为什么“白名单没补”会断

GitHub webhook 投递的出口 IP 并不固定在某一段，而是在整个 hooks 范围内轮换（这一句是我的推断——公告本身只说”新增了这些段”，没有描述轮换机制；但既然同一个用途的地址被拆成多个 CIDR，轮换是合理的工程猜测）。如果你只授权了旧段，一旦某次投递从新段出站，请求就会卡在你的网络边界，GitHub 端看到的是连接超时或拒绝。更麻烦的是，这不是账号权限失败，GitHub 不会像 token 失效那样在 UI 里给一个明确错误。常见表现是：仓库设置里 webhook 配置正常，但 delivery 记录一直 pending 或失败，应用端没收到任何事件。

这对 AI 编程场景尤其难受：很多团队用 webhook 触发 Copilot automations、CI 里的 agent、issue reaction bot 或 PR review pipeline。这些任务跑在后台，没有人在失败瞬间盯着，等发现时可能已经积压了多个任务。所以新增 IP 段的真正风险不是“会断”，而是“断得没有存在感”。

排查时可以先看 GitHub 仓库的 webhook delivery 日志，确认接收端返回码；如果返回的是 connection failed 或 timeout，就要怀疑网络层拦截。然后把你防火墙上的 allowlist 和 curl -s https://api.github.com/meta | jq -r '.hooks[]' 的结果做 diff。手动维护的列表如果漏了这三段，补上即可。

如果只是想快速检查这三个新增段是否已经存在，可以本地做一次判断：

hooks=$(curl -s https://api.github.com/meta | jq -r '.hooks[]')
for cidr in 9.234.98.160/28 9.234.98.176/28 9.234.106.48/28; do
  grep -qF "$cidr" <<<"$hooks" || echo "missing $cidr"
done

这段脚本只负责告诉你本地记录是否缺项，不会直接修改防火墙规则。真实更新安全组时，不同云平台的命令和权限差异很大，需要把 hooks 列表接到自己的安全组自动化里。

三个 CIDR 具体是哪三段

官方给的地址块一共三条，都是 /28（每个 16 个地址），完整三条见上面的清单，这里只讲两个容易踩的点。

第一，前两条相邻，可以精确合并成一条。 .160 和 .176 看起来像一段连续的地址，但 /28 的边界是每 16 个地址一卡：按掩码算，.160 那块覆盖 .160~.175，.176 那块覆盖 .176~.191（这个范围是按 /28 掩码算出来的，公告只给了 CIDR 本身）。两块边界对齐且相邻，所以精确聚合的结果是 9.234.98.160/27 —— 正好 32 个地址，一个不多一个不少。

这条值得单独说，因为很多人会本能地觉得”两块挨着就不能合并”。能合并，但要精确聚合，不能拍脑袋加宽。

第二，第三条在另一个 /24 里。 前两条是 9.234.98.x（同一个 9.234.98.0/24），第三条是 9.234.106.x（9.234.106.0/24）。两者都在 9.234.0.0/16 内，但分属不同的 /24。

这一点有实际的坑：很多云控制台在添加规则时会推荐”相近规则”，而”相近”常常给一个更宽的块。如果你为了省事把前两条近似成 9.234.98.0/24，第三条就会整个漏掉 —— 它不在那个 /24 里。

那三条能不能合成一条？能，但要清楚代价：能同时覆盖三条的最紧父块是 9.234.96.0/20，而三条加起来只有 48 个地址 —— 合并成 /20 等于把 4096 个地址放行，其中 4048 个跟官方这次公告无关。该怎么做：官方给三条是有原因的，直接逐条加最稳妥，也最不容易出错。如果你嫌规则条数多，前两条可以用精确聚合后的 9.234.98.160/27 代替两条 /28（覆盖范围完全等价），但第三条不要跟它们合并 —— 一合并就等于放行 4096 个地址。

还有两个容易被忽略的限定条件：这些地址针对 github.com 上的 webhook 投递，GitHub Enterprise Cloud（GHEC）的所有套餐同样适用（原文写的是 across all plans, including GitHub Enterprise Cloud）。注意 Cloud 版和自建版是两回事 —— 自建实例不在这条公告的覆盖范围内（这一点是我的推断，原文只写了 github.com 与 Enterprise Cloud）。如果你同时跑 github.com 和 GHEC 两套环境，白名单要分别确认，很多团队只改了其中一个。

如果不维护 IP 白名单，这事和你无关

如果你的 webhook 接收端点直接暴露在公网、只靠 secret 签名校验，没有 IP 层准入，那这次变更不需要你做任何事。GitHub 官方在 webhook best practices 里更关注的是：用 X-Hub-Signature-256 做签名校验、设置 secret、快速返回 2xx 避免投递重试。对这类部署，出口 IP 变化不影响接收逻辑（这一点属于我的推断，官方公告只说明了 CIDR 变更本身）。

真正需要动作的是安全策略比较严格的团队：出于合规要求，入站 webhook 必须来自固定 IP 段，不然一条事件都进不了内网。这类团队应该把“GitHub webhook 来源 IP 是否变化”作为基础设施巡检项，而不是等到投递失败再查。IP 白名单和签名校验解决的其实是两个不同问题：白名单限制来源，签名校验保证内容未被篡改。企业环境里两者并存并不少见，所以这类变更虽然小，仍然值得写进巡检清单。

参考来源

• GitHub Changelog：Webhook IP ranges added to the Meta API — https://github.blog/changelog/2026-10-29-webhook-ip-ranges-added-to-the-meta-api/
• GitHub Docs：Meta API（Get GitHub meta information）— https://docs.github.com/rest/meta/meta#get-github-meta-information
• GitHub Docs：Best practices for using webhooks — https://docs.github.com/webhooks/using-webhooks/best-practices-for-using-webhooks
• GitHub Changelog 列表 — https://github.blog/changelog/