CI Runner 为什么需要固定出口 IP
流水线里的构建机访问外部服务时，对方看到的是 Runner 的出口地址。很多服务会用「允许名单」的方式限制来源，比如企业制品仓库、内部数据库、第三方支付或邮件接口、云厂商的 API Server。此时 Runner 的出口地址如果每次都变，就会出现「有时能过、有时被拒」的现象，排查起来非常折磨人。本文把这个需求拆成三个问题：哪些场景真的需要固定出口，有哪些做法，每种做法各自有什么限制。所有关于 GitHub 的说明都对照 2026 年 10 月查阅的官方文档，功能和限制可能会变，落地前请再核对。与独享 IP、静态 IP 的基础概念有关的内容，可以先看DevOps 关于独享 IP、静态 IP 的说明，这里不重复。
先判断：你真的需要固定出口吗
「固定出口 IP」很容易被当成默认方案，但它也有成本和维护负担。先确认自己落在下面哪一类。
需要固定出口的典型场景
对方服务只接受白名单内的来源地址，并且没有其他认证方式可选；部署目标是受限访问的集群，要求构建机地址可追溯；审计要求能明确说出一条发布操作来自哪个地址。这些场景的共同点是：来源地址本身被用来作为访问控制的一部分。
可以不用固定出口的场景
如果对方支持短期凭证、密钥或者基于身份的认证（比如 OIDC），优先用这些方式，它们比 IP 白名单更贴近「谁在访问」这个问题本身。IP 白名单应该是其中一层限制，而不是唯一的防线。
三种做法的取舍
托管 Runner 的地址段，为什么不适合精确白名单
托管 Runner 的出口地址来自一个很大的轮换地址池，地址段可以通过 GitHub 的 meta 接口查询，但范围很宽、会不时变化。把这么大的地址段全部加进白名单，等于把同一平台上的很多其他用户也放进来了，不算真正的限制，维护成本也高。
大型 Runner 的静态 IP，限制在哪里
GitHub 官方文档说明，大型 Runner 可以在组织设置的 Actions、Runners 里，在网络选项下勾选为该 Runner 分配独立、静态的公网地址范围。文档同时列出了几条限制：组织需要使用 GitHub Enterprise Cloud；macOS 的大型 Runner 不支持静态 IP；每个 Runner 是一个可自动扩展的池，池内所有任务共用同一段静态地址范围；默认最多可以配置 10 个带静态 IP 地址范围的 Runner 池。注意它给的是一段地址范围，而不是单个地址，需要对方支持按范围放行。
文档还特别提醒了一个坑：当大型 Runner 的虚拟机与 Azure 存储账户在同一区域时，流量会走私有的 Azure 地址而不是公网地址范围，即使防火墙规则配对了，仍可能出现连接失败。所以官方建议不要只依赖基于允许名单的规则，除非使用静态公网地址范围或 VNet 集成。
自托管 Runner 加 NAT 网关，适合什么团队
自己管理 Runner 的话，把它放在云上的私有子网，再让子网的出站流量经过一个绑定了弹性公网 IP 的 NAT 网关，出口地址就是那一个固定的地址。这对对方来说最容易配置（只需放行一个地址），代价是你需要自己维护 Runner，包括扩缩容、更新和安全。Runner 网络抖动导致的随机失败，可以再参考GitHub Actions 构建随机失败的网络排查。
| 做法 | 出口地址形态 | 主要限制 |
|---|---|---|
| 托管 Runner 默认 | 大地址池，会变化 | 不适合精确白名单 |
| 大型 Runner 静态 IP | 独立的静态地址范围 | 需 Enterprise Cloud，不支持 macOS，注意同区域存储的内网地址问题 |
| 自托管 Runner + NAT 网关 | 单个固定地址 | 需要自己维护 Runner 和网关 |
落地后怎么验证，怎么避坑
配置完成后，不要默认「应该已经固定了」，用一个小步骤直接验证。在流水线里加一步输出出口地址：
curl -sS https://api.ipify.org
# 或者用你自己的内部服务返回来源地址，避免依赖第三方连续跑几十次，确认返回的地址始终落在预期范围内。下面是几个常见的坑：
- 只固定了部分流量。依赖安装、镜像拉取、代码托管请求走的可能是不同的路径，需要分别验证。
- 内网地址和公网地址混用。某些云服务商的同区域流量会走内网，来源地址不再是你对外公布的那个，这正是前文官方文档提醒的情况。
- 多个项目共用同一个出口。同一个地址上的请求量会叠加，对方服务的限流按地址计算时，很可能让正常构建互相挤压。
- 变更没有演练。地址一旦需要更换，要提前和对方确认同时保留新旧两个地址的过渡期，避免上线窗口突然失败。
对已经有团队共用同一出口的情况，还要留意「账号验证不断触发」的问题，参见团队共用出口 IP 导致 GitHub/GitLab 频繁要求验证。
开发机和流水线的出口，其实是同一个管理问题
很多团队只给 CI 固定了出口，开发者自己的电脑却每天走不同的地址。结果是流水线能过，人工排障时把同一个命令拿到本地跑，却被同一个服务拒绝。NasaCode 提供的独享 IP 可以让开发机这一端也有一个固定、可追溯的出口，和流水线的出口分开写进对方的允许名单，记录清楚“哪个地址对应谁”；是否适合你们的安全要求，建议先和你们的安全负责人确认。
小结
给 CI Runner 固定出口 IP 的决策顺序是：先确认对方确实只支持白名单，再在托管大型 Runner 静态 IP 和自托管 NAT 网关之间按团队能力选择，落地后用流水线里的出口检查步骤持续验证。官方文档中的限制可能随时调整，具体以你使用时的最新文档为准。
