網站 DNS 解析速度怎麼測試？DNS 回應時間檢測與排查方法

網站 DNS 解析速度會直接影響使用者第一次造訪的體驗。本文介紹 DNS 回應時間的測試方法，包括線上多節點檢測、nslookup 與 dig，並結合不同地區、電信業者及解析結果，分析 DNS 延遲、逾時和 CNAME 鏈路等常見問題，幫助站長快速判斷 DNS 是否成為網站存取速度的瓶頸。

2026-09-205 分鐘閱讀

網站打開慢的時候，很多人第一反應是檢查伺服器，看看 CPU、頻寬或 CDN 有沒有問題。但實際存取一個網站時，瀏覽器並不是一開始就直接連線伺服器，而是要先完成 DNS 解析，把網域名稱轉換成對應的 IP 位址。如果這一步只花了十幾毫秒，通常很難被使用者察覺；但如果 DNS 查詢需要一、兩百毫秒，甚至偶爾出現逾時，即使伺服器本身回應很快，使用者第一次打開網站時仍然可能明顯感覺變慢。

更麻煩的是，DNS 解析慢不一定每個地方都慢。同一個網域，北京電信可能幾十毫秒就能回傳結果，換到廣州移動或某些海外網路後，解析時間卻明顯增加。所以排查網站 DNS 速度時，不能只在自己電腦上執行一次查詢，更值得關注的是：解析花了多久、不同地區是否存在明顯差異，以及有沒有某些電信業者持續出現異常。

一、什麼是網站 DNS 解析速度測試？

使用者在瀏覽器輸入一個網站位址，例如：

www.example.com

瀏覽器需要先知道這個網域對應哪台伺服器，之後才能繼續建立連線。簡化的網站存取流程大致是：

輸入網域
↓
DNS 查詢
↓
取得伺服器 IP
↓
建立 TCP 連線
↓
TLS 握手
↓
送出 HTTP 請求
↓
伺服器回傳頁面

這裡所說的 DNS 解析速度，主要是從發起 DNS 查詢，到取得可用解析結果之間所消耗的時間。

例如一次網站測速得到：

DNS：18 ms
TCP：32 ms
TLS：45 ms
TTFB：96 ms

這裡的 18 ms 就是 DNS 階段消耗的時間。要注意，DNS 解析時間和伺服器回應時間並不是同一個指標。

DNS 發生在瀏覽器真正連線伺服器之前，而 TTFB 主要反映請求送出之後，到伺服器開始回傳第一個位元組所花費的時間。如果 DNS 很慢，單純升級伺服器配置通常沒有太大作用；反之，如果 DNS 只有十幾毫秒，而 TTFB 達到幾百毫秒，排查重點就應該轉向伺服器、資料庫、CDN 回源或應用程式。

二、網站 DNS 解析速度怎麼測試？

實際排查時，我通常不會只用一種方法。Chahu 線上多節點工具比較適合先看地區差異，nslookup 適合快速確認解析結果，而 dig 更適合進一步觀察查詢時間和 DNS 伺服器。

1. 使用 Chahu 線上 DNS 測速工具

如果不想用命令列，最方便的方法就是直接使用線上 DNS 查詢或 DNS 測速工具。

直接打開 Chahu 的 DNS 檢測：

https://www.chahu.com/dns

輸入要測試的網域後，可以查看目前 DNS 解析情況。Chahu 本身還提供 DNS 測速，以及不同電信業者網路環境下的檢測能力，更適合排查「自己這裡正常，但部分地區使用者回報異常」這類問題。

例如一個網站測試後出現：

北京電信 18 ms
上海聯通 24 ms
浙江電信 21 ms
廣州移動 96 ms
深圳移動 112 ms

這種結果就比單純看到一個「平均 38ms」有價值。

因為從整體平均值來看似乎不算特別慢，但廣州和深圳移動節點明顯高於其他地區，那麼排查重點就可以進一步縮小到特定電信業者線路、遞迴 DNS 或權威 DNS 網路覆蓋。

如果 DNS 檢測正常，但網站還是存取慢，也可以繼續結合 Ping、網站測速或 TCPing 查看後面的網路鏈路。這樣就能把問題區分成：

DNS 解析慢
網路連線慢
伺服器回應慢
頁面資源載入慢

而不是只看到「網站慢」三個字。

2. 使用 nslookup 檢查 DNS

Windows 使用者可以直接打開 CMD 或 PowerShell：

nslookup example.com

正常情況下會回傳網域對應的 IP 位址。

如果想指定 DNS 伺服器，也可以這樣測試：

nslookup example.com 8.8.8.8

然後換另一個 DNS：

nslookup example.com 1.1.1.1

還可以根據實際使用環境測試其他公共 DNS。

這種方法比較適合判斷不同 DNS Resolver 回傳的結果是否一致。

例如：

DNS A → 203.0.113.10
DNS B → 203.0.113.10
DNS C → 203.0.113.80

如果網站剛修改過解析，而不同 DNS 回傳了不同 IP，很可能和 DNS 快取、TTL 或解析同步有關。

不過，nslookup 更適合檢查「解析到了哪裡」，如果主要目的是觀察精確的 DNS Query Time，dig 通常會更直觀。

3. 使用 dig 查看 DNS 查詢時間

Linux 和 macOS 環境下可以直接使用：

dig example.com

回傳結果中重點看：

;; Query time: 23 msec

這裡的 23 msec 就表示這一次 DNS 查詢大約花了 23 毫秒。

如果想分別測試不同 DNS，可以使用：

dig @8.8.8.8 example.com

以及：

dig @1.1.1.1 example.com

假設得到：

DNS A：18 ms
DNS B：25 ms
DNS C：126 ms

那麼至少可以確認，解析速度差異並不是網站伺服器造成的，而是和目前使用的 DNS Resolver、網路線路或上游 DNS 查詢過程有關。

要注意的是，單次結果仍然不能代表長期表現。DNS 本身存在快取，同一個網域第一次查詢和後續查詢的耗時可能不完全一樣，所以最好多測試幾次再判斷。

三、DNS 解析速度多少算正常？

DNS 並沒有適用於所有網站的絕對標準，因為解析速度會受到使用者地區、電信業者、本地遞迴 DNS、快取狀態以及權威 DNS 節點位置等因素影響。如果只是做日常網站效能排查，可以大致參考下面這個範圍：

DNS 解析時間	大致情況	排查建議
20 ms 以內	很快	一般無需處理
20～50 ms	正常	多數網站可以接受
50～100 ms	略慢	建議觀察地區差異
100～200 ms	明顯偏慢	檢查 DNS 節點與線路
200 ms 以上	較慢	可能影響首次存取體驗
Timeout / SERVFAIL	異常	優先排查 DNS 服務與配置

這張表更適合當作排查參考，而不是硬性標準。比如一個主要服務北美使用者的網站，在亞洲測試 DNS 得到 80ms，並不能直接說明 DNS 有問題；但如果它主要面向國內使用者，北京、上海、廣州多個網路都長期超過 150ms，就值得繼續檢查。實際維運中，比單純追求「最低 DNS 延遲」更重要的是穩定性和地區一致性。平均 20ms，但每隔一段時間就出現一次 800ms 或逾時，不一定比長期穩定在 35ms 的 DNS 更好。

四、網站 DNS 解析慢的原因有哪些？

DNS 解析速度異常，通常不是網站程式本身造成的。遇到這種情況，可以先從 DNS 網路和配置本身開始排查。

1. DNS 節點距離使用者較遠

如果權威 DNS 的網路覆蓋和網站主要使用者分布差異很大，查詢就可能需要經過更長的網路路徑。

例如網站使用者主要集中在亞洲，而 DNS 服務在亞洲缺少足夠好的節點或網路互聯，最終表現出來的就是部分地區 DNS Query Time 偏高。

2. 不同電信業者之間有明顯差異

這種情況在多電信業者網路環境中比較常見。

例如：

中國電信：22 ms
中國聯通：31 ms
中國移動：118 ms

如果重複測試後一直是類似結果，就說明不能簡單歸結為「DNS 整體慢」，更可能是某個電信業者到 DNS 節點之間的線路、調度或遞迴查詢出了問題。

這也是為什麼網站 DNS 測速最好不要只測一個節點。

3. DNS 快取沒有命中

DNS 查詢並不是每一次都會完整地從頭開始。

如果本地或遞迴 DNS 已經快取了結果，查詢通常會比較快；如果快取沒有命中，則可能需要繼續向上查詢權威 DNS，整個過程自然會更長。

因此，同一個網域連續測試幾次時，出現一定的耗時差異並不奇怪。

4. CNAME 鏈路過長

接入 CDN、雲端服務或第三方平台以後，有些網域會出現多層 CNAME。

例如：

www.example.com
↓
CNAME
↓
cdn.example.net
↓
CNAME
↓
edge.example.net
↓
A / AAAA

CNAME 並不是不能使用，CDN 場景下它本來就很常見。

真正需要注意的是，不必要的 CNAME 層級不要堆得太多。每增加一層，都可能讓 DNS 查詢過程變得更複雜。

5. DNS 服務偶發逾時

有些問題平均數據很難看出來。

例如測試十次：

18 ms
21 ms
19 ms
23 ms
Timeout
20 ms
18 ms
450 ms
22 ms
19 ms

如果最後只計算平均值，問題可能並不明顯，但真實使用者已經遇到了兩次異常。

這種情況下應該關注 P95、P99，或至少觀察多次測試結果，而不是只盯著一次最快值。

6. A 與 AAAA 解析存在異常

現在不少網站同時配置 IPv4 的 A 記錄和 IPv6 的 AAAA 記錄。如果其中一條 DNS 解析或後續 IPv6 網路存在問題，部分終端存取時也可能出現等待、回退或連線速度異常。

所以網站開啟 IPv6 後突然出現部分使用者首次存取變慢，也可以把 A、AAAA 以及 IPv4/IPv6 實際鏈路分別測一下。

五、怎麼判斷到底是不是 DNS 導致網站慢？

這是排查網站速度時比較關鍵的一步。很多人看到網站載入用了兩三秒，就直接認為伺服器慢，但真正有價值的是把整個存取過程拆開。

例如：

DNS 185 ms
TCP 32 ms
TLS 41 ms
TTFB 88 ms
Download 126 ms

這種情況非常明顯。

伺服器開始回應只用了 88ms，TCP 和 TLS 也沒有明顯異常，反而 DNS 單獨占用了 185ms。那麼繼續優化 PHP、資料庫或伺服器 CPU，很可能不會明顯改善首次存取速度。

真正應該優先處理的是 DNS。

再看另外一種情況：

DNS 17 ms
TCP 29 ms
TLS 43 ms
TTFB 680 ms
Download 115 ms

這裡 DNS 已經很快了，真正拖慢網站的是 TTFB。

這種情況下繼續換 DNS 服務商意義就不大，需要進一步檢查伺服器處理時間、動態頁面、資料庫查詢或 CDN 回源。

還有一種：

DNS 20 ms
TCP 260 ms
TLS 310 ms
TTFB 390 ms

這種情況下 DNS 也不是主要矛盾，更值得排查伺服器距離、跨境線路、CDN 調度或 TCP/TLS 網路連線。

所以網站測速最好不要只得到一個：

總載入時間：1.8 秒

而是儘量把鏈路拆開看：

DNS → TCP → TLS → TTFB → Download

只有知道時間究竟花在哪一步，優化才有方向。

六、DNS 解析慢以後怎麼優化？

如果已經確認問題集中在 DNS 階段，第一步不是馬上換伺服器，而是重新檢查目前 DNS 架構是否適合網站使用者分布。

對於國內使用者較多的網站，可以重點觀察電信、聯通、移動之間是否存在持續差異；如果是全球業務，則需要查看亞洲、歐洲、北美等主要使用者區域的 DNS 延遲是否均衡。

DNS 服務本身的全球網路覆蓋也是一個重要因素。一個 DNS 在某個地區表現很好，並不代表所有地區都一樣，所以選擇時更應該結合實際使用者位置，而不是只看某個測試點的最低延遲。

另外還要檢查 CNAME 鏈路。

如果已經變成：

業務網域
↓
CNAME A
↓
CNAME B
↓
CNAME C
↓
最終 IP

就有必要確認這些跳轉是不是都有實際用途。

TTL 也需要合理設定：TTL 太短會增加 DNS 查詢頻率和權威 DNS 壓力，但 TTL 太長以後，一旦更換伺服器、修改 CDN 或調整解析記錄，舊快取又可能長時間存在。

因此不存在「TTL 越低越好」或「TTL 越高越快」這種簡單結論，更合理的做法是根據網站變更頻率和業務穩定性設定。

最後，DNS 優化完成以後最好重新進行多節點測試，而不是只在自己的電腦清理一次快取後重新整理瀏覽器。真正需要驗證的是不同地區使用者拿到的解析結果和查詢時間有沒有一起恢復正常。

七、DNS 查詢和 DNS 速度測試有什麼區別？

這兩個概念很容易被混在一起，但實際解決的問題並不一樣。

一般 DNS 查詢更關注：

網域解析到了哪個 IP？
A 記錄是否正確？
AAAA 是否存在？
CNAME 指向哪裡？
TTL 是多少？

例如網站剛更換伺服器，最重要的問題可能只是：

example.com

現在究竟還指向舊伺服器，還是已經解析到新伺服器，這屬於 DNS 查詢。

而 DNS 速度測試更關注的是：

解析花了多長時間？
不同地區差多少？
不同電信業者有沒有異常？
是否出現逾時？
DNS 有沒有拖慢網站存取？

所以，如果只是想確認 CDN 的 CNAME 有沒有配置正確，可以做 DNS 查詢；如果使用者回報「第一次打開網站特別慢」，就應該進一步觀察 DNS 回應時間。這兩種檢測並不衝突，只是解決的問題不同。

結語

網站 DNS 解析速度並不是越低越值得單獨追求，真正需要關注的是解析是否穩定，以及不同地區、不同電信業者之間有沒有明顯差異。如果 DNS 查詢只有二、三十毫秒，但網站還是打開很慢，就應該繼續檢查 TCP 連線、TLS 握手、TTFB 和頁面資源；如果 DNS 本身已經達到一、兩百毫秒，甚至部分地區開始出現逾時，那麼再怎麼調整伺服器參數，也解決不了使用者真正連線網站之前的這段等待時間。

實際排查時，可以先透過 Chahu 線上多節點 DNS 檢測觀察不同地區的解析情況，再使用 nslookup 或 dig 進一步驗證 DNS 回傳結果和查詢時間。確認 DNS 沒有異常後，再繼續往 TCP、TLS、TTFB 和頁面載入階段排查。把整條存取鏈路拆開來看，往往比單獨盯著一個「網站載入用了幾秒」，更容易找到真正拖慢網站的地方。