免費工具 · 名稱伺服器生效檢查

名稱伺服器生效檢查工具

換了名稱伺服器，網站還是打不開？貼上網域：這一頁會透過 RDAP 讀註冊管理機構自己的那筆紀錄（.tw、.com.tw、.台灣的註冊管理機構是 TWNIC），再問兩家獨立的公開解析器手上快取了什麼。對網域查 NS，答案有三種，不是兩種——NOERROR 並帶著 NS 紀錄，代表委派在，你在等快取過期；NXDOMAIN 代表上層 zone 裡根本沒有你這個網域的委派；SERVFAIL 代表委派在，但沒有任何權威伺服器回答。註冊管理機構已經列出你的新名稱伺服器，你就是在等；還列著舊的，那就不是等的問題。免費、即時、免註冊——不會送任何東西到 Clize。

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

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

nameserver · 委派檢查

網域

網域、主機名稱或完整網址都可以——www.example.com.tw 和 https://example.com.tw/blog 都行。NS、SOA、MX、TXT 查的是可註冊的那一層（com.tw、net.tw、org.tw、idv.tw 會自動認出）；A 和 AAAA 查你輸入的主機名稱。

你在受理註冊機構後台填的名稱伺服器（選填）

一行一個，或用逗號分開。填了之後，檢查還會告訴你：你存下的那一組，是不是公開網路現在回的那一組。

或試試這幾個——每一個會落在三種回答裡不同的一種：

公開網路怎麼說

紀錄（兩家解析器並排）

自己跑一次

資料來源：TWNIC 域名服務 Q&A（相關設定）（DNS 設定多久生效、更改 DNS 要找受理註冊機構）、TWNIC .tw 域名安全鎖（server update prohibited 與暫時解鎖）、TWNIC DNS 檢測服務訊息列表（Lame Server、上下層 NS 不一致）、TWNIC RDAP 服務、RFC 2308（負快取）、RFC 9224 與 IANA 的 RDAP 引導表（這一頁怎麼找到你的註冊管理機構）、RFC 7480 §5.6（為什麼瀏覽器可以讀 RDAP）、ICANN 的 EPP 狀態碼說明（hold 與 update prohibited 的意思）。.tw 的 TTL、SOA 序號與 RDAP 比對是 2026 年 9 月 26 日的實測；2026 年 6 月的故障是我們自己的。

發布： dk · Clize · 更新於 2026年9月26日

怎麼確認名稱伺服器的變更生效了沒

三個步驟，都在這一頁完成。檢查是從你的瀏覽器透過 HTTPS 讀公開 DNS 與註冊管理機構的公開紀錄——不會碰到你在受理註冊機構的帳號，沒有東西要安裝，也不用註冊。

輸入網域。 輸入網域、主機名稱或網址，按「檢查委派」。這一頁會透過 RDAP 讀註冊管理機構自己的紀錄（.tw、.com.tw、.台灣是 TWNIC），同時向 dns.google 與 cloudflare-dns 查 NS、SOA、A、AAAA、MX、TXT——註冊管理機構現在的答案，擺在兩份獨立的快取旁邊。
先看委派那一行。 它只會是三種狀態之一。NOERROR 並帶著名稱伺服器，代表委派完好，你在等快取。NXDOMAIN 代表上層 zone 沒有你的委派，等也沒用。SERVFAIL 代表委派在，但後面的名稱伺服器沒有提供這個 zone。
再比對註冊管理機構和解析器。 註冊管理機構已經列出新的名稱伺服器、某家解析器卻還回舊的，那家解析器拿的是快取——這才是「DNS 同步」，它會自己結束。如果連註冊管理機構都還列著舊的那一組，就沒有任何東西在路上：改動沒到註冊管理機構。在 .tw，TWNIC 說註冊系統是定時更新、最多 24 小時；超過一天還是舊的，就回受理註冊機構查。註冊管理機構沒有提供 RDAP 的 TLD，就改比兩家解析器。

三種回答，不是兩種：NOERROR、NXDOMAIN、SERVFAIL

講「DNS 沒生效」的中文文章，幾乎都只分兩種：好了，或是「還在同步」。這個分法是錯的，也是很多人對著一個永遠不會自己好的問題等了三天的原因。對網域查 NS，答案有三種，不是兩種：NOERROR 並帶著 NS 紀錄 = 委派在，你在等快取過期；NXDOMAIN = 上層 zone 裡沒有你這個網域的委派；SERVFAIL = 委派在，但沒有任何權威伺服器回答。

你拿到的回答	代表什麼	等一等會好嗎？
`NOERROR` + NS 紀錄	註冊管理機構有你網域的委派，後面的名稱伺服器也回答了。你看到的，就是公開網路看到的。	會——前提是顯示的是新的那一組。如果還是舊的，是某些快取還拿著，它們會自己過期。
`NXDOMAIN`	上層 zone——`tw.`、`com.tw.`、`com.`——被問到，回答這個名稱不存在。沒有委派可循：網域過期、從未註冊，或被移出 TLD 的 zone。	不會。這個狀態沒有任何東西在路上。
`SERVFAIL`	解析器從上層拿到了轉介，所以委派存在——但它指向的伺服器答不出來。名稱伺服器填錯、新主機上沒有建 zone，或上層的 DS 紀錄對不上 zone 的 DNSSEC 金鑰。	不會。得有人去修 zone 或 DS 紀錄。

上面的工具讀出這個狀態之後，還會讀第二樣東西，把前兩種情況徹底分開：SOA。對你的網域查 SOA，健康的 zone 會回它自己的 SOA——證明從根、經過 TLD、一路到你的名稱伺服器，整條鏈都走通了。沒有委派的網域會回 NXDOMAIN，並在 authority 區段放上上層的 SOA；以 .com.tw 為例，那一行寫的是 com.tw. … a.twnic.net.tw. snw.twnic.net.tw.——TWNIC 管的 zone 明白告訴你，它這裡沒有你。在瀏覽器裡，這兩種情況長得一模一樣：一個打不開的網頁。它們根本不是同一個問題。

「DNS 同步」到底是什麼

沒有什麼東西在「同步」。沒有資料從一台伺服器複製到另一台，也沒有一波更新正在繞地球，那種綠點紅點的全球地圖追的也不是它。你改了名稱伺服器之後，註冊管理機構寫入新的委派，相關的每一台權威伺服器立刻就有新答案。真正花時間的是反方向：之前已經問過的解析器，手上還拿著舊答案，要等它的 TTL 跑完。所謂的同步，是一堆快取照各自的時鐘，一個一個過期。

台灣網路上流傳的等待時間，有些比你想的還舊。TWNIC 的 DNS 學習網還掛著一份頁尾標示 2003 年的問答，寫著「台灣地區約需一至三天」、全球一至七天；主機商的說明頁也還看得到「台灣網域 (.tw) 則要等 24~72 小時」。這些都不是今天 .tw 的數字——下一節是我們直接向 .tw 權威伺服器量到的值。上限從來不是日曆天數，而是舊紀錄被最後一台解析器快取時帶著的 TTL，加上上層 zone 的 NS TTL。

上面的檢查給你數字，而不是傳說。每個回答都帶著那家解析器手上那份快取剩下的 TTL——那就是這份快取還能騙你多久。兩家解析器回不同的名稱伺服器，是「同步」看得見的樣子。兩家解析器一致地回一組你根本沒設定的答案，那就不是同步；那代表改動沒有到註冊管理機構，你該回受理註冊機構，而不是繼續等。

輸出最上面的「REGISTRY」那一段，讓大多數 TLD 不必再用推的。RDAP——在 gTLD 已經取代 WHOIS 的註冊資料查詢協定——用一般的 HTTPS 回答註冊管理機構現在登記的名稱伺服器，而 RFC 7480 建議 RDAP 伺服器讓瀏覽器讀取公開紀錄。所以這一頁直接問註冊管理機構：註冊管理機構已經列出你的新名稱伺服器，你就是在等快取；還列著舊的，改動就沒有落地。TWNIC 的 RDAP 列在 IANA 的引導表裡：.tw 走 https://ccrdap.twnic.tw/tw/（.com.tw、.net.tw、.org.tw、.idv.tw 也在這裡），.台灣 走 https://ccrdap.twnic.tw/taiwan/，回應帶著 access-control-allow-origin: *，瀏覽器可以直接讀。2026 年 9 月 26 日我們抽了 39 個 .tw、.com.tw、.org.tw、.net.tw 網域，把 RDAP 列的名稱伺服器和 .tw 權威伺服器實際發出去的委派逐一比對：39 個全部相同。沒有瀏覽器可讀 RDAP 的註冊管理機構——.jp、.de、.io 都是——那一段會空著，頁面會直說，不會用猜的。

.tw 的實測：委派快取一小時、負快取十五分鐘，前面還有 TWNIC 的「定時更新」

下面的值是 2026 年 9 月 26 日直接向權威伺服器查的——.tw 九台（a～h.dns.tw 加上 anytld.apnic.net）回的都一樣——不是任何管理介面上的說明文字。

延遲	實測值	誰決定
`.tw` 委派 NS 的 TTL（例：`shopee.tw`）	3600 秒 = 1 小時	TWNIC
`com.tw` 委派 NS 的 TTL（例：`pchome.com.tw`；`org.tw`、`net.tw` 相同）	3600 秒 = 1 小時	TWNIC
`.tw` 與 `com.tw` 的負快取	900 秒 = 15 分鐘	TWNIC
你舊紀錄（包括舊 zone 裡 NS 紀錄）的 TTL	你或原本的 DNS 業者設的值	你——只有這一段降得動
（對照）`.com` 委派 NS 的 TTL	172800 秒 = 48 小時	Verisign

$ dig @a.dns.tw NS shopee.tw +norec +noall +authority
shopee.tw.      3600  IN  NS  ns-123.awsdns-15.com.
$ dig @a.twnic.net.tw NS pchome.com.tw +norec +noall +authority
pchome.com.tw.  3600  IN  NS  dns.pchome.com.tw.
$ dig @a.dns.tw A no-such-name.tw +norec +noall +authority
tw.  900  IN  SOA  a.dns.tw. snw.twnic.net.tw. … 3600 900 1296000 900

快取那一段，在 .tw 是小時等級，不是兩三天。你改的是上層 zone 裡屬於你的那一筆委派，TWNIC 讓解析器把它快取最多一小時；那句「24 到 48 小時」對得上的是 .com 的 172800，不是 .tw。剩下的只有你舊紀錄自己的 TTL——要提前多久調降，DNS TTL 計算機會幫你算。

快取以前還有一段：TWNIC 的「定時更新」

一小時是快取那一段。在它前面，還有一段屬於註冊管理機構自己：TWNIC 的域名服務問答寫明，完成 DNS(HOST/IP) 指定之後，註冊系統是定時更新 TWNIC 資料庫的，最多 24 小時內生效；PChome 買網址與 HiNet 的說明也都寫「約 24 小時」。這一段跟 TTL 無關，問解析器的工具都看不到它走完了沒有——只有 REGISTRY 那一段看得到。

這個上限不代表每一筆都要等滿。我們在同一天 09:31 到 10:38（UTC）之間，每 20～30 秒讀一次 SOA 序號：這 67 分鐘裡，.tw 的序號至少變了 20 次，com.tw 至少 7 次，兩邊最長一段沒有變動的時間約 22 分鐘——zone 本身整天都在更新，不是一天才重建一次。所以實務上這樣讀：送出後的頭一天內，註冊管理機構那一段還是舊的，先別急著判定失敗；超過 24 小時還是舊的，就不是等的問題，回受理註冊機構查。

台灣各家後台：這個設定叫什麼、改動會卡在哪裡

在台灣的後台裡，名稱伺服器很少叫「名稱伺服器」。TWNIC 自己的用語是「DNS(HOST/IP) 指定」，更改一律要到網域所屬的受理註冊機構辦，不能在 TWNIC 改；各家受理註冊機構的叫法又各不相同。最常見的一種失敗，是改到了隔壁那個長得很像的設定。

業者	改名稱伺服器的地方	很像、但不是它的設定
HiNet 域名註冊	網域資訊 → DNS主機 →「更新DNS主機」（欄位叫 DNS/HOST Server Name）	「更新DNS紀錄」——那是 HiNet 免費 DNS 代管裡的紀錄
PChome 買網址	「設定DNS自管／代管」→ DNS自管	DNS 代管的 IP 對應設定
網路中文	域名管理 → DNS → DNS主機設定 →「DNS自管」（至少兩組主機名稱與 IP）	「DNS 代管」的紀錄——那裡可以新增 NS 紀錄，但那不會改到委派
Gandi（繁中介面）	「域名」→ 你的網域 →「名稱伺服器」分頁 →「變更」→「外部」	DNS 紀錄

在代管的紀錄裡新增一筆 NS，是把新名稱伺服器寫進舊業者的 zone；上層的委派一個字也沒變。症狀在上面的工具裡很清楚：REGISTRY 那一段還是舊的那一組。

改動送不到 TWNIC 的三個台灣式原因

Email 驗證沒完成。HiNet 的網域資訊頁明寫：未完成 Email 驗證作業，就無法進行 DNS 相關設定（DNS 主機、HiNet DNS 代管、轉址）。PChome 買網址設定 DNS 前要先收驗證碼信，它的常見問題還特別提到 HiNet 信箱的垃圾信過濾會把驗證碼擋掉。
名稱伺服器主機沒有在註冊管理機構建檔。如果你要用的名稱伺服器是 .tw 底下的主機（例如 ns1.xyz.com.tw），HiNet 的說明是：它必須先由 xyz.com.tw 的註冊人，透過自己的受理註冊機構在管理局完成主機名稱與 IP 的建檔，其他網域才能使用，否則新增時就會出錯。.tw 以外的主機（例如 ns1.xyz.net）建檔不需要 IP，受理註冊機構可以直接代辦。
域名安全鎖。TWNIC 的「.tw 域名安全鎖」（Registry Lock）啟用後，網域會帶著 serverUpdateProhibited、serverTransferProhibited、serverDeleteProhibited，在 RDAP 那一段顯示為 server update prohibited 等狀態。這時要改名稱伺服器，得先由服務管理人到 TWNIC 的域名安全鎖網站，通過 Email 與手機驗證後申請暫時解鎖（15 分鐘到 48 小時可選），再回受理註冊機構修改。

負快取：委派修好了，為什麼還是 NXDOMAIN

最折磨人的版本，是你把問題修好了，卻什麼都沒發生。委派修好之後，NXDOMAIN 還可能在負快取 TTL（SOA 的 minimum）這段時間內繼續出現。解析器記住「這個名稱不存在」，就跟記住位址一樣；RFC 2308 把這份記憶的壽命定為 SOA 的 minimum 欄位與 SOA 紀錄本身 TTL 兩者中較小的那個，所以工具把它報成一個數字。.tw 和 com.tw 兩個值都是 900 秒；com. 也是 900 秒；有些 ccTLD 和根是一整天。

在 .tw 有一個細節：.tw 與 com.tw 的權威伺服器回答「SOA 型」查詢的否定回應時，會把那筆 SOA 的 TTL 設成 0（2026 年 9 月 26 日直接問九台 .tw 與五台 com.tw 伺服器量到的；同一個不存在的名稱，改問 A、NS、TXT 都是 900）。所以工具的負快取秒數取自 NS 查詢拿到的那筆 SOA，並在兩家解析器之間取較大的值——在 .tw 上它報 900 秒，也就是 15 分鐘，這才是瀏覽器查 A 和 AAAA 時實際會碰到的長度。

我們在自己的網域上看過這整件事。2026 年 6 月，四個 .app 網域在註冊管理機構那邊失去了委派，全球回 NXDOMAIN 大約四天。受理註冊機構在 6 月 30 日 17:30 UTC 把委派補回去——當天晚上，大部分的網路還是連不上：故障期間問過的解析器，還在它們的負快取時間裡。整段時間有兩個儀表板都說一切正常：Cloudflare 的 zone 顯示 active，受理註冊機構自己的欄位顯示 verified。唯一說實話的，是從兩家獨立解析器讀到的公開權威 DNS。這也是為什麼四層網域健康檢查（英文）從註冊管理機構那一層開始，而不是從任何業者的狀態欄位開始。

實務上：.tw 網域顯示 NXDOMAIN，就把委派修好，然後給它十五分鐘，再判斷修正有沒有用。負快取長達一整天的 TLD，就要有長尾的心理準備，這段時間裡不要再「修」第二次。

換完名稱伺服器之後，真正會壞的地方

八種失敗幾乎涵蓋全部。上面的委派狀態告訴你是哪一類；這裡告訴你該去看哪裡。

受理註冊機構收下了，卻沒有送到 TWNIC。後台顯示已儲存，公開網路還是回舊的那一組。有時卡在 Email 驗證沒完成，有時是被退件，多半什麼提示也沒有。工具裡的症狀：REGISTRY 那一段還是舊的名稱伺服器（沒有 RDAP 的 TLD，則是兩家解析器一致地回舊的那一組）。
新的名稱伺服器上根本沒有建 zone。委派指向一群從沒聽過你網域的伺服器，它們拒絕回答。症狀：兩家解析器都 SERVFAIL。先建 zone，再改委派——順序就是全部的訣竅。TWNIC 的 DNS 檢測服務把「被指定的 DNS 並不管理這個網域」叫 Lame Server，還點名一種很多人會犯的填法：在 DNS 指定裡填了 168.95.1.1 這類只提供大眾查詢的快取伺服器——它不管理你的網域，是同一個問題。
DNSSEC 沒關就搬家。DS 紀錄還在上層 zone，還指著舊業者的金鑰，所以每一台會驗證的解析器都拒收新業者的回答。症狀：到處都是 SERVFAIL，但直接問新的名稱伺服器，它答得好好的。先到受理註冊機構移除 DS，等它的 TTL 過完，再到新的那邊重新開啟 DNSSEC。REGISTRY 那一段會告訴你上層有沒有 DS。
紀錄沒有搬過去。委派完美、zone 也活著，偏偏大家實際輸入的那個主機名稱沒有 A 或 AAAA。症狀：工具顯示委派正常，位址那一行卻是空的。這是「換名稱伺服器明明成功了」網站卻打不開最常見的原因——從 HiNet、PChome 的免費 DNS 代管搬到 Cloudflare 這類外部 DNS 時，代管裡的紀錄不會跟著你走，要先在新的那邊建好。
MX、SPF、DKIM、DMARC 被忘了。郵件壞得比網站安靜，也比網站晚，因為寄件伺服器會重試好幾天，才有人注意到退信。看上面輸出的 MX 和 TXT 那幾行，不要只看位址。如果這個網域掛著你的 agent 依賴的信箱，信箱那一側（英文）也會在同一刻斷掉。
你只是還在一個又舊又長的 TTL 裡。什麼都沒壞。舊紀錄帶著很長的壽命被發出去，有些快取還拿著。上面每個回答剩下的 TTL，就是倒數計時。
搬家期間網域過期，或被移出 TLD 的 zone。沒有人會去找這一個，因為在瀏覽器裡它跟其他狀況分不出來，在 DNS 回應裡卻一眼就看得到。症狀：NXDOMAIN，authority 區段是上層 zone 的 SOA，REGISTRY 那一段出現 client hold、server hold 這類狀態（gTLD 還可能是 redemption period）。以 HiNet 為例，網域到期後的隔天中午就會凍結、停止解析。續約、救回，或找受理註冊機構——等待沒有用。
被鎖住，更新被拒絕。client update prohibited 要註冊管理機構拒絕對網域的更新，server update prohibited 是註冊管理機構那一側的同一把鎖——在 .tw，它就是 TWNIC 的域名安全鎖。REGISTRY 那一段在舊名稱伺服器旁邊出現任何一種，先懷疑鎖：client 的鎖在受理註冊機構解除，server 的鎖只能經過註冊管理機構。

同樣的檢查，在終端機裡做

這裡沒有任何獨門技術；這一頁只是把兩家公開解析器和註冊管理機構的公開紀錄包裝起來。每一行輸出都能用 dig 重現，工具也會印出你輸入的網域對應的指令。.com.tw 網域最常用的是這幾個：

dig NS example.com.tw +short            # 委派解析出來是什麼
dig @8.8.8.8 NS example.com.tw +short   # 同一個問題，問某一份特定的快取
dig @1.1.1.1 NS example.com.tw +short   # 再問另一份——答案不一樣＝還在同步
dig @a.twnic.net.tw NS example.com.tw +norec +noall +authority   # 直接問上層：TWNIC 現在發出的委派，不經過快取
dig SOA example.com.tw                  # NXDOMAIN 時，authority 區段寫著拒絕你的是哪個 zone
curl -s https://ccrdap.twnic.tw/tw/domain/example.com.tw   # TWNIC 自己的紀錄：名稱伺服器、狀態、DNSSEC

直接註冊在 .tw 底下的網域（例如 example.tw），把 a.twnic.net.tw 換成 a.dns.tw；上層伺服器回的是轉介，NS 紀錄放在 authority 區段，所以這一行不能用 +short。想看整條鏈，dig +trace NS example.com.tw 會從根、經過 tw.、com.tw.，一段一段走到你的名稱伺服器，告訴你到底是哪一段斷了。

TWNIC 與 HiNet 的說明教的都是 Windows 內建的 nslookup，它一樣能指定要問哪一家解析器：

nslookup -type=NS example.com.tw 8.8.8.8
nslookup -type=NS example.com.tw 1.1.1.1

手邊連 nslookup 都不能用——鎖起來的公司電腦、手機——同樣兩家解析器也能用一般的 HTTPS 問：

curl -s -H 'accept: application/dns-json' \
  'https://dns.google/resolve?name=example.com.tw&type=NS'

這個請求就是這一頁實際在跑的東西。原始的 JSON 值得讀一次：Status 欄位是 RCODE（0 NOERROR、2 SERVFAIL、3 NXDOMAIN），Answer 放紀錄，否定回答時 Authority 放的是發出否定的那個 zone 的 SOA。

瀏覽器看不到的，以及完整檢查多了什麼

先把這一頁的邊界講清楚。瀏覽器可以透過 HTTPS 跟遞迴解析器講話，大多數 TLD 也可以跟註冊管理機構的 RDAP 服務講話——所以它讀得到三件事：註冊管理機構登記了什麼、委派鏈解不解得通、zone 回答了什麼。它不能直接問你 TLD 的名稱伺服器，看不到你在受理註冊機構的帳號，也看不到排隊中的改動（例如 TWNIC 定時更新之前的那一段）；沒有瀏覽器可讀 RDAP 的 TLD，它完全看不到註冊管理機構；DNS 以外的東西它也看不到——網站前面的 proxy、還沒核發的憑證、從沒建立的主機綁定、回 502 的來源伺服器。這些故障的感覺全都是「換了名稱伺服器之後網站打不開」，但沒有一個是 DNS。

clize domain check <domain> 是同樣的第一層，上面再疊三層。它跑的是一模一樣的雙解析器 DoH 探測——dns.google 優先、cloudflare-dns 備援、RCODE 讀成三種狀態——接著檢查 Cloudflare zone、主機名稱與網站 worker 的綁定，以及網站內容是不是真的在提供。四層、一個指令，所以綠燈代表連得到，而不只是有委派。不帶網域參數時，它會掃過帳號裡的每一個網域。平台也會定時探測：每 30 分鐘一次 cron，連續兩輪失敗才寄警示信，偶爾一次不穩的 DoH 回答不會吵醒任何人。

這個檢查的存在，正是因為上面講的六月那次故障——它是事故之後的修正，連同每次部署後都會跑的委派驗證。想看其餘的部分：Agent Domains（英文）涵蓋從 CLI 買網域、匯入網域與指向網站，用程式註冊網域（英文）講的是從程式碼做同一件事，指令參考（英文）列出 CLI 的所有指令。部署網域上的網站是另一個指令（英文）、另一層——這也正是健康檢查把它們分開回報的原因。

常見問題

更改名稱伺服器之後，多久會生效？

沒有固定答案，「24 到 48 小時」是傳說。以 .tw 為例，我們 2026 年 9 月 26 日直接向 .tw 權威伺服器查到：委派 NS 的 TTL 是 3600 秒（1 小時），com.tw 這一層也是 3600 秒，負快取 900 秒。在快取之前還有註冊管理機構那一段：TWNIC 說註冊系統會定時更新資料庫，最多 24 小時內生效。剩下的是你舊紀錄自己的 TTL。檢查工具會顯示每個回答剩下的 TTL，你可以直接讀倒數，不用猜。

DNS 設定好幾天了還是沒生效，怎麼判斷是壞了還是還在等？

對你的網域查 NS，看回應碼，不要看時鐘。NOERROR 並帶著 NS 紀錄，代表委派在，你在等快取過期。NXDOMAIN 代表上層 zone 裡沒有你網域的委派，等下去不會好。SERVFAIL 代表委派在，但沒有任何權威伺服器回答。接著比對註冊管理機構和解析器：註冊管理機構已經列出新的名稱伺服器、解析器還回舊的，那是快取，會自己結束；設定好幾天了，註冊管理機構自己都還列著舊的，就代表改動沒有送到——TWNIC 說它的定時更新最多 24 小時——回受理註冊機構查。

換了名稱伺服器之後網站打不開，要先查什麼？

先看委派狀態，再看紀錄。委派正常、工具卻顯示你的主機名稱沒有 A 或 AAAA，代表紀錄沒有在新的名稱伺服器上重建——這是最常見的原因，而且不是等的問題；從 HiNet、PChome 的免費 DNS 代管搬走時，代管裡的紀錄不會跟著你走。委派是 SERVFAIL，代表新的名稱伺服器上沒有這個 zone，或上層留著過時的 DS 紀錄讓 DNSSEC 驗證失敗。NXDOMAIN 則代表根本沒有委派：過期、從未註冊，或被移出 TLD 的 zone。

怎麼查 TWNIC 現在登記的是哪一組名稱伺服器？

問註冊管理機構，不要問解析器。解析器回的是快取；TWNIC 的 RDAP 服務回的是它此刻登記的委派，加上 client hold、client update prohibited 這類狀態，以及上層有沒有 DNSSEC 的 DS 紀錄。上面的工具會自動讀 RDAP，放在輸出的最上面。在終端機裡，curl -s https://ccrdap.twnic.tw/tw/domain/example.com.tw 做的是同一件事，.台灣網域則走 https://ccrdap.twnic.tw/taiwan/。.jp、.de 這類沒有瀏覽器可讀 RDAP 的 TLD，就用 whois 或該註冊管理機構自己的查詢頁。

為什麼有些人查到新的，有些人查到的還是舊的？能強制更新嗎？

因為他們問的是不同的快取，其中一份還拿著改動之前的答案。「DNS 同步」從來就只有這個意思。兩邊都沒有錯：每一家解析器回報的，是它快取了什麼、那份還剩多久，較舊的那份過期，差異就消失。別人的快取沒辦法提早清掉；你碰得到的只有兩份：Google Public DNS 與 Cloudflare 1.1.1.1 都有清除單一名稱快取的公開頁面，清了只對用那兩家的人有效。下一次能做的，是改動前一天先把舊紀錄的 TTL 調低。全球同步地圖也無法告訴你改動對不對——它只告訴你哪些快取已經跟上；要確認改動本身，看註冊管理機構那一段。

網域狀態出現 client update prohibited 或 server update prohibited，還能改名稱伺服器嗎？

要先解鎖。client update prohibited 是受理註冊機構那一側的鎖，在受理註冊機構解除。server update prohibited 是註冊管理機構那一側的鎖；.tw 網域啟用 TWNIC 的域名安全鎖後就會帶著它，這時要由服務管理人到 TWNIC 的域名安全鎖網站，通過 Email 與手機驗證後申請暫時解鎖，時間可選 15 分鐘到 48 小時，解鎖期間再回受理註冊機構修改名稱伺服器。鎖沒解開之前，註冊管理機構會拒絕這次更新，等多久都不會生效。

委派修好了，為什麼還是回 NXDOMAIN？

負快取。解析器會把「這個名稱不存在」記住一段時間，長度是負快取 TTL，RFC 2308 定為 SOA 的 minimum 欄位與 SOA 紀錄本身 TTL 中較小的那個。.tw 和 com.tw 都是 900 秒，也就是 15 分鐘。工具在 .tw 網域上可能顯示 0 秒：那是 .tw 權威伺服器回答 SOA 型查詢時把 TTL 設成 0，瀏覽器實際查的 A、AAAA 用的是 900 秒。在我們自己 2026 年 6 月的故障裡，委派補回去之後好幾個小時，大部分解析器才停止回 NXDOMAIN。

這個工具會把我的網域送到哪裡？

網域名稱會送到它查詢的兩家公開 DNS 解析器——dns.google 與 cloudflare-dns——以及負責你這個 TLD 的註冊管理機構的 RDAP 服務（.tw、.com.tw 是 TWNIC 的 ccrdap.twnic.tw，.com 則是 Verisign），因為那就是查詢本身；用來找出該問哪個 RDAP 的 IANA 引導表，下載時不帶你的網域。不會送到 Clize，沒有帳號、不用註冊，我們這邊也不記錄；檢查工具是一段在你瀏覽器裡執行的小程式。如果完全不想用第三方服務，就複製工具印出的指令，自己在終端機裡跑。

clize domain check — 四個層次，一個指令

瀏覽器看得到兩層，CLI 看得到四層。

同樣的雙解析器委派檢查，再加上 Cloudflare zone、主機名稱綁定，以及網站是不是真的在提供內容——可以檢查單一網域，也可以掃過帳號裡的每一個網域。平台每 30 分鐘重跑一次，連續兩次失敗才發警示。

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

[ Agent Domains by Clize → ]