GitHub Actions 停用 Node 20：代理 CI 遷移至 Node 24 的實作方案
GitHub 於 2026 年 9 月 23 日宣布，GitHub Actions runner 已不再提供 Node 20。JavaScript Action 現在使用 Node 24 執行，臨時的 ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION 退出開關亦已移除。Action 維護者需要把 runs.using 更新為 node24 並發布新版本，工作流程使用者則應升級至支援 Node 24 的 Action 版本。
對於在 CI 中執行代理連線、DNS、TLS、網頁收集或區域驗證的團隊而言，這不只是版本標籤變更。JavaScript Action 可能在業務工作啟動前便失敗，也可能因 Action 執行環境、內建相依套件或 runner 系統環境改變而出現新的網路行為。正確遷移的關鍵，是將這些問題與真正的代理故障分開。
先釐清變更邊界
GitHub Actions 的 JavaScript Action 執行環境，是 GitHub 用來執行 runs.using 所指定 Action 的 Node 程序。它不一定等於專案測試程式透過 setup 步驟安裝的 Node 版本。
因此必須注意：
- 即使儲存庫仍測試 Node 20 應用程式，第三方 JavaScript Action 也可能已在 Node 24 執行；
- shell、Docker 與 composite Action 有不同的執行邊界；
- 應用程式測試矩陣仍可明確安裝組織支援的 Node 版本；
- Action 執行環境改變並不能證明代理服務、出口 IP 或目標網站已經變更。
工作失敗時，應定位在 Action 啟動、憑證準備、代理連線、通道協商、TLS、目標處理或結果驗證階段，而非將遷移後的所有異常都歸咎於代理。
修改前先盤點所有 Action
檢查可重用工作流程、組織範本與儲存庫工作流程中的每個 uses: 項目，記錄 Action 擁有者、精確版本、類型、用途、密鑰權限及網路角色。優先檢查以下 Action：
- 讀取代理端點或驗證資訊；
- 準備瀏覽器或資料收集環境；
- 設定憑證、DNS 或網路路由；
- 上傳診斷成品或快取；
- 執行組織內部維護的 JavaScript 網路檢查。
對內部 JavaScript Action，檢查 action.yml 或 action.yaml，將 runs.using 改為 node24，依專案規則重新建置提交至儲存庫的分發檔案，並發布新的不可變版本。除非發布政策明確允許，否則不要暗中移動既有標籤。
核查自架 runner 相容性
GitHub 指出，Node 24 不相容於 macOS 13.4 及更早版本，也沒有 ARM32 官方支援。因此，這些環境中的自架 runner 不屬於 Node 24 JavaScript Action 的受支援路徑。
建立 runner 清單，至少記錄作業系統、版本、架構、runner 版本、網路位置及標籤。修改工作流程前，將不受支援的機器移出相關標籤群組。若工作偶爾被排程到一台過舊 runner 並失敗，很容易被誤判為區域代理不穩定。
也要確認出站政策允許 runner 存取經核准的 Action 與相依來源。代理例外清單必須盡量小，並以 NO_PROXY 政策測試驗證。
遷移期間保護代理憑證
執行環境遷移經常伴隨臨時偵錯記錄，而這正是憑證最容易外洩至工作輸出、成品或問題報告的時候。
CI 應使用獨立、最小權限的代理身分；任何診斷輸出前先遮罩；不要列印完整代理 URL；不受信任的 pull request 不得接觸正式環境密鑰。在對 fork 或外部可控事件開放網路測試前，先執行 GitHub Actions 觸發保護方案。
優先採用短期或容易輪替的憑證。若任何值可能進入記錄，應立即撤銷並輪替；刪除記錄行不能讓已外洩的密鑰恢復安全。
執行代理專項金絲雀矩陣
先建立低頻金絲雀工作流程，再逐步推廣。只測試自有或明確獲授權的目標；比較既有有效證據與 Node 24 Action 路徑時，保持目標、負載及代理帳號不變。
至少涵蓋：
| 層級 | 應記錄的證據 |
|---|---|
| Action 啟動 | Action 版本、runner 標籤、明確啟動標記 |
| DNS | 解析模式、預期主機結果、沒有靜默直連回退 |
| 代理連線 | 閘道是否到達、驗證結果、有界連線時間 |
| 通道與 TLS | CONNECT 結果、憑證驗證、TLS 與 ALPN 摘要 |
| 路由 | 預期市場及位址家族、不洩漏憑證的路線識別 |
| 回應 | 確定性本文標記、長度或摘要、必要標頭 |
| 失敗處理 | 穩定錯誤類別、重試次數、總截止時間、取消結果 |
如正式環境同時需要 IPv4 與 IPv6，應分別驗證。對實際使用的 HTTP 代理、HTTPS CONNECT 與 SOCKS 模式分開測試。絕不能透過關閉憑證驗證讓金絲雀「通過」。
區分執行環境回歸與代理回歸
使用小而清晰的證據矩陣：
- 將直連作為診斷對照，執行受控請求；
- 使用同一目標與負載透過代理執行；
- 比較託管 runner 與受支援的自架 runner；
- 比較升級後的 Action 與工作直接呼叫的最小客戶端；
- 檢查第一個失敗階段，而不只看最終狀態碼。
若直連與代理路徑都在建立連線前失敗，應調查 Action 或 runner。若直連成功但代理驗證失敗，應檢查密鑰注入與編碼。若通道已建立但 TLS 失敗，應核對憑證、SNI 及信任庫。若只有回應標記變化，應檢查客戶端解析及內容處理。
curl 8.23 代理回歸窗口提供另一套區分客戶端變更與代理行為的方法。
控制重試與取消
執行環境錯誤不應觸發出口輪替。啟動、模組載入及平台不受支援等錯誤應歸類為本機且不可重試。網路錯誤必須服從單一端到端截止時間，並依失敗階段限制重試。
同時要明確驗證取消行為。工作取消後必須關閉 socket、終止子程序並釋放瀏覽器工作階段，否則 GitHub 顯示工作完成後，隱藏流量仍可能繼續。代理請求取消測試提供完整檢查清單。
分階段上線
建議順序：
- 更新內部 Action，並在非正式環境 runner 群組驗證；
- 依穩定版本或 commit 固定政策鎖定經審核的第三方 Action；
- 在一個區域執行代理金絲雀矩陣；
- 擴展至所需市場與位址家族；
- 更新共用工作流程範本；
- 監控有效結果率、耗時、重試及每次有效結果成本；
- 移除過期變通方案及不受支援的 runner。
不要使用非官方修補恢復已移除的 Node 20 退出開關。回復應選擇仍在受支援平台執行的已驗證工作流程或 Action 版本，而非重新引入不受支援的執行環境。
遷移檢查清單
- 已盤點每個 JavaScript Action 與可重用工作流程。
- 內部 Action 已宣告
node24並發布經審核的新版本。 - 第三方 Action 已升級至支援 Node 24 的版本。
- 應用程式 Node 版本與 Action 執行環境分開記錄。
- 自架 runner 符合作業系統與架構要求。
- 代理密鑰與不受信任事件隔離，記錄已遮罩。
- 必須使用代理的測試已停用直連回退。
- 已涵蓋 DNS、驗證、CONNECT、TLS、IPv4、IPv6 與回應完整性。
- 啟動失敗不會輪替出口或消耗網路重試預算。
- 取消操作會關閉 socket 與子程序。
- 上線門檻使用有效結果率，而非只看狀態碼。
- 已移除不受支援的 runner 與臨時變通方案。
常見問題
這是否代表工作流程不能再測試 Node 20 應用程式？
不一定。公告針對 JavaScript Action 的執行環境。應用程式測試版本仍可獨立安裝，但必須遵循應用程式與平台的支援政策。
每個工作流程都要直接改成 Node 24 嗎？
通常是升級 Action 版本。runs.using 位於 Action 本身的中繼資料中；內部自訂 Action 則需要重新建置並發布。
遷移後出現代理錯誤，是否代表代理故障？
不能直接下結論。先定位失敗階段。runner 相容性、Action 啟動、密鑰注入、DNS、信任庫或客戶端行為，都可能在代理服務參與前失敗。
還能繼續使用環境變數退出開關嗎？
GitHub 表示臨時 Node 20 退出開關已不可用。應完成受支援遷移，而非依賴繞過方式。
哪些情況應阻止上線？
若受控金絲雀發現憑證外洩、靜默直連、不受支援 runner、TLS 驗證變更、有效結果率明顯下降或無界重試放大，應阻止上線。
合規說明
只對自有或明確獲准的系統、帳號、資料與市場執行網路及代理測試。遵守存取控制、隱私義務、目標條款與速率限制。不得使用代理隱藏違規收集或繞過限制。保持憑證驗證啟用，保護憑證，並只保留最低限度的診斷證據。
來源說明：GitHub，《Node 20 is no longer available in GitHub Actions》，2026 年 9 月 23 日。外部研究位置僅保存在內部營運紀錄。
