線上 DNS 查詢怎麼用？網域名稱解析檢測完整教學

本文詳細介紹線上 DNS 查詢的使用方法，包含 A、AAAA、CNAME、MX、TXT 等常見記錄的查詢與結果判讀，並結合 TTL、多地區節點與電信商解析差異，說明網域修改、CDN 切換及解析異常時的實際排查思路。

Chahu 團隊2026-09-185 分鐘閱讀

網站換伺服器、修改網域解析或者接入 CDN 之後，很多人第一件事就是重新整理網頁，看看網站能不能正常開啟。頁面能存取，就覺得 DNS 已經生效；如果打不開，就開始懷疑伺服器、CDN 或者憑證出了問題。

但實際維運中，DNS 解析並不是修改完成後，全國甚至全球所有使用者同時更新。同一個網域，北京電信可能已經拿到了新的 IP，廣州移動還在用舊快取，海外某些地區又可能回傳另一組 CDN 節點。如果只在自己的電腦上 Ping 一次，很容易得到一個並不完整的判斷。這時候，更直接的方法是做一次線上 DNS 查詢。

透過不同地區、不同電信業者節點回傳的結果，可以看到網域目前解析到了哪裡，A、AAAA、CNAME 等記錄是否正確，以及修改 DNS 後還有哪些地區沒有完成更新。對於伺服器搬遷、CDN 切換、信箱設定或者解析異常排查來說，這一步通常比單純重新整理瀏覽器更有參考價值。今天我們就從實際使用出發，具體看看線上 DNS 查詢怎麼用，以及查詢結果應該怎麼看。

一、線上 DNS 查詢能查什麼？

存取網站時，瀏覽器最終需要連接的是伺服器 IP，而不是我們平時看到的網域。

比如使用者存取：

www.example.com

在真正建立 HTTP 或 HTTPS 連線之前，系統首先需要透過 DNS 找到這個網域對應的位址。

大致過程可以理解為：

使用者輸入網域
      ↓
本機快取 / 遞迴 DNS
      ↓
權威 DNS
      ↓
回傳 A、AAAA、CNAME 等記錄
      ↓
得到伺服器或 CDN 節點位址
      ↓
建立網路連線
      ↓
存取網站

線上 DNS 查詢工具做的事情，本質上就是從指定的測試節點發起 DNS 查詢，然後把目前拿到的解析記錄展示出來。和自己電腦執行一次 nslookup 不同，多節點 DNS 查詢還能從不同地區觀察解析結果，因此更容易發現區域性的快取、線路解析或者 CDN 調度問題。

日常比較常見的查詢需求包括：

查看網域目前解析到哪個 IPv4 或 IPv6 位址；
檢查修改 DNS 後是否已經生效；
查看 CDN 的 CNAME 是否設定正確；
判斷不同省份、電信業者回傳的解析是否一致；
檢查 MX、TXT 等信箱和網域驗證記錄；
判斷異常地區是否仍然使用舊 IP。

所以線上 DNS 查詢並不只是「查一個 IP」，真正有價值的是透過不同位置的查詢結果判斷目前 DNS 狀態是否符合預期。

二、線上 DNS 查詢怎麼用？

線上 DNS 查詢操作並不複雜，這裡以 Chahu 的 DNS 查詢功能為例：

如果只是排查一般網站解析，通常按照「輸入網域—選擇記錄類型—查看不同節點結果」這幾個步驟就能完成。

1. 輸入需要查詢的網域

開啟 Chahu，找到DNS 查詢頁面，首先填寫需要檢測的網域，例如：

www.example.com

這裡要注意，DNS 查詢針對的是網域，而不是具體網頁路徑。

例如下面這種寫法適合查詢：

www.example.com

而不是：

https://www.example.com/product/page.html

因為 /product/page.html 屬於網站內部 URL 路徑，並不是 DNS 負責解析的部分。

如果網站同時使用：

example.com
www.example.com
api.example.com

那麼這幾個網域也可能設定了完全不同的解析記錄，排查時最好分別查詢，不要預設根網域正常就代表所有子網域都正常。

2. 選擇需要查詢的 DNS 記錄類型

DNS 並不是只有「網域對應 IP」這一種記錄，不同記錄承擔的作用不同。網站存取異常時，首先要確認自己到底應該查哪一種。

DNS 記錄	主要作用	常見排查場景
A	將網域解析到 IPv4 位址	換伺服器、網站打不開、IP 切換
AAAA	將網域解析到 IPv6 位址	IPv6 存取異常
CNAME	將一個網域指向另一個網域	CDN、雲端服務、第三方平台
MX	指定郵件伺服器	企業信箱收發異常
TXT	保存文字驗證資訊	SPF、DKIM、DMARC、網域驗證
NS	指定權威 DNS 伺服器	更換 DNS 服務商
CAA	限制可為網域簽發憑證的 CA	SSL 憑證簽發異常

如果只是想知道網站目前指向哪個伺服器，一般先查 A 記錄；如果網站接入了 CDN，則還要重點看 CNAME；如果網站已經開啟 IPv6，而部分使用者回報打不開，就應該同時檢查 AAAA 記錄；企業信箱驗證失敗，則通常需要檢查 MX 和 TXT。先確定記錄類型，再看結果，排查效率會高很多。

三、A、AAAA、CNAME、MX 和 TXT 分別怎麼看？

不同 DNS 記錄回傳的內容不一樣，判斷方式也不能混在一起。

1. A 記錄：看 IPv4 是否正確

A 記錄是日常網站維運最常查的一類。

例如查詢結果顯示：

www.example.com
203.0.113.20

如果 203.0.113.20 正好是剛剛更換的新伺服器 IP，說明目前這個 DNS 查詢節點已經拿到了新記錄；如果仍然回傳舊 IP，則需要繼續判斷：權威 DNS 是否已經修改；TTL 是否還沒過期；目前遞迴 DNS 是否仍然保留舊快取。單獨看到一個 IP 本身並沒有太大意義，關鍵是要知道它是不是你預期的 IP。

2. AAAA 記錄：檢查 IPv6

AAAA 和 A 的邏輯類似，只不過回傳的是 IPv6 位址。

例如：

2001:db8::10

有些網站會遇到：IPv4 存取完全正常，但開啟 IPv6 後，部分行動網路或者支援 IPv6 的使用者存取異常這種問題。這時候就要檢查 AAAA 是否仍然指向舊伺服器、錯誤伺服器，或者某個已經失效的 IPv6 位址。如果網站目前根本沒有部署 IPv6，卻意外存在 AAAA 記錄，也值得重點檢查。

3. CNAME：重點看 CDN 和第三方服務

接入 CDN 後，經常會使用 CNAME。

例如：

www.example.com
        ↓
example.cdn-provider.net
        ↓
203.0.113.30
203.0.113.31

這時候不要只盯著最後一個 IP。首先需要確認：CNAME 有沒有指向你目前正在使用的 CDN 位址。如果已經從舊 CDN 切換到新 CDN，但查詢結果仍然回傳舊 CNAME，那麼問題很可能仍在 DNS 解析這一層。如果 CNAME 正確，而不同地區最終回傳的 IP 不同，也不一定有問題。因為很多 CDN 會根據使用者所在地區、電信業者和網路狀況回傳不同的邊緣節點，這本身就是正常的調度行為。

4. MX：查看企業信箱解析

MX 記錄主要用於郵件。

比如企業信箱遷移以後，經常會遇到：郵件收不到；網域驗證失敗；舊郵件服務仍然收到部分郵件等問題。這時候就要查詢 MX，看它是否已經指向新的郵件伺服器。另外還要注意 MX 記錄的優先順序。通常數字越小，優先順序越高。比如：

10 mx1.example.com
20 mx2.example.com

郵件伺服器通常會優先嘗試 mx1.example.com。

5. TXT：看 SPF、DKIM、DMARC 和網域驗證

TXT 記錄本身用途非常多。

常見的包括：

SPF；
DKIM；
DMARC；
Google Search Console 驗證；
SaaS 平台網域所有權驗證；
SSL DNS 驗證。

如果第三方平台一直提示「驗證失敗」，不要只反覆點擊驗證按鈕，可以先查詢 TXT，確認記錄到底有沒有真正發布到 DNS。尤其是比較長的 SPF 或 DKIM 內容，要注意是否存在漏字元、重複記錄或者主機名稱填寫錯誤的問題。

四、DNS 查詢結果應該怎麼看？

拿到查詢結果之後，建議按照幾個固定順序判斷，不要看到某個節點不一樣就馬上認定是 DNS 故障。

1. 先看回傳位址是不是預期結果

這是最基礎的一步。

例如你剛剛把網站遷移到：

203.0.113.20

大部分節點都已經回傳新位址，而少數仍然是：

192.0.2.10

首先就能判斷出：目前存在新舊解析並存的情況。

接下來再判斷是正常快取，還是解析設定本身存在問題。

2. 再看異常是不是集中在某個地區或電信業者

如果全國大部分地區都正常，只有少數節點還在用舊 IP，一般優先考慮 DNS 快取。

但如果出現：

電信：全部正常
聯通：全部正常
移動：大量異常

那就值得進一步檢查：

智慧 DNS 的行動線路設定；
電信業者遞迴 DNS 快取；
特定線路是否設定了不同記錄；
是否存在區域性的 DNS 異常。

這種情況下，多節點結果的價值就體現出來了。

3. 看 TTL

TTL 是判斷 DNS 生效時間時非常關鍵的一個參數。

例如：

TTL = 600

600 秒就是 10 分鐘。

簡單理解，遞迴 DNS 拿到這條記錄後，可以在 TTL 有效期內繼續使用快取，而不需要每次存取都重新查詢權威 DNS。

所以 TTL 越短，一般越有利於快速切換解析；TTL 越長，快取保持的時間也越長。

但這裡有一個經常被忽略的問題：

現在把 TTL 調低，並不會讓之前已經快取的舊記錄立即失效。

例如原來的 TTL 是：

3600 秒

某個遞迴 DNS 剛剛快取了舊 IP。

這時候你把 TTL 改成：

300 秒

之前那份舊快取仍然可能按照原來的 TTL 繼續存在，直到它自己過期。

所以準備遷移伺服器或切換 CDN 時，比較穩妥的做法是提前降低 TTL，而不是等切換當天才調整。

4. 看 CNAME 鏈路是否正確

CDN 使用者尤其應該關注這一項。

例如預期配置應該是：

www.example.com
        ↓
new-cdn.example.net

但查詢仍然顯示：

www.example.com
        ↓
old-cdn.example.net

這種情況顯然說明 CDN 切換還沒有完全反映到當前查詢節點。如果 CNAME 已經正確，就可以繼續向下檢查最終返回 IP，再結合 Ping、HTTP 或網站測速判斷實際節點是否工作正常。

5. 看有沒有 NXDOMAIN、SERVFAIL 或逾時

DNS 查詢並不是只有「有 IP」和「沒 IP」兩種結果。

比較常見的異常還包括：

查詢狀態	一般代表什麼
NXDOMAIN	當前 DNS 判斷該網域不存在
SERVFAIL	DNS 伺服器未能正常完成查詢
Timeout	查詢過程逾時
No Answer	網域存在，但沒有查詢類型對應的記錄

比如查詢 A 記錄返回 No Answer，不一定說明網域不存在，也有可能這個網域只有 CNAME 或 AAAA。遇到異常狀態時，不要只看紅色提示，還要結合查詢的記錄類型和網域配置一起判斷。

五、修改 DNS 後，怎麼判斷解析有沒有完全生效？

實際遷移網站時，可以按照下面這個順序排查。

第一步：確認權威 DNS 已經返回新記錄

如果權威 DNS 自己仍然返回舊 IP，那麼問題顯然不在快取，而是在解析配置本身。

這時候應該先回到 DNS 管理後台檢查：

主機記錄有沒有填錯；
A 或 CNAME 是否修改成功；
是否存在重複記錄；
是否修改了錯誤的網域；
NS 是否仍然指向當前 DNS 服務商。

第二步：查詢不同地區的解析結果

權威 DNS 正確之後，再看不同地區。重點觀察：新 IP 佔比；是否仍然存在舊 IP；異常是否集中在某個電信商；國內和海外結果是否存在明顯差異。

第三步：對比 TTL

如果只有少數節點還在使用舊記錄，並且修改時間還沒有超過此前設置的 TTL，可以先觀察一段時間；如果已經明顯超過 TTL，大量地區依然沒有更新，就需要繼續排查 DNS 服務商、遞迴 DNS 或配置問題。

第四步：檢查網站本身

當所有地區 DNS 都已經解析正確之後，DNS 排查實際上就應該暫時結束。如果網站仍然打不開，下一步就應該去看：TCP 是否能連接；80 / 443 埠是否開放；SSL 憑證是否正確；HTTP 狀態碼是否正常；CDN 是否能夠正常回源。

一個比較實用的排查路徑是：

修改 DNS
    ↓
檢查權威 DNS
    ↓
是否返回新記錄？
    ↓
   是
    ↓
多地區 DNS 查詢
    ↓
解析是否基本一致？
    ↓
   是
    ↓
檢查 Ping / TCP / HTTP / SSL

這樣不會在 DNS 已經正常的情況下繼續浪費時間反覆查解析。

六、線上 DNS 查詢可以排查哪些實際問題？

DNS 查詢最適合用於「先確定問題是不是出在解析層」。下面幾個場景在實際維運中都很常見。

1. 換伺服器以後，部分使用者還存取舊網站

這是最典型的 DNS 快取問題：可以先查詢 A 記錄，看看不同地區返回的是新 IP 還是舊 IP。如果絕大多數地區已經切換，少數仍然保留舊位址，通常可以結合 TTL 判斷是否仍處於正常快取週期。伺服器遷移時，舊伺服器不要在 DNS 修改完成後立刻關掉，保留一段過渡時間，可以避免仍然拿到舊解析的使用者直接存取失敗。

2. 接入 CDN 後，部分地區沒有走 CDN

這時候首先檢查 CNAME。

確認：

業務網域
↓
CDN CNAME
↓
CDN 邊緣節點

整個解析鏈路是不是正確。

DNS 正常後，再結合 Ping 或網站測速結果查看不同地區實際存取的節點。

CDN 場景下不同地區返回不同 IP 本身並不奇怪。北京、廣州、新加坡甚至美國使用者都可能被調度到不同邊緣節點，這通常正是 CDN 的正常工作方式。

3. IPv4 正常，但部分使用者打不開網站

這種問題要特別注意 AAAA。如果網站存在錯誤的 IPv6 解析，一些支援 IPv6 的使用者可能優先嘗試 IPv6，結果連接到錯誤位址，而 IPv4 使用者卻完全正常。排查「只有部分網路打不開」時，不要只查 A，還應該順手看看 AAAA。

4. 企業信箱突然無法收信

信箱問題除了伺服器本身，也經常和 DNS 有關。

可以依次檢查：

MX
TXT / SPF
DKIM
DMARC

特別是在企業信箱遷移、網域更換 DNS 服務商或者修改 MX 之後，如果舊記錄沒有完全更新，就可能出現部分郵件仍然投遞到舊伺服器的情況。

5. SSL 憑證申請或自動驗證失敗

部分 SSL 憑證驗證會依賴 DNS。

這時候可以檢查：TXT 是否正確；CNAME 驗證記錄是否存在；CAA 是否允許對應 CA 簽發憑證。

如果主控台裡明明已經加入了驗證記錄，但憑證平台一直提示找不到，可以先透過線上 DNS 查詢確認記錄是否真正對外可見。

七、線上 DNS 查詢和 nslookup、dig 有什麼區別？

線上工具和命令列工具並不存在誰一定比誰更專業的問題，它們適合的情境不同。

查詢方式	特點	更適合什麼情況
線上 DNS 查詢	無需安裝，可直接查看多地區結果	站長、SEO、日常維運
nslookup	使用簡單，多數系統可用	本機快速查詢
dig	資訊詳細，可指定 DNS 和 Trace	網路維運、深入排查
多節點 DNS 查詢	能觀察不同地區和電信商差異	CDN、全國業務、解析生效檢測

例如在本機執行：

nslookup www.example.com

看到的主要是：你當前網路環境透過當前 DNS 伺服器拿到了什麼結果。而多節點線上 DNS 查詢更關注：不同地區使用者現在分別能拿到什麼結果。這兩者並不衝突。實際排查時經常是先用線上工具看整體情況，再透過 dig 或 nslookup 對具體異常繼續深挖。

八、網站 DNS 出現異常的正確排查順序

如果平時不經常處理 DNS 問題，可以直接記住下面這套順序：

① 查詢 A / AAAA / CNAME
        ↓
② 確認權威 DNS 是否正確
        ↓
③ 查看國內不同地區和電信商
        ↓
④ 有海外業務再看全球節點
        ↓
⑤ 對比新舊 IP 和 TTL
        ↓
⑥ DNS 正常後繼續檢查 Ping / TCP / HTTP / SSL

第一、第二步就發現異常，優先檢查 DNS 配置：如果權威 DNS 正常，但只有少部分地區沒有更新，重點關注 TTL 和遞迴 DNS 快取；如果全國甚至全球大部分節點的解析都已經正確，而網站依然無法存取，就應該及時把排查方向轉向伺服器、CDN、網路連線或者 HTTP 服務。這樣能夠快速確定問題在哪一層，而不是在伺服器、CDN 和 DNS 之間來回猜。

網域解析本質上是一場全球節點同步資訊的接力賽，理清它的生效邏輯後，很多看似無解的存取異常其實都有跡可循。不管是剛上線的專案還是日常的維運巡檢，養成「先查解析、再測連通性、最後看業務」的習慣，能讓你在處理故障時從容很多。建議把 Chahu 多節點查詢工具存進書籤，遇到解析不確定或者跨區存取慢的時候抽空查一下，往往能幫你避開不少隱性的網路坑。