網站打不開怎麼做 DNS 查詢？域名解析故障排查指南

網站突然打不開時，很多人的第一反應都是先看伺服器：CPU 有沒有跑滿、Nginx 是否正常、資料庫是不是掛了，或者乾脆先把伺服器重啟一遍。很多時候你會看到伺服器本身沒有任何異常，直接存取源站 IP 也能正常回應，可一換成域名就打不開；又或者自己電腦存取一切正常，客戶卻回報某些地區一直提示找不到伺服器。這時大多是在 DNS 解析出了問題。

域名存取網站之前，需要先透過 DNS 找到對應的伺服器 IP。如果 A 記錄仍然指向舊伺服器、CNAME 設定錯誤、本機 DNS 快取沒有重新整理，或者不同電信商的遞迴 DNS 回傳結果不一致，最終表現出來都可能是「網站打不開」。

所以，碰到域名突然無法存取時，與其一下子就動手調整伺服器，不如先查清楚：這個域名現在到底被解析到了哪裡？下面就按照實際網站維運中的排查順序，看看如何透過 DNS 查詢快速判斷故障究竟出在域名解析、CDN、網路線路還是源站伺服器。

一、網站打不開，為什麼要先檢查 DNS？

使用者在瀏覽器中輸入一個域名之後，並不會直接連線網站伺服器。正常的存取過程大致是：

使用者輸入域名
    ↓
本機 DNS 快取
    ↓
遞迴 DNS 伺服器
    ↓
權威 DNS 伺服器
    ↓
A / AAAA / CNAME 解析記錄
    ↓
CDN 節點或源站 IP
    ↓
網站伺服器

也就是說，在瀏覽器真正建立 HTTP 或 HTTPS 連線之前，首先要完成 DNS 查詢。如果 DNS 沒有回傳正確位址，後面的伺服器即使完全正常，使用者一樣打不開網站。

例如網站原本部署在：

103.10.1.10

後來伺服器遷移到了：

103.20.2.20

但 DNS 記錄仍然回傳舊 IP：

example.com → 103.10.1.10

這時候新伺服器設定得再完善也沒有意義，因為使用者請求根本沒有到達新伺服器。實際排障時，可以先透過幾個現象快速判斷是否值得優先檢查 DNS：

因此，網站打不開時，DNS 查詢通常是成本最低、定位速度最快的一步。

二、網站打不開怎麼做 DNS 查詢？

排查 DNS 時，不需要一開始就研究大量複雜記錄。

對於普通網站無法存取的問題，首先看三個東西就夠了：

• A 記錄

• AAAA 記錄

• CNAME 記錄

其中最關鍵的問題是：

目前查詢到的 IP 或 CNAME，是否和你實際設定的一致？

1. 使用線上 DNS 查詢工具

如果不習慣使用命令列，可以直接透過線上 DNS 查詢工具檢查。

例如使用 Chahu DNS 查詢，輸入需要排查的域名後，可以檢視目前回傳的 A、AAAA、CNAME 等記錄。

假設查詢：

www.example.com

得到：

A → 203.0.113.20

這時候首先去伺服器或 CDN 控制檯確認：

203.0.113.20

是不是你現在真正使用的伺服器位址。

如果後台已經換成：

203.0.113.80

而 DNS 仍然回傳 .20，問題基本已經定位到了 DNS 記錄或快取這一層。線上查詢還有一個好處，就是可以避免只看自己電腦裡的 DNS 快取結果。

2. 使用 nslookup 查詢

Windows、macOS 和 Linux 都可以透過命令列查詢 DNS。

Windows 中可以使用：

nslookup example.com

正常情況下會回傳類似：

Name:    example.com
Address: 203.0.113.20

如果出現：

Non-existent domain

或者完全查不到有效位址，就需要檢查域名本身和 DNS 設定。

也可以指定公共 DNS，例如：

nslookup example.com 8.8.8.8

然後再換一個 DNS：

nslookup example.com 1.1.1.1

如果不同 DNS 回傳的結果不同，就說明問題可能和 DNS 快取或同步有關。

3. 使用 dig 進一步檢查

Linux、macOS 或安裝了相關工具的環境，可以使用：

dig example.com

只想檢視 A 記錄時：

dig example.com A

查詢 CNAME：

dig www.example.com CNAME

檢視指定 DNS：

dig @8.8.8.8 example.com

dig 相比 nslookup 能看到的資訊更多，特別適合排查 TTL、權威 DNS、CNAME 鏈路等問題。

不過對於普通站長來說，核心仍然不是工具本身，而是確認：

不同查詢方式得到的解析結果，到底是不是你預期的結果。

三、A 記錄和 CNAME 最常見的 4 種解析故障

DNS 能查到結果，並不代表解析設定一定沒有問題。

很多網站打不開，恰恰是因為 DNS「有結果，但結果錯了」。

1. A 記錄還指向舊伺服器

這是伺服器遷移以後非常常見的問題。

例如舊伺服器：

198.51.100.10

新伺服器：

198.51.100.50

結果 DNS 查詢仍然是：

example.com → 198.51.100.10

這時候要檢查：

• DNS 控制檯中的 A 記錄是否真的修改成功；

• 是否修改錯了域名；

• @ 和 www 是否分別設定；

• 是否存在多個 A 記錄；

• 舊記錄是否仍然保留。

不少網站遷移後會出現一種情況：

example.com → 新伺服器
www.example.com → 舊伺服器

於是存取不帶 www 的域名正常，存取 www 卻打不開。

因此排查時不要只查一個位址，至少同時檢查：

example.com
www.example.com

2. CNAME 設定錯誤

如果網站接入了 CDN，通常不會直接把域名解析到某個固定 IP，而是使用 CNAME。

例如 CDN 服務商提供：

abc123.cdn-provider.com

DNS 中應該設定：

www.example.com
        ↓
CNAME
        ↓
abc123.cdn-provider.com

如果 CNAME 拼寫錯誤、記錄沒有儲存成功，或者仍然指向舊 CDN 位址，網站就可能出現存取失敗。

所以接入 CDN 後打不開網站，第一件事應該檢查：

www.example.com 的 CNAME

是否和 CDN 控制檯提供的目標域名完全一致。

這裡尤其要注意複製過程中多出來的字元、錯誤的主機記錄以及舊設定沒有刪除等問題。

3. A 記錄和 CNAME 發生衝突

同一個主機名通常不應該同時存在 A 和 CNAME。

例如：

www.example.com → A → 203.0.113.20

同時又設定：

www.example.com → CNAME → abc.cdn.com

這類衝突設定可能導致 DNS 服務商直接不允許儲存，也可能在遷移或歷史設定中留下異常記錄。

如果網站剛接入 CDN，建議重新檢查原有 A 記錄是否已經按照服務商要求處理。

尤其不要看到「以前網站就是這樣設定的」，就預設舊記錄可以繼續留著。

4. AAAA 記錄指向了錯誤的 IPv6 伺服器

這是一個非常容易被忽略的問題。

假設網站的 A 記錄正常：

A → 203.0.113.20

但同時存在：

AAAA → 2001:db8::1234

而這個 IPv6 位址已經失效。

部分支援 IPv6 的使用者裝置可能會優先存取 AAAA 記錄，於是就出現一種很奇怪的現象：

有些人存取完全正常，有些人卻一直打不開。

如果伺服器並沒有正常部署 IPv6，而 DNS 中還保留著舊 AAAA 記錄，可以重點檢查這一項。

四、為什麼自己能打開，其他地區卻打不開？

網站故障中最麻煩的一類情況，不是所有人都打不開，而是：

自己這裡秒開，客戶那裡卻始終存取失敗。

這種情況很容易讓維運誤以為「網站明明沒問題」。

實際上，DNS 並不是全球所有使用者同時拿到同一個快取結果。

DNS 快取和 TTL 會造成解析不同步

假設網站之前的解析為：

example.com → 103.10.10.10
TTL = 3600

現在修改成：

example.com → 103.20.20.20

權威 DNS 上的記錄雖然已經修改，但不同地區的遞迴 DNS 可能仍然快取舊結果。

於是短時間內可能出現：

上海電信    → 103.20.20.20
北京聯通    → 103.10.10.10
廣州移動    → 103.10.10.10
海外 DNS   → 103.20.20.20

這樣一來，存取體驗自然就不一樣。

如果舊伺服器已經關閉，那麼仍然拿到舊 IP 的使用者就會直接打不開網站。

這時候不要只查自己電腦

本機執行一次：

nslookup example.com

只能說明你目前使用的 DNS 回傳了什麼。

並不能代表其他省份、電信商或海外網路看到的解析結果。

更有效的方法是使用多節點 DNS 查詢，例如透過 Chahu 檢視不同地區、不同電信商對同一個域名的解析結果。

如果絕大多數節點已經回傳新 IP，而少部分節點仍然是舊 IP，那麼問題通常更接近：

• TTL 尚未完全過期；

• 部分遞迴 DNS 仍有快取；

• 電信商 DNS 更新較慢。

如果出現完全不相關的 IP，則需要進一步排查 DNS 污染、解析線路設定或 CDN 排程。

五、DNS 正常但網站仍打不開，該查哪裡？

如果查詢結果已經確認：

example.com → 正確 IP

這只能說明 DNS 這一關基本通過了。

後面還有 TCP、TLS、HTTP、CDN 和源站等多個環節。

這時候就不要繼續圍著 DNS 轉，而應該往下一層檢查。

1. 先做 Ping 測試

可以先嘗試：

ping example.com

重點看兩件事：

第一，Ping 時解析出來的 IP 是否仍然正確。

第二，目標網路是否存在明顯丟包或延遲異常。

如果需要看多個地區，可以繼續使用 Chahu 的多節點 Ping 測試，對比不同網路下的連通情況。不過這裡要注意：

Ping 不通不等於網站一定打不開。

很多 CDN、雲伺服器或者防火牆會主動停用 ICMP，因此 Ping 逾時只能作為參考，不能直接認定伺服器故障。

2. 檢查 80 和 443 連接埠

對於普通網站，最重要的通常是：

TCP 80
TCP 443

假設 DNS 查詢正常：

example.com → 203.0.113.20

但 443 連接埠無法建立連線，那麼問題已經不再是 DNS。可能原因包括：

• Nginx 或 Apache 沒有啟動；

• 雲伺服器安全群組未開放 443；

• 系統防火牆攔截；

• CDN 節點無法連線源站；

• Web 服務監聽位址錯誤。

尤其是 HTTPS 網站，如果 443 不通，瀏覽器基本無法正常存取。

3. 再做 HTTP/HTTPS 測試

網站真正提供服務使用的是 HTTP/HTTPS。所以 DNS 和 Ping 都正常後，最好繼續測試 HTTP 回應。重點觀察：

• HTTP 狀態碼；

• TCP 建連；

• TLS 握手；

• TTFB；

• 頁面是否成功回傳。

不同狀態碼對應的問題方向也不同：

例如：

DNS 正常
Ping 正常
HTTPS 回傳 502

這種情況繼續修改 DNS 基本沒有意義，應該重點排查 CDN 回源或者源站 Web 服務。

六、瀏覽器常見錯誤分別代表什麼問題？

其實排查網站打不開的問題，最忌諱的就是一句大而無當的「網頁報錯了」。瀏覽器彈出的那行英文字母，往往已經把最直接的線索甩到了我們臉上。遇到問題時，第一步先把那行錯誤代碼複製下來，然後再對著下面的幾種常見情況去逐一排查：

1. DNS_PROBE_FINISHED_NXDOMAIN

這句話通俗點說，就是「網路上的導航儀根本找不到這個域名」。

如果你的使用者看到這個，大概率是域名解析層直接斷了。可以順著這個思路查：

• 域名本身： 看看域名是不是欠費過期了，或者域名狀態被註冊商鎖了。

• 解析記錄： 檢查 DNS 的 NS（ Name Server ）設定有沒有亂，A 記錄或者 CNAME 記錄是不是被誤刪了，或者剛改完解析還沒生效。

• 安全設定： 如果開過 DNSSEC，瞅瞅是不是簽名配錯了導致解析校驗失敗。

排查建議： 先用站長工具或者終端查一下公開 DNS。如果連第三方工具都什麼也查不到，那就不用折騰伺服器了，趕緊去域名控制檯看解析。

2. ERR_NAME_NOT_RESOLVED

這個也是 DNS 報錯，但跟上邊的 NXDOMAIN 有點區別，它往往更偏向於用戶端（也就是你自己電腦/網路）查不到解析。

排查建議： 直接在命令列打 nslookup 你的域名。

• 如果外網和公共 DNS（比如 114 或 8.8.8.8）能查到 IP，但你本機電腦查不到，問題肯定在本機：

  • 檢查電腦手動設的 DNS 是不是掛了。

  • 清一下本機 DNS 快取（ Windows 執行 ipconfig /flushdns）。

  • 重啟下路由器，或者懷疑是不是電信商 ISP 的 DNS 在抽風。

3. ERR_CONNECTION_TIMED_OUT

這個報錯意味著：域名已經成功找到了 IP，但你的電腦發過去請求，對方遲遲沒有給你任何回應，直到逾時。

既然 IP 能拿到，說明 DNS 沒大問題，這時候就要往網路鏈路和伺服器方向去想了：

• 伺服器狀態： 機子是不是死機了？或者 CPU/記憶體爆了導致回應不過來？

• 網路與線路： 中間的網路線路是不是斷了，或者丟包極其嚴重？

• 安全防護： 檢查雲伺服器的安全群組有沒有放行連接埠，伺服器內部的防火牆（如 iptables/ufw）是不是把請求攔截了。

• CDN 與源站： 如果用了 CDN，看下是節點沒連上源站，還是源站本身網路堵死了。

4. ERR_CONNECTION_REFUSED

逾時（ TIMED_OUT ）是「壓根沒回應」，而拒絕連線（ REFUSED ）則是「目標伺服器收到了請求，但明確把你彈回來了」。

這說明網路通路是順暢的，IP 和連接埠也找到了，但目標連接埠根本沒有程式在監聽，或者被直接拒絕了。

比如 DNS 和 IP 都正常，但請求 https 時報這個錯，通常排查：

• 服務有沒有開： Nginx、Apache 或者你的 Node/Java 程式到底跑起來沒有？

• 連接埠監聽： Web 服務是不是漏配了 443 連接埠？或者只監聽了 127.0.0.1 而沒監聽 0.0.0.0？

• 容器映射： 如果用 Docker 跑的服務，檢查 -p 連接埠映射有沒有漏寫或者寫錯。

5. SSL 憑證錯誤

SSL 報錯看著是加密問題，但很多時候它的根子其實在 DNS 解析不一致上。

最典型的場景：你剛給網站換了新伺服器、切了新 IP，或者重新部署了憑證。但因為各地的 DNS 重新整理有延遲，一部分地區存取的是新伺服器（憑證正常），另一部分地區還在請求舊伺服器（憑證已過期或未設定），這就導致「有人存取正常，有人提示憑證不安全」。

排查建議： 遇到這種報錯，別急著重跑憑證腳本，先看報錯使用者的實際存取情況：

• 讓他們 ping 一下域名，看解析出來的 IP 到底是新站還是舊站。

• 檢查 CDN 上面部署的憑證狀態，看是不是只更新了源站，忘更新 CDN 了。

• 確認一下憑證的域名比對範圍，看看是不是漏掉了 www 子域名或者根域名。

七、怎麼區分 DNS、CDN 和源站故障？

網站存取涉及很多環節，真正高效的排障方式並不是一次把所有設定翻一遍，而是逐層排除。可以參考下面這張表：

八、網站打不開時，推薦按照這個順序排查

如果不確定從哪裡開始，可以直接按照下面這套順序執行：

網站打不開
   ↓
① 查詢 DNS
   ↓
能否獲得 IP 或 CNAME？
 ├─ 否 → 檢查域名、NS、A/CNAME
 └─ 是
      ↓
② 回傳結果是否正確？
 ├─ 否 → 檢查 DNS 記錄、TTL、快取
 └─ 是
      ↓
③ 多地區 DNS 結果是否一致？
 ├─ 否 → 檢查區域 DNS 快取、線路解析
 └─ 是
      ↓
④ 測試 Ping / TCP 80 / 443
      ↓
⑤ 測試 HTTP/HTTPS
      ↓
⑥ 檢查 CDN 節點與回源
      ↓
⑦ 檢查源站伺服器

這套順序最大的好處，是可以先把不同故障層分開。例如 DNS 都沒有解析成功，就沒有必要先去調 Nginx；如果 DNS 已經正確，而網站回傳的是 502，也沒有必要不停重新整理 DNS 快取。

實際排障中，最浪費時間的往往不是問題有多複雜，而是一開始就在錯誤的層級反覆修改設定。

九、修改 DNS 以後多久才能恢復？

不少站長修改完 A 記錄或者 CNAME 後，會不斷重新整理網頁，發現十幾分鐘過去還沒恢復，就以為 DNS 設定錯了。

實際上，DNS 修改並不代表所有使用者會在同一秒拿到新記錄。

影響更新時間的主要因素是 TTL（Time To Live）。

例如原解析記錄：

TTL = 3600

代表遞迴 DNS 理論上可以快取這條記錄 3600 秒，也就是約 1 小時。

如果在快取尚未過期時修改 IP，那麼部分 DNS 伺服器可能仍然繼續回傳舊位址。

除此之外，還可能受到：

• 本機作業系統 DNS 快取；

• 瀏覽器快取；

• 路由器 DNS 快取；

• ISP 遞迴 DNS；

• 公共 DNS 更新狀態；

等因素影響。因此修改 DNS 後，最好不要只在一台電腦上反覆測試，而是透過多個 DNS 節點確認新的解析結果是否已經逐步生效。

伺服器遷移前可以提前降低 TTL

如果提前知道要更換伺服器或 CDN，可以在正式切換之前把 TTL 調低。比如原來是：

3600

可以提前調整為：

300

等舊 TTL 基本失效以後再遷移伺服器。這樣切換時，新舊 IP 同時存在的時間通常會明顯縮短。遷移完成並確認業務穩定以後，再根據實際情況恢復正常 TTL。

網站打不開只是最終表現，背後的原因可能完全不同。有時候只是 A 記錄還指向舊 IP，有時候是 CNAME 沒有正確接入 CDN，有時候則是 DNS 已經完全正常，真正的問題出在 443 連接埠、SSL、CDN 回源或者源站服務。所以實際排查時，可以先從 DNS 開始。

先確認域名能不能正常解析，再確認解析出來的 IP 或 CNAME 是否正確；如果只是部分地區異常，再透過 Chahu 這類多節點查詢工具對比不同電信商的 DNS 回傳結果。DNS 確認正常以後，再繼續往 Ping、TCP、HTTP、CDN 和源站方向檢查。

按照這種從前往後的方式逐層排除，通常比一看到網站打不開就反覆重啟伺服器，更容易找到真正的問題所在。DNS 查詢並不是一個單獨的測速動作，它更像是整個網站故障排查流程的第一道分界線：DNS 都沒走通，就先別碰伺服器；DNS 已經正確，就繼續往下一層查。