您更新了一條 A 記錄。您的新伺服器正在執行。您導航到您的域，但仍然看到舊網站。或者其他國家/地區的某人可以看到新網站，但您卻看不到。或者這兩種情況對於不同的使用者同時發生。

這是 DNS 傳播。這不是錯誤，也不是您的註冊商速度慢。這就是正在發生的事情以及如何管理它。

什麼是 DNS 傳播？

DNS（域名系統）是一個全球分佈的資料庫，將域名對映到 IP 地址。它不是一個單一的伺服器——它是一個由數千個解析器組成的層次結構，每個解析器都會快取一段時間的答案。

當您更新 DNS 記錄時，您正在更改您的 DNS 記錄上的資料 權威域名伺服器 — 您的註冊商或 DNS 提供商控制的。但網際網路的其餘部分不會直接查詢您的權威伺服器。他們問他們的 本地遞迴解析器 （通常由其 ISP 或公共 DNS 服務執行，例如 1.1.1.1 或 8.8.8.8），它有自己的記錄快取副本。

傳播是快取副本過期並被新記錄替換的過程。

完整的 DNS 解析器鏈

理解 為什麼 傳播需要時間，需要了解 DNS 查詢的實際工作原理：

DNS 解析器鏈圖顯示查詢如何從裝置透過 ISP 解析器、根伺服器、TLD 伺服器傳輸到權威域名伺服器
完整的 DNS 查詢鏈。步驟 2-4 通常會被跳過，因為遞迴解析器已經快取了答案 - 這正是傳播需要時間的原因。

步驟 1 — 您的瀏覽器檢查其本地快取。 現代瀏覽器獨立於作業系統快取 DNS 結果。 Chrome 快取 60 秒； Firefox 最多可達 TTL 值。 chrome://net-internals/#dns 顯示Chrome當前的快取。

步驟 2 — 您的作業系統存根解析器檢查其快取。 Windows、macOS 和 Linux 都維護本地 DNS 快取（用 ipconfig /flushdns, dscacheutil -flushcache, 或 resolvectl flush-caches ）。

步驟 3 — 查詢您的遞迴解析器。 這通常是您的 ISP 的解析器， 1.1.1.1, 8.8.8.8，或企業 DNS 伺服器。它有自己的快取，與您的快取分開，並在所有使用者之間共享。如果 10,000 人使用同一個 ISP 解析器，則一個快取的答案可以為所有人提供服務。

步驟 4 — 遞迴解析器遍歷層次結構 （如果其快取為空）。它向根域名伺服器請求 TLD，向 TLD 伺服器請求權威域名伺服器，然後向權威伺服器請求您的記錄。它會使用您指定的 TTL 快取答案。

傳播很慢，因為： 步驟 4 僅在解析器的快取過期時執行。在那之前，它會提供舊的快取答案 - 無論您在權威伺服器上更改了什麼。

TTL：控制一切的數字

TTL（生存時間）是您在每個 DNS 記錄上設定的值，以秒為單位。它告訴解析器在重新查詢權威伺服器之前將您的記錄快取多長時間。

常用TTL值：

TTL 秒 典型用途
1分鐘 60 主動遷移、測試
5分鐘 300 預遷移（設定24小時前）
15分鐘 900 經常更改的記錄
1小時 3600 大多數記錄的標準
4小時 14400 穩定記錄
24小時 86400 許多提供商的預設值
48小時 172800 名稱伺服器 (NS) 記錄

您設定的TTL決定了 最大 傳播視窗。但有一個問題。

圖表顯示 DNS 傳播時間與 TTL 值以及最佳、典型和最壞情況的情況
最好的情況反映了完全尊重 TTL 的解析器。最壞的情況：一些 ISP 解析器快取遠遠超出宣告的 TTL，特別是對於短 TTL，將 5 分鐘以下的任何內容視為“5 分鐘”以減少負載。

關於 TTL 的骯髒秘密： 許多 ISP 忽略低 TTL 值。為數百萬使用者提供服務的解析器無法承受每 60 秒重新查詢一次高流量域的費用。無論您宣告什麼，有些都會強制執行 5 分鐘的最短快取時間。這意味著對於部分解析器來說，非常低的 TTL（60-300 秒）在實踐中更像是 5 分鐘的 TTL。

24 小時 TTL 意味著某些使用者可能會在您進行更改後的整整 24 小時內看到您的舊記錄 - 即使您在上一次 TTL 到期後立即進行了更改。

DNS 傳播實際需要多長時間？

甘特式時間線圖顯示 DNS 記錄更改後 DNS 傳播到世界不同區域
1 小時 TTL 記錄的區域傳播時間線。 Local resolvers update fastest; outlier ISPs that ignore TTL can lag by hours.這解釋了為什麼有些使用者看到您的新網站，而另一些使用者看到舊網站。

對於標準 1 小時 TTL，您可以期待以下結果：

  • 您的本地裝置： 重新整理快取後幾乎立即完成
  • 同城解析器： 5–30 分鐘（解析器在快取過期時進行權威查詢）
  • 主要公共 DNS（8.8.8.8、1.1.1.1）： 通常 10–60 分鐘
  • 全球傳播： 1–4 小時
  • 速度慢/異常的 ISP： 長達 8-12 小時

你隨處可見的“長達 48 小時”的數字在技術上是可行的，但對於具有正常 TTL 的 A 和 CNAME 記錄來說越來越罕見。對於 NS（名稱伺服器）記錄更改來說更準確，NS（名稱伺服器）記錄更改具有更長的固有 TTL，並透過根/TLD 層傳播。

為什麼具體是48小時？ NS 記錄的 TTL 通常由登錄檔（而不是您）設定，通常為 24-48 小時。當您在註冊商處更改域名伺服器時，您將等待 TLD 序號產生器構更新，並且該更新會透過全球根伺服器傳播。此路徑比固定名稱伺服器內的簡單記錄更改需要更長的時間。

專業方法：預先降低 TTL

人們在 DNS 遷移中犯的最大錯誤：更改記錄而不首先降低 TTL。

計劃遷移的正確流程：

  1. 遷移前48小時： 將您計劃更改的所有記錄的 TTL 降低至 300 秒（5 分鐘）
  2. 等待完整的當前 TTL （給解析器時間來獲取新的短 TTL）
  3. 更改您的記錄 — 傳播現在最多需要 5 分鐘而不是 24 小時
  4. 遷移穩定後： 將 TTL 提高到 3600 或更高

這是 5 分鐘傳播視窗和 24 小時傳播視窗之間的差異。每個 DNS 專業人員都會這樣做。大多數初學者都是透過艱難的方式學習的。

如何立即檢查 DNS 傳播

最快的方法：使用我們的 DNS 傳播檢查器 — 它同時從多個地理位置查詢您的域，並顯示每個區域是否返回您的舊記錄或新記錄。

您要找的是：

  • 綠色/匹配IP： 這些地區看到您的新記錄
  • 舊IP仍然顯示： 這些解析器的快取尚未過期
  • 混合結果： 傳播過程中正常 — 有些區域看到新的，有些區域看到舊的

透過命令列檢查 如果你想直接驗證權威答案（繞過任何快取）：

命令 
# Query a specific DNS server directly (bypasses your local cache)
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

# On Linux/macOS — dig gives more detail
dig example.com @8.8.8.8
dig example.com @1.1.1.1

# Check the TTL of your current record
dig example.com | grep -i ttl

# Query the authoritative nameserver directly (no cache)
dig example.com @ns1.yourprovider.com

如果 dig @ns1.yourprovider.com 顯示您的新記錄，但是 dig @8.8.8.8 仍然顯示舊的，您的更改是正確的 - 您只是在等待遞迴解析器的快取過期。

重新整理本地 DNS 快取 停止在您自己的計算機上看到過時的資料：

命令 
# Windows
ipconfig /flushdns

# macOS (Sequoia / Sonoma)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Chrome browser cache only
# Navigate to: chrome://net-internals/#dns → click "Clear host cache"

注意：如果您的 ISP 解析器仍然快取了舊答案，則重新整理本地快取並沒有幫助。您的裝置只會重新查詢 ISP 的解析器並再次獲得過時的答案。

常見 DNS 傳播場景

場景一：網站遷移到新伺服器

您將從舊主機→新主機。舊A記錄： 203.0.113.10。新： 198.51.100.20.

傳播過程中會發生什麼： 擁有快取舊記錄的使用者登陸舊伺服器。解析器已重新整理的使用者會看到新伺服器。兩臺伺服器都需要執行並提供相同的內容，直到傳播完成。如果過早關閉舊伺服器，快取陳舊的使用者會收到錯誤。

緩解措施： 更改後，使舊伺服器保持至少一個完整的 TTL 活動狀態。如果原始 TTL 為 24 小時，請在更改後保持舊伺服器 24 小時執行。

場景 2：電子郵件提供商遷移（MX 記錄）

MX 記錄更改會影響入站電子郵件的遞送位置。傳播期間傳送的電子郵件可能會落在舊郵件伺服器或新郵件伺服器上，具體取決於傳送伺服器解析的 MX 記錄。

風險： 電子郵件在您停止監控舊伺服器後傳送到舊伺服器。 修復： 配置舊郵件伺服器在遷移後一週內轉發到新郵件伺服器，或在 TTL 視窗期間保持舊郵箱可訪問。

場景3：CDN或負載均衡器割接（CNAME更改）

指向 CDN 或負載均衡器的 CNAME 記錄通常比 A 記錄傳播得更快 — CNAME 本身會快取，但 CDN 返回的底層 IP 可以快速更改，而不會影響記錄的傳播。

注意： CNAME 扁平化。某些 DNS 提供商會在區域頂端“扁平化”CNAME 記錄（將 CNAME 替換為其解析為的 A 記錄）。如果提供商快取了扁平化 IP，則可能會在遷移期間導致意外行為。

場景 4：名稱伺服器（NS 記錄）更改

最慢的傳播型別。 Nameserver records are stored at the TLD registry level (.com, .net等），TTL 由登錄檔設定，通常為 24-48 小時。您無法控制此 TTL。

當您在註冊商處更改域名伺服器時：

  1. 您的註冊商通知 TLD 註冊管理機構
  2. Registry updates the delegation
  3. 註冊管理機構的更新在全球根名稱伺服器上傳播

預計完全傳播需要 12-48 小時。沒有任何 TTL 預降低技巧可以提供幫助。

故障排除清單

✅ 如果您的 DNS 更改沒有傳播

1. 確認新記錄在<strong>權威伺服器</strong>上正確無誤：<code>dig example.com @ns1.yourprovider.com</code><br> 2. 檢查多個公共解析器看到的內容：<a href="/dns-propagation.php">DNS 傳播工具 →</a><br> 3. 重新整理本地快取（上面的命令） - 您可能只是看到自己的舊記錄快取<br> 4. 檢查您的 TTL：<code>dig example.com | grep TTL</code> — 如果是 86400，您將等待 24 小時<br> 5. 如果權威顯示正確，但解析器不正確：等待 TTL 到期 — 無其他可做<br> 6. 如果權威顯示錯誤記錄：您在錯誤的提供商處進行了更改，或者尚未儲存

DNS 傳播與 DNS 複製：區別

這些經常被混淆。它們相關但又不同：

DNS 傳播 = 等待遞迴解析器快取過期並重新查詢。這是您作為使用者所經歷的延遲。你不能強迫它。只能透過預先降低TTL來減少它。

DNS 複製 = 在同一區域的多個權威名稱伺服器之間同步（例如， ns1.provider.com 和 ns2.provider.com）。大多數 DNS 提供商會在幾秒鐘內完成複製。如果您進行了更改，但在 5 分鐘內未在提供商自己的名稱伺服器上顯示，則這是提供商方面的問題 - 請聯絡支援人員。

工具