DNS 記錄改完後，你仍看到舊 IP，通常不是「設定沒有儲存」，而是某個遞迴 DNS 還在使用先前快取的答案。TTL 決定一筆 DNS 答案可以被快取多久；它不是按下儲存後，全世界一起倒數的計時器。
因此，搬站時最有效的方法不是改完才把 TTL 調低，而是提前降低 TTL，等待原本較長的 TTL 過去，再切換 IP。
你會學到什麼
- 分清楚 TTL、DNS 快取與俗稱的「DNS 傳播」。
- 理解為什麼不同網路會同時看到新舊 IP。
- 知道降低 TTL 為什麼必須在正式變更前做。
- 正確理解 Cloudflare Proxied 與 DNS only 的 300 秒。
- 用 Windows、Linux 與 macOS 比對不同 Resolver。
- 辨認舊記錄快取與 NXDOMAIN 負快取的差異。
開始前先確認
- 你知道 DNS 由哪個平台管理，以及目前的 NameServer。
- 你知道要修改的是 A、AAAA、CNAME、MX 或其他哪一筆記錄。
- 你已記錄舊值、新值與目前 TTL。
- 網站搬家時，新主機已完成測試，舊主機會保留一段交接時間。
- Email DNS 變更要另外盤點 MX、SPF、DKIM、DMARC，不要只看網站 IP。
還不熟悉記錄類型時，先看DNS 基礎觀念解析。
TTL 是什麼
TTL 是 Time To Live，以秒為單位。DNS 基礎規範 RFC 1034將它定義為 Resource Record 可以留在快取中的時間上限。
例如：
| TTL | 換算 | 代表意思 |
|---|---|---|
300 | 5 分鐘 | Resolver 最多可在這段期間重用答案 |
1800 | 30 分鐘 | 半小時後需要重新向上游查詢 |
3600 | 1 小時 | 最多快取一小時 |
86400 | 24 小時 | 最多快取一天 |
TTL 較短，變更後通常能較快讓新的查詢取得新值，但 Resolver 需要更常重新查詢。TTL 較長，可增加快取命中並減少查詢，但計畫變更時要預留更長交接時間。
「DNS 傳播」其實是各地快取陸續過期
大家常說「DNS 正在傳播」，聽起來像新資料正在一台一台推送到全世界。更精確的理解是：
- 你在 DNS 管理平台修改記錄。
- 權威 DNS 開始回答新值；平台完成更新的速度由供應商決定。
- 之前查過這筆記錄的遞迴 Resolver，仍可能保留舊答案。
- 每台 Resolver 在自己的舊 TTL 到期後，才重新查詢權威 DNS。
- 不同使用者使用不同 Resolver，也在不同時間查過，所以會陸續切換。
這就是為什麼：
- 你用手機網路看到新站，公司網路仍看到舊站。
- 同事正常，你的電腦卻還不正常。
- 用
1.1.1.1和8.8.8.8查到不同結果。 - 權威 DNS 已是新 IP，遞迴 DNS 仍回舊 IP。
想看完整查詢路徑，可閱讀DNS 解析完整流程圖解。
為什麼改完才降 TTL 通常太晚
假設原本記錄是：
example.com A 192.0.2.10 TTL 3600
時間軸如下：
| 時間 | 你做的事 | 某台 Resolver 的狀態 |
|---|---|---|
| 12:00 | 尚未變更 | 查到舊 IP，依 TTL 3600 快取到約 13:00 |
| 12:10 | 把 TTL 改成 300 | 先前快取仍保有舊的 3600 秒期限 |
| 12:20 | 把 IP 改成新值 | 權威 DNS 回新 IP，但該 Resolver 仍可回舊 IP |
| 約 13:00 | 舊快取到期 | Resolver 重新查詢，才看到新 IP 與 TTL 300 |
重點是：你把權威記錄的 TTL 改小，不能遠端召回已經存在其他 Resolver 裡的舊答案。 Cloudflare 的 DNS FAQ也提醒，舊資料可能依先前記錄的 TTL 留在快取中；如果預期會變更，應事先降低 TTL。
搬站前正確降低 TTL 的步驟
步驟一：記錄現在的值
先保存：
- 記錄名稱。
- 類型。
- 舊 IP 或目標值。
- 目前 TTL。
- Proxy 狀態。
- 修改人與預計切換時間。
如果是正式網站，先完成網站搬家前 DNS、Email、SSL 檢查表。
步驟二：只降低要切換記錄的 TTL
假設現在 TTL 是 3600 秒，可先調整為 300 秒。不要順手修改 IP，也不要在同一時間大量重建其他記錄，否則之後很難判斷哪個變更造成問題。
步驟三：等待「原本的 TTL」完整走過
原本是 3600 秒，就至少等待一小時；原本是 86400 秒，就要預留一天。等待是讓先前取得舊 TTL 的 Resolver 有機會自然過期。
實務上還要考慮你的變更風險、Resolver 行為與使用者分布，所以不要把「等待一個 TTL」誤解成絕對零風險保證。
步驟四：切換到新 IP
新主機應先完成：
- 網站內容與資料庫測試。
- 正確的網域與 HTTPS 設定。
- 必要的防火牆與服務確認。
- 動態網站的最後資料同步計畫。
再修改 A / AAAA / CNAME。舊主機先保持可用，讓仍持有舊快取的訪客不會直接看到錯誤。
步驟五：同時查權威 DNS 與多個 Resolver
不要只用自己的瀏覽器重新整理。先確認權威 DNS 回新值，再比對公共 Resolver、公司網路與手機網路。
步驟六：穩定後再調回日常 TTL
變更完成並觀察穩定後，再把 DNS only 記錄調回適合日常營運的 TTL。沒有任何變更計畫時，不一定需要永久維持極短 TTL。
Cloudflare 的 Auto 300 秒要怎麼理解
Cloudflare 的 TTL 官方文件目前說明：
- Proxied（橘色雲朵）記錄：預設 TTL 是
Auto，值為 300 秒，而且不能手動修改。 - DNS only（灰色雲朵）記錄：
Auto同樣是 300 秒，但可依方案支援的範圍選擇其他 TTL。 - 本機 DNS 快取可能讓實際體驗超過五分鐘，因此 300 秒不是「每位使用者五分鐘內保證看到變更」。
還有三個重要差異。
Proxied 記錄查到的是 Cloudflare IP
Proxied A、AAAA 或 CNAME 對外查詢時，使用者通常看到 Cloudflare Anycast IP，不是原站 IP。當你只修改 Cloudflare 後方的 Origin IP 時，公共 DNS 查詢結果可能仍是 Cloudflare IP，不能用「dig 有沒有顯示新原站 IP」判斷後端設定。
DNS TTL 不等於 CDN Cache TTL
DNS TTL 管理 DNS 答案多久重新查詢；Browser Cache TTL、Edge Cache TTL 管理網頁、圖片或其他 HTTP 內容多久重新抓取。網站仍顯示舊頁面時，可能是 CDN 或瀏覽器內容快取，不一定是 DNS。
NameServer TTL 是另一件事
更換 NameServer 是改變哪一組權威 DNS 負責你的網域，不等於只修改一筆 A 記錄。Cloudflare 文件也將 Nameserver TTL 與一般 DNS record TTL 分開說明。換 DNS 平台前必須先完整複製 Zone，並預留較保守的交接時間。
Windows 怎麼查 DNS 與不同 Resolver
開啟「命令提示字元」或 Windows Terminal。
查 Cloudflare Public DNS：
nslookup example.com 1.1.1.1
查 Google Public DNS：
nslookup example.com 8.8.8.8
查指定類型，例如 MX：
nslookup -type=MX example.com 1.1.1.1
請把 example.com 換成你的網域。比對結果時記錄查詢時間、Resolver 與回傳 IP，不要只寫「有時正常、有時不正常」。
Linux 與 macOS 怎麼查 TTL
Linux / macOS 常用 dig：
dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
典型回答：
example.com. 247 IN A 198.51.100.20
247 是這次答案顯示的 TTL 秒數。向同一台有快取的 Resolver 再查時，數字可能逐步下降；快取到期並重新取得答案後，TTL 會從權威記錄提供的值重新計算。
先查網域使用的 NameServer：
dig example.com NS +short
再直接詢問其中一台權威 DNS：
dig @ns1.example-dns.test example.com A +noall +answer
ns1.example-dns.test 只是格式示例，必須換成上一個指令查到的真實 NameServer。若權威 DNS 已回新值、公共 Resolver 仍回舊值，通常就是在等快取；若權威 DNS 自己仍回舊值，先回 DNS 管理平台與 Zone 設定查錯。
更多查詢方式可參考whois 與 nslookup 查詢教學。
新增記錄後仍是 NXDOMAIN：可能是負快取
如果名稱先前不存在，Resolver 可能已快取「不存在」的答案，也就是 NXDOMAIN。此時你新增一筆 TTL 300 的記錄，不代表舊的不存在答案會立刻消失。
Cloudflare 的 General DNS issues 官方文件說明，負快取期限與 Zone 的 SOA 設定有關；降低新記錄 TTL 不會加速已存在的負快取到期。
常見情境：
- 你先測試
new.example.com，當時記錄不存在。 - Resolver 快取 NXDOMAIN。
- 你才新增 A 或 CNAME。
- 權威 DNS 已有記錄，但同一 Resolver 暫時仍回答不存在。
處理時應先直接查權威 DNS，再換不同 Resolver 比對。清除自己電腦的 DNS 快取只影響本機，不能清除 ISP 或公共 Resolver 已保存的答案。
常見問題
TTL 設 300，為什麼十分鐘後還是舊 IP
可能原因包括：
- 舊答案是在 TTL 降低前快取，仍依原本較長 TTL 存活。
- 你查的是本機、公司或 ISP 的不同快取層。
- 實際問題是 CDN 或瀏覽器內容快取。
- 修改了錯誤的 DNS 平台，現在的 NameServer 不使用那個 Zone。
- Proxied 記錄本來就只會顯示 Cloudflare IP。
重新開機能讓全世界更新嗎
不能。重新開機或清除本機 DNS 快取，只處理你這台裝置。上游 Resolver 的快取仍要依自己的期限與行為更新。
可以把 TTL 永久設很短嗎
可以使用平台允許的短值，但不一定有必要。穩定、不常變動的記錄可使用較長 TTL；有明確搬遷計畫時再提前降低。要兼顧變更速度、查詢量與營運風險。
所有人都看到新 IP，就能立刻關舊主機嗎
不建議只靠少數測試立刻關閉。還要確認應用程式資料同步、背景工作、Email、Webhook、API、搜尋引擎與其他外部服務是否仍連到舊環境。保留交接窗口通常更安全。
DNS 切換檢查表
- 確認目前真正的權威 NameServer。
- 保存完整 DNS 記錄與舊值。
- 提前降低要變更記錄的 TTL。
- 等待原本 TTL 完整走過。
- 新主機先用測試方式確認網站可用。
- 變更時不要誤動 MX、SPF、DKIM、DMARC。
- 直接查權威 DNS。
- 比對至少兩個公共 Resolver。
- 用公司網路與手機網路實際測試。
- 保留舊主機與回復方案。
- 穩定後再恢復日常 TTL。
如果改完仍不確定卡在哪一層，可依DNS 問題排除教學逐步查；要把網域接到虛擬主機，則看網域指向虛擬主機教學。
需要規劃網站搬家、DNS 切換與 Email 共存，可從聯絡侃瑞科技提供目前 NameServer、要修改的記錄類型、舊 TTL 與預計切換時間。我們會先把切換順序與回復點排好，再進行變更。