你看到的症状：防火墙规则看似未变，但 Xcode Cloud 无法连接企业 Git 仓库，或工作流在拉取代码时失败。
判断：适合负责企业网络、安全或代码托管策略的团队。最快做法：以 Apple 当前公布的 Xcode Cloud 出口 IP 范围为准，同步核对防火墙与仓库 allowlist，再用真实工作流验证；不要沿用旧规则，也不要依赖未经核实的第三方 IP 清单。
谁该看：企业 IT 网络负责人：梳理 Git 服务入口、网关和访问控制规则。
安全工程师：审查来源范围、变更影响、审批依据与回滚记录。
代码托管管理员：确认仓库 allowlist 和 Xcode Cloud 的仓库授权均有效。
最后更新于 2026 年 10 月 26 日；地址依据已复核 Apple Developer 的Xcode Cloud 发布说明与项目设置文档。Apple 记录出口范围在 2026 年 2 月 10 日发生变更；这不代表之后永远不会再变，执行时仍应打开官方页面核对现行内容。
Xcode Cloud 出口 IP 防火墙更新的依据
先把“官方公布的来源地址”与“你们自己配置的网络策略”分开处理。Apple 的项目设置文档列出 Xcode Cloud 用于访问 Git 仓库的范围；发布说明记录了变更。官方资料是地址依据，但它无法证明你公司的防火墙、云安全组或仓库端 allowlist 已经更新并生效。
截至本次核对，Apple 文档列出的范围为 2 个 IPv4 CIDR 和 7 个 IPv6 CIDR。下面的地址是当前文档所列内容，不能视为永久固定值；每次提交规则变更前，都应重新打开官方页面核实。
IPv4
57.103.0.0/22
57.103.64.0/18
IPv6
2a01:b747:3000:200::/56
2a01:b747:3001:200::/56
2a01:b747:3002:200::/56
2a01:b747:3003:200::/56
2a01:b747:3005:200::/56
2a01:b747:3006:200::/56
2a01:b747:3004:200::/56
这些范围适用于 Xcode Cloud 访问代码托管服务的网络核验，不应被误用为“所有 Xcode Cloud 通信都走这些地址”的证明。Apple 说明其连接代码托管服务使用 HTTPS；项目设置资料要求在相应 Git 服务器入口核对入站 HTTPS allowlist。协议、端口与服务入口仍须结合你实际的托管架构确认，不能把应用出站访问、Webhook 或开发者登录流量一并归入此规则。参见 Apple 的源代码管理连接说明和Xcode Cloud 安全说明。
网络负责人：先画清入口与规则对象
容易漏掉的不是 IP 本身，而是同一条访问路径上存在多个策略层。公网负载均衡器可能先做来源限制，云防火墙或安全组再做一次过滤，主机防火墙与 Git 服务本身也可能各自维护 allowlist。只改其中一层，结果可能是控制台显示规则已更新，但流量仍被另一层拒绝。
| 规则位置 | 你需要确认的事项 | 变更留档 |
|---|---|---|
| 云防火墙、安全组或边界网关 | 目标是否为实际 Git 服务入口；是否仅允许必要来源与 HTTPS；IPv4、IPv6 是否分别纳入核验 | 变更前后策略、命中日志、审批单 |
| 负载均衡器或反向代理 | 流量是否经过该入口；来源地址是否被代理链改写；是否另有访问控制策略 | 入口配置、相关日志、回滚版本 |
| 主机防火墙与仓库服务 | 服务端是否另设来源 IP 限制；规则是否作用于仓库 HTTPS，而非无关服务 | 服务端规则、授权检查结果 |
不要把表中各层机械地全部改一遍；先通过架构图、访问日志或管理员确认，找出真正承载仓库访问的入口。把规则对象写具体，例如云侧安全组名称、负载均衡器策略或主机防火墙配置位置，避免只在工单里写“更新 IP”。
⚠️ 允许范围放宽到任意来源，可能暂时掩盖规则遗漏，却会扩大暴露面，也会让后续审计无法说明为什么开放。应以最小必要来源、目标和协议提交变更；实际控制效果必须由你的配置与日志验证。
代码托管管理员：把网络许可与仓库授权分开
企业防火墙 allowlist解决的是“网络请求能否到达入口”，仓库授权解决的是“Xcode Cloud 是否获准访问该仓库”。前者成功，不等于身份验证、组织审批或仓库权限已经具备。Apple 的接入文档也分别要求确认网络可达性，以及执行授权所需的代码托管平台角色或权限；具体要求取决于你使用的平台和组织设置。
自托管 Git 服务应先确认对外访问的仓库域名、入口地址和 HTTPS 终止位置，再检查来源限制实际应用在哪一层。如果平台有组织级和仓库级策略，分别确认策略所有者、继承关系与实际生效范围。不要把用于管理、监控或登录的 IP 规则误当作仓库克隆路径的完整规则。
| 核验对象 | 网络层核对 | 身份与仓库层核对 |
|---|---|---|
| 自托管 Git | 入口是否可达；网关、反向代理、主机规则是否覆盖正确流量 | Xcode Cloud 连接的实例是否正确；目标仓库是否已授权 |
| 企业代码托管平台 | 组织或实例 allowlist 是否接受 Apple 当前范围 | 仓库安装范围、组织审批和访问角色是否满足要求 |
| 多实例或依赖仓库 | 每个实际访问的 Git 服务入口分别核验 | 主代码库与私有依赖库可能需要分别连接和授权 |
尤其要盘点构建依赖：应用代码能拉取，不代表工作流所需的私有包、子模块或脚本访问的其他仓库也能访问。Apple 的依赖项接入指南指出，构建所需的私有依赖可能来自不同的代码托管实例；因此应按实际访问清单逐个核对，而不是只测试主仓库。
常见决策问答
Xcode Cloud 的 IP 范围该去哪里查？
查看 Apple Developer 的项目设置页和发布说明，并以页面当前内容为准。将核验日期、页面地址与变更单一并留存；搜索引擎缓存或团队过去复制的清单都不能代替当下的官方记录。
出口范围变化后，哪些网络规则值得复核？
从 Git 服务入口向外逐层检查边界网关、云侧规则、负载均衡器、主机防火墙及服务端来源限制。只修改实际命中的访问路径，逐项确认 IPv4 与 IPv6 策略，并记录旧规则，以便出现问题时判断是漏改还是误改。
自托管 Git 如何开放 Xcode Cloud 访问？
按 Apple 官方现行范围配置 Git 服务入口的来源策略，并确认该入口提供所需的 HTTPS 仓库访问。随后另行核验 Xcode Cloud 的仓库连接、授权账号和仓库范围；不要用扩大网络来源来替代仓库权限配置。
如何确认 allowlist 更新后工作流能拉取代码？
观察规则命中与拒绝日志，再执行真实 Xcode Cloud 工作流，确认它连接的是预期仓库并完成代码拉取。若失败，继续区分网络规则传播、DNS 或入口配置、身份授权及工作流配置；保留失败阶段和运行记录，避免仅凭一次失败就反复改 IP 规则。
安全负责人：收紧变更边界并保留证据
IP 清单不是完整的安全审批材料。变更说明应写明官方依据、受影响的仓库入口、来源地址族、协议范围、规则所有者、审批人和回退方式。安全审查重点是这次变更是否只扩大了必要访问，而不是“规则已经加上”这一句话。
建议先对照你现行基线，再做影响分析：哪些策略会被修改、哪些已有例外会继续生效、IPv6 是否有独立入口、规则是否可能被组织级策略覆盖。NIST 对配置变更控制的要求强调审查变更影响、记录决定并实施批准后的变更，可将其作为企业变更单设计的参考，而不是替代你自身的安全制度。NIST 安全控制文档
若使用托管代码平台，还要确认 allowlist 的管理层级与继承规则。以企业 IP allowlist 文档为例，平台策略可能影响组织级资源，也可能允许不同管理角色维护不同层级的条目；因此提交前应确认你改的是实际控制仓库访问的策略，而非同名但作用范围不同的策略。企业 IP allowlist 管理说明
CI 平台工程师：用实际工作流验收
网络探测只能回答部分问题。打开 Git 服务网页或收到网关响应，最多说明某个入口对某个请求有回应；它不能单独证明工作流具备仓库授权，也不能证明构建脚本需要的依赖服务可访问。应选择能代表真实构建的工作流，确认它连接正确仓库，并观察从仓库读取到构建结束的完整记录。Apple 对工作流配置与构建动作的说明也将连接仓库、克隆代码、解析依赖和执行构建视为相关但不同的环节，验收记录应覆盖实际失败阶段。工作流配置说明与工作流动作说明
在你有权访问的网络环境中，可先做入口和仓库层的基础核验。下面的地址仅是占位符，替换为你自己的仓库主机和仓库路径；不要把示例主机名当成实际地址：
curl -I https://git.example.internal/
git ls-remote https://git.example.internal/team/app.git HEAD
curl 的响应可帮助确认 HTTPS 入口是否有回应，但不等于仓库授权通过；git ls-remote 则能进一步验证该凭据是否可读取指定仓库的引用。若企业限制本机直接访问，或测试凭据与 Xcode Cloud 使用的授权不同，这些命令只能用于排除部分问题，最终验收仍应由 Xcode Cloud 工作流完成。
变更执行与验收顺序
- 先冻结依据。 由网络负责人打开 Apple 官方发布说明和项目设置文档，核对现行 IP 范围、地址族和适用场景，把页面链接与核验时间附在变更申请中。
- 再确认访问路径。 由网络与代码托管管理员共同确认 Xcode Cloud 访问的是哪个 Git 实例、哪个域名及哪些入口策略；若依赖代码在其他实例，另列检查对象。
- 审查最小规则。 记录需要调整的来源范围、目标入口和 HTTPS 访问规则；保留变更前配置。不要为了快速恢复访问而添加任意来源或开放无关服务。
- 分别更新两类策略。 网络负责人更新实际承载连接的防火墙、网关或服务入口规则；代码托管管理员独立核验仓库 allowlist、组织策略与 Xcode Cloud 仓库授权。
- 执行代表性工作流。 由 CI 平台工程师触发目标工作流，检查仓库连接、代码拉取、依赖解析和构建结果，并留存运行记录及相关拒绝日志。
- 关闭变更单。 安全负责人审查官方地址依据、审批记录、实施差异、验收证据和回滚责任人；指定后续谁监控 Apple 文档变更，何时重新评估规则。
按验证结果选择下一步
- 若官方来源、入口对象和仓库授权都已确认，且工作流成功拉取代码： 保留新基线及验收记录，关闭本次变更，并把后续复核责任写入运维流程。
- 若网关日志显示来源被拒绝： 对照 Apple 当前地址重新检查实际命中的规则层、地址族和规则传播状态；不要先放宽到任意来源。
- 若网络入口已响应，但仓库仍拒绝访问： 转交代码托管管理员核验账号、仓库范围、组织审批和授权关系；不要把身份问题归咎于出口 IP。
- 若主仓库可读而构建仍失败： 检查工作流引用的其他代码托管实例、私有依赖和脚本配置，并按失败阶段分别定位；不要仅凭构建失败判定官方范围不完整。
这套闭环的价值在于让每个岗位都能证明自己负责的环节，而不是把“放行了 IP”当成验收结论。你应留存的证据至少包括官方来源、变更前后规则、审批与回滚信息，以及能证明 Xcode Cloud 实际访问仓库的工作流记录；企业是否已生效，最终只能由实际配置、日志和测试确认。
如果你的当前方案是自购 Mac mini 作为团队构建机，前期硬件采购、持续维护和容量闲置都需要纳入运营决策；而 Xcode Cloud 出口 IP 规则管理本身并不会因换成 Mac 而消失，两者也不是同一种服务。只有在你还要为 macOS 专属任务评估执行环境、需要临时或测试用 Mac 时，才值得把远程 Mac 租赁与自购方案并列比较；可先查看 Mac 方案比较，若要核实 OakVM 已公开的接入信息，再通过联系页面询问，不应预设未公开的网络能力或安全承诺。
常见问题
Xcode Cloud 使用的出口 IP 范围应从哪里核实？
以 Apple Developer 的 Xcode Cloud 项目设置文档和发布说明为准，核对页面当前列出的 IPv4、IPv6 CIDR 范围及适用场景。将页面核验日期、文档地址和规则版本记录到变更单；不要把搜索结果摘要、旧工单附件或第三方汇总表当作权威地址源。
出口范围有变化时，企业网络团队要检查哪些规则？
先沿访问路径检查 Git 服务前的云防火墙、安全组、负载均衡器和主机防火墙，再检查服务自身或代码托管平台的来源 IP 限制。只调整实际承载仓库 HTTPS 访问的规则，确认 IPv4 与 IPv6 策略没有遗漏，并保留修改前配置、审批记录和回滚责任人。
自托管 Git 服务要怎样允许 Xcode Cloud 拉取代码？
确认仓库域名可从公网或已配置的接入路径到达，并依据 Apple 当前公布的来源网段，在服务入口允许必要的 HTTPS 访问。随后单独核实 Xcode Cloud 已获仓库授权及所需角色权限；网络规则允许连接，不代表身份认证、组织审批或仓库授权已经通过。
修改 allowlist 后怎样判断工作流恢复正常？
先从网关或防火墙日志确认请求命中预期规则，再启动能代表团队实际构建场景的 Xcode Cloud 工作流，检查仓库连接、代码拉取及构建结果。若仍失败，分别检查规则传播、仓库身份授权、目标仓库实例和工作流配置，并保存运行记录；单次失败不能单独证明 IP 清单仍有误。
为关键构建任务配置独享云端 Mac
OakVM 提供独享 Apple Silicon 物理节点，可将需要 macOS 环境的构建任务接入现有流水线。