2026 年域名與 DNS：Cloudflare DNS 完整設定
2-1 網域註冊商怎麼選？與 Cloudflare Registrar 的差異
網域註冊商（Registrar）是你「買網域」的地方，而 DNS 服務商是你「托管解析」的地方，這兩者可以不同。很多人的做法是：網域在 A 公司買，Nameserver 指向 Cloudflare，解析在 Cloudflare 管理。這完全沒問題，也是最常見的組合。
Cloudflare 自己也有 Registrar 服務，特色是「以成本價續約、不加價」，而且不玩首年便宜、次年漲價那套。如果你手上網域很多，長期下來可以省下不少錢。不過它有幾個前提：你必須先有一個使用 Cloudflare 的網站，而且可註冊的頂級網域種類相對有限，像 .tw 這類地區型網域不見得都支援。
無論你用哪一家，請務必確認兩件事：第一，你擁有網域的管理權限（能取得轉移碼、能修改 NS）；第二，註冊商帳號有開啟兩步驟驗證。網域被盜的災難程度遠高於主機被盜，因為你失去的是整個入口。
2-2 免費方案夠用嗎？Cloudflare 方案差異對照
很多人第一個問題是：「我只需要 DNS，免費版會不會有什麼限制？」答案是：對絕大多數個人站長與中小型網站來說，免費版非常夠用。以下整理幾個方案在 DNS 相關功能上的差異，方便你判斷。
項目
Free
Pro（含以上）
DNS 查詢量
不限量
不限量
Anycast 全球節點
DNSSEC
支援
支援
代理模式（橘雲）
支援
支援
WAF 自訂規則
受限
較完整
憑證類型
通用憑證
可含更多進階選項
技術支援
社群
工單優先
可以看出，DNS 本身的核心功能在免費版並沒有被閹割。真正差異比較大的是 WAF 規則數量、快取規則的細緻度、以及碰到問題時有沒有人可以幫你。如果你只是要「讓網域正確解析、順便有基本防護」，免費版完全沒問題；如果你跑的是電商或有大量會員資料的服務，升級到 Pro 以上會比較安心。
2-3 把網域加入 Cloudflare 的完整流程
流程其實不複雜，但每一步都有容易忽略的細節：
example.com），不要輸入 www.example.com。步驟三：選擇方案。先選 Free 即可，之後隨時可以升級。
xxx.ns.cloudflare.com 這樣的格式。這裡最容易出錯的是步驟四。很多人急著改 NS，結果原本的 MX 記錄沒有被掃到，改完之後公司信箱全部收不到信。所以強烈建議：在改 NS 之前，先到你原本的 DNS 管理後台，把所有記錄截圖或匯出，然後逐筆跟 Cloudflare 掃描出來的結果比對。
三、Cloudflare DNS 記錄設定實戰
接下來進入實際操作。Cloudflare 的 DNS 介面左側選單點進去就是「DNS → Records」，所有記錄都在這裡管理。以下逐類說明。
3-1 A、AAAA、CNAME：三種最常見的記錄
A 記錄負責把名稱對應到一個 IPv4 位址。例如 example.com → 203.0.113.10。這是最基礎的記錄類型，通常用於你的主機有固定 IP 的情況。
AAAA 記錄是一樣的邏輯，只是對應到 IPv6 位址。如果你的主機支援 IPv6，建議一併設定，因為行動網路與部分 ISP 已經大量走 IPv6，對連線品質有正面幫助。
CNAME 記錄則是「別名」，把名稱指向另一個名稱，而不是 IP。例如把 www.example.com 指向 example.com，或是在使用第三方服務（如電商平台、部落格託管）時，對方會請你設定一筆 CNAME 指向他們的網域。
選擇原則很簡單：對方給你 IP 就用 A／AAAA，對方給你網域名稱就用 CNAME。另外要記得一個傳統限制：根網域（example.com 本身）在標準 DNS 中不能用 CNAME，不過 Cloudflare 有提供 CNAME Flattening 的機制，實務上可以設定，它會自動幫你解析成 A 記錄。這個機制在 2026 年依然是 Cloudflare 的實用特色之一。
3-2 MX 與 TXT：郵件與驗證記錄
這兩類記錄跟網站瀏覽無關，但跟你的「身份驗證」與「郵件收發」息息相關，而且一旦設定錯誤，症狀通常很難懂。
MX 記錄決定「寄給這個網域的信要送到哪台伺服器」。如果你使用 Google Workspace、Microsoft 365 或自架郵件伺服器，服務商都會給你一組 MX 記錄。有幾個重點：
MX 記錄的值是「主機名稱」，不是 IP。
每筆 MX 都有一個優先順序（Priority），數字越小優先度越高。
.（空值）來明確表示「此網域不接收郵件」，避免被冒用。TXT 記錄則是拿來放文字資料的，最常見的用途有三個：網域所有權驗證（Google Search Console、各種 SaaS 服務）、SPF 記錄（授權哪些伺服器可以代替你寄信）、以及 DKIM 公鑰。TXT 記錄的內容通常是長長的一串，複製貼上時要特別小心不要多貼了引號或空格。
3-3 CAA、SRV、NS 與其他進階記錄
CAA 記錄用來限制「哪些憑證頒發機構可以幫這個網域簽發 SSL 憑證」。例如你可以設定只允許 Let's Encrypt 與 Google Trust Services 簽發，這樣即使有人試圖用其他管道申請憑證也會被拒絕。對安全性要求較高的網站，建議設定。
SRV 記錄用於指定特定服務的主機與埠號，常見於 VoIP（如 SIP）、Minecraft 伺服器、Exchange 自動探索等場景。它的欄位比較多（Priority、Weight、Port、Target），設定前務必確認服務商給的格式。
NS 記錄則是用來指定子網域的權威伺服器。例如你可以把 dev.example.com 交給另一組 Nameserver 管理，實現「子網域委派」。這個功能在大團隊分工時很有用，但設定門檻也比較高。
四、橘雲與灰雲：最關鍵、也最常被搞混的開關
在 Cloudflare 的 DNS 記錄列表裡，每一筆記錄右邊都有一個雲朵圖示，可以切成橘色或灰色。這個小小的開關，決定了流量會不會經過 Cloudflare，影響層面極大。
4-1 橘雲與灰雲的差異對照
比較項目
橘雲（Proxied）
灰雲（DNS Only）
流量路徑
經過 Cloudflare 邊緣節點
直接連到你的伺服器
源站 IP
被隱藏
公開可見
快取
可啟用
WAF / 防護
可套用
無法套用
非 HTTP 服務
不支援
支援
憑證管理
Cloudflare 可代管
需自行處理
看表格就很清楚：橘雲的優點是隱藏源站、有快取與防護；灰雲的優點是「什麼都能通」，因為它就是最原始的 DNS 行為。
4-2 什麼情況一定要用灰雲？
這是最實務的問題。以下幾種情況，請務必使用灰雲，否則服務會直接掛掉：
反過來說，只要你的服務是「一般使用者用瀏覽器存取的網站」，幾乎都應該開橘雲。這是 Cloudflare 最大的價值所在。
五、安全設定：DNSSEC、SSL/TLS 與郵件驗證
DNS 記錄設好只是基本盤，接下來這三組設定才是真正決定你的網站「安不安全、專不專業」的關鍵。
5-1 DNSSEC 的正確開啟步驟與常見陷阱
DNSSEC 的原理是在 DNS 回應上加上數位簽章，讓解析器可以驗證答案沒有被中間人竄改。開啟步驟如下：
在 Cloudflare 的 DNS 設定頁面找到 DNSSEC 區塊，點選啟用。
等待生效，通常幾小時內完成。
最大的陷阱在於：DS 記錄填錯，整個網域會直接無法解析。因為驗證失敗的網域，對支援 DNSSEC 的解析器來說就是「不存在」。所以填寫時務必逐字核對，並且在改動後的幾小時內持續用 dig 或線上工具檢查。如果你同時正在做其他 DNS 變更，建議錯開時間，免得問題發生時不知道是哪一項造成的。
另外，如果你之後要把網域轉移到別的註冊商，記得先確認 DS 記錄的處理方式，有些註冊商在轉移過程中會移除 DNSSEC 設定，導致解析中斷。
5-2 SSL/TLS 加密模式：Flexible 為什麼是災難
Cloudflare 的 SSL/TLS 設定有幾種模式，分別代表「瀏覽器 ↔ Cloudflare」與「Cloudflare ↔ 你的源站」這兩段連線的加密方式。這裡直接說結論：
Off：完全沒有加密，只有在你真的需要除錯時才短暫使用。
Full：兩段都加密，但不驗證源站憑證是否有效。
為什麼 Flexible 是災難？因為它會造成「看起來有鎖頭，實際上後半段是明文」的假象。更嚴重的是，如果你的源站有做「強制 HTTPS 轉址」，就會形成無限重導迴圈，網站直接打不開。此外，部分資安稽核會直接判定這種配置不合格。所以除非你有非常特殊的理由，請一律使用 Full (Strict)，並在源站安裝有效的憑證（Cloudflare 有提供 Origin Certificate 可以免費使用，效期長、申請方便）。
5-3 SPF、DKIM、DMARC：寄信不再進垃圾桶
如果你有從自己的網域寄信（不管是公司信箱還是電子報），這三筆記錄幾乎是必備的。它們的關係可以這樣理解：
v=spf1 include:_spf.google.com ~all。v=DMARC1; p=quarantine; rua=mailto:[email protected]。設定順序建議是：先確認 SPF 正確、再上 DKIM、最後才把 DMARC 的政策逐步從 p=none 調緊到 quarantine 甚至 reject。直接跳到 reject 很容易把自己正常的信也擋掉。另外要特別注意：同一個網域只能有一筆 SPF 記錄，如果你有多個服務需要授權，要用 include 合併在同一筆裡面，不能開兩筆。
六、效能與維運：TTL、快取與日常檢查
設定完成不代表結束。這一節談的是長期的維運習慣，以及遇到問題時該怎麼自己排查。
6-1 TTL 該設多少？
TTL（Time To Live）代表「這筆記錄可以被快取多久」，單位是秒。數值越大，解析器快取越久，查詢量越少、速度越快；數值越小，變更生效越快，但查詢量增加。
實務上的建議是：
變更完成且穩定後：再調回 3600 秒。
要注意的是，開橘雲的記錄在 Cloudflare 介面上 TTL 會顯示「Auto」，這是因為實際對外的 TTL 由 Cloudflare 依情況決定，你不需要（也不能）手動設定。
6-2 用 dig 與 nslookup 自我診斷
當你覺得「改了但沒生效」，第一件事不是重複按儲存，而是確認 DNS 到底回了什麼。在終端機（Windows 可用 PowerShell 或 CMD）輸入：
dig example.com A：查詢 A 記錄。
dig example.com MX：查詢 MX 記錄。
dig @1.1.1.1 example.com：指定用 Cloudflare 的解析器查詢。nslookup example.com：Windows 上較通用的替代指令。看輸出的時候，重點看兩件事：ANSWER SECTION 回的是不是你預期的值，以及 TTL 剩多少。如果回的是舊值，那就是快取還沒過期，等一下就好；如果回的是完全不相關的值，那可能是你查到別的網域，或是本機 hosts 檔有設定。
6-3 五個最常見的設定錯誤
整理一下在論壇上最常被問到的狀況：
mail 打成 maill）。這五個狀況涵蓋了絕大多數的求助案例。養成一個習慣：每次變更前先想清楚「我改了什麼、預期結果是什麼」，變更後立刻用 dig 驗證，就能省下大量時間。
七、結語：把 DNS 當成基礎設施，而不是雜事
Cloudflare 把過去需要專業知識才能架設的 Anycast DNS、DDoS 防護、憑證管理與 CDN，包裝成一個幾乎人人上手的介面，這確實降低了門檻。但工具越簡單，越容易讓人忽略它背後的邏輯，於是橘雲灰雲分不清、SSL 模式亂選、郵件記錄漏設的狀況依然層出不窮。
希望這篇文章能幫你把整套流程走過一遍。真正重要的不是記住每一個按鈕在哪裡，而是理解「為什麼要這樣設」——當你知道代理模式只處理 HTTP、知道 DNSSEC 的 DS 記錄會影響整個網域的可解析性、知道 Flexible 會造成重導迴圈，你就有能力在遇到問題時自己判斷，而不是只能發文求救。
如果你在設定的過程中卡住了，歡迎把 dig 的輸出結果貼到「雅寶社區 · 頂客論壇」的 3C 科技教學版，附上你做了哪些變更、預期結果是什麼，通常很快就能找到答案。DNS 這門學問看似枯燥，但把它弄懂之後，你會發現自己對整個網路運作的理解都往上跳了一個層次。