網站搬家後 SSL 無法啟用，可能是什麼原因？

網站搬到新主機後，如果 SSL 無法安裝、HTTPS 打不開，或瀏覽器顯示憑證錯誤，先不要一直刪除再重裝憑證。

SSL 憑證簽發前，憑證機構需要確認你確實控制該網域。若網域仍指向舊主機、www 沒有解析到新環境，或中間經過 Cloudflare 等代理服務而設定未對齊，驗證就可能失敗。

比較有效的排查方式，是先分辨問題屬於哪一種，再從 DNS、主機、憑證及網站內容依序檢查。

先確認：你遇到的是哪一種 SSL 問題？

「SSL 無法啟用」可能指不同狀況：

1. 主機後台無法簽發憑證：按下安裝或 Get 後出現失敗訊息。
2. 憑證已安裝，但 HTTPS 無法開啟：瀏覽器顯示連線不安全、名稱不符或協定錯誤。
3. 透過 Cloudflare 開啟時出錯：例如 525、526，暫停代理後反而能連線。
4. 網站可以用 HTTPS 開啟，但仍顯示不完全安全：常見原因是頁面還載入 HTTP 圖片、字型或程式檔案。
5. HTTPS 正常，但 HTTP 沒有自動轉向 HTTPS：這是重新導向尚未設定，不代表憑證沒有生效。

這些問題看起來都和 SSL 有關，處理方式卻不相同。先記下主機或瀏覽器顯示的完整錯誤訊息，會比只說「SSL 壞了」更容易定位。

原因一：網域還沒有指向新主機

這是網站搬家後最常見的原因。

以 Let’s Encrypt 的 HTTP-01 驗證為例，憑證機構會透過網域連到指定路徑，確認主機能提供正確的驗證內容。如果網域仍解析到舊主機，驗證請求就到不了正在申請憑證的新主機。

先確認：

• 主網域的 A Record 是否為新主機 IP
• www 的 A Record 或 CNAME 是否指向正確位置
• 目前真正生效的 Nameserver 在哪個平台
• DNS 中是否仍有舊的 A Record 或 AAAA Record
• 主機後台是否已加入並識別這個正式網域

如果 DNS 設定分散在註冊商、Cloudflare 與主機商之間，很容易修改到沒有實際生效的那一邊。不確定控制層級時，可先參考：A Record、CNAME 與 Nameserver 有什麼不同？

原因二：主網域正常，但 www 尚未生效

安裝憑證時，主機通常會同時處理：

• example.com
• www.example.com

如果其中一個已指向新主機，另一個仍指向舊位置或根本沒有 DNS 紀錄，憑證機構可能無法完成所有名稱的驗證。

因此，不能只測試首頁開不開。應分別確認主網域與 www 的 DNS 結果，也要核對憑證實際涵蓋哪些網域名稱。

若網站決定使用不含 www 的正式網址，仍可保留正確的 www 解析與憑證，再把它重新導向主要版本。不要讓另一個版本直接落到錯誤主機或顯示憑證警告。

原因三：DNS 剛修改，外部查詢仍讀到舊資料

DNS 修改後，各地遞迴 DNS 與裝置快取不一定同時更新。你所在網路可能已經連到新主機，憑證機構使用的查詢位置卻仍取得舊紀錄；反過來也可能發生。

這時應先查詢目前公開 DNS 結果，而不是一直重裝 SSL。可分別檢查主網域、www、A、AAAA 與 CNAME，確認外部查詢已回傳預期內容。

若剛完成網域切換，應等解析結果穩定後再申請憑證。SiteGround 也提醒，太早安裝憑證可能因主網域或 www 尚未完成傳播而導致簽發失敗。

原因四：Cloudflare 代理與主機憑證沒有對齊

使用 Cloudflare 時，瀏覽器不是直接連到網站主機，而是先連到 Cloudflare。因此會同時存在兩段加密連線：

1. 訪客瀏覽器到 Cloudflare
2. Cloudflare 到原始主機

Cloudflare 邊緣憑證已啟用，不代表原始主機也有有效憑證。

如果 Cloudflare 使用 Full (strict)，原始主機必須提供有效、未過期、網域名稱相符且可被信任的憑證；否則可能出現 526 錯誤。Full 雖然仍會用 HTTPS 連接原始主機，但不會像 Full (strict) 一樣嚴格驗證憑證。

Flexible 則是訪客到 Cloudflare 使用 HTTPS，Cloudflare 到主機仍用 HTTP。它不適合作為正式 WordPress 網站長期解法，也可能在 WordPress 或主機同時強制 HTTPS 時形成重新導向迴圈。

排查時要分開確認：

• Cloudflare Edge Certificate 是否已啟用
• DNS 紀錄目前是 Proxied 還是 DNS only
• 原始主機是否已安裝正確憑證
• Cloudflare SSL/TLS 模式是否與原始主機狀態相符

不要為了暫時消除錯誤就把模式長期降成 Flexible。正確方向是讓原始主機先具備可用憑證，再使用符合需求的加密模式。

原因五：CAA 紀錄不允許該憑證機構簽發

CAA 是 DNS 中用來指定哪些憑證機構可以替網域簽發憑證的紀錄。

如果網域存在 CAA 紀錄，卻沒有允許目前使用的憑證機構，簽發就可能被拒絕。例如使用 Let’s Encrypt 時，要確認 CAA 規則沒有排除 letsencrypt.org。

一般沒有自行設定 CAA 的網站，不必為了安裝 SSL 主動新增複雜規則。但如果網站曾使用其他主機、企業 DNS 設定或安全服務，應檢查是否留下限制。

修改 CAA 前，要先確認現有紀錄是否由其他服務使用，不要看到陌生紀錄就直接刪除。

原因六：安裝的憑證與實際網址不相符

瀏覽器會檢查憑證中的網域名稱是否與正在開啟的網址一致。常見錯誤包括：

• 憑證只涵蓋 example.com，卻開啟 www.example.com
• 網站改用新網域，但主機仍送出舊網域的憑證
• 子網域沒有包含在標準憑證的涵蓋範圍
• 主機上的虛擬主機設定選到了另一個網站或預設憑證
• 憑證已過期，或憑證鏈不完整

如果錯誤訊息是名稱不符，重點不是清快取，而是查看瀏覽器收到的憑證到底簽給哪個網域，再回主機確認憑證安裝位置與涵蓋名稱。

在 SiteGround，可到「Site Tools → Security → SSL Manager」確認目標網域目前安裝的憑證。若憑證尚未建立，可選擇正確網域後安裝 Let’s Encrypt；如果剛搬家，應先確認 DNS 已經指向該 SiteGround 網站。

原因七：憑證正常，但頁面仍載入 HTTP 資源

如果 HTTPS 網頁能開啟，瀏覽器卻顯示不完全安全，通常不是憑證簽發失敗，而是 Mixed Content。

常見來源包括：

• 文章或頁面中的舊 HTTP 圖片
• Elementor 背景圖或產生的 CSS
• 自訂字型、JavaScript 或外部資源
• 主題選項與自訂 CSS 中寫死的 http://
• 快取仍保存切換前的頁面或樣式

可使用瀏覽器開發者工具的 Console 或 Network 查看是哪一個資源仍透過 HTTP 載入，再從內容、Elementor、主題設定或快取來源處理。

不要把 Mixed Content 和「SSL 沒裝成功」混在一起。前者表示主頁已經能建立 HTTPS 連線，只是頁面內部仍混用了不安全資源。

建議依這個順序排查

順序	檢查項目	要確認的結果
1	完整錯誤訊息	是簽發失敗、憑證錯誤、Cloudflare 錯誤或 Mixed Content
2	主網域與 www 的 DNS	都指向預期的新主機或正確代理服務
3	主機網域設定	正式網域已加入正確網站，不是只修改 DNS
4	主機端憑證	憑證存在、未過期，且涵蓋實際使用的網域
5	Cloudflare 設定	Edge Certificate、Proxy 與 SSL/TLS 模式彼此一致
6	CAA 與特殊 DNS	沒有限制目前的憑證機構，沒有舊 AAAA 等干擾紀錄
7	HTTPS 與網站內容	HTTP 正確轉向 HTTPS，頁面沒有 Mixed Content

如果網站正處於臨時網址切換正式網址的階段，可以搭配：網站從臨時網址切換成正式網址，要檢查哪些地方？。那篇處理完整上線流程，本篇則只用於 SSL 與 HTTPS 問題的定位。

哪些動作不要太早做？

遇到 SSL 問題時，以下做法容易讓情況更混亂：

• DNS 尚未確認就反覆刪除、重裝憑證
• 同時修改 A Record、Nameserver、Cloudflare 模式與 WordPress 網址
• 只因一台電腦正常，就認定全球 DNS 已完成更新
• 把 Cloudflare 改成 Flexible 後就視為問題解決
• 在憑證尚未正常前，先全面強制 HTTPS
• 沒看錯誤訊息就清除所有快取或重裝 WordPress

一次只調整一個層級，記錄修改前後狀態，才容易判斷是哪個設定真正造成問題。

CyberP7N 實際處理時的判斷方式

CyberP7N 處理網站搬遷後的 SSL 問題時，會先把「DNS 是否到達新主機」與「主機是否已有正確憑證」分開確認。

如果網站使用 Cloudflare，還會分別測試 Cloudflare 對外的邊緣憑證，以及 Cloudflare 連回原始主機的狀態。這樣可以判斷錯誤發生在訪客到 Cloudflare，還是 Cloudflare 到主機，而不是看到 HTTPS 錯誤就直接更換 SSL 模式。

確認憑證正常後，才會開啟 HTTPS 重新導向並檢查 Mixed Content。最後再清除 SiteGround Dynamic Cache、Cloudflare 快取與瀏覽器快取，使用無痕視窗重新測試主網域、www 及重要頁面。

結語

網站搬家後 SSL 無法啟用，最常見的問題不是憑證按鈕失效，而是網域驗證路徑還沒有對齊：DNS 仍指向舊主機、www 尚未解析、Cloudflare 與原始主機的加密模式不一致，或憑證涵蓋的名稱不正確。

先辨認錯誤類型，再依序確認 DNS、主機網域、憑證、Cloudflare 與頁面資源。等憑證真正可用後，再啟用 HTTPS 重新導向與處理 Mixed Content，會比反覆安裝憑證更安全，也更容易找出原因。