// 免費工具 · DNS TTL 計算

DNS TTL 計算機 · 換算工具

輸入 TTL，除了換算成幾小時幾分鐘，還會給你實際要走的順序。搬名稱伺服器或搬主機之前要先把記錄的 TTL 降到 300 秒——但要提前多久降，是由你現在掛著的那個 TTL 決定的。如果已經在回 NXDOMAIN，它還會照 RFC 2308 算出負快取時間，那正是「修好了卻還沒好」的原因。全部在你的瀏覽器裡算完，輸入的值不會送到任何地方。

免費即時免註冊在瀏覽器裡執行

其他語言：EnglishDeutsch日本語EspañolFrançais한국어繁體中文Português (Brasil)

dns · ttl 計算

秒數，或時間長度寫法：3600 / 1h / 90min / 1d 12h / 04:00:00。超過一週的值不接受。

常用值 — 點一下就填入：

只在切換作業期間使用的低 TTL。300 秒是慣例，低於 60 只會增加查詢次數，換不到什麼。

兩個都在 NXDOMAIN 回應的 authority 區段的 SOA 裡：dig SOA example.tw。RFC 2308 取小的那個。預設值 900 是在 .tw 註冊管理機構實測到的。

結果

          

        

      

    


    

      
發布： dk · Clize · 更新於 


      

      

      
TTL 計算機怎麼用

      
三個輸入欄，不用帳號，計算全部在本機完成。你輸入的值不會被送到任何地方。

      
    
        
  1. 填入現在掛著的 TTL。 把即將要改的那筆記錄上設定的 TTL 填進去，秒數或 1h 這種寫法都可以。會得到換算後的時間，以及它屬於切換用、平衡、還是穩定型。
    2. 
        
  2. 讀變更順序。 作業期間要用的低 TTL、要提前幾小時放出去、切換後快取跟上需要多久、以及結束後調回什麼值，會依序列出來。
    3. 
        
  3. 如果已經在回 NXDOMAIN，把 SOA 的數字也填進去。 執行 dig SOA example.tw，把 minimum 欄位和 SOA 記錄自己的 TTL 填入，就會算出 RFC 2308 的負快取時間——也就是修好之後那個「查無此網域」還會殘留多久。
    4. 
      


      
換名稱伺服器：什麼時候降、什麼時候切

      
順序本身很短。難的是要提前多久降，而答案由你現在掛著的那個 TTL 決定。

      
    
        
  1. 先降 TTL。把要搬的那筆記錄的 TTL 改成 300 秒。這時候什麼都還沒搬。
    2. 
        
  2. 等一個舊 TTL 的時間。已經用 3600 快取走的解析器，要等那一小時過完才會重新來問。保守一點就等兩倍。
    3. 
        
  3. 然後才切換。這時候大家手上都是 300 秒的版本，真正的切換五分鐘內就跟上了。
    4. 
        
  4. 穩定後調回去。改回 3600 或 14400。一直掛著 300 只會讓查詢量變多。
    5. 
      

      
這裡有一個很常見的誤解：調降 TTL 本身不會讓切換變快。只有「降得夠早」才會。切換當天早上才降，快取仍然照昨天那個長 TTL 在走。


      
.tw 的兩個數字，還有「24 到 48 小時」是哪來的

      
中文網路上講換 DNS，幾乎都會出現「要等 24 到 48 小時」。那不是 .tw 的數字。

      
下面的值是 2026 年 9 月 5 日直接向 .tw 的權威伺服器查來的，不是管理介面上的說明文字。

      

      

        
延遲實測值我能改嗎

        
          
.tw 委派 NS 的 TTL3600 秒 = 1 小時不能 — 由註冊管理機構決定

          
.tw 負快取900 秒 = 15 分鐘不能 — 不過很短

          
我自己記錄的 TTL我設定的值能 — 只有這個降得動

          
（對照）.com 委派 NS 的 TTL172800 秒 = 48 小時不能

        
      

      

      
你可以自己重算：

      
$ dig @b.dns.tw NS gov.tw +noall +authority +answer
gov.tw.  3600  IN  NS  g.twnic.net.tw.

$ dig @b.dns.tw A zzz-nx-test.tw
tw.  900  IN  SOA  a.dns.tw. ... 3600 900 1296000 900

      
.tw 是這個系列裡最快的。委派只快取一小時，負快取十五分鐘，兩半都短。換名稱伺服器在 .tw 本質上是一小時等級的作業，不是兩天。那個「24 到 48 小時」是 .com 的 172800 被整段搬過來的說法，.tw 只有它的 1/48。

      
台灣還多一層：第二層網域

      
這是 .de、.fr、.jp 那幾個市場沒有的結構差異。台灣的網域絕大多數註冊在第二層——com.tw、net.tw、org.tw、idv.tw——而 com.tw 這一層自己也帶著 3600 的委派 TTL。

      
$ dig @b.dns.tw NS pchome.com.tw +noall +authority
com.tw.  3600  IN  NS  b.twnic.net.tw.

      
所以 www.example.com.tw 這條鏈上有兩段委派快取要跑完，而不是一段。好消息是兩段都是 3600，所以最壞情況仍然在兩小時內；壞消息是排查的時候要記得多看一層——如果你只查了 example.com.tw 的委派而忽略 com.tw，你會漏掉一段。

      
台灣主機商在自己 zone 上實際回的值

      
2026 年 9 月 5 日，直接向各家的權威伺服器查它們自家網域的 A 記錄 TTL。這跟管理介面的預設值是兩回事——這是它們實際發出去的數字。

      

      

        
業者自家 zone 的 A 記錄 TTL

        
          
cloudmax 匯智 (cloudmax.com.tw)180 秒

          
PChome (pchome.com.tw)300 秒

          
中華電信 HiNet (hinet.net)86400 秒 = 24 小時

        
      

      

      
HiNet 那一格是整份表裡的異數。如果你的記錄託管在會回 86400 的地方，那 .tw 委派只快取一小時的好處就被你自己記錄的 TTL 抵消掉了——註冊管理機構那一側很快，慢的是你這一側。這也正好說明為什麼「換 DNS 要多久」沒有單一答案：要看是哪一段。


      
負快取怎麼算：為什麼修好的當下沒有好

      
只要網域曾經短暫地「不存在」——委派斷掉、記錄被刪、搬遷中出現空窗——在那段時間問過的解析器會把「沒有」這個答案快取起來。而那份快取的壽命不是由你記錄的 TTL 決定，是由 SOA 決定。

      
RFC 2308 的規則是 min(SOA 的 minimum 欄位, SOA 記錄自己的 TTL)。只讀 minimum 會算錯——實務上兩個值不一樣的 zone 很多，這時候小的那個贏。

      
$ dig SOA example.tw +noall +authority

      
這就是為什麼故障結束得比修復晚。委派已經修好，卻還是有一部分使用者看不到，多半不是還壞著，而是負快取還沒過期。.tw 的話是 15 分鐘。


      
常見的 TTL 值，各自用在哪裡

      

      

        
TTL時間什麼時候用

        
          
601 分鐘正在處理故障。長期掛著只會增加查詢成本

          
3005 分鐘切換用的標準值。只在搬遷期間

          
90015 分鐘常變動的記錄。跟 .tw 負快取一樣長

          
36001 小時平衡點。多數記錄的預設值，也是 .tw 委派 NS 的 TTL

          
144004 小時穩定的記錄，例如不太動的 MX

          
8640024 小時幾乎不動的記錄。HiNet 在自家 zone 用的就是這個

          
17280048 小時.com 委派 NS 的 TTL。「24 到 48 小時」的出處

        
      

      

      
把最後兩列跟第四列擺在一起看：.tw 的委派是 3600，.com 是 172800。同一句「換 DNS 要等兩天」，套在 .tw 上會讓你多等四十七個小時。

      


      
// 常見問題

      

    

      換名稱伺服器之前，TTL 要設多少？
      
把要搬的那筆記錄的 TTL 降到 300 秒，等一個現在掛著的 TTL 那麼久（保守就等兩倍），然後才切換。如果現在是 3600，就要在切換前至少一小時、保守兩小時把它降下來。切換當天早上才降沒有用，因為快取仍然照昨天那個長 TTL 在走。穩定之後調回 3600 或 14400。

    

    

      TTL 3600 是幾小時？
      
3600 秒剛好是 1 小時。把這筆記錄快取走的解析器，最多一小時內不會再來問。所以規劃變更時，那一小時必須擺在切換之前。

    

    

      .tw 網域換名稱伺服器要多久？
      
2026 年 9 月 5 日直接向 .tw 權威伺服器查到的委派 NS TTL 是 3600 秒，也就是一小時；負快取是 900 秒。兩半都短，所以 .tw 換 NS 本質上是一小時等級的作業。網路上常講的「24 到 48 小時」來自 .com 的 172800 秒，不是 .tw 的數字。要注意的是 .tw 多半註冊在第二層，com.tw 這一層自己也帶 3600 的委派 TTL，所以最壞情況要算兩段。

    

    

      負快取的 TTL 怎麼算？
      
照 RFC 2308，是 min(SOA 的 minimum 欄位, SOA 記錄自己的 TTL)。只讀 minimum 會算錯，因為兩個值不同的 zone 很多。用 dig SOA example.tw 把兩個值查出來。.tw 註冊管理機構兩個都是 900，所以負快取是 900 秒、15 分鐘。

    

    

      把 TTL 調低，切換就會變快嗎？
      
只有在調低的時間點夠早的時候才會。TTL 不會回溯套用到已經被快取的答案。另外，換的如果是名稱伺服器本身，還有一段委派 TTL 不歸你管——在 .tw 是一小時，在 .com 是四十八小時。

    

    

      TTL 設得很短不好嗎？
      
低於 60 秒，查詢量會增加而換不到什麼。處理故障或搬遷中的那幾個小時是合理的，長期掛著就會讓解析器一直回來問，回應延遲也跟著變高。事情結束之後記得調回去。

    

      


    

      
clize domain check — 讀回應上帶的 TTL，不是你設定的那個

      

        
有意義的是回應裡附著的那個 TTL。

        
一個命令，從兩個系列的公開解析器讀你的網域，列出每筆記錄剩下的 TTL，接著往下確認 zone、主機名稱指派，以及實際上正在服務的內容。

        
$ npm i -g @clize/clize && clize install
$ clize domain check example.tw

        [ Agent Domains → ]
      

    

    

      
延伸閱讀 — TTL、委派，以及中間發生的事