症狀：macOS larger runners 的建置工作連不到私有套件庫，或企業防火牆只放行固定來源 IP。
最快解法：GitHub Actions macOS larger runners 企業內網接入，先核對 runner 的網路限制；需要直接存取內網或靜態 IP 時，不要預設選它，先評估網路路徑已驗證的自管 Mac。依賴可公開存取，或中介方案已實測通過，才優先考慮托管 runner。
負責企業網路策略的 IT 主管：你需要確認私有倉庫、套件註冊表與內部服務如何供 CI 存取。
負責 iOS/macOS 流水線的平台工程師：你需要把適合托管與自管 Mac 的工作拆清楚。
負責 CI 安全與採購的決策者：你需要同時核對網路控制、運維責任與資源承載方式。
先盤點公開依賴，再判斷托管 runner 是否合適
若建置流程所需的程式碼、依賴及建置服務都能從 runner 存取，macOS larger runners 可列為優先評估對象；但「托管」不等於適合所有企業工作負載。GitHub 的 macOS larger runners 文件說明，這類 runner 不提供靜態 IP，也不支援 Azure private networking。
先不要只看工作流程是否成功跑完。把建置任務使用的套件來源、原始碼倉庫、測試 API、憑證服務和產物目的地逐項列出，區分「公開可連線」與「登入後才可用」；後者仍可能需要特定私網、DNS 或來源 IP 條件。
案例：如果建置只抓取公開套件，而原始碼倉庫授權可由工作流程使用的憑證完成，托管 runner 可能可行。若同一條流程還要呼叫只在內網解析的 API，單看程式碼下載成功就放行，會漏掉真正的網路依賴。
驗收時保留實際 workflow 設定、依賴清單和建置記錄。任何一項依賴只能從內部網路取得，都應轉入私有依賴情境檢查，而不是靠「目前似乎能跑」作判斷。
為私有倉庫與內部服務畫出實際路徑
macOS larger runners 能否存取企業私有套件倉庫，取決於服務入口和 runner 所在網路之間是否有可用路徑，也取決於認證方式。先按入口方向畫出「runner 到服務」的連線，不要把工作流程拿到有效 token，誤當成已具備網路可達性。
| 依賴類型 | 你要確認的條件 | 驗收證據 |
|---|---|---|
| 私有套件註冊表、制品庫 | 是否有公開入口、內網 DNS、來源位址或 VPN 要求 | workflow 的下載結果、服務端存取記錄 |
| 密鑰服務、內部 API | 連線路徑、工作流程身份、憑證範圍 | 認證結果、拒絕記錄、憑證使用範圍 |
| 原始碼倉庫、建置服務 | 授權方式是否符合組織政策，是否另有私網限制 | checkout 結果、建置記錄及網路控制記錄 |
逐一核對私有套件庫、內部 API、密鑰服務和制品庫的 DNS、入口、防火牆規則及認證機制。成功登入不能證明網路路徑正確；能連線也不能證明權限範圍合理。
GitHub 文件提供使用 OIDC 向 API 閘道認證的做法，詳見以 OIDC 連線至 API 閘道。這類身分驗證處理的是「誰可以呼叫服務」，不會自動替 runner 建立到任意內網服務的連線。你仍須依目標服務設計並實測網路入口。
防火牆要求靜態 IP 時，先停用錯誤假設
如果企業防火牆以來源 IP 白名單作為硬性條件，macOS larger runners 不是可直接假定符合的選項。GitHub 官方文件列明，macOS larger runners 不提供靜態 IP；同一份托管 runner 網路限制說明也不應被解讀為其他作業系統 runner 的網路功能可以套用到 macOS。
| 選項 | 可能適合的條件 | 主要限制與驗收點 |
|---|---|---|
| macOS larger runners | 依賴可由 runner 存取，且不要求靜態 IP 或 Azure private networking | 需核對服務入口、授權及 macOS 專屬限制 |
| 經核准的網關或網路覆蓋 | 目標服務支援該方式，且 GitHub 文件適用範圍及實測均確認 | 需核驗身份、憑證範圍、出口路徑與稽核 |
| 企業網路內的自管 Mac | 網路團隊能按主機位置和政策配置必要路徑 | 團隊承擔主機維護、憑證保護及工作流程風險 |
先問清楚防火牆要固定的是入站來源 IP、允許清單中的出口位址，還是其他身份條件。若要求確實是固定來源 IP，請網路團隊評估具備所需網路路徑的自管 Mac，或評估已獲核准、且針對目標 macOS runner 實測可行的替代方案。
不要把 GitHub 的大型 runner 權限與網路設定文件中其他 runner 類型的說明，直接當作 macOS larger runners 的能力證明。驗收資料要能對應到實際執行工作流程的 runner 類型。
有中介方案時，逐項驗證適用範圍
不能直接連線到私網，不代表任何網關或網路覆蓋方案都適用。先確認目標服務是否能透過受控 API 暴露必要功能，再確認工作流程身份如何取得、憑證能做什麼，以及請求從哪裡離開 runner。
GitHub 提供透過 WireGuard 建立網路覆蓋的方案說明，也提供Azure private networking 的適用範圍說明。後者不能作為 macOS larger runners 支援 Azure private networking 的依據；官方文件對 macOS larger runners 的限制仍須優先採信。
每一條路徑都要對照目標服務、憑證範圍、出口位置和稽核記錄。若文件沒有明確涵蓋目標 macOS runner，就先標記「待驗證」，再以測試工作流程和服務端記錄確認；不要在架構圖上把尚未測通的連線畫成既有能力。
自管 Mac 先確認網路位置與主機責任
自管 Mac 的優勢是企業可依主機位置及自身網路策略規劃連線方式；它不是註冊成 runner 後，就自動取得私有套件庫或內部 API 的權限。GitHub 的自管 runner 通訊要求說明 runner 需要與 GitHub 建立通訊；企業還須自行管理主機連線、服務存取及相應的安全控制。
先以測試工作流程驗證必需網域、服務連接埠、身份認證和失敗時的可觀測性。再確認憑證如何保存、誰可修改 runner 主機、工作流程能否執行不受信任的程式碼，以及主機故障後由誰處理。
自管 Mac 的缺點也要納入決策：你要負責作業系統與建置工具維護、主機可用性、憑證管理及更新安排。網路可達不等於主機隔離；遠端連線也不會消除不可信工作流程對主機造成的風險。若考慮遠端 Mac 資源，可先查看MACCOME 的 Mac 雲端算力服務資訊，但網路能否接入特定企業服務，仍須依實際交付路徑與企業政策核驗，不應由服務名稱推定。
混合流水線按任務拆分，逐項驗收
如果只有部分建置步驟需要內網，先評估是否能把公開依賴的編譯、測試工作，與受限服務存取、簽名或發布工作拆開。拆分的目的不是把風險藏到下一個工作，而是讓每個 runner 的網路和權限都能明確驗收。
在決定採用托管、自管或混合承載前，用真實 workflow 驗證任務路由、建置產物傳遞和簽名環節。若產物從一個工作交給另一個工作，要確認產物來源、完整性檢查及接收方權限；簽名憑證則應限制在確實需要的工作流程中。
以下清單可作為上線前的放行條件：
- [ ] 列出每個工作流程需要存取的倉庫、套件庫、制品庫、密鑰服務及內部 API。
- [ ] 標記每個依賴是公開可達、組織授權可達，還是必須經企業私網連線。
- [ ] 確認防火牆要求的是固定來源 IP、特定身份，還是其他網路條件。
- [ ] 查明 GitHub 官方文件是否明確涵蓋目標 macOS runner；未明確涵蓋的方案先列為待驗證。
- [ ] 以真實 workflow 驗證 DNS、連線、認證、服務端記錄及失敗訊息。
- [ ] 檢查產物交接、簽名權限、主機維護責任和不可信工作流程風險。
- [ ] 記錄尚未通過的驗收項；存在硬性網路缺口時，不要以正式發布工作流程繞過。
如果公開依賴工作可獨立執行，而私網工作仍需人工或企業控制的網路路徑，先以分段試跑驗證產物傳遞與簽名，不要只因其中一段成功就判定整條流水線適合托管 runner。
常見問題 FAQ
macOS larger runners 能存取企業私有套件庫嗎？
要看套件庫的入口和認證方式。先確認它是否可公開連線，或是否要求內部 DNS、VPN、固定來源 IP等條件；再以測試 workflow 核對下載結果和服務端存取記錄。若套件庫只能在企業網路內到達，先確認該 macOS runner 有實際可用的接入路徑。
GitHub Actions macOS larger runners 支援靜態 IP 白名單嗎？
GitHub 文件指出 macOS larger runners 不提供靜態 IP。若防火牆必須依固定來源 IP 放行，應停止把此 runner 當成預設選項，改由網路團隊評估自管 Mac 或其他已獲核准的路徑。替代方案需在目標 runner 與目標服務間完成實測，不能只引用其他 runner 類型的文件。
iOS CI 必須連企業內網時，應選托管還是自管 Mac？
先確認必需服務是否只能由內網存取，以及是否有經核准的中介方案。若沒有可驗證的中介路徑，自管 Mac 較適合進一步評估，但仍須確認主機所在網路、服務權限和憑證管理。若依賴都能公開存取，才把托管 runner 列為優先候選。
CI 無法直接接入內網時，可以用網關或網路覆蓋方案嗎？
可以列入設計評估，但必須核實官方文件是否適用於目標 macOS runner，並確認服務支援、工作流程身份、憑證範圍、出口路徑及稽核記錄。API 閘道可能適合有限的服務呼叫，網路覆蓋方案則需另行驗證連線範圍；兩者都不是未經測試即可通用的私網連線保證。
托管 runner 省去部分主機維護，但 macOS larger runners 的靜態 IP 與私網能力限制，可能不符合企業白名單或內部服務要求；自管 Mac 可按企業網路規劃，代價是維護、憑證與主機風險由你承擔。若你需要臨時建置或測試環境，可先向 MACCOME 核對實際網路接入方式、交付路徑與適用範圍，再決定是否租用遠端 Mac；若工作負載長期穩定且持續高負載，或必須使用實體介面，則應先比較自購與自管方案，不要假設租用一定合適。了解服務選項可從 MACCOME 繁體中文服務頁開始，並以你的真實 workflow、網路記錄與權限政策完成驗收。