先做這件事
WordPress DNS SSL 重新導向：不要在沒有備份時連續試錯
DNS 決定連到哪個服務，SSL 憑證驗證網域，重新導向統一正式網址。任何一層設定不一致都可能造成迴圈、憑證錯誤或分流到舊站。
本文聚焦「依 DNS → 憑證 → 來源站 → WordPress URL → CDN → redirect 順序。」。對應的使用情境是：搬站或啟用 HTTPS 後出現憑證、迴圈或部分使用者無法開啟。。排查時請保存每一步的時間、畫面與日誌差異，才能把同時發生但無關的變更排除。
排查原則：先保存錯誤與現況，再從低風險、可回復的檢查開始；一次只改一個變因。
問題症狀
- 部分地區仍看到舊站
- 瀏覽器顯示憑證網域不符
- HTTP 與 HTTPS 或 www 互相迴圈
先用一個可重複的操作描述問題：哪個網址、哪個角色、哪個裝置，以及錯誤出現前最後成功的時間。畫面相同不代表根因相同。
可能原因
- 01A／AAAA／CNAME 指向不同來源。需要用錯誤日誌、Network 或隔離測試確認，不應只因時間接近就下結論。
- 02憑證未涵蓋網域或尚未簽發。需要用錯誤日誌、Network 或隔離測試確認，不應只因時間接近就下結論。
- 03CDN、主機與 WordPress 重複強制轉址。需要用錯誤日誌、Network 或隔離測試確認，不應只因時間接近就下結論。
修改前備份
匯出 DNS 記錄、TTL、CDN／主機 redirect 與 WordPress URL 設定；保存修改前解析結果與憑證資訊。
備份需放在站外，並至少檢查壓縮檔能開啟、資料庫能解析、版本清單完整；檔名要包含網站與時間。
由低風險到高風險的排查順序
-
1. 查權威 DNS 與實際 A／AAAA／CNAME
這一步保持唯讀或可快速回復，先蒐集證據再改設定。 -
2. 確認憑證涵蓋根網域與 www
這一步保持唯讀或可快速回復，先蒐集證據再改設定。 -
3. 直接測來源站 Host 與 HTTPS
每完成一步就重測同一個最小重現，確認問題是否改變。 -
4. 統一 WordPress Address 與 Site Address
每完成一步就重測同一個最小重現，確認問題是否改變。 -
5. 只保留一層清楚的 canonical redirect 並跨網路測試
只把已在測試環境通過的最小變更套用到正式站，並立刻跑回歸測試。
排查過程一次只處理一層；每一步都用同一個失敗案例重測，結果沒變就回復該步再前進。
如何確認修復成功
HTTP、www 與非 www 都以單次合理跳轉到唯一 HTTPS URL，憑證有效，首頁、文章、REST 與資源 200。
- 以原本的最小重現步驟再次測試。
- 檢查首頁、登入、REST API、表單與網站最重要的交易流程。
- 查看 PHP error log、瀏覽器 Console 與 Network 是否新增錯誤。
- 以 390px 手機寬度確認沒有版面級橫向溢位。
把症狀與證據對成一條排查路徑
| 目前看到的症狀 | 先驗證的原因 | 最小安全動作 |
|---|---|---|
| 部分地區仍看到舊站 | A／AAAA／CNAME 指向不同來源 | 查權威 DNS 與實際 A／AAAA／CNAME |
| 瀏覽器顯示憑證網域不符 | 憑證未涵蓋網域或尚未簽發 | 確認憑證涵蓋根網域與 www |
| HTTP 與 HTTPS 或 www 互相迴圈 | CDN、主機與 WordPress 重複強制轉址 | 直接測來源站 Host 與 HTTPS |
這張表不是用來直接判定根因，而是把「看到什麼、要查什麼、哪個動作可回復」放在同一列。若第一列的證據不成立，就不要跳到高風險修改。
如何還原
恢復原 DNS 與 redirect 設定並等待 TTL；不要在傳播期間反覆來回修改。
還原後要再次檢查 PHP 日誌、快取與資料一致性；只看到首頁恢復，仍不足以證明背景排程與表單正常。
何時應停止自行操作
無法確認權威 DNS、憑證私鑰、CDN來源或變更會中斷郵件時，停止並由主機／DNS 專業人員處理。
停止不是放棄，而是避免把可復原的錯誤變成停機、資料損失或資安事件。準備好時間線、備份、錯誤日誌與已嘗試步驟，能顯著縮短專業人員的診斷時間。
常見問題
可以直接在正式站測試嗎？
不建議。先備份並在測試環境重現，正式站只套用已驗證的最小變更。
需要關閉所有外掛嗎？
不應在沒有計畫時一次關閉。先保存清單，再用隔離或健康檢查方式逐步排除。
修好後要做什麼？
清除必要快取、重測主要流程、保存變更紀錄並確認監控沒有新錯誤。
官方文件與查核來源
以下文件用於核對 WordPress、WooCommerce、PHP 或資料庫行為。第三方外掛與主機設定仍需查閱該產品當前版本的正式文件。