DNS 問題排除教學：網站無法訪問、解析錯誤等疑難雜症解決

DNS 排錯最容易浪費時間的地方，不是工具不夠，而是你沒有順序。很多人一出問題就同時改紀錄、清快取、換平台，最後根本不知道是哪一步有效。這篇就是幫你建立一套比較不會越修越亂的排錯流程。

你如果不想每次都只是照著別人的畫面一步一步跟著按，卻不知道自己到底改了什麼，這篇會比較適合你。重點不是讓你背流程，而是讓你下次遇到類似情況時，還知道該怎麼自己判斷。

你會學到什麼

• 用更有順序的方式處理常見 DNS 問題。
• 知道什麼時候該查 NS、A、MX，什麼時候該看 Cloudflare。
• 熟悉幾個排錯時真的有用的指令與工具，包含 Windows 與 macOS 的差異。
• 了解 SSL 憑證與 DNS 之間的關聯性。

什麼情況最適合先看這篇

• 正在處理網域、解析、Cloudflare 或郵件紀錄，想一次把觀念和排錯順好的人
• 你現在正要處理「DNS 問題排除」這類操作
• 你希望做完之後不只功能能用，連驗證與排錯也有概念

開始前先確認

• 先整理好你改過哪些紀錄。
• 準備好網域名稱與目前主機資訊。
• 如果是正式站，先避免同時做太多變更。

先提醒你一件事

DNS 問題常常不是設定全錯，而是你同時改了太多地方，最後分不清楚是哪一步造成的。

詳細教學與操作步驟

DNS 排錯流程圖

遇到 DNS 問題時，建議按照這個順序來排查，不要跳步驟：

問題一：修改 DNS 記錄後沒有生效

這是最常見的 DNS 問題，通常與 TTL 和 DNS 傳播有關。

排除步驟：

1. 確認記錄已儲存： 回到 Cloudflare DNS 頁面，確認記錄已正確顯示。

2. 檢查 TTL： 如果之前的 TTL 設定較高（例如 24 小時），可能需要等待該時間過後新記錄才會生效。

3. 清除本機 DNS 快取：

   # Windows
   ipconfig /flushdns
   
   # macOS
   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   
   # Linux
   sudo systemd-resolve --flush-caches
   

4. 使用線上工具確認傳播狀態： 前往 dnschecker.org，輸入你的網域查看全球各地的解析結果。

預防措施： 在計畫修改 DNS 記錄前，先將 TTL 降低至 300 秒（5 分鐘），等待原本的 TTL 時間過後再進行修改，這樣新記錄可以更快生效。

問題二：ERR_NAME_NOT_RESOLVED（無法解析網域名稱）

瀏覽器顯示此錯誤代表完全無法找到你的網域。

可能原因與排除：

1. Nameserver 尚未生效： 如果你剛更改 Nameserver 到 Cloudflare，可能還在傳播中（最長 48 小時）。使用以下指令確認：

   nslookup -type=NS example.com
   

   確認回傳的是 Cloudflare 的 Nameserver。

2. 網域已過期： 登入網域註冊商確認網域是否仍在有效期內。

3. DNS 記錄不存在： 確認 Cloudflare 中有設定正確的 A 或 CNAME 記錄。

4. 打字錯誤： 仔細檢查網域名稱是否拼寫正確。

問題三：SSL 憑證因 DNS 設定問題而失敗

這是很多站長會遇到的狀況：DNS 看起來設對了，網站也能開，但 SSL 憑證卻簽發失敗或出現錯誤。

案例一：Let's Encrypt 憑證簽發失敗

Let's Encrypt 在簽發憑證時，需要透過 DNS 或 HTTP 驗證你是網域的擁有者。如果 DNS 設定有問題，驗證就會失敗。

常見原因：

• A 記錄指向的 IP 不是申請憑證的那台主機。
• 開了 Cloudflare Proxy（橘色雲朵），Let's Encrypt 驗證被 Cloudflare 攔截。
• CNAME 鏈太長，驗證超時。

解決方式：

1. 確認 A 記錄指向正確的主機 IP。
2. 如果使用 Cloudflare，簽發 Let's Encrypt 憑證時，暫時把 Proxy 切成 DNS Only（灰色雲朵）。
3. 或者直接使用 Cloudflare 提供的免費 SSL 憑證，搭配 Full (Strict) 模式。

案例二：CAA 記錄阻擋憑證簽發

如果你有設定 CAA 記錄，只允許特定 CA 簽發憑證，但實際使用的 CA 不在清單中，憑證簽發就會被拒絕。

# 檢查 CAA 記錄
dig example.com CAA

# 確認結果中包含你使用的 CA
# 例如使用 Let's Encrypt，應該有：
# example.com. CAA 0 issue "letsencrypt.org"

案例三：DNS 切換導致既有 SSL 憑證失效

當你把 DNS 從一台主機切換到另一台主機時，原本主機上的 SSL 憑證不會自動跟著搬過去。新主機需要重新申請憑證。

排除步驟：

1. 確認新主機上的 Web Server 已正確設定 SSL。
2. 如果使用 cPanel，等 DNS 生效後，到 cPanel → SSL/TLS Status 執行 AutoSSL。
3. 如果使用 Cloudflare，確認 SSL/TLS 模式設定為 Full 或 Full (Strict)。

問題四：啟用 Cloudflare Proxy 後出現 Mixed Content 警告

開啟 Cloudflare Proxy（橘色雲朵）後，網站可能出現部分資源載入失敗或瀏覽器顯示「不安全」的警告。

原因： 你的網站內有資源使用 http:// 載入，但 Cloudflare 預設會強制使用 HTTPS。

解決方法：

1. 登入 Cloudflare Dashboard，進入你的網域。
2. 前往「SSL/TLS」→「Overview」。
3. 將 SSL 模式設定為「Full」或「Full (Strict)」。
   • Full： Cloudflare 與你的伺服器之間使用 SSL，但不驗證伺服器憑證。
   • Full (Strict)： 需要伺服器上有有效的 SSL 憑證（建議使用）。
4. 前往「SSL/TLS」→「Edge Certificates」，開啟「Always Use HTTPS」。
5. 檢查你的網站原始碼，將所有 http:// 的資源連結改為 https:// 或使用 // 開頭的相對協定。

問題五：Cloudflare 錯誤頁面

當使用 Cloudflare Proxy 時，可能遇到以下錯誤頁面：

DNS 診斷指令：Windows vs macOS 完整對照

不同作業系統的 DNS 診斷指令有些差異。以下是完整的對照表：

查詢 DNS 記錄：

網路連線測試：

進階 dig 用法（macOS / Linux）：

# 查詢 A 記錄（完整輸出）
dig example.com

# 精簡輸出（只看結果）
dig example.com +short

# 指定 DNS 伺服器查詢（繞過本機快取）
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# 追蹤完整解析路徑（排錯神器）
dig example.com +trace

# 查詢特定記錄類型
dig example.com MX
dig example.com TXT
dig example.com AAAA
dig example.com CAA

# 查看 DNSSEC 相關記錄
dig example.com +dnssec

# 反向 DNS 查詢（IP 反查網域）
dig -x 203.0.113.10

Windows PowerShell 進階用法：

# 使用 Resolve-DnsName（PowerShell 內建）
Resolve-DnsName example.com
Resolve-DnsName example.com -Type MX
Resolve-DnsName example.com -Type TXT
Resolve-DnsName example.com -Server 8.8.8.8

# 測試特定 port 是否開放
Test-NetConnection example.com -Port 443
Test-NetConnection example.com -Port 25

真實案例分享

案例一：Email 突然全部進垃圾郵件

一位站長反映，原本正常的企業信箱突然所有寄出的郵件都進了對方的垃圾郵件匣。

排查過程：

1. 用 dig example.com TXT +short 查看 SPF 記錄 — 發現 SPF 記錄消失了。
2. 回去查 Cloudflare DNS 頁面 — 記錄確實不見了。
3. 原因：前一天為了設定 Google Site Verification，不小心把 SPF 的 TXT 記錄覆蓋掉了。
4. 解決：重新加回 SPF 記錄，等待傳播後恢復正常。

案例二：網站時好時壞，某些地區打不開

一位站長反映網站在台灣能開，但在中國大陸打不開。

排查過程：

1. 用 dnschecker.org 查看全球解析狀態 — 發現中國的 DNS 解析結果不一致。
2. 用 dig example.com +trace 追蹤 — 發現 NS 記錄還有一台指向舊的 DNS 服務商。
3. 原因：更換 DNS 服務商時，只改了一台 NS，忘了改另一台。
4. 解決：到註冊商把所有 NS 記錄統一指向 Cloudflare。

案例三：AutoSSL 一直簽發失敗

使用 cPanel 虛擬主機的站長，AutoSSL 一直顯示簽發失敗。

排查過程：

1. 查看 AutoSSL 錯誤訊息 — 顯示 DNS DCV（Domain Control Validation）失敗。
2. 用 dig example.com A +short 查看 — A 記錄指向的是 Cloudflare 的 IP，不是主機 IP。
3. 原因：Cloudflare Proxy 開著（橘色雲朵），cPanel 的 AutoSSL 驗證被 Cloudflare 攔截。
4. 解決方式 A：暫時關閉 Cloudflare Proxy，等 AutoSSL 簽發成功後再開回來。
5. 解決方式 B：直接使用 Cloudflare 的免費 SSL，在 SSL/TLS 設定中選 Full 模式。

線上診斷工具

仍然無法解決？

如果以上方法都無法解決你的問題，請透過以下方式聯繫侃瑞科技技術支援：

• 登入 客戶中心 提交工單。
• 提供你的網域名稱、遇到的問題描述、以及你已嘗試的排除步驟，我們的工程師將盡快協助你處理。

做完後怎麼確認自己真的有設對

• 至少用 dig、nslookup 或線上工具再驗一次，區分是設定錯、快取，還是 propagation。
• 重新看一次你剛剛改過的設定值、網址、帳號或紀錄，確認沒有填錯對象。
• 如果這篇操作會影響正式網站或正式信箱，建議再從不同網路或不同裝置測一次。

這一題最常踩的坑

• 一有問題就把 Nameserver 跟記錄一起全部重改。
• 只看瀏覽器畫面，不查實際 DNS 查詢結果。
• 忽略本機快取或 ISP 快取，誤以為自己設定錯。
• SSL 憑證出問題時只看 SSL 設定，沒檢查 DNS 是否正確。
• 同時改太多東西，搞不清楚是哪一步修好的。

如果你要往下一步走

如果你是在設定前就想先建立正確觀念，可以回頭補 DNS 基礎觀念解析。 如果你接下來要把網站正式上線，也可以直接銜接侃瑞的 主機方案 或 VPS 方案。