DNS 是什麼？網域指向設定教學與實作

想像一下：你買了一個漂亮的網址，主機也開好了，WordPress 也裝完了，結果打開瀏覽器輸入網址，畫面一片空白。你盯著「無法連上這個網站」那行字，開始懷疑主機是不是壞了、網域是不是買錯了、還是全世界聯合起來整你。

答案通常很無聊：DNS 還沒指過去。網域跟主機之間那一條隱形的線，你還沒接上。

DNS（Domain Name System，網域名稱系統）是整個網際網路的翻譯層，它把你輸入的 whoops.tw 換成一串機器看得懂的數字位址。沒有它，你只能背 IP 才能開網站，你的讀者更不可能記得住你。這一篇我會帶你從查詢原理、紀錄種類，一路走到在網域商後台按下儲存的那一步，再把實務上常見的坑一次講清楚。如果你正在找的是網域怎麼挑、怎麼買，可以先看網域申請購買全攻略，這篇專注在「買到之後怎麼指過去」。

DNS 是什麼？把「好記的名字」翻譯成「找得到的位置」

電腦跟電腦之間的溝通靠 IP 位址（Internet Protocol address）。IPv4 長得像 203.0.113.45，IPv6 更長，一整串十六進位字元。你不可能背下每個網站的 IP，你的訪客更不可能。DNS 解決的就是這個落差：讓人類用名字、讓機器用 IP，中間靠 DNS 做翻譯。

這套翻譯機制的規範在 1987 年就定下來了（RFC 1035：Domain names 的實作與規格文件），將近四十年過去，底層邏輯幾乎沒變。你今天在網域商後台改的每一筆紀錄，走的還是這套老規矩。搞懂它一次，往後十年都受用。

換個方式想。你的網域就像一間公司的總機號碼，但光有總機不夠。你還得準備一張分機表，告訴總機：打來找「網站」的，轉到某一台主機的 IP；找「信件」的，轉到 Gmail 或郵件主機；要放「驗證文件」的，丟進 TXT 那一格。DNS 紀錄，就是這張分機表。誰拿到這張表、表上寫了什麼，決定了你的網域最終會把流量送到哪裡去。

而這張分機表，不是只存在一個地方。它被分散在全球好幾層伺服器上，一層指給下一層看。你改了某一層的表，不代表全世界立刻看到新版本。這個「分散接力」的特性，是所有 DNS 疑難雜症的根源，也是接下來幾個段落的主軸。

這種分散設計是刻意安排的容錯策略。試想，如果全球所有 DNS 查詢都集中到一台機器，那台機器掛了，整個網際網路等於同時斷線；就算不掛，也會被流量灌爆。所以 DNS 從設計之初就是分層、分散、可快取的架構。每一層都能把答案留一份在記憶體裡，上層掛了，下層還能用快取頂一陣子。這個設計帶來的副作用，就是你改了紀錄之後「不會立刻全球生效」。這算不上缺陷，它其實是同一套容錯機制附帶的代價。理解了這一層，你就不會再把 DNS 傳播當成 bug，而是會把它當成設計特性來管理。

一通電話的接力：DNS 查詢背後的 4 層委派

很多人以為 DNS 就是「一個大資料庫，輸入網址就吐出 IP」。實際上完全不是。當你在瀏覽器輸入一個網址，背後發生的是一場四層接力賽，每一層只負責回答一小部分，然後把你往下指。搞懂這場接力，你才會明白為什麼 DNS 有時候改了不生效、為什麼除錯要從某一層開始查。

這四層是這樣運作的：

1. 遞迴解析器（Recursive Resolver）：通常是你的 ISP 或你設定的公共 DNS（例如 Google Public DNS 或 Cloudflare 1.1.1.1）。它接到你的查詢後，代替你跑完剩下三層，然後把最終 IP 回傳給你的瀏覽器。它是你的「跑腿小弟」。
2. 根伺服器（Root Server）：解析器第一站。全球有 13 組根伺服器位址（IANA 的 Root Servers 清單），它不認識你的網域，但它知道「誰負責 .tw」。它把你指向 TLD 伺服器。
3. TLD 伺服器（Top-Level Domain Server）：管理 .tw、.com、.org 這類頂級網域的伺服器。它查一下自己的資料，告訴解析器：「whoops.tw 的權威伺服器在某某那邊。」
4. 權威伺服器（Authoritative Server）：真正握有你網域分機表的那一台。你網域商或主機商的 NS（Name Server）就是這一層。解析器問它「whoops.tw 的 IP 是多少」，它翻一下 A 紀錄，把答案回傳。到此接力結束。

整個過程通常在幾十毫秒內跑完。但你注意到一個關鍵了嗎？真正說了算的是第四層的權威伺服器。前三層只是在「問路」。所以，當你改了 DNS 卻沒生效，問題往往不是你改錯了紀錄，而是你改的那台機器，根本不是目前權威伺服器。這個陷阱我在後面會專門拿出來講，因為它是實務上最常見、也最讓人崩潰的那一種。

6 種你一定會碰到的 DNS 紀錄（附對照表）

DNS 紀錄的種類有十幾種，但你架站、搬家、做 SEO 會用到的，九成集中在接下來介紹的這六種。我用一張表把它們整理出來，你在後台看到這些縮寫時可以對著查。

紀錄類型	名稱	作用	常見值範例
A	Address（IPv4）	把網域指向一個 IPv4 位址。網站指向主機最常用到。	203.0.113.45
AAAA	Address（IPv6）	跟 A 一樣，但指向 IPv6 位址。未來會越來越常見。	2001:db8::1
CNAME	Canonical Name	把一個網域「別名」指向另一個網域。常用在子網域指向託管服務。	shop.example.com → shops.myplatform.com
MX	Mail Exchange	指定收信的郵件伺服器。改這個才收得到信。	ASPMX.L.GOOGLE.COM（企業信箱服務範例）
TXT	Text	放任意文字，主要用來做網域驗證、SPF、DKIM。	v=spf1 include:_spf.google.com ~all
NS	Name Server	宣告「這個網域的分機表由誰管理」。改 NS 等於換總機系統。	ns1.cloudflare.com

這裡有幾個新手容易搞混的地方，我挑重點說。

CNAME 不能放在根網域。很久以來的規矩是 example.com 這個根層級只能放 A 紀錄，不能放 CNAME。如果你想讓根網域指向某個 CDN 或託管平台，但對方只給你一個 CNAME 目標，就會卡住。後來有些網域商推出了「CNAME Flattening」或 ALIAS 紀錄來繞過這個限制，Cloudflare 和部分服務商都有支援，但不是每一家都有。買網域時如果預期會用到，值得先確認。

MX 紀錄改錯會害你收不到信。這一條我放在心上，因為信件中斷的代價通常比網站打不開更嚴重，你會漏掉訂單通知、客戶來信。如果你用 Google Workspace 收發信，MX 紀錄的設定值是固定的那一組，Google 官方文件寫得很清楚。設好之後，用 dig MX 你的網域 驗證一下是不是真的指到 Google，不要憑感覺認為「我按了儲存應該沒問題」。

NS 紀錄是最關鍵、也最容易被漏掉的一種。它決定了「你改的其他紀錄到底有沒有人看」。這件事太重要，我直接用整個下一段來講。

TXT 紀錄也常用於郵件驗證與政策。若用自有網域寄信，應依郵件供應商的官方指示分別設定 SPF、DKIM 與 DMARC；每個服務的值與部署順序可能不同，不能直接複製別人的紀錄。這些設定有助收件端驗證來源，但到達率仍受名單品質、寄送行為與內容影響。如果用 WordPress 發信，也要搭配正確的SMTP 設定。

AAAA 跟 A 紀錄作用相近，差別在於它指向 IPv6。只有在主機與網站服務已完整支援並測試 IPv6 時才新增；錯誤或過期的 AAAA 可能讓部分訪客優先走到無法使用的位址。尚未支援時，保留正確的 A 紀錄即可。

「改了 A 紀錄卻連不上？」NS 才是真正的分機表

這一節的內容，是實務上最多團隊卡關、也最容易踩的雷。

以常見的搬家情境為例：在網域商後台新增 A 紀錄，網站卻怎麼都連不上，追查後才發現 NS 已指向另一組 DNS 服務。也就是說，你修改的不是目前具權威性的 DNS 區域。

這到底是怎麼一回事？回想前面講的四層接力：最終說了算的是「權威伺服器」，也就是 NS 指向的那一台。你的網域商後台能讓你編輯紀錄，但只要 NS 指向別處（例如你之前接了 Cloudflare、或主機商接管了 DNS），那麼你在網域商後台加的 A 紀錄、MX 紀錄，完全不會被查詢。全世界問到你的網域時，都會被 NS 帶去另一台伺服器查那份表，你改的這份表等於放在一個沒人查的抽屜裡。

判斷你到底該去哪裡改，有一個簡單的檢查流程：

1. 先用 dig NS 你的網域 或線上工具查出目前的 NS 指向哪家（網域商？Cloudflare？主機商？）。
2. NS 指到哪裡，你就去那個後台改紀錄。網域商只是「註冊商」，它後台能改 DNS，不代表它就是目前生效的那一份。
3. 如果 NS 指向 Cloudflare，你去 Cloudflare 改；如果指向主機商提供的 NS，你去主機商的 DNS 介面改。網域商後台那邊可以放著不管，反正沒人看。
4. 想讓 DNS 回到網域商管理，就把 NS 改回網域商的預設值。但注意，這個動作會觸發傳播，改回去之後紀錄要以網域商那邊的版本為準。

這個觀念一旦通了，你省下的除錯時間是以小時計的。我後來遇到任何「改了 DNS 卻沒生效」的情況，第一個動作一定是查 NS 指到哪，A 紀錄值對不對放第二步再看。順序錯了，後面檢查再多都白費。很多團隊在這裡耗掉一整天，就是因為一直在對的紀錄類型、對的值上打轉，卻從沒想過自己改的根本不是目前生效的那份分機表。

TTL 與傳播：為什麼改了 DNS 不會馬上生效

「DNS 傳播」（propagation）這個詞你一定聽過，常被講成「改了之後要等全球伺服器同步」。這個說法不算錯，但會誤導你。真正發生的不是「同步」，而是「快取到期」。

每一筆 DNS 紀錄都帶一個 TTL（Time To Live，存活時間），單位是秒。它告訴沿途每一個伺服器：「這份答案你可以先留著，接下來 TTL 這麼多秒內，有人再問你同一個問題，你就直接用這份，不要再跑一趟接力。」這個機制是效能考量，試想全球數十億次查詢如果每次都跑完四層接力，根伺服器早就被灌爆。

問題就出在這個快取。你改了 A 紀錄，但每一層解析器（你讀者的 ISP、公共 DNS、甚至瀏覽器本身）可能還握著舊答案，而且它們會把舊答案留到 TTL 歸零才重新問。於是出現了這個現象：有人看到新網站，有人還在連舊的，過了幾小時到一天才全部一致。

快取可能存在於瀏覽器、作業系統、本地網路與 ISP 的遞迴解析器，因此同一辦公室也可能暫時看到不同結果。可以重連網路、清除本機快取，或用不同解析器交叉測試；上游快取通常仍要等 TTL 到期。各瀏覽器的內部工具會改版，不要只依賴特定網址。

所以 TTL 的策略很實用：

• 平時：可從 3600 秒（一小時）作為起點，降低重複查詢與權威 DNS 負載；它不保證網站內容回應會有明顯變化。
• 準備搬家或改指向之前：先把 TTL 降到很短（例如 300 秒，五分鐘），維持至少一個舊 TTL 的時間（讓所有快取都更新成短的），然後再改紀錄值。這樣改完之後，全世界丟掉舊答案的速度會快很多。
• 搬家穩定之後：再把 TTL 調回高一點。

這個「先降 TTL、再改值、再調回」的三拍節奏能縮短多數遞迴解析器保留舊值的時間，但負快取、供應商行為與本機快取仍可能造成差異，不能保證全球在幾十分鐘內完成。

從網域商到主機：網域指向設定實戰

原理講完了，接著是實作。不同網域商的後台長得不一樣，但底層動作都一樣：找到 DNS 管理介面，新增或修改紀錄，儲存。我用兩個最常見的情境帶你走一遍，其他服務商的操作只是介面差異。若你的網域是向 Namecheap 購買，可以對照Namecheap 網域指向主機的實戰步驟逐項設定。

情境一：網域指向虛擬主機或 VPS（用 A 紀錄）

這是最基本的情境。你在主機商那邊拿到一個 IP 位址，要把網域指過去。

1. 登入網域商後台，找到 DNS 管理（有的叫 Zone Editor、DNS Settings、名稱伺服器管理）。
2. 新增一筆 A 紀錄，主機名稱填 @（代表根網域）或留空，值填主機商給你的 IP。
3. 如果你想讓 www 也指過去，再加一筆 A 紀錄，主機名稱填 www，值填同一個 IP。或者用 CNAME 把 www 指向你的根網域。
4. 確認 NS 指向這個後台（參考上一節的檢查流程，不要在沒生效的地方改）。
5. 儲存，等 TTL 到期後用瀏覽器或 dig 驗證。

不同註冊商的介面名稱會變，但判斷流程相同：先確認權威 NS，再到實際生效的 DNS 後台修改與驗證。

情境二：網域指向託管平台（用 CNAME 或接管 NS）

如果使用託管平台或 CDN，對方可能提供 CNAME 目標，而不是固定 IP。這時常見做法有兩種：

• 子網域用 CNAME：把 shop.你的網域 用 CNAME 指到對方給的目標。這是乾淨的做法。
• 根網域的處理：根網域（@）傳統上不能放一般 CNAME。若 DNS 服務支援，可使用 ALIAS、ANAME 或 CNAME Flattening；否則依平台文件採用 A/AAAA 或指定的 NS 方案。

這裡沒有放諸四海皆準的唯一解，因為每家平台吃法不同。我的建議是：先搞清楚你的主機商或平台「給你什麼」（IP？CNAME 目標？還是要求你改 NS？），再回頭決定紀錄怎麼填。順序反了，你會在後台瞎忙半天卻連不上。如果你的站是跑在 WordPress 上，先把主機類型和主機方案比較搞清楚，再回來看 DNS，會更踏實。

TXT 紀錄的隱藏任務：網域驗證

除了 email 信譽設定，TXT 紀錄還有一個極常用的用途：證明你是網域的擁有者。Google Search Console、Google Workspace、各種 CDN 和第三方服務，在讓你使用進階功能之前，都會要求你做「網域驗證」。做法通常是在 DNS 裡加一筆 TXT 紀錄，值是對方給你的一長串驗證碼。對方的系統去查你的 DNS，看到那串碼，就確認了你的所有權。

這件事看似簡單，但有一個地雷：如果你同時要驗證多個服務，每個服務都給你一筆 TXT 紀錄，你不需要也不應該把它們合併成同一筆。DNS 允許同一個名稱下存在多筆 TXT 紀錄，你就照著加，每一筆獨立存在就好。有些新手以為後加的會覆蓋掉前面的，於是只留一筆，結果其他服務的驗證就掉了。如果你在設定 Google Search Console 或 Search Console 安裝 時卡在驗證這一步，回頭檢查一下 TXT 紀錄是不是被覆蓋了，這是常見原因。

DNS 與 SEO 的三個交會點

DNS 聽起來是純技術設定，跟 SEO 沒直接關係？不完全對。它跟搜尋排名至少有三個交會點，而且每一個都值得你在乎。

第一，DNS 解析速度是頁面載入的第一關

使用者在瀏覽器輸入網址後，第一個發生的網路動作就是 DNS 查詢。解析還沒完成，後面什麼 TCP 連線、HTML 下載、圖片載入全都排不上隊。Google 很早就把網頁速度列入行動搜尋的排名因素（2018 年 1 月），而速度對使用者體驗和轉換的影響，也在 web.dev 的研究中被反覆驗證。DNS 解析雖然通常只佔幾十毫秒，但在追求極致效能的場景裡，它是被優化的一環。

實務做法有兩個方向。一是選一個夠快的權威 DNS 服務，例如把 DNS 接管交給 Cloudflare（它有免費方案），解析速度通常比網域商預設的 DNS 快上一截。二是使用像 Cloudflare 1.1.1.1 或 Google Public DNS 這類公共解析器來測試，確認你的 DNS 回應夠俐落。想更系統性地優化整體速度，可以參考我們寫的載入速度優化全攻略，DNS 只是其中一環。

dns-prefetch 與 preconnect可用於確定會使用的重要第三方來源，提前進行 DNS 查詢或連線。不要為每個來源都加提示，否則會浪費連線資源。它們通常是細部優化，應以瀑布圖驗證，而不是為了排名追求 Core Web Vitals 全綠。相關觀念可看Core Web Vitals 與 SEO。

如果你想從 CDN 的角度再加速一層，把靜態資源快取到全球邊緣節點，CDN 與網站速度是另一個值得讀的方向。CDN 的設定本身也跟 DNS 有關，因為你通常得把網域用 CNAME 指到 CDN 提供的位址，或把 NS 接管交給 CDN 商。

第二，DNS 是 HTTPS 的前置條件

SSL 憑證讓網站使用 HTTPS。憑證簽發單位可以透過 HTTP、DNS 等方式驗證網域控制權；若採 HTTP 驗證，網站指向與路由要正確，採 DNS 驗證則要新增指定紀錄。DNS 設錯可能讓驗證失敗，但不是所有憑證都要求網域先指向最終主機。

如果你想搞清楚 HTTP 跟 HTTPS 差在哪、為什麼該換，可以先看HTTP vs HTTPS 比較，再回頭把SSL 憑證安裝教學走完。順序會是：DNS 指好主機 → 裝 SSL → 啟用 HTTPS → 到 WordPress 設定裡把網址改成 HTTPS 版本。

第三，www 與非 www 的選擇

網站可以使用 example.com 或 www.example.com，兩者在 DNS 層是不同名稱。從 SEO 角度，兩者都能排名，但應選定主要版本，統一內部連結、canonical 與301 重導向。重複內容通常是 canonical 選擇問題，不是自動處罰；轉址鏈的主要風險是延遲與抓取複雜度，也不宜宣稱每一跳必然損失固定 PageRank。更多細節可看www 與非 www 的 SEO 取捨、canonical 設定與子網域 vs 子目錄。

部分一條龍服務會在網域與主機同時購買時自動串接 DNS。之後若搬家或拆開管理，仍要先確認權威 NS、紀錄與帳號權限，不要假設初始設定會永遠適用。

5 種改 DNS 時一定有人會犯的錯（附修正方式）

原理懂了、紀錄認得了，但實際下手時，有些錯誤就是會反覆出現。不是你不聰明，而是 DNS 的某些設計本身就反直覺。我把最常見的五種失誤整理成表格，每一種都附上怎麼發現、怎麼修正。

常見錯誤	症狀	怎麼修正
在錯的後台改紀錄（NS 指向別處）	改了 A 紀錄，但怎麼等都不生效，網站還是連到舊主機	先 dig NS 確認權威伺服器在哪，去那個後台改
忘了設 www 版本	打 example.com 正常，打 www.example.com 卻連不上	補一筆 www 的 A 紀錄或 CNAME，再做 www 與非 www 的重導向
搬家前沒先降 TTL	改完指向，部分訪客幾小時甚至一天後還連到舊站	下次搬家前至少一個舊 TTL 週期先調低 TTL，再等一個週期改值
改了 NS 但沒把紀錄搬過去	把 NS 從網域商改到 Cloudflare 後，信收不到了、子網域也掛了	改 NS 之前，先在新 DNS 服務那邊把原有紀錄完整重建一遍
根網域硬塞 CNAME	後台報錯，或設了卻不生效	根網域用 A 紀錄，或改用支援 CNAME Flattening 的服務

第四種特別危險。切換 NS 前要在新服務完整建立 A、AAAA、MX、TXT、CAA 等現有紀錄，並在可能的情況下直接查詢新權威伺服器確認回應；一般公共解析器在正式切換前未必會使用新區域。逐筆比對後再改 NS，能降低網站、郵件與驗證同時中斷的風險。

DNS 除錯工具箱：自己抓問題不靠客服

DNS 出問題時，最慢的解法是寫信給客服等回覆。最快的解法是自己用工具查一遍，八成的問題你能在十分鐘內定位。以下是我常用的幾個工具，從簡單到進階排列。

nslookup：Windows、Mac、Linux 都內建。打開終端機輸入 nslookup 你的網域，它會回傳目前解析到的 IP。簡單暴力，適合快速確認。缺點是它預設用的是你系統的 DNS，如果你想指定用 Google 或 Cloudflare 的解析器來查，指令會是 nslookup 你的網域 8.8.8.8。

dig：Mac 和 Linux 內建（Windows 要額外裝）。比 nslookup 更靈活，能指定查特定紀錄類型。dig A 你的網域 查 A 紀錄，dig NS 你的網域 查 NS 指到哪裡，dig MX 你的網域 查郵件設定。這個 dig NS 就是我前面強調的「第一步一定要做的檢查」。

線上檢查工具：如果你不想開終端機，或想看「全球各地目前解析到什麼」，用 WhatsMyDNS、DNSChecker 這類網站。它們會從全球幾十個節點同時查你的網域，讓你一眼看出傳播進度，哪些地區已經看到新值、哪些還在舊的。搬家或改指向的當下，這個工具特別有用。

強制走特定解析器驗證：當你懷疑某個 ISP 的快取卡住，可以把電腦的 DNS 暫時改成 Cloudflare 1.1.1.1 或 Google Public DNS（8.8.8.8），再用瀏覽器開網站。如果走這些公共解析器能看到新版本，但走 ISP 預設的看不到，那就確定了：是 ISP 的快取還沒到期，不是你改錯。等就是了。

把這幾個工具串成固定檢查流程：先用 dig NS 確認權威 DNS，再用 dig A 確認紀錄值，接著查看不同地區的解析狀態，並用公共解析器交叉驗證。

我舉一個具體的情境，讓你看這套流程怎麼跑。假設你剛把網站搬到新主機，改了 A 紀錄，等了兩小時，自己用瀏覽器開卻還是看到舊網站。第一步，你開終端機跑 dig NS 你的網域 +short，確認 NS 指向的是你正在改的那個後台（假設是 Cloudflare）。第二步，跑 dig A 你的網域 +short，如果它回傳的還是舊 IP，表示你的紀錄可能根本沒儲存成功，或者你改到的是另一份 zone file。第三步，如果你在 Cloudflare 後台確認紀錄值是新的、但 dig 還是回舊的，檢查 Cloudflare 那筆紀錄的 proxy 狀態（橘色雲朵 vs 灰色雲朵），因為開啟 proxy 時回傳的是 Cloudflare 的 IP，不是你主機的 IP，這是正常的不是錯誤。第四步，把電腦 DNS 改成 8.8.8.8 再測一次，如果走 Google 解析器看到的是新版本，那就是你原本 ISP 的快取還沒到期，再等就好。

這個走法的好處是：每一步都在排除一個可能性，不會在同一個地方打轉。你從「NS 對不對」一路推到「是不是快取問題」，整條鏈排查完，剩下的就只有等待。比起在後台反覆改來改去、或者寄信給客服等半天，效率高得多。

搬家與遷移時的 DNS 檢查清單

網站搬家是最容易出 DNS 事故的時刻，因為同時有太多變數在動。我把搬站時該走的檢查清單列出來，你可以當成 checklist 直接用。

階段	該做的事	為什麼
搬家前 24 至 48 小時	把 TTL 調降到 300 秒左右，等待一個舊 TTL 週期過去	確保改紀錄時，全球快取能快速丟掉舊值
搬家前	用 dig NS 確認目前 DNS 在哪裡管理	避免在沒生效的後台改紀錄（前面講的 NS 陷阱）
搬家當下	在新主機上架好完整網站、測試沒問題後，再改 A 紀錄指向新 IP	順序錯了會出現「DNS 已指過去但新站還沒好」的空窗期
改完 DNS 後	用線上工具監控傳播進度，自己用公共解析器交叉驗證	確認全球陸續看到新版本
搬家後	SSL 憑證在新主機上重新簽發、確認 HTTPS 正常	換了主機，舊憑證不會跟著搬過去
搬家後	把 TTL 調回較高的值（例如 3600 秒）	回復日常的解析效率
換網域時	舊網域用 301 重導向指向新網域對應頁面	保留對應關係並協助搜尋訊號遷移；不保證流量完全不受影響

這份清單不是裝飾品，是搬站時該一條一條打勾照著走的。漏掉其中任何一條，事後補救的成本往往比一開始照表操課高上好幾倍。如果你正在規劃 WordPress 搬家，不論是換主機或換網域，我們寫過更完整的步驟拆解：換主機搬家教學、換主機加換網域指南。

搬 WordPress 站時，DNS 之外還要檢查 WordPress 位址與網站位址，以及固定網址結構。舊網址若改變卻沒有對應 301，可能造成 404、流量與索引波動，但不是「SEO 一夕歸零」的固定結果。搬家時應把 DNS、WordPress 設定、固定網址與 SSL 當成一組處理；完整脈絡可看從零架 WordPress。

5 步驟行動方案：幫你的網域做一次 DNS 體檢

讀到這裡，你不該只是「知道了」，而是現在就動手檢查一次自己的網域。DNS 是那種平時沒人理、出事才被想起來的基礎建設。花十分鐘走完下面五步，你能抓出絕大多數潛在問題。

1. 查出你的 NS 指到哪裡。輸入 dig NS 你的網域 +short，確認目前由哪組權威 DNS 回答。若後台修改沒生效，先核對是否改到正確服務。
2. 確認 A 紀錄指向正確的主機 IP。輸入 dig A 你的網域 +short，比對它回傳的 IP 是不是你目前主機的 IP。如果不對，去 NS 指向的那個後台改。
3. 檢查 www 版本。輸入 dig A www.你的網域 +short，確認 www 也指到正確位置。再對照你的 canonical 設定和重導向，確保主要版本一致。
4. 確認 MX 紀錄。輸入 dig MX 你的網域 +short，確認它指向你實際使用的郵件服務（Gmail、主機商郵件、或其他）。這一步能幫你避免「不知不覺收不到信」的無聲災難。
5. 跑一次全球傳播檢查。把網域丟進 WhatsMyDNS 或 DNSChecker，看全球節點回傳的值是不是一致。如果有些地區還在舊值，可能是某次改動的 TTL 還沒到期，記下來追蹤就好。

這五步走完，你對自己網域的 DNS 狀態就有了完整的掌握。比任何「DNS 教學」讀十遍都實用，因為你手上拿的是你自己網站的真實數據，不是別人文章裡的範例。花十分鐘動手查一次，勝過讀一整天的理論。

DNS 不是什麼性感的話題，但它是一切網站營運的地基。地基穩了，你才敢在上面蓋 SEO、蓋內容、蓋電商、蓋任何你想要的東西。地基不穩，上面的東西再漂亮，一個 DNS 設定出錯就全打回原形。把這套觀念跟流程內化成基本功，你往後架站、搬家、除錯都會比別人少走很多冤枉路。

DNS 是技術 SEO 的一塊拼圖，可搭配技術 SEO 指南、網站結構、Sitemap 設定與索引檢查一起整理。把權威 NS、TTL、主要紀錄與驗證流程寫成維護文件，日後的連線問題會更容易定位。