Cloudways DNS 切換後排錯教學：TTL、解析及回滾的六步檢查

把 WordPress 轉到 Cloudways 後，最常見的問題不是網站本身，而是 DNS 尚未完全更新、舊記錄仍然存在，或 HTTPS 和主要網域沒有同步。本文針對切換後出現間歇性 404、部分訪客仍到舊主機、郵件失效及需要回滾的情況，提供六步排錯流程。所有示範畫面中的網域、IP、帳戶、電郵、伺服器及網站識別資料均已遮蔽。

切換後先不要做甚麼？

不要立即刪除舊主機、反覆修改 DNS 或同時更換 SSL。先保存目前記錄和切換時間，讓每一次變更都有可比較的基線；公開截圖只保留匿名標籤。

步驟 1：備份目前 DNS 記錄

把 A、AAAA、CNAME、MX、TXT 及驗證記錄匯出或截圖保存。密碼、驗證 token、電郵和真實網域必須遮蔽，只保留記錄類型、TTL 及用途，方便之後比較。

步驟 2：確認 Cloudways 公開 IP

在 Cloudways 應用程式或伺服器資訊頁取得目前公開 IP，再與 DNS 管理器的 A 記錄比較。不要把完整 IP 寫入文章或公開記事；以「新主機 IP」和末段遮蔽的示範值記錄即可。

步驟 3：降低 TTL 並等待快取更新

切換前可先把 TTL 調低，讓遞迴 DNS 較快重新查詢；切換後不要因為單一網絡仍顯示舊 IP 就立即再次修改。用多個解析器、手機網絡及公司網絡分別測試，並記錄查詢時間。

步驟 4：逐項更新網域記錄

先更新網站的 A 或 CNAME，再按需要處理 www、API、驗證及郵件相關記錄。MX 和 SPF 不應因網站搬家而隨意刪除；每改一項便測試一次，避免把多個錯誤混在一起。

步驟 5：檢查解析及 HTTPS 傳播

確認不同地區解析結果逐步指向新主機，再測試首頁、登入、圖片、表單及 API。若 HTTPS 顯示錯誤，先確認 Cloudways 憑證涵蓋主要網域與 www 版本，不要用停用安全檢查來掩蓋問題。

步驟 6：保留回滾方案並完成驗證

若新主機出現持續 5xx、資料庫錯誤或付款失敗，先保存錯誤時間和已遮蔽日誌，再按預先記錄的舊 DNS 值回滾。修正後重新降低 TTL、核對解析，並觀察一個完整高峰週期才清理舊主機。

常見問題：DNS 傳播要等多久？

時間受 TTL、遞迴 DNS 和網絡快取影響，不能只以單一工具判斷。應以多地區、多網絡結果和連續時間觀察作準。

常見問題：切換後郵件失效怎麼辦？

先檢查 MX、SPF、DKIM 和 DMARC 是否仍保留，並確認郵件服務沒有被網站 A 記錄變更覆蓋。網站搬遷和郵件搬遷應分開驗證。

總結

DNS 切換的安全做法是先備份、再確認目標、逐項變更、跨網絡驗證，最後保留可回滾記錄。這樣即使傳播期間出現間歇性問題，也能按證據處理，而不是盲目重複修改。