先做這件事
Error Establishing a Database Connection：不要在沒有備份時連續試錯
資料庫連線錯誤可能是 MySQL 服務不可用、主機／連接埠、帳密、權限、連線數或資料庫損壞。不要把完整帳密貼到公開工具。
本文聚焦「先判斷全站、主機與資料庫可用性，再核對設定，不在公開頁顯示憑證。」。對應的使用情境是：網站顯示無法建立資料庫連線，希望安全判斷設定或服務問題。。排查時請保存每一步的時間、畫面與日誌差異，才能把同時發生但無關的變更排除。
排查原則：先保存錯誤與現況，再從低風險、可回復的檢查開始；一次只改一個變因。
問題症狀
- 前後台同時顯示連線錯誤
- 間歇性錯誤伴隨主機高負載
- 搬站或改密碼後立即發生
建立最小重現：從乾淨瀏覽器完成相同步驟，記錄每一次請求與回應。不能重現時，先查時間相關的排程、快取與日誌。
可能原因
- 01DB_NAME、DB_USER、DB_PASSWORD、DB_HOST 錯誤。需要用錯誤日誌、Network 或隔離測試確認，不應只因時間接近就下結論。
- 02資料庫服務停止或連線數耗盡。需要用錯誤日誌、Network 或隔離測試確認，不應只因時間接近就下結論。
- 03使用者權限或主機防火牆改變。需要用錯誤日誌、Network 或隔離測試確認，不應只因時間接近就下結論。
修改前備份
保存 wp-config.php 的加密副本與主機資料庫資訊，但報告中遮蔽密碼；若資料庫可連線，立即匯出。
不要把同一主機上的自動快照當唯一備份。至少複製一份到獨立位置，並保存修改目標的單獨副本。
由低風險到高風險的排查順序
-
1. 確認主機與資料庫服務狀態
這一步保持唯讀或可快速回復，先蒐集證據再改設定。 -
2. 從安全位置核對 wp-config.php 四項設定
這一步保持唯讀或可快速回復，先蒐集證據再改設定。 -
3. 用主機提供的安全測試確認帳號權限
每完成一步就重測同一個最小重現，確認問題是否改變。 -
4. 檢查連線數、磁碟與 MySQL 日誌
每完成一步就重測同一個最小重現，確認問題是否改變。 -
5. 修正後更換可能暴露的憑證
只把已在測試環境通過的最小變更套用到正式站，並立刻跑回歸測試。
先在 staging 重現，再把可證明有效的最小差異部署到正式站。正式站 QA 要涵蓋原問題與網站最重要流程。
如何確認修復成功
首頁、後台、REST 與查詢穩定回應，MySQL 日誌無持續拒絕或資源耗盡。
- 以原本的最小重現步驟再次測試。
- 檢查首頁、登入、REST API、表單與網站最重要的交易流程。
- 查看 PHP error log、瀏覽器 Console 與 Network 是否新增錯誤。
- 以 390px 手機寬度確認沒有版面級橫向溢位。
把症狀與證據對成一條排查路徑
| 目前看到的症狀 | 先驗證的原因 | 最小安全動作 |
|---|---|---|
| 前後台同時顯示連線錯誤 | DB_NAME、DB_USER、DB_PASSWORD、DB_HOST 錯誤 | 確認主機與資料庫服務狀態 |
| 間歇性錯誤伴隨主機高負載 | 資料庫服務停止或連線數耗盡 | 從安全位置核對 wp-config.php 四項設定 |
| 搬站或改密碼後立即發生 | 使用者權限或主機防火牆改變 | 用主機提供的安全測試確認帳號權限 |
這張表不是用來直接判定根因，而是把「看到什麼、要查什麼、哪個動作可回復」放在同一列。若第一列的證據不成立，就不要跳到高風險修改。
如何還原
還原修改前 wp-config.php 與資料庫使用者權限；若改密碼，確保站點與所有排程同步更新。
正式還原前再備份一次故障現況。這份副本可能包含事故後新增資料，也是分析與差異補回的依據。
何時應停止自行操作
無法安全存取資料庫、疑似憑證外洩或主機層服務故障時，停止反覆重試並聯絡主機商。
停止不是放棄，而是避免把可復原的錯誤變成停機、資料損失或資安事件。準備好時間線、備份、錯誤日誌與已嘗試步驟，能顯著縮短專業人員的診斷時間。
常見問題
可以直接在正式站測試嗎？
不建議。先備份並在測試環境重現，正式站只套用已驗證的最小變更。
需要關閉所有外掛嗎？
不應在沒有計畫時一次關閉。先保存清單，再用隔離或健康檢查方式逐步排除。
修好後要做什麼？
清除必要快取、重測主要流程、保存變更紀錄並確認監控沒有新錯誤。
官方文件與查核來源
以下文件用於核對 WordPress、WooCommerce、PHP 或資料庫行為。第三方外掛與主機設定仍需查閱該產品當前版本的正式文件。