WordPress 文章儲存失敗？用 Edge 找出 REST API 的 403 與錯誤回應
區塊編輯器按下「更新」後顯示儲存失敗，前台卻還能正常開啟。這時先不要重裝 WordPress：編輯器儲存文章會透過 REST API 發出請求，失敗的回應往往比畫面上的提示更能縮小範圍。
以下用 Microsoft Edge 的開發人員工具找出這一次儲存請求。開始前先把未儲存的文字複製到安全的位置；建議使用測試文章重現問題，避免反覆提交正式內容。
第一步：找到真正失敗的儲存請求
- 在 Edge 開啟出問題的編輯畫面，按 F12，切到「Network／網路」。如果看不到分頁，展開更多工具；選擇 Fetch/XHR 篩選。
- 清空清單後，對測試文章做一個小修改並按「更新」或「儲存草稿」。Network 只記錄開啟工具後的請求。
- 找到與該文章有關、方法為 POST 或 PUT 的請求，網址通常包含
/wp-json/wp/v2/posts/文章ID；不同網站也可能使用其他 REST 路由。先確認它發生在剛按儲存的時間點，不要把背景 GET 請求誤認為儲存請求。 - 點開該列的 Headers 與 Response，記下狀態碼、請求路徑，以及回應中的錯誤代碼或簡短訊息。不要轉寄完整 HAR：其中可能包含登入 Cookie、nonce、文章內容和其他敏感資料。
第二步：依回應選擇下一個檢查
401：先確認登入工作階段與帳號權限。把內容備份後重新登入，在新的編輯畫面重試；若只有某個帳號發生，與正常帳號的角色和編輯權限做對照。
403：查看 Response。若是 JSON 且錯誤碼為 rest_cookie_invalid_nonce，可能是編輯頁長時間開啟後驗證資訊過期；先保存未儲存文字、重新載入並登入後再試。若回應是防火牆的 HTML 阻擋頁，記下時間和請求路徑，交給網站或防火牆管理者檢查規則紀錄。403 只是拒絕請求的結果，不能單憑狀態碼判定一定是外掛。
404：核對 REST 路徑與網站網址是否正確，並到「工具 → 網站健康狀態」查看 REST API 診斷；也可由管理員檢查網址改寫設定。500：保存發生時間與回應，請主機管理員比對 PHP 或伺服器錯誤紀錄。這些狀態碼都只提供方向，必須和實際回應一起判斷。
若 Network 顯示 200，仍要看 Response：代理、外掛或應用程式可能回傳不是預期 JSON 的內容，或在成功狀態碼中帶有錯誤訊息。若根本沒有送出儲存請求，再查看 Console 是否有 JavaScript 錯誤，並記下出問題的外掛或檔案名稱。
第三步：驗證與安全回復
修正後回到同一篇測試文章，重做剛才的小修改，確認儲存請求成功、重新整理後內容仍存在，並用另一個有適當權限的帳號交叉測試。若懷疑外掛衝突，可先依疑難排解模式教學逐一測試，避免直接停用正式站所有外掛。測試過程若變更防火牆或快取規則，記錄原設定並在完成後確認是否需要恢復。
WordPress 後台的 REST API 通常使用登入 Cookie 與 nonce；應用程式密碼是另一種給外部程式使用的驗證方式，不能拿來直接解釋編輯器每一次 403。詳細機制見 WordPress REST API 驗證文件；操作 Network 面板可參考 Microsoft Edge 官方說明。
臉書留言
一般留言