症状：工作流命中 xcode-27，却连接不上企业私有服务。
最快解法：不要把 GitHub Actions xcode-27 Runner 企业选型简化成“标签能用就迁移”；公开依赖、无需固定出口或 Runner 专属 UDID 的任务可先试托管节点，依赖私网、固定出口或设备注册条件的任务应先验收网络与签名边界，必要时保留自托管 Mac。
适合负责 GitHub Actions 和企业网络策略、需要核对私有依赖与防火墙要求的 IT 负责人。
也适合划分 PR、设备测试和发布任务的 iOS 平台工程负责人，以及评估 Mac 构建容量的技术总监。
最后更新于 2026 年 9 月 28 日；标签、网络限制与设备标识说明核实自 GitHub Actions 官方 Runner 文档及 Apple Developer 官方资料。
SECTION 01先按任务场景路由，而不是按 Runner 标签做决定
xcode-27 是工作流选择 Runner 的标签，不是企业私网访问能力的承诺。GitHub 官方 Runner 文档将 macOS arm64 的 xcode-27 标为 Public preview；较大规格列表中还单独列出 xcode-27-xlarge。两种标签不能混为一种节点，也不能仅凭名称推断其网络、镜像或设备能力。(GitHub 官方 Runner reference)
先把实际工作负载放进以下路由：
- 公开依赖验证、普通 PR 检查：源代码与依赖都能从 Runner 正常访问，且任务不依赖企业私网、固定源地址或 Runner 主机 UDID，可优先评估托管 Runner。
- 私有仓库构建：先分别核对仓库授权和构建期间所需服务的网络连通性。能检出仓库，不代表能访问内部包仓库、制品服务或私网 API。
- 设备测试与开发签名：模拟器任务和依赖设备注册、实体设备连接或指定签名配置的任务分开验收；后者不要只用一次“构建成功”作为迁移依据。
- 正式签名发布：将生产凭证和发布工作流单独设定权限边界。若任务依赖固定出口、内部发布服务或特定设备注册条件，应保留满足这些条件的自托管 Mac，或先验证替代网络路径。
SECTION 02公开依赖与普通 PR：先让实际工作流跑通
公开依赖并不自动等于适合迁移。你仍需要确认工作流选择的标签确实可用、依赖获取路径没有企业代理或许可限制，并验证所用社区 Actions 是否兼容目标 arm64 环境。GitHub 说明其官方 Actions 兼容 arm64 Runner，但社区 Actions 可能需要手动安装或并不兼容；因此，“标签可匹配”只是入口，不是完整验收。(GitHub larger runners reference)
可以先选一个不含生产密钥、也不触达内部服务的普通 PR 检查任务，保持原有节点作为回退路径。比较真实流水线中的依赖安装、测试结果、产物生成和失败日志；如果只是下载依赖或某个社区 Action 出错，先定位兼容性问题，不要误判为私网限制。
适合先试托管 Runner的情形：
- 工作流只需拉取公开源码和公共依赖；
- PR 验证不要求访问公司内部 API 或私有制品库；
- 任务不使用 Runner 主机的固定 UDID完成设备注册相关签名；
- 失败时仍能回退到已有节点，不影响发布窗口。
GitHub-hosted Runner 可访问 GitHub 自身服务，但任务也可能需要访问工作流指定的其他网络。对防火墙而言，仓库授权、出站规则和服务端白名单是不同的检查项。(GitHub 官方 Runner 网络说明)
SECTION 03私有仓库检出与内网依赖要分层验收
需要访问私有仓库时，先区分仓库授权与构建期间的网络连通性。仓库检出成功，只能说明对应的仓库访问流程可用，不能证明 Runner 已进入企业网络，也不能证明它能访问内部包仓库、制品服务和私网 API。
为每个内部依赖记录目标主机名、端口、身份认证方式和预期路由，再从实际工作流验证 DNS 解析、连接建立、认证和下载。不要只在个人电脑或办公网里 curl 成功，就推定 CI 节点也有相同路径。验收时保存服务端访问日志、Runner 侧错误信息和失败时的路由结果，便于区分 DNS、网络策略、凭证或服务端拒绝。
GitHub 的通用文档介绍了 GitHub-hosted Runner 连接私有网络资源的方式，但这不代表每种 Runner 类型都支持同一种网络接入。特别是 macOS larger runner，官方列出的限制包括目前不支持 Azure private networking 和固定 IP；不能把 Linux 或 Windows Runner 的能力套到 macOS 上。(GitHub Runner 概念与网络说明)
若内网服务不可达，你可以先调整依赖架构，例如让构建使用可从目标节点访问的制品入口；如果安全策略要求服务只能接受私网连接，则把相应任务路由到具备已验收网络路径的自托管 Mac。GitHub 对自托管 Runner 的说明也明确指出，此类节点可安装访问本地网络所需的软件，但操作系统与工具更新等管理责任由使用方承担。(GitHub 自托管 Runner 文档)
SECTION 04固定出口与私网入口：按防火墙证据验收
企业 iOS CI 私网访问能否靠固定 IP 白名单解决？不一定。固定源 IP、加入私有网络和一般出站访问是三种不同条件：白名单只能在目标服务接受该源地址且地址稳定时发挥作用；它不会自动创建到内网的路由。相反，有私网接入路径也不必然意味着出口地址符合另一套白名单策略。
GitHub 文档说明，GitHub-hosted Runner 的 IP 范围较多，不建议把这些范围用作内部资源的白名单；其 IP 列表还会定期更新。对 macOS larger runner，官方明确说明目前不提供固定 IP 和 Azure private networking 能力。因此，如果你的防火墙要求稳定源地址或私网接入，不要从其他操作系统或 Runner 规格类推，先核对目标 macOS Runner 的当前支持范围。(GitHub-hosted Runner IP 范围与限制)
交付给安全团队的验收证据至少应包括：目标服务的连接结果、服务端防火墙日志、实际观察到的源地址，以及失败时请求走向或被拒绝的位置。如果你的策略依赖稳定出口，而目标托管 macOS Runner 无法满足，就应将相关任务路由到经验证的自托管 Mac，而不是反复扩大白名单。
SECTION 05设备测试与开发签名要分开验证
模拟器测试与依赖设备注册、特定 Runner 主机标识或实体设备连接的任务，验收条件并不相同。Apple Developer 的说明指出，创建开发或 Ad Hoc provisioning profile 需要已注册设备；GitHub 则说明 macOS arm64 Runner 没有静态 UUID/UDID。两项事实合在一起意味着：若你的签名流程要求稳定的 Runner 主机 UDID，就不能把 arm64 托管 Runner 当作已经满足注册条件。(Apple Developer 注册设备说明)
注意不要把 Runner 主机 UDID 和 要测试的 iPhone 或 iPad 的设备标识 混为一谈。项目可能只运行模拟器测试，也可能还要将测试设备登记进开发者团队并生成相应配置文件；这两类流程的验收条件不同。Apple 的分发说明也区分了注册设备与 provisioning profile，并说明自动签名和手动配置在设备及配置文件管理上有不同处理方式。(Apple Developer 注册设备分发说明)
建议把设备相关任务单独执行一次端到端验收：从工作流实际运行的节点检查签名身份、配置文件、设备注册条件和测试目标，确认产物能否安装并完成预期测试。若其中任何条件依赖某台受控 Mac 或特定设备环境，就保留该节点承接这类任务；不要因托管节点能编译成功，便推断它也能完成设备测试和正式发布。
SECTION 06正式签名发布：分离不可信 PR 与生产凭证
正式发布不能为了统一节点而扩大密钥暴露范围。GitHub 的安全使用文档建议按最小权限管理工作流凭证，并提醒不可信 PR 与特定触发方式组合时存在安全风险；自托管 Runner 文档也提醒，公开仓库的分叉 PR 可能向 Runner 提交危险代码。把生产签名任务与普通 PR 放在同一权限路径，可能让节点隔离、密钥管理和审计责任都变得不清楚。(GitHub Actions 安全使用指南)
你可以按任务信任级别分流：普通 PR 只运行无生产凭证的验证；受控分支的常规构建只拿到构建必需的最小权限；生产发布使用单独审批、限定仓库和环境，并只向发布任务提供必要签名材料。签名材料是否能安全地注入某类托管节点，也应以实际配置和团队策略验收为准，不能因某个 Runner 标签存在就默认凭证流程适用。Apple 对开发 provisioning profile 的说明可用于核对开发签名要求，但生产发布的权限设计仍须与你的工作流触发条件和密钥管理方案一并审查。(Apple Developer 创建开发 provisioning profile)
发布前可勾选的路由验收清单
- [ ] 记录实际使用的 Runner 标签，并确认它对应的 macOS 类型与架构；不把
xcode-27和xcode-27-xlarge当作同一规格。 - [ ] 从工作流节点测试私有仓库检出、内部依赖下载和私网 API 访问，分别保存授权结果与连通性证据。
- [ ] 向网络团队核对是否要求静态出口、固定源 IP 或私网接入，并用目标服务日志确认实际路径。
- [ ] 将模拟器测试与依赖设备注册或 Runner 主机 UDID 的签名任务拆开验收。
- [ ] 核查社区 Actions、工具安装和产物上传流程在目标 arm64 节点上是否实际可用。
- [ ] 为普通 PR、常规构建和正式发布分别设置 Runner 路由与凭证范围，禁止让不可信 PR 接触生产签名材料。
- [ ] 写明失败回退节点、告警责任人与恢复条件；回退流程应实际执行验证，而非只在文档中预留。
按场景混合使用托管与自托管节点，通常比强行全量迁移更容易控制风险。是否保留自托管 Mac，应由私网访问、设备条件和生产凭证要求决定，而不是由团队对某个标签的偏好决定。
如果现有方案是让每位开发者各自维护 Mac，或让一台办公网内主机同时承担 PR、设备测试和生产签名，常见代价是设备闲置与采购扩容不灵活、网络与系统维护责任集中、任务隔离和故障回退难以审计。对于需要临时增加构建或验证环境的团队，可以把远程 Mac 租赁纳入候选，但应先确认交付方式、网络路径、权限隔离和签名流程是否符合你的要求；你可以先查看 MACNOX 的远程 Mac 服务说明，再按实际节点需求核对当前套餐信息。若你的任务必须进入指定私网、连接实体设备或满足固定签名条件，未完成验收前，不要仅凭 xcode-27 标签承诺迁移。