把網域接上 Cloudflare 之後，每一筆 DNS 記錄旁邊都有一個小雲朵圖示，橘色或灰色。很多人第一次設定時隨手把它們全點成橘色，網站確實變快了，過了一小時卻發現信收不到、WooCommerce 的訂單通知信全部寄不出去，而且整個過程沒有跳出任何錯誤訊息。這顆雲朵就是 Cloudflare DNS 代理模式的開關，橘雲代表流量會先經過 Cloudflare、灰雲代表只做純 DNS 解析。它看起來只是個顏色切換，實際上決定了你的網站有沒有 CDN 與防護、伺服器真實 IP 會不會外洩，以及郵件、SSH、資料庫這些非網頁服務能不能正常運作。

這篇會把橘雲與灰雲的差別講清楚，逐一說明哪種記錄該開橘雲、哪種一定要留灰雲，並把實務上最常踩的坑攤開來講，包含信件靜默中斷、SSL 模式設錯造成的轉址迴圈、WordPress 抓不到訪客真實 IP，以及伺服器 IP 從郵件記錄漏出去的問題。

Cloudflare DNS 代理模式到底是什麼

Cloudflare DNS 代理模式指的是「讓流量先經過 Cloudflare 再轉到你的主機」這件事，在 DNS 記錄上用橘雲（Proxied，代理）與灰雲（DNS only，僅 DNS）兩種狀態表示。這顆雲朵只會出現在能被代理的記錄類型上，也就是 A、AAAA、CNAME 三種。

橘雲開啟時，Cloudflare 扮演反向代理（Reverse Proxy）的角色，站在訪客與你的來源主機（origin server）之間。訪客連到的不是你的伺服器，而是 Cloudflare 的邊緣節點；DNS 查詢回傳的也不是你主機的真實 IP，而是 Cloudflare 的 Anycast IP。所有 HTTP 與 HTTPS 流量都會先進到 Cloudflare 的全球網路，過濾、快取、套用規則之後，再轉送到你的主機。

灰雲則相反，Cloudflare 只當一台單純的權威 DNS 伺服器，把網域解析成你主機的真實 IP，然後就放手。訪客的瀏覽器會直接連上你的伺服器，中間沒有任何 Cloudflare 介入，自然也沒有快取、沒有防火牆、沒有流量分析。

兩者的差別不是「強一點」與「弱一點」，而是「流量有沒有經過 Cloudflare」這個根本分歧。橘雲是 Cloudflare 幾乎所有進階功能的前提，沒開橘雲，你買的 CDN、WAF、Bot 管理、頁面規則全部用不到；但也正因為流量被攔截轉送，某些服務反而會因此中斷。

橘雲（Proxied）開啟後會多出哪些功能

橘雲開啟後，流量經過 Cloudflare 邊緣節點，以下這些防護與加速會在請求碰到你的主機之前就先發生：

• CDN 與靜態快取：圖片、CSS、JavaScript 這類靜態資源會被快取在 Cloudflare 全球三百多個節點，訪客從最近的資料中心載入，延遲降低，你的主機也少扛很多請求。
• DDoS 防護：第三、四層的網路型攻擊與第七層的應用層攻擊都在邊緣被吸收，你的主機根本看不到那些惡意流量，且預設常駐、不必額外設定。
• WAF 網站應用程式防火牆：每一筆 HTTP 請求都會被檢查是否含有 SQL 注入、跨站腳本、目錄穿越等常見攻擊手法，惡意請求在進到你的應用程式之前就被擋下。
• SSL/TLS 終止：Cloudflare 在邊緣處理 SSL 交握，把加解密的運算負擔從你的主機移開，也能順帶啟用自動 HTTPS 改寫、HTTP/2、HTTP/3 等功能。
• 隱藏來源 IP：DNS 查詢回傳的是 Cloudflare 的 IP，攻擊者用 dig 或 nslookup 查不到你伺服器的真實位址。這是橘雲最被低估、卻最有價值的安全好處之一。
• 流量分析與 Bot 管理：流量分析、機器人偵測、速率限制這些功能全都建立在「流量經過代理」這個前提上，灰雲的記錄完全享受不到。

對一個跑在 WordPress 或 WooCommerce 上的網站來說，橘雲帶來的不只是速度，還有一層幾乎零成本的安全護欄，這也是大多數公開網站都該替主網域與 www 開啟橘雲的原因。

灰雲（DNS only）模式適合哪些情況

灰雲適合任何「不是 HTTP/HTTPS 網頁流量」或「會被代理破壞」的服務。當記錄設成灰雲，Cloudflare 只回傳你主機的真實 IP，訪客直連你的伺服器，因此：

• 你的真實 IP 會公開在 DNS 查詢結果裡，任何人用 dig 都查得到。
• 沒有任何 CDN 快取，每一筆請求都直接打到你的主機。
• 沒有 Cloudflare 的 DDoS 防護與 WAF 過濾。
• 那個子網域不會有 Cloudflare 的流量分析資料。
• 但好處是任何通訊協定都能正常運作，SMTP、FTP、SSH、遊戲伺服器都不受限。

灰雲不是「比較不安全的選項」，而是「給特定服務用的必要模式」。郵件伺服器、檔案傳輸、遠端登入、資料庫連線這些服務本來就需要直連，硬套橘雲只會讓它們無法連線。判斷原則很單純，這筆記錄服務的是不是純粹的網頁流量，是就開橘雲，不是就留灰雲。

橘雲與灰雲怎麼分配給每一筆記錄

最簡單的判斷規則是「HTTP/HTTPS 流量走橘雲，其他全部走灰雲」。下面這張表是一個同時跑網站、郵件、FTP 的主機常見的配置：

要特別記住的是，並非所有記錄類型都能被代理。只有 A、AAAA、CNAME 三種會顯示雲朵圖示，可以選橘雲或灰雲；MX、TXT、SRV、NS、CAA 這些記錄根本不會出現雲朵，Cloudflare 一律當作純資訊解析處理，你也不需要為它們煩惱代理狀態。

cPanel 或 Plesk 主機還有一個額外的細節，cpanel、whm、webmail 這類後台子網域如果開橘雲，長時間的大檔上傳很容易撞到代理的逾時限制，建議直接留灰雲，省得遇到傳一半斷線的怪問題。

為什麼信件記錄開橘雲會讓郵件靜默中斷

把郵件相關記錄開成橘雲，是新手導入 Cloudflare 時最常見、也最難察覺的錯誤。Cloudflare 的代理只處理特定埠的 HTTP 與 HTTPS 流量，而 SMTP 收信走 25 埠、送信走 465 或 587 埠，IMAP 與 POP3 也各有自己的埠，這些流量經過 Cloudflare 代理時不會被轉送，而是直接被丟棄。

最麻煩的地方在於它是「靜默」失敗。寄信的人不會收到退信通知，你的後台也不會跳錯誤，網站本身看起來一切正常，只是信就是收不到、也寄不出去，而且這個狀況往往是切換後一個小時才浮現，讓人很難把「信件壞掉」跟「剛剛點了那顆雲朵」連在一起。對跑 WooCommerce 的站來說，這代表訂單確認信、出貨通知、會員密碼重設信全部消失，影響直接打到營收。

正確做法是讓所有跟郵件有關的 A 或 AAAA 記錄維持灰雲，典型的就是 mail 這個子網域。MX 記錄本身因為不是可代理的類型，Cloudflare 不會顯示雲朵，你只要確認它指向的主機名稱（通常就是那個灰雲的 mail 記錄或第三方郵件服務）解析正確即可。SPF、DKIM、DMARC 這些 TXT 記錄也照常設定，它們不受代理影響。

SSL 模式設錯會跟橘雲一起製造轉址迴圈

開了橘雲還要把 SSL/TLS 模式設對，否則最容易撞上的就是 ERR_TOO_MANY_REDIRECTS 轉址迴圈。Cloudflare 與你主機之間的加密模式有好幾種，其中「彈性（Flexible）」是製造轉址迴圈的頭號元兇。

彈性模式的問題出在它讓 Cloudflare 用 HTTP（未加密）連你的主機，但把回應用 HTTPS 傳給訪客。如果你的主機本身設了「所有 HTTP 一律轉 HTTPS」的規則，或 WordPress 裝了強制 HTTPS 的外掛，迴圈就立刻成形：Cloudflare 用 HTTP 打主機，主機回一個轉去 HTTPS 的 301，Cloudflare 收到後再用 HTTP 打主機，無限重複，瀏覽器最後就丟出轉址過多的錯誤。

正解是把 SSL/TLS 模式設成「完整（嚴格）」（Full Strict），並在主機上安裝有效的憑證。如果主機還沒有憑證，Cloudflare 提供免費的 Origin CA 憑證，在 SSL/TLS 後台就能產生並安裝到主機，之後 Cloudflare 與主機之間的連線就是加密且經過驗證的。要注意 Origin CA 憑證只被 Cloudflare 信任、瀏覽器不直接信任它，所以萬一你哪天把橘雲關掉、讓訪客直連主機，他們會看到憑證錯誤，這是使用這張憑證時要記得的取捨。

各模式的差別整理如下：

設好「完整（嚴格）」之後，再到邊緣憑證設定把「永遠使用 HTTPS」打開，讓 Cloudflare 在邊緣就把 HTTP 請求轉成 HTTPS，這樣主機端就可以拿掉自己那條 HTTP 轉 HTTPS 的規則，一個轉址就夠了，不必兩邊都做。

開了橘雲之後 WordPress 為什麼抓不到訪客真實 IP

橘雲開啟後，WordPress 看到的訪客 IP 會全部變成 Cloudflare 的 IP，因為從主機的角度看，連進來的確實是 Cloudflare 的邊緣節點，不是真正的訪客。這對一般瀏覽沒影響，但會弄壞一票依賴 IP 的功能。

具體會出狀況的包含：留言、登入記錄全部顯示同一批 Cloudflare IP；安全外掛（例如限制登入失敗次數、封鎖可疑 IP 的工具）會因為看到所有人都是同一個 IP 而誤判，要嘛擋錯人、要嘛整批放行；主機層的 fail2ban 之類防護也會因為只看到 Cloudflare 的 IP 而失效。

Cloudflare 其實有把真實訪客 IP 放在一個叫 CF-Connecting-IP 的 HTTP 標頭裡，你要做的是讓主機或 WordPress 去讀這個標頭、還原成真正的來源 IP。常見作法有幾種：在 WordPress 的 wp-config.php 裡判斷這個標頭存在時，把 REMOTE_ADDR 換成標頭裡的值；在 cPanel/WHM 環境用 Apache 的 mod_remoteip 模組，指定 RemoteIPHeader 為 CF-Connecting-IP 並加上 Cloudflare 的 IP 範圍；Nginx 則用 set_real_ip_from 搭配 Cloudflare 的 IP 區段，把真實 IP 還原。Cloudflare 官方的 WordPress 外掛也能協助處理這件事。設定好之後，後台與安全工具才會重新看到真正的訪客來源。

怎麼確認某筆記錄目前是橘雲還是灰雲

最直接的方式是在 Cloudflare 後台看雲朵顏色，但流量切換後想確認實際生效狀態，用 dig 從命令列查最準。指令是查詢該網域的 A 記錄：

dig +short A example.com

如果回傳的是 Cloudflare 的 IP，代表這筆記錄是橘雲代理中；如果回傳的是你主機的真實 IP，代表它是灰雲純解析。Cloudflare 的邊緣 IP 常落在以下幾個區段，看到這些就是代理狀態：

• 104.16.0.0/12
• 172.64.0.0/13
• 173.245.48.0/20
• 103.21.244.0/22

要切換狀態，登入 Cloudflare 後台、選網域、進左側的「DNS」「記錄」，每一筆 A、AAAA、CNAME 旁邊都有雲朵圖示，點一下就能在橘雲與灰雲之間切換，變更通常幾分鐘內生效。如果是要批次管理大量記錄，Cloudflare 的 API 也能查詢與修改每筆記錄的 proxied 欄位（true 是橘雲、false 是灰雲），適合自動化場景。

主網域開了橘雲，IP 還是可能從郵件記錄漏出去

代理的保護強度，取決於你最弱的那一筆記錄。這是一個常被忽略、卻很現實的問題：就算主網域開了橘雲、成功把真實 IP 藏起來，只要 mail 這類子網域是灰雲（而它必須是灰雲，郵件才能正常運作），攻擊者還是能透過查 mail 子網域拿到你伺服器的真實 IP。

換句話說，隱藏 IP 這件事只要有一個灰雲記錄指向同一台主機就破功了。要降低這個風險，可以考慮幾個方向：郵件用獨立的伺服器或不同的 IP，跟網站主機分開；在主機防火牆上設規則，只接受來自 Cloudflare IP 範圍的 HTTP 流量，其他來源一律擋掉；或啟用 Cloudflare 的來源驗證拉取（Authenticated Origin Pulls，mTLS），確保只有 Cloudflare 能連到你的網頁主機。當然，對多數一般網站來說，郵件 IP 外洩是個可以接受的風險，不必過度設計，重點是知道有這回事，別誤以為開了橘雲就滴水不漏。

順帶一提，Cloudflare 確實有一個叫 Spectrum 的產品可以代理任意 TCP/UDP 埠，包含 SSH、郵件、遊戲伺服器，但那是付費的企業級功能，不是橘雲這顆開關預設的行為，一般方案下別指望橘雲能代理非網頁服務。

接上 Cloudflare 前，先把每筆記錄的雲朵想清楚再切換

橘雲與灰雲的選擇，歸結成一句話就是「網頁流量走橘雲，其他走灰雲」。主網域與 www 開橘雲拿 CDN 與防護，網頁應用子網域同樣開橘雲，郵件、FTP、SSH、資料庫一律留灰雲，MX、TXT、SRV 這些記錄則根本沒有代理選項、不用煩惱。設定流程上，建議先在 Cloudflare 後台把所有匯入的記錄逐筆確認雲朵狀態、再切換 Nameserver，這樣切過去的瞬間就是對的狀態，不會留下空窗期。

切換之後別忘了三件收尾：SSL/TLS 設成「完整（嚴格）」避開轉址迴圈、在主機端還原 CF-Connecting-IP 讓 WordPress 看得到真實訪客、確認郵件記錄維持灰雲讓信件正常收發。把這顆小雲朵當成一次性、要記錄下來的架構決策，而不是隨手亂點的開關，後面那些信件中斷、登入記錄全變同一個 IP、轉址迴圈的怪問題，多半就不會找上門。