自訂網域 SSL 失敗時，該檢查哪些地方

如果你把 DNS 指向平台後，自訂網域還是跳出「不安全」警告，那你的 DNS 記錄大概沒錯，卡住的是你的主機和憑證機構之間的握手。多數代理商會以為這是平台的 bug，但這幾乎都是設定上的競態條件：你的網域技術上已經指向正確的地方，但 Mydrop 的主機派送設定還在找上一個目標指派。

我們懂。客戶在等、品牌入口頁要上線，結果現在這個網址跳出安全錯誤。就是這種卡點，會把一場順順的活動上線，變成跟 IT 部門硬碰硬的高壓對峙。你並不孤單，我們在幾百個品牌部署裡都看過這狀況。問題很少出在平台本身，多半是某筆「幽靈」記錄，或是一個還沒清掉的殘留指派，擋在代管 SSL 完成之前。

數字變動之前，先發生了什麼

大多數 SSL 開通延遲，都是從 DNS 控制台裡一個小小、看似無害的變更開始的。你可能把 CNAME 記錄更新成指向 Mydrop 主機，但只要還留著一筆舊的 A 記錄，或你的 TTL（存活時間）設得太高，全球 DNS 快取就會繼續照舊的路由指示跑上好幾個小時。

真正的麻煩，是你想硬把它修好的時候開始的。很多團隊會一直狂按「重新整理 SSL」，以為這樣能把系統叫醒。結果往往相反：你打斷的是一個早就跑到一半的自動背景工作。

想終止這個錯誤訊息迴圈，先快速檢查一下目前的 DNS 狀態。這份清單能抓出「已設定」和「已開通」之間最常見的落差。

5 點 DNS/SSL 健康檢查清單

1. 傳播檢查： 你的 CNAME 記錄是否已完整傳播到全球名稱伺服器？（可以用 DNSChecker 這類工具確認）
2. 記錄乾淨度： 有沒有把指向舊伺服器的舊 A 記錄全部清掉？
3. 指派鎖定： 這個網域目前是不是還被指派到 Mydrop 裡另一個使用中的頁面？
4. 主機衝突： 這個網域目前是不是被其他工作區或保留的公開主機佔用？
5. 開通等待期： 你有沒有至少留 15 分鐘，讓自動排程工作偵測到新的 DNS 狀態，再手動介入？

如果 DNS 狀態確認沒問題，但 sslState 還是亮著錯誤，那你碰到的很可能是目標指派衝突。這會發生在平台想幫一個網域申請憑證，但這個網域同時被指向 link-in-bio 頁面和 brand-portal 頁面的時候。

解法是把網域完全解除指派，到你的網域設定裡操作，再確認一次「DNS 已驗證」狀態，然後重新指派到你真正要的目標。把它想成主機派送層的一次強制重開：清掉路由快取，讓代管 SSL 的生命週期從頭乾淨跑一遍。

多數團隊不是遇到技術故障，而是欠了「協調債」：網域設定和平台路由就是沒對上。記錄確認好之後，就讓系統自己去完成握手，耐心是你最好的診斷工具。

先檢查這幾種失敗模式

當你的網域卡在「不安全」狀態，問題幾乎都出在你的 DNS 記錄和我們的開通服務之間的競態條件。我們看過太多代理商在這裡踩雷。你更新了 DNS、在後台按下按鈕，然後期待馬上握手成功。但 DNS 這東西很任性，它常常只傳播一半：有些伺服器已經看到你新的 CNAME，其他伺服器卻還在看你的舊架構，或根本一片空白。

最常見的兇手，是一筆看不見的殘留記錄。你可能把 portal.clientbrand.com 的 CNAME 更新了，卻忘了刪掉指向舊伺服器的 A 記錄。這會造成「腦裂」：我們的代管 SSL 服務要驗證所有權時，偶爾會打到舊伺服器，而不是我們的路由層，開通就這樣逾時。

常見錯誤： 只靠瀏覽器的重新整理鍵。瀏覽器快取 DNS 回應快得誇張。先清快取，更好的做法是用伺服器端工具檢查，再判斷這筆記錄是不是真的在全球生效了。

另一個常見的卡點，是目標指派衝突。如果這個網域之前指向別的工作區，或被保留成系統層級的主機，內部路由邏輯會基於安全考量擋下 SSL 流程。它不會讓你把手上的憑證掛到一個還沒被你目前工作區完整認領的主機上。結果你就卡在一個永遠不會結束的「待處理」狀態，因為底層的派送服務基本上在說：「我還不認得這是你的。」

---

分辨訊號與雜訊的那個依據

別再猜平台是不是「只是慢」，開始看真正的訊號。我們就是為此打造內部 DNS 檢查工具，讓它成為唯一的判斷依據。如果它回傳「待處理」或「衝突」狀態，你按幾百次「重新整理 SSL」也不會改變結果。

用這份 5 點 DNS/SSL 健康檢查清單快速檢查一遍，再決定要不要開客服單或敲你的開發團隊。

步驟	檢查項目	失敗時怎麼做
1	CNAME 已傳播	用 dig 或 nslookup 確認記錄指向我們的主機，不是你的舊伺服器。
2	沒有衝突的 A 記錄	把同一個子網域的 A 記錄全部刪掉。這是握手逾時的第一號元兇。
3	主機可用性	確認這個主機沒在你的設定裡被指派給其他工作區。
4	SSL 狀態訊號	到後台看具體的 sslError 代碼：DNS_PENDING 代表再等等，AUTH_FAILURE 代表記錄要修。
5	排程同步	至少等 15 分鐘。我們背景工作會定期更新網域狀態，手動重新整理有時反而會把這個計時器歸零。

SSL 的黃金法則： DNS 檢查沒過，SSL 開通基本上就是暫停的。平台不會去幫一個它無法明確證明屬於你的網域申請憑證。把 DNS 檢查當成守門員。它一變綠燈，代管 SSL 的生命週期就會自動啟動。如果你看到 DNS_PENDING，幾乎可以確定是傳播延遲，去倒杯咖啡，讓網路自己追上。如果你看到 AUTH_FAILURE，那就是有設定上的幽靈，得去你的 DNS 供應商後台把它揪出來。

這週該修的事

如果你現在正盯著失敗的 SSL 狀態，別再按那顆按鈕了，先從 DNS 記錄下手。最常見的解法簡單到有點意外：確認你的 CNAME 或 A 記錄沒有跟幽靈主機打架。很多時候，一筆指向舊伺服器的舊 A 記錄，或一個根層級轉址，還留在你的 DNS 供應商那裡，讓我們的開通服務直接撞牆。

先把路清乾淨，檢查你的 DNS 設定。如果你用 Mydrop 管理自訂網域，確認 CNAME 精準指向工作區設定裡提供的那個公開自訂網域目標。只要指向別的地方，我們的代管 SSL 生命週期就無法驗證所有權，開通會無限期卡住。

5 步 DNS 與 SSL 復原清單

1. 檢查重複記錄： 刪掉任何可能跟你的 CNAME 搶同一個主機的 A 或 AAAA 記錄。
2. 確認目標對齊： 確認你的 CNAME 指向網域設定裡指定的那個公開目標。
3. 等傳播完成： 給網路一點時間。DNS 變更可能幾分鐘就好，運氣差遇到固執的全球解析器，也可能要一小時。
4. 清掉主機衝突： 確認沒有其他工作區或已停用的入口頁還佔著同一個主機。
5. 手動重新整理： 確定記錄都乾淨了，再到 Mydrop 網域設定裡手動觸發一次重新整理。

如果記錄都清乾淨了還是失敗，檢查這個主機是不是保留的公開主機，或已經被指派給其他工作區。這在大團隊很常見：某個部門半年前「借」了一個網域去做活動頁，然後忘了還。

---

什麼時候該停止診斷，直接改流程

如果你每個月都要為 SSL 憑證排錯超過一次，那你面對的是協調問題，不是技術問題。最好的團隊不會等到「不安全」警告跳出來，才發現網域設定錯了。他們建立「先驗證」的文化，把網域開通當成專案生命週期裡一個獨立、有閘門的階段。

多數代理商的錯誤，是在 DNS 還沒完整傳播、SSL 還沒開通前，就把品牌網址交給客戶。等到客戶點連結、上線當下看到瀏覽器警告，就成了高壓卡點。換個做法，調整你的內部作業習慣：在任何 link-in-bio 頁面或客戶入口頁被放進活動簡報之前，把「網域就緒」當成必勾的檢查項。

操作守則： 在 Mydrop DNS 檢查回傳確認的「已驗證」狀態訊號之前，絕對不要把自訂網域放進任何對客戶的溝通或上線時程裡。

把驗證往專案流程前面移，你就能甩掉最後一刻追 DNS 更新的壓力。這會讓 SSL 開通從一場技術對峙，變成例行、自動的背景流程。當你把「先驗證」的規則標準化，你就不再是自家行銷頁面的 IT 救火隊，而是那個每次都準時上線的團隊。

結語

在 Mydrop 這種多租戶環境裡，SSL 失敗幾乎都不是平台壞了。它們是 DNS 記錄跟預期的主機派送沒對上的產物，或是網域被兩邊拉扯的設定競態條件。一旦你搞懂 SSL 只是長長一串 DNS 驗證後的最後握手，「錯誤狀態」就不再神秘。檢查你的記錄、清掉幽靈、對每個新的品牌入口頁落實先驗證的政策。你的團隊和客戶，都會愛上那種一進站就安全、有品牌感、馬上能用的順暢體驗。