Salesforce Workbench 錯誤：停機期間 API 工具故障排除

已於 2026 年 9 月 16 日驗證。在 Salesforce 事件期間，Workbench 錯誤很容易被誤讀。登入失敗可能是由於會話過期、環境錯誤、Workbench 路由損壞或 Salesforce API 中斷造成的。即使兩者都可能出現在開發人員試圖快速工作時，返回的請求503 Service Unavailable指向的方向也可能不同。401 Invalid Session

故障排除的目標並非強行通過某個請求，而是要確定是哪一層出現故障，在系統不穩定時保護數據，並判斷何時證據足夠充分，可以等待、切換工具或聯繫正確的支援管道。

快速診斷：該錯誤最可能表示什麼？

你所看到的	最可能的層	下一步最佳行動
工作台頁面無法載入	工作台站點、瀏覽器、DNS 或網頁路徑	開啟 Salesforce 信任狀態，並從允許的備用網路測試網站。
工作台載入成功，但登入失敗，並顯示 401 錯誤。	會話、OAuth、使用者名稱、密碼或登入流程	啟動新的授權登入並確認所選環境。
API 請求回傳 403	權限、關聯應用程式策略或 API 限制	檢查用戶、已連接的應用程式和請求限制；不要將其視為停機的證據。
多個 API 呼叫傳回 500、502 或 503 錯誤。	Salesforce平台、邊緣路由、維護或過載	將錯誤時間與您在 Trust 上的實例和產品狀態進行比較。
只有一個查詢或物件失敗	請求語法、物件存取、記錄共享或資料問題	將請求簡化為無害的、已知良好的讀取操作，並檢查回應正文。

此表僅供參考，並非診斷結果。相同的 HTTP 錯誤代碼可能由不同的端點、驗證方法和組織策略導致。

首先，了解 Workbench 的支援範圍。

Workbench 是一款基於瀏覽器的套件，可透過多種 API 與 Salesforce 組織進行交互，包括 REST、SOAP、批次處理、串流、元資料和 Apex 相關工具。然而，Workbench 網站聲明它並非 Salesforce 的官方產品，Salesforce 也不為 Workbench 本身提供支援。其「關於」頁面也警告用戶不要將該應用程式用於生產資料。

此警告會改變您在服務中斷期間的應對方式。 Salesforce 支援團隊可以調查 Salesforce 服務、實例或 API 問題，但可能無法排查所有 Workbench 介面行為。反之，僅由 Workbench 報告的問題可能屬於 Workbench 本身或瀏覽器路徑，而非 Salesforce 平台。

盡可能將故障排除訊息設定為唯讀。請勿將密碼、OAuth金鑰、會話ID、存取權杖、客戶記錄或未經編輯的請求頭貼到螢幕截圖、聊天訊息或公開問題報告中。

範例 Workbench 登入畫面，顯示了標準、進階、OAuth、環境、API 版本、使用者名稱、密碼、會話 ID 和伺服器 URL 欄位。 — 首先確定 Workbench 登入路徑和所選環境。所示介面僅為示意圖，並非實際登入介面，也不會要求您在文章圖片中輸入憑證。

步驟 1：在變更 Workbench 設定之前，請檢查 Salesforce 信任狀態

在新分頁中開啟Salesforce Trust Status。 Salesforce的說明文件會引導客戶造訪此頁面，以了解產品中斷和服務降級。 Trust 頁面可以顯示產品資訊以及特定實例的資訊。

查看兩種視圖：

從產品角度來看：尋找影響您使用的 Salesforce 服務的事件、服務降級、中斷或維護事件。
您的實例視圖：搜尋您的執行個體或我的網域，然後開啟符合的結果。

標記為「可用」的實例並不保證所有 API 操作都能正常運作。它僅表示該實例及其服務根據 Salesforce 的狀態定義為可用。「效能下降」表示存取可能有延遲或部分功能；「服務中斷」表示執行個體無法使用；「維護」表示正在進行維護，該維護事件可能會影響訪問，也可能不會。

範例 Salesforce 信任狀態頁面，其中包含一個「搜尋實例或網域」字段，內容為 mycompany，並顯示「可用實例」結果。 — 步驟 1 — 將整體信任狀態資訊與受影響組織的實例進行比較。所示畫面僅為已記錄的查找工作流程的範例指南，並非實際事件的證據。

步驟二：重試前請確認環境及組織結構。

Workbench 可以連接到不同的 Salesforce 環境。在斷定 API 故障之前，請確認失敗的請求是針對生產環境、沙箱環境或其他授權的環境。在一個環境中成功的測試並不能清除實際故障的環境中的異常。

使用受影響組織的“我的網域”或實例標識符。 Salesforce 文件指出，“我的網域”前綴可用於“信任狀態”，管理員可以在“設定”下的“公司資訊”中找到實例。記下實例、環境、API 版本、大致故障時間和端點。這份簡短的記錄可以避免一個常見的錯誤：將生產環境的錯誤與正常的沙箱狀態進行比較。

如果 Workbench 登入頁面本身顯示不支援的登入方法或循環跳轉回登入介面，請將其視為單獨的身份驗證或 Workbench 問題，直到信任狀態和直接 Salesforce 登入結果顯示正常為止。在疑似服務中斷期間，請勿重複提交憑證；過多的重試可能會導致帳戶鎖定或增加調查的干擾。

步驟三：對 API 回應進行分類，而不是猜測

Salesforce 的 REST API 文件解釋說，回應頭包含 HTTP 狀態代碼，回應體通常包含一條訊息，並在相關情況下包含與錯誤關聯的欄位或物件。請保留這兩份證據。

程式碼	Salesforce 的記錄線索	如何在停機期間解讀它
400	請求無法被理解，通常是因為 JSON 或 XML 正文無效。	通常情況下，應先修復請求，然後再將其視為故障。
401	會話 ID 或 OAuth 令牌已過期或無效。	透過已批准的流程重新進行身份驗證；僅出現 401 錯誤並不能證明平台故障。
403	請求被拒絕，通常是由於權限問題或 API 限制。	在將問題升級為可用性事件之前，請先檢查存取權限和限制。
500	Lightning平台發生錯誤。	僅在記錄回應後重試；將重複失敗與信任狀態進行比較。
502	Salesforce Edge 無法與實例成功通訊。	路由或平台方面可能存在問題，尤其是在多個請求之間。
503	伺服器不可用；可能涉及維護或過載。	檢查是否有事故或維修事件，避免破壞性重試。

範例 Workbench API 請求畫面，顯示了一個安全的 GET 請求以及 401 無效會話、502 Salesforce Edge、503 服務不可用和 500 內部伺服器錯誤的回應行。 — 步驟 3 — 在變更憑證或請求之前，記錄 HTTP 程式碼和回應意義。此範例不包含令牌、客戶資料或真實事件標識符。

步驟 4：執行安全對比測試

了解狀態和環境後，使用允許的最小唯讀測試案例。一個好的對比測試應具備三個特點：針對受影響的組織、不修改數據，並且足夠簡單，不太可能出現請求格式錯誤。

在記錄下第一次回覆後，重複一次同樣的無害請求。
如果請求傳回 401，則開始新的授權身分驗證流程，而不是重複使用舊會話。
如果傳回 400、403 或 404，請檢查端點、API 版本、物件名稱、權限和請求正文。
如果反覆傳回 500、502 或 503，請將時間和實例與信任狀態進行比較。
如果瀏覽器 UI 運作正常但 Workbench 運作失敗，請使用已核准的內部用戶端或整合診斷程式測試相同的授權 API 路徑。

請勿將寫入、刪除、批次更新、元資料部署或遷移請求用作健康檢查。在發生故障期間，寫入操作可能會導致結果不完整、工作重複，或造成恢復已完成的假象。

何時應該改變故障排除方法？

當信任狀態顯示發生事件時，請改變方法。

除非您有獨立證據表明請求格式錯誤，否則請停止重新設計查詢。保存事件編號、受影響的服務、實例、開始時間和最新更新。遵循 Salesforce 的復原訊息，並防止佇列中的工作重複重試。

當信任狀態可用但僅使用 Workbench 失敗時，請變更方法

請專注於 Workbench、瀏覽器、網頁、身份驗證或本機原則。嘗試使用隱私瀏覽視窗、支援的其他瀏覽器以及允許的網路環境。 Workbench 網站將 Workbench 的特定支援引導至其開源社群資源，而 Salesforce 幫助中心仍然是取得 Salesforce 產品和帳戶支援的途徑。

當錯誤持續為 401 或 403 時，請改變方法。

接下來進行身份和授權分析。確認使用者、關聯應用程式策略、OAuth 範圍、會話時間長度、API 存取權限、設定檔或權限集以及組織限制。重複刷新瀏覽器無法修復缺少的權限或無效的令牌。

當一個端點發生故障但簡單的讀取操作仍然有效時，請改變方法。

調查端點、物件、欄位、記錄共用、API 版本、請求正文和回應正文。僅憑局部故障不足以將 Salesforce 整體標記為故障。逐步縮小請求範圍，直到確定問題是出在語法、存取權限、資料還是依賴服務。

Workbench 的「關於」頁面範例顯示了以下資訊：Workbench 不是 Salesforce 的官方產品，不受 Salesforce 支持，不應用於生產數據，並且由開源社群提供支援。 — 第四步－尊重 Workbench 的支持和安全限制。平台問題請使用 Salesforce 官方支持，Workbench 特有的行為問題請使用開源社群資源。

你應該向客服提交哪些證據？

如果 Salesforce 問題仍然存在，請使用您的成功計畫中提供的相應管道的官方 Salesforce 支援指南。指南內容包括：

組織識別碼、實例和環境
UTC 時間戳與您的本地時區
涉及的工作台頁面或 API 操作
HTTP 代碼、錯誤代碼和已編輯的回應正文
無論是 Salesforce 使用者介面、其他使用者或其他已核准的客戶，都可能發生故障。
信任狀態事件編號或未顯示符合事件的備註

在傳送日誌前，請移除憑證、會話 ID、存取權杖、客戶名稱、記錄 ID 和敏感資料。如果問題僅出現在 Workbench 上，請使用Workbench 說明頁面上提供的支援途徑；Salesforce 不提供 Workbench 本身的產品支援。

如何驗證恢復狀況

綠色狀態指示燈令人鼓舞，但這並不意味著恢復完成。需要分層驗證恢復情況：

確認事件頁面顯示已解決或實例狀態恢復為可用。
透過已核准的 Salesforce 或 Workbench 流程登錄，不要重複使用過期的會話。
運行之前失敗的那個無害的唯讀請求。
將 HTTP 程式碼、回應時間和回應正文與記錄的失敗進行比較。
檢查整合、排隊作業和下游通知，是否有延遲或重複的工作。

你想要的結果不僅僅是「頁面開啟」。你想要的是原始授權操作成功，產生預期的回應，並且沒有任何未經審查的副作用。

自檢清單

範圍：您是否檢查了產品層級的信任頁面和受影響的實例？
環境：您是否確認了生產環境與沙盒環境的區別，以及正確的網域名稱或實例？
證據：您是否保存了確切的 HTTP 代碼、錯誤代碼、時間和已編輯的回應？
安全性：在事件發生期間，您是否避免了寫入、刪除、批次、部署和遷移請求？
決策：您是否區分了僅 Workench 出現的問題和 Salesforce API 故障？
恢復：您是否重新測試了原始操作並檢查了延遲的下游工作？

結論

對於 Salesforce Workbench 在停機期間出現的錯誤，首先應檢查信任狀態和受影響的實例，然後在變更憑證或重寫請求之前對 HTTP 回應進行分類。如果在簡單的唯讀測試中反覆出現 500、502 或 503 錯誤，並且存在匹配的信任事件，則表示問題可能出在 Salesforce 端。如果發生 401、403、400 錯誤或僅 Workbench 本身的故障，則通常需要對身份驗證、權限、請求、瀏覽器或 Workbench 本身進行故障排除。由於 Workbench 並非 Salesforce 支援的產品，因此請勿在其中使用生產數據，並明確記錄邊界，並在發現問題時使用最新的官方狀態和支援指南。