當域名啟用 Cloudflare 的代理服務時，其基礎網絡行為將發生改變。DNS 查詢返回的是 Cloudflare 的 IP 地址而非源服務器的 IP 地址，從而將 Cloudflare 的 Anycast 網絡確立為流量終結點。所有訪客的請求都會先經過 Cloudflare 的基礎設施（全球 310 多個數據中心）的轉發，然後才到達源服務器。
該架構帶來了顯著優勢：通過邊緣流量分流實現 DDoS 防護、Web 應用防火牆（WAF）檢測、機器人管理以及全球內容緩存。然而，它從根本上改變了安全邊界。源服務器不再接收來自不同訪問者 IP 的流量；相反，所有經過代理的請求看起來都似乎源自 Cloudflare 的 IP 範圍。
Cloudflare 運營著幾個主要的 IPv4 網絡塊：104.16.0.0/12（1,048,576 個地址）、172.64.0.0/13（524,288 個地址）、 162.158.0.0/15（131,072 個地址），以及包括 173.245.48.0/20、188.114.96.0/20 和 198.41.128.0/17 在內的眾多較小地址段。 這些地址段共同構成了 Cloudflare 任播路由基礎設施的主幹。
白名單挑戰
傳統的安全實踐側重於基於 IP 的訪問限制——例如防火牆規則、安全組配置以及僅允許授權來源訪問的入侵防禦系統。Cloudflare 的代理模型使這種方法變得更為複雜。
當所有合法流量看似都源自 Cloudflare 的 IP 地址時，那些未考慮此架構的簡單防火牆配置會無意中阻擋合法訪問者。反之，若僅將所有 Cloudflare IP 範圍加入白名單，則會產生潛在的安全漏洞：如果攻擊者（通過 DNS 歷史記錄、證書透明度日誌或配置錯誤）發現了源服務器的 IP 地址，他們便可直接連接到源服務器，從而完全繞過 Cloudflare 的保護。
安全界已開發出多種架構模式來應對這些挑戰。
傳統的白名單方法
防火牆配置
對於仍採用傳統基於IP的安全方案的組織而言，將Cloudflare的IP地址範圍加入白名單仍然是必要的。完整列表如下：
- 104.16.0.0/12
- 172.64.0.0/13
- 162.158.0.0/15
- 198.41.128.0/17
- 108.162.192.0/18
- 141.101.64.0/18
- 173.245.48.0/20
- 188.114.96.0/20
- 103.21.244.0/22
- 103.22.200.0/22
- 103.31.4.0/22
具體實現因平臺而異。AWS 安全組需要設置允許這些 IP 範圍訪問 80/443 端口的入站規則。iptables 配置中，必須在默認的 DROP 策略之前顯式添加 ACCEPT 規則。使用 fail2ban 的 NGINX 需要添加包含 Cloudflare IP 範圍的 ignoreip 聲明，以防止意外阻斷。
不過，這種方法需要持續維護。Cloudflare會定期添加新的IP範圍；一旦白名單過時，隨著新的任播IP被屏蔽，就會導致莫名其妙的連接失敗。
經過身份驗證的源拉取
除了 IP 白名單機制外，Cloudflare 還提供了經過身份驗證的源站拉取機制。TLS 客戶端身份驗證證書可確保只有 Cloudflare 的基礎設施才能與源站服務器建立連接，即使攻擊者發現了源站 IP 地址也是如此。這種基於證書的方法比單純的 IP 白名單機制更為穩健，因為證書無法通過偽造 IP 地址進行欺騙。
現代零信任架構
基於 IP 的安全方案的侷限性推動了零信任模型的採用——這種架構會驗證每一條連接，無論其來源看似如何。在 Cloudflare 的支持下，零信任原則通過多種機制得以體現。
基於身份的訪問控制
與僅依賴 Cloudflare IP 外觀來信任連接不同，現代實現方案會通過多種因素來驗證身份：設備證書、用戶身份驗證令牌以及行為分析。Cloudflare Access 提供了這一功能，可在流量到達源服務器之前，在邊緣端強制執行身份驗證。
基於隧道的連接
Cloudflare Tunnel（原名 Argo Tunnel）可在源服務器與 Cloudflare 網絡之間建立出站連接，從而完全避免了源 IP 地址暴露在公共網絡中的情況。源服務器通過本地隧道守護進程進行連接，無需配置入站防火牆規則。這種架構消除了源 IP 地址暴露所帶來的攻擊面，因此無需進行 IP 白名單設置。
基於標頭的驗證
對於需要直接訪問源服務器的應用，自定義標頭提供了驗證機制。Cloudflare 可以注入經過加密簽名的標頭（X-Cloudflare-Token），由源服務器進行驗證，從而確保請求確實通過 Cloudflare 的基礎設施傳輸，無論其顯示的源 IP 地址為何。
自帶IP（BYOIP）架構
企業部署有時需要自定義 IP 地址。Cloudflare 的 BYOIP 功能允許客戶通過 Cloudflare 的任播網絡發佈其自有 IP 地址段。
在 BYOIP 配置中，DNS 返回的是客戶擁有的 IP 地址（例如 152.3.15.0/24），而非 Cloudflare 的默認地址段。流量通過 BGP 公告的客戶前綴路由至 Cloudflare 網絡，隨後被代理至源服務器（可能使用獨立的客戶自有地址段，如 152.3.14.0/24）。
該架構滿足了企業的多項需求：IP信譽管理、遵守地址分配法規，以及從自建基礎設施的無縫遷移。然而，這也帶來了額外的複雜性——客戶必須提供授權書（LOA）以發佈IP地址段，並確保所分配的專用地址空間在其環境中未被其他用途佔用。
IP情報與威脅檢測
雖然 Cloudflare 負責邊緣安全防護，但源服務器也能借助有關實際訪問者來源地的 IP 情報。CF-Connecting-IP 標頭會將真實的客戶端 IP 地址通過 Cloudflare 的基礎設施傳遞出去，從而使源服務器能夠基於訪問者的實際位置（而非 Cloudflare 的任播節點）進行速率限制、地理定位和欺詐檢測。
對於需要全面 IP 情報的應用（如安全平臺、欺詐防範系統或分析引擎），額外的代理基礎設施可補充 Cloudflare 的功能。IPFLY 的住宅代理網絡提供真實的 IP 多樣性，可用於從不同地理角度測試源服務器的行為，從而確保 CF-Connecting-IP 處理、地理定位邏輯以及區域內容分發在 Cloudflare 的全球基礎設施中正常運行。
IPFLY 的數據中心代理通過 Cloudflare 網絡提供高吞吐量、低延遲的連接，用於對源基礎設施進行負載測試——從而驗證在真實的流量模式下，速率限制、緩存行為和動態內容生成能否正常運行。憑藉毫秒級的響應時間和 99.9% 的正常運行時間，IPFLY 的基礎設施可支持對受 Cloudflare 保護的架構進行全面驗證。
監測與驗證
要有效部署 Cloudflare，需要持續監控源站的可訪問性。常見的故障模式包括：證書過期導致認證拉取失敗、防火牆規則變更意外阻斷 Cloudflare 地址範圍，以及源服務器資源耗盡導致 521 錯誤（Web 服務器不可用）。
通過多種網絡路徑（包括模擬真實用戶連接的住宅代理網絡）進行合成監控，可驗證端到端可用性。IPFLY 的靜態住宅代理提供來自特定地理區域的穩定監控端點，從而能夠檢測可能影響部分全球用戶的區域性任播路由問題或源服務器訪問問題。
建築演變
Cloudflare 的 IP 範圍管理已從簡單的白名單機制發展為複雜的零信任架構。現代部署方案越來越傾向於採用基於隧道的連接、證書認證以及基於身份的訪問控制，而非基於 IP 的信任機制。然而，瞭解 Cloudflare 的 IP 基礎設施對於故障排除、舊系統集成以及結合多層防護的混合架構而言，仍然至關重要。
這一根本性轉變表明，在當今的威脅環境下，IP 地址——無論是 Cloudflare 的任播地址範圍還是源服務器 IP——都無法提供足夠的安全保障。要實現全面防護，必須採取多層次防禦策略：包括邊緣防護、源服務器加固、認證連接，以及無論流量來源如何，都要進行持續監控。
要在 Cloudflare 後端保護源服務器，僅靠正確的 IP 白名單還遠遠不夠——還需要從多種網絡角度進行全面測試，以確保您的防護措施切實有效。IPFLY 的住宅和數據中心代理網絡為全面驗證您的 Cloudflare 保護架構提供了基礎設施。 使用我們的靜態家庭用戶代理，模擬來自 190 多個國家的真實用戶連接，驗證地理定位、CF-Connecting-IP 處理以及區域內容分發功能是否正常。利用我們高吞吐量的數據中心代理，通過 Cloudflare 網絡對源站容量進行負載測試，確保您的基礎設施在處理峰值流量時不會出現 521 錯誤或性能下降。 憑藉毫秒級響應時間、99.9% 的運行時間、支持大規模測試的無限併發數以及 24/7 技術支持，IPFLY 可無縫集成到您的 Cloudflare 安全驗證工作流中。切勿等到生產環境中才發現配置漏洞——立即註冊 IPFLY，在攻擊者得手之前全面測試您的源站保護方案。
