症狀：本地程式可以產生 JWT，但 fastlane 或 CI 在遠端 Mac 回傳 App Store Connect API 401。
最快解法：不要先反覆撤銷並重建密鑰；先確認呼叫的是 App Store Connect API 還是 App Store Server API，再依序核對密鑰來源、JWT 欄位與系統時鐘、角色權限，以及遠端 Mac 的憑據注入方式。只有最小測試請求仍持續失敗，才整理請求 ID 向 Apple 回報。
這篇適合三類人：透過 fastlane 上傳 TestFlight、但 API Key 認證突然失敗的獨立開發者；把發布任務搬到遠端 Mac 後出現「本地成功、遠端 401」的維護者；以及自行產生 JWT、直接呼叫 App Store Connect API 的後端或自動化開發者。
先判斷 401 究竟來自哪一層
不要把所有「上傳失敗」都當成 JWT 錯誤。你應先記下請求網址、HTTP 狀態、Apple 回傳的錯誤碼、request ID、觸發工具，以及失敗發生在 API 查詢、fastlane action、Transporter 上傳，還是 App Store Connect 後台處理。Apple 的官方錯誤回應說明可用來區分認證失敗與已認證但無權限的情況。
同一把金鑰產生出 JWT，只代表簽章流程有輸出，不代表該令牌適用於目前的服務。你需要先確認程式實際呼叫的是 App Store Connect API；若端點屬於 App Store Server API，便應回到該服務的金鑰入口與授權規則重新核對。不要因為兩者都使用 Apple 生態系，便假定密鑰可以互換。
App Store Connect API 為什麼會回傳 401 NOT_AUTHORIZED？
常見原因包括密鑰入口不對、JWT 的 kid 或 iss 與密鑰不匹配、令牌時間欄位無效、遠端主機時鐘偏移，或呼叫端使用的角色不允許該資源。401 是排查起點，不是足以證明「密鑰已損壞」的結論。
第一步：核對密鑰用途，而不是猜檔名
登入 Apple Developer 或 App Store Connect 的管理介面，確認這把 .p8 私鑰是在哪一個密鑰入口建立，並將介面上的 Key ID、Issuer ID、所屬團隊與角色，和自動化設定逐項比對。Apple 的App Store Connect API 密鑰說明是判斷用途的依據；檔名如 AuthKey_XXXX.p8 不能證明它屬於哪項服務。
App Store Connect API Key、In-App Purchase Key 與其他 Apple 服務密鑰，即使同樣以 .p8 檔案形式存在，也不能只靠副檔名或檔案位置互換。若你最近更換了團隊、角色或自動化帳號，請同時檢查管理介面是否已啟用 API 存取，而不是只在本機重新產生 JWT。
App Store Connect API Key 和 In-App Purchase Key 可以混用嗎？
不應混用。它們的服務入口與授權範圍不同；只有在官方文件明確指出適用於該端點時，才可使用相應密鑰。若你無法從管理頁面確認用途，先停止輪換，保存現有設定，重新建立一個用途清楚且可回退的測試配置。
第二步：逐層檢查 JWT 與系統時鐘
App Store Connect API 的 JWT 應使用 ES256，並正確填入 kid、iss、iat、exp 與 aud 等欄位；簽章所用私鑰也必須與 Apple 產生的 Key ID 對應。這些欄位的用途與令牌要求，應以 Apple 的JWT 產生文件為準，不要照抄網路上未標明版本的範例。
排查時把問題拆成三層：
- Header：確認
alg是ES256，kid沒有多餘空格，且不是另一把密鑰的 ID。 - Payload：確認
iss、aud、iat、exp的格式、時間方向與官方要求一致；不要把完整令牌寫入日誌。 - 簽章輸入：確認遠端 Mac 讀到的私鑰內容完整，換行沒有在 Base64 解碼或環境變數注入時被破壞。
接著比較本地電腦與遠端 Mac 的系統時間。休眠恢復、快照回滾、手動改時鐘或時間同步服務異常，都可能讓新產生的令牌在 Apple 看來尚未生效或已失效。用可信時間來源檢查兩邊，不要以「JWT 解碼工具能讀出內容」當作有效認證證據；解碼成功只代表格式可讀，不能代表 Apple 接受簽章與時間。
提醒：不要在 Shell 歷史紀錄、CI 輸出、Issue 或建置產物中貼出完整 JWT、私鑰、Issuer ID 組合、App ID、Bundle ID 或主機路徑。除錯時只保留欄位名稱、遮罩後的識別碼、錯誤碼與 request ID。
第三步：分清楚認證失敗與角色權限
當密鑰和 JWT 看起來正確，下一步是檢查 API Key 所屬角色是否能執行目標動作，以及是否能存取目標 App。Apple 的角色權限表可用來核對讀取、管理與發布相關權限。
建議先使用該密鑰可以執行的最小只讀請求，再測試原本的 TestFlight 上傳任務。若最小請求也回傳 401，優先回到密鑰、JWT 與環境層；若只讀請求成功，但特定資源回傳拒絕，則要檢查角色、App 存取範圍、團隊協議或帳號狀態。不要把 401、403 與上傳後的處理失敗混寫成同一種問題。
你可以將下列資料放入不含秘密內容的診斷紀錄：
| 檢查項目 | 本地終端 | SSH 工作階段 | CI／Runner 工作 |
|---|---|---|---|
| 實際端點 | 遮罩後記錄 | 遮罩後記錄 | 遮罩後記錄 |
| Key ID | 只保留部分字元 | 只保留部分字元 | 只保留部分字元 |
| JWT 欄位 | 欄位存在性與格式 | 同樣檢查 | 同樣檢查 |
| 系統時間 | 記錄檢查結果 | 記錄檢查結果 | 記錄檢查結果 |
| 回應證據 | 狀態、錯誤碼、request ID | 狀態、錯誤碼、request ID | 狀態、錯誤碼、request ID |
這張表不是用來預設哪個入口一定失敗，而是幫你找出差異真正出現的位置。
第四步：檢查 fastlane 與遠端 Mac 的憑據注入
fastlane 可以透過 API Key 設定使用 key_id、issuer_id、key_filepath 或 key_content；實際參數和格式應以fastlane 的 App Store Connect API 文件為準。你要核對的是「執行中的 fastlane 實際讀到什麼」，而不是設定檔裡看起來寫了什麼。
在互動式終端、SSH 工作階段與 CI Runner 分別執行脫敏的最小認證測試，依序檢查：
- [ ] 顯示實際工作目錄，確認相對路徑沒有指向不存在的
.p8。 - [ ] 只輸出
key_id的遮罩值，確認沒有載入舊密鑰。 - [ ] 檢查
issuer_id、key_filepath或key_content是否在該工作階段真的存在。 - [ ] 若使用環境變數，確認 SSH 與 Runner 的作用域、Secret 名稱及換行內容一致。
- [ ] 若使用 Base64，先在遠端還原到受限權限的暫存檔，再比對檔案內容雜湊；不要輸出私鑰本身。
- [ ] 確認 CI 的工作目錄、Shell、使用者帳號與本地測試不同之處。
- [ ] 將 JWT 認證私鑰、程式碼簽名憑證與上傳憑據分開管理。
JWT 在本地驗證成功，為什麼 Apple 仍然拒絕請求？
因為本地驗證工具通常只檢查格式、簽章或時間，未必會確認 Apple 端點、密鑰服務、角色與資源範圍。你必須在與實際自動化任務相同的環境中，用同一組遮罩後設定完成最小 API 請求，才能判斷是令牌問題還是執行環境問題。
fastlane 使用 API Key 上傳 TestFlight，為什麼仍然認證失敗？
常見邊界在於 fastlane 讀取了另一個檔案、CI 沒有注入某個環境變數、私鑰換行被破壞，或使用的 API Key 角色不覆蓋目標動作。先按照 fastlane 的實際輸入做脫敏紀錄，再區分「API 認證失敗」與「建置、簽名或上傳傳輸失敗」，不要直接刪除所有憑據重來。
第五步：用最小請求與真實上傳驗收
修復後不要只確認「JWT 已產生」。請按照以下順序完成驗收：
- 固定一個權限允許的最小只讀端點，記錄端點與使用的 Key ID 遮罩值。
- 在本地終端執行一次，保存狀態、錯誤碼與 request ID。
- 在 SSH 登入的遠端 Mac 執行同一測試，確保使用相同版本的程式與同一套注入規則。
- 在 CI Runner 執行同一測試，確認無人值守環境不依賴互動式 Shell 設定。
- 認證成功後，執行一次實際的 TestFlight 自動上傳任務。
- 將執行帳號、密鑰類型、入口、失敗階段與時間記入內部紀錄，但不保存完整 JWT 或私鑰。
如果新密鑰、不同網路與本地／遠端對照後，最小官方 API 請求仍持續回傳 401，便不要無限輪換密鑰。整理脫敏的 request ID、錯誤回應、端點、執行時間、密鑰入口與驗證結果，再透過 Apple 的支援渠道回報；論壇上的個別 401 案例只能協助辨識症狀，不能直接證明 Apple 存在系統性故障。
修好 App Store Connect API 401 後，遠端 Mac 是否值得長期保留？
如果你目前是在本地電腦、臨時 CI 或共用雲端環境排查，短期內可以先修正現有流程；但若發布工作需要穩定保留私鑰注入、工作目錄、日誌與 Runner 狀態，遠端 Mac 會更容易建立可重現的驗收環境。你可以先閱讀 KVMFLUX 的遠端 Mac 使用情境，再依工作頻率評估按週測試或按月保留。
自購 Mac 的缺點是前期硬體支出、閒置時仍持續佔用成本，以及你要自行處理遠端喚醒、磁碟空間、帳號隔離和長時間在線；臨時雲端 Runner 則可能遇到環境每次重建、Secret 注入位置不一致與除錯狀態難以保留。若你的需求是短期驗證、自動上傳或需要一台持續在線的發布主機，租用 KVMFLUX 的遠端 Mac 可讓你先用真實 TestFlight 任務驗收，再決定是否長期採用；可先查看遠端 Mac 方案與計費方式，而不是在 401 尚未定位前盲目購買硬體或撤銷全部密鑰。