GitHub Runner 熔斷演練開始：先檢查代理出口再排查工作停滯

GitHub 公布的計畫顯示，GitHub Enterprise Cloud 自託管 Runner 於 2026 年 9 月 14 日進入新的熔斷演練階段，9 月 16 日和 18 日還有設定與執行聯合演練，9 月 25 日計畫全面執行最低版本要求。對於在自託管基礎設施上執行合規資料蒐集、瀏覽器測試、廣告驗證或市場研究工作的團隊，風險不只來自舊 Runner。代理、防火牆或企業憑證鏈也可能讓原本上線的 Runner 無法更新、重新註冊或保持服務連線。

GitHub 還在 9 月 3 日發布 Runner 淘汰資訊 REST API，回傳 Runner 版本、註冊停止時間與執行停止時間，讓平台團隊能在工作長期排隊前自動識別風險。

這不是代理產品變更，而是一次維運就緒事件。正確回應是盤點版本、驗證現有網路政策下的控制面路徑，並在下一個視窗前執行具代表性的灰度工作。

GitHub 公布了什麼

官方計畫提出兩個不同要求：重新設定或註冊 GitHub Enterprise Cloud 自託管 Runner 時，版本至少為 2.329.0；繼續執行工作時，則需要在每個新版本發布後 30 天內保持更新。

註冊最低版本不是永久執行最低版本。固定在舊映像中的 Runner 會隨執行門檻移動而失去資格。GitHub 亦說明，關鍵安全更新發布時，舊 Runner 的工作排程可能暫停，直到完成升級。

9 月 14、16、18 日的演練視窗為美國東部時間上午 11 點至下午 3 點。期間不受支援的 Runner 可能間歇性無法註冊或執行工作。GitHub Enterprise Cloud 預計在 9 月 25 日全面執行；本計畫不包含 GitHub Enterprise Server。

為何使用代理的 Runner 要另外檢查

自動更新只有在 Runner 能透過核准的網路路徑存取所需服務時才有效。常見斷點包括：

• 允許清單允許儲存庫流量，卻遺漏 Runner 更新流量；
• 代理憑證過期或範圍錯誤；
• Runner 映像缺少企業 TLS 檢查憑證；
• 服務帳號與互動式終端讀取不同代理環境變數；
• 代理閘道或服務端點在 Runner 網路內解析不同；
• 虛擬機器、容器或擴充模板快取舊 Runner；
• 長工作期間黏性出口意外變化；
• 重試策略把短暫拒絕放大成連線風暴。

不要藉由繞過企業代理或未經審查擴大出口權限來「修復」。目標是證明核准路徑，並記錄最小必要規則。

立即執行五步檢查

1. 盤點全部 Runner

記錄名稱、作業系統、版本、映像來源、自動更新設定、負責人、代理路由與最近一次成功工作。必須包含臨時池和自動擴充模板，因為目前上線機器正常，不代表日後新建的映像是新的。

在權限允許的儲存庫、組織或企業範圍呼叫淘汰資訊介面，同時比較註冊與執行時間。無法解析的回應應視為盤點失敗，不能假設仍受支援。

2. 使用真實服務帳號測試

診斷必須使用啟動 Runner 的相同身分、環境和服務管理器。管理員終端可能擁有不同代理變數、憑證庫和 DNS。

確認 Runner 回報預期版本；代理變數指向核准閘道且日誌不含秘密；HTTPS 通道與憑證鏈可用；內部敏感主機沒有被錯誤送入代理；更新檢查不會反覆要求驗證。代理使用者名稱、密碼、Token、Cookie 與完整請求標頭都應遮蔽。

3. 先分類失敗再重試

不要透過輪換出口 IP 處理版本政策拒絕。版本問題不是路線品質問題。

4. 更新來源映像

若 Runner 來自黃金映像、容器或啟動指令碼，應更新來源，而非只修補上線機器。建立完成後讀取實際二進位版本，不能只相信建置日誌中的套件版本。

保留回復能力，但不得回復至已不受支援的 Runner。將網路與代理設定分開版本化，方便區分 Runner 升級回歸與出口政策變更。

5. 灰度一項正式環境形態工作

選擇小規模、已授權且不會對外部目標製造負載的工作流程，涵蓋程式碼或成品存取、代理驗證、DNS、TLS、一次輕量目標請求、結果驗證與日誌遮蔽。

先在一個新 Runner 上執行，並保留舊容量。比較排隊、註冊、連線建立、首次成功率、407、TLS 失敗與清理結果，再逐步擴大新池。

可用代理出口證明指南記錄預期路徑；若出口屬於允許清單，應依代理出口允許清單切換流程保留重疊驗證。

為演練視窗增加專用監控

依 Runner 池與映像版本觀察註冊失敗、無合格 Runner 的排隊工作、啟動與完成率、代理驗證、通道和 TLS 失敗、更新檢查失敗、每個邏輯工作的重試量、出口路由或 ASN 突變、取消後的清理情況。

使用關聯 ID 連接 Runner 生命週期、工作、代理路由與最終結果，但不得暴露憑證。保留視窗前、中、後的證據，四小時平均值可能掩蓋 20 分鐘尖銳故障。

同時改善工作流程身分觀察

GitHub 9 月 3 日更新也為可重用工作流程增加定義工作流程的引用、提交、儲存庫與檔案路徑內容。在可用範圍內，這些欄位能協助確認究竟是哪一個重用工作流程定義了工作。

它們是可觀察性訊號，不是單獨的授權依據。不得把不可信事件資料直接拼入命令、代理設定或目標 URL。保持最小權限，並透過平台秘密控制保護網路憑證。可參考GitHub Actions 代理快取檢查指南驗證 CI 網路行為。

就緒檢查清單

• [ ] 所有固定與臨時 Runner 來源都已盤點。
• [ ] 已收集版本與兩個淘汰時間。
• [ ] 測試在真實 Runner 服務帳號下執行。
• [ ] 映像與日誌中沒有嵌入代理憑證。
• [ ] HTTPS 通道、DNS 與 TLS 信任通過。
• [ ] 黃金映像和啟動指令碼建立受支援版本。
• [ ] 正式環境形態灰度工作在新池通過。
• [ ] 407、TLS、DNS、逾時與版本拒絕已分開。
• [ ] 重試有上限並加入抖動。
• [ ] 演練監控依 Runner 與映像版本分組。
• [ ] 回復目標仍受支援且符合網路政策。
• [ ] 沒有混淆 Enterprise Cloud 與 Enterprise Server 範圍。

常見問題

2.329.0 會永久足夠嗎？

不會。它是新架構的註冊最低版本，執行資格會隨新版本發布而移動。

本計畫影響 GitHub Enterprise Server 嗎？

GitHub 說明這次 Enterprise Cloud 計畫不影響 Enterprise Server，但後者仍需遵守自身版本支援政策。

代理會讓合格 Runner 看起來過舊嗎？

代理不會改變本機版本，但可能阻斷更新、註冊或服務通訊。版本與網路可達性必須分層診斷。

演練期間應繞過代理嗎？

不應作為例行修復。先驗證核准路徑，確有必要端點遭阻擋時，再申請最小且經審查的規則變更。

何時應該回復？

只有新映像出現已驗證回歸、且舊映像仍受支援時才回復。不得回復至服務將拒絕的版本。

合規說明

自託管 Runner 與代理僅可用於合法、已授權的工作流程。遵守目標條款、存取政策、速率限制、隱私義務與組織網路控制。不得使用替代路線或位址輪換規避 GitHub 執行規則或目標限制。保護秘密、最小化日誌，並在改變出口政策前取得審查。

內部核對來源：GitHub Changelog《GitHub Actions: Early September 2026 updates》，2026 年 9 月 3 日；GitHub Changelog《GitHub Actions: Minimum version enforcement timeline for self-hosted runners》，2026 年 6 月 12 日。