查 Cloudflare Flexible／Full SSL、轉址迴圈、Cache Rules、橘雲代理、Origin 狀態與 520–526 錯誤，不把所有問題都歸到快取。
先搞懂一件事：Cloudflare 是兩段連線，不是一段
幾乎所有的坑，追到底都是同一個誤會：以為訪客到你主機是一條線。實際上 Cloudflare 把它切成兩段——訪客到 Cloudflare 邊緣節點是第一段，Cloudflare 邊緣再連到你的主機（官方叫 origin，來源伺服器）是第二段。第一段永遠照訪客用的協定走，你在瀏覽器打 https 它就是 https，這段幾乎不用你操心。真正被你設定左右、也最容易出事的是第二段：SSL 模式管的是第二段、5xx 錯誤幾乎全發生在第二段、橘雲灰雲決定第二段要不要走 Cloudflare。把這個雙段模型放進腦子，後面每一個症狀都會突然變得合理。
SSL 模式與轉址迴圈：ERR_TOO_MANY_REDIRECTS 的真兇
瀏覽器跳 ERR_TOO_MANY_REDIRECTS，十之八九是 SSL 模式選錯。Cloudflare 有四種模式：Off、Flexible、Full、Full (strict)，它們控制的正是上面說的第二段。問題出在 Flexible——它讓第一段走 HTTPS，第二段卻用 HTTP 連你主機。於是迴圈長這樣：請求進來是 https，Flexible 用 http 轉給主機，主機設定了「所有 http 一律轉 https」，就把它又轉回 https，繞回 Cloudflare，Flexible 再降成 http⋯⋯兩邊各拗各的，無限打轉。正解很單純，到 SSL/TLS 的 Overview 把模式改成 Full 或更安全的 Full (strict) 就解了。
順便把四種模式的差別講到底，因為選錯不只是會迴圈，還牽涉資安。Flexible 最要命的地方是它其實是「加密劇場」：訪客瀏覽器上那把鎖是給人心安的，第二段卻是明文，在 Cloudflare 到你主機之間任何一個節點都能被竊聽、竄改。做金流、登入、後台的站台用 Flexible，等於門面上鎖、後門大開，絕不該用。Full 會把第二段加密，但不驗證主機憑證，連自簽憑證都收；Full (strict) 則連憑證的有效性、網域是否相符都驗，是正式站唯一該用的模式。主機端要裝什麼憑證？最省事是裝一張 Cloudflare 的 Origin CA 憑證——它只被 Cloudflare 信任、效期可長達十五年、而且免費，專門給第二段用。要留意一個邊界：Origin CA 憑證只有在橘雲代理下才有效，哪天你把那個子網域改回灰雲直連，瀏覽器不認這張憑證，就得換一張公開受信任的憑證。診斷期間也順手檢查 Always Use HTTPS 與 Automatic HTTPS Rewrites，有沒有跟主機端的轉址規則兩邊互推，那也會繞成一圈。
快取設定：Page Rules 要退場，動態頁千萬別亂快取
先講一個方向性的大事：Page Rules 已經走入歷史。從二〇二五年一月起，官方停止讓帳號新建 Page Rules，既有規則會分批自動遷移到新的 Rules 系列，免費方案本來也只有三條可用。新站請直接上 Cache Rules、Configuration Rules、Redirect Rules。這裡有個容易被忽略、卻會咬人的差異：Page Rules 是第一條命中就套用、由上往下比優先序；新的 Rules 則是可堆疊、後命中者勝，多條規則會依序疊加，同一個設定若被後面的規則再設一次，以最後那條為準。搬家時心裡沒有這個差別，遷完常常發現行為跟原本對不上。舉個實例，若規則一對圖片路徑開快取、規則二對整個網域略過快取，因為規則二排在後面命中，最後全站都會略過快取，跟你以為的相反。
最危險的快取誤用，是對動態頁開「Cache Everything」。它會連 HTML 一起快取，於是 wp-admin、購物車、會員專頁這種因人而異的內容也被存起來，結果把 A 使用者的頁面送給 B 使用者看，等於把別人的訂單、地址、登入狀態外洩出去，這是真實發生過的資安事故，不是嚇唬。要嘛別對這些路徑開，要嘛在 Cache Rules 用 cookie 或路徑條件把動態頁明確排除。想確認某一頁到底有沒有被邊緣存起來，看回應標頭的 cf-cache-status 就好：HIT 是命中快取、MISS 是這次回主機、DYNAMIC 是判定為動態沒快取、BYPASS 是被規則略過，一眼就知道邊緣在做什麼，不必用猜的。
另一個天天被問的是「CSS／JS 明明改了，前台卻還是舊的」。原因就是邊緣節點還在送快取版本，沒清就不會更新。到 Caching 的 Configuration 做 purge，官方建議用單一網址清除最精準，別動不動 Purge Everything——那會把整站快取一次清光，命中率瞬間歸零，所有請求同時打回主機，遇到流量高峰等於自己給自己製造一次負載尖峰。長期更好的做法是檔名帶版本號（cache busting），像 app.v2.css，換個網址邊緣自然抓新檔，根本不必清。臨時要全站繞過快取除錯，可以開 Development Mode，它預設三小時後自動關閉，也不會清掉既有快取。最後把 Edge Cache TTL（檔案在 Cloudflare 邊緣存多久）跟 Browser Cache TTL（在訪客瀏覽器存多久）這兩個觀念分清楚，快取行為就不會再讓你摸不著頭緒。
520 到 526 與根因排查：先分清是誰的問題
看到 5 開頭的 520 到 526，先建立一個共識：這些幾乎都是第二段，也就是 Cloudflare 連你主機這一段出問題，不是 Cloudflare 邊緣壞掉。搞錯方向去改 Cloudflare 設定，只會越弄越亂。逐一拆開：
- 520：主機回了空的或無法辨識的回應，常見於後端程式崩掉、回應被截斷、或標頭超過大小上限。
- 521：主機拒絕連線，最典型是主機防火牆把 Cloudflare 的來源 IP 擋掉了。
- 522：連線逾時，多半也是沒放行 Cloudflare IP，或主機負載過高連不上。
- 523：連不到主機，通常是 DNS 記錄裡的來源 IP 填錯，或路由有問題。
- 524：Cloudflare 連上了主機、但主機在預設的 Proxy Read Timeout（一百二十秒）內沒回 HTTP 回應，常見於跑很久的請求，像大型匯出、報表產生。
- 525：與主機的 SSL 交握失敗，多半是 443 沒開，或憑證、加密套件配置不對。
- 526：Full (strict) 模式下，主機憑證無法通過驗證。
排查有個很省事的通用招：直接用 curl 打主機的真實 IP、繞過 Cloudflare，或暫時把該筆記錄轉成灰雲直連，看通不通，馬上就知道問題是在主機那段還是 Cloudflare 那段，不必兩邊亂猜。對應解法也很有規律。521、522 這種被擋或連不上的，到主機防火牆把 Cloudflare 官方公布的 IP 區段全部放行；同時記得在主機做真實 IP 還原（讀取 CF-Connecting-IP 標頭），否則你的存取日誌全是 Cloudflare 的 IP，某天防禦機制一啟動，反而把真實訪客一起封掉。524 逾時別只想著把長任務搬到一個灰雲、不經代理的子網域治標，那只是繞過時間限制；更該做的是把那種同步卡兩分鐘的請求改成非同步——丟進工作佇列、前端輪詢結果，別讓一個 HTTP 連線硬撐。企業方案雖然能把逾時上限拉到六千秒，但那是最後手段，不是常態解。525、526 就回頭把憑證裝對，最省事一樣是換上 Origin CA 憑證，並確認 443 有開。
橘雲與灰雲：DNS proxy 掛錯，服務會莫名中斷
最後是那朵讓新手最常翻車的雲。橘雲是 proxied，流量會過 Cloudflare、隱藏來源 IP、享有 CDN 加速與 WAF 防護；灰雲是 DNS only，只單純回傳記錄、不做代理，來源 IP 會直接曝光。要記住一條原則：只有 A、AAAA、CNAME 這種跑 HTTP／HTTPS 的記錄能掛橘雲，MX、TXT 這些都不能 proxy，郵件的 MX 記錄一定要維持灰雲，誤開橘雲，信件立刻收發不了，這是掛錯雲最常見的一種災情。
還有一個界線要畫清楚：橘雲代理只支援標準的 HTTP／HTTPS 連接埠，你把 SSH、FTP、郵件、遊戲伺服器這類非 HTTP 的服務掛上橘雲，服務會直接壞掉，因為那條 HTTP 代理鏈根本看不懂非 HTTP 的封包。這種需求要走 Spectrum——它是 Cloudflare 另一條走第四層（TCP／UDP）的代理，能替非 HTTP 服務擋 DDoS、藏來源 IP，但屬於付費方案的功能，不是一般代理能取代的。橘灰雲怎麼掛、哪些記錄該代理、哪些該直連，看似小事，卻是最容易讓服務莫名其妙中斷的地方，設定前務必先想清楚這筆記錄到底跑的是什麼協定。
講到底，Cloudflare 的坑，十有八九不是它本身有毛病，而是它跟你主機、DNS、憑證這三邊的設定沒對齊，偏偏症狀又特別嚇人，一串錯誤碼看得人心慌。廷皓科技深耕高雄與南台灣，服務涵蓋高雄、台南、屏東，從 Cloudflare 導入、SSL 與快取規則調校，到 5xx 與轉址迴圈的根因排查都能接手，一次幫你把網站的速度跟資安顧好。網站接上 CDN 之後狀況不斷，或想趁還沒出事先做一次完整健檢，都歡迎跟廷皓聊聊。
