了解Cloudflare與源站之間的通信需要追蹤完整的請求路徑。當訪客訪問經Cloudflare代理的域名時，DNS解析會返回Cloudflare的任播IP地址。訪客的瀏覽器會連接到最近的Cloudflare數據中心——這是全球310多個站點中的一部分。Cloudflare的邊緣節點負責處理TLS終止、緩存和安全檢查。對於緩存未命中的情況或動態請求，Cloudflare會建立到源站伺服器的新連接，並轉發帶有修改後標頭的請求，以指示真正的客戶端IP地址。
此路徑會產生多個故障點：DNS配置錯誤、SSL證書問題、源站伺服器過載、網絡連接問題，以及——對本次討論而言至關重要的——基於IP的封鎖阻止了Cloudflare與源站之間的通信。
錯誤代碼分類法
Cloudflare在520-530範圍內的錯誤碼特別表明源站連接問題。瞭解這些碼可加速故障排除。
錯誤 521：Web 伺服器已停機
Error 521表示Cloudflare無法與源伺服器建立TCP連接。源伺服器看似離線或從Cloudflare的網絡無法訪問。常見原因包括：
原始伺服器實際離線（硬體故障、作業系統當機、服務停止）
網路連線中斷（路由問題、網際網路服務供應商問題）
防火牆封鎖Cloudflare IP範圍（最常見的可預防原因）
原始伺服器超載（連接積壓耗盡）
不正确的DNS解析（Cloudflare指向錯誤/已停用的IP）
診斷方法首先從直接源站可訪問性測試開始。您能否直接連接到源站IP？如果可以，則問題特定於Cloudflare的路徑；如果不可以，則源站存在更廣泛的可用性問題。
當直接存取有效但Cloudflare收到521錯誤時，防火牆封鎖便成為首要嫌疑。驗證所有Cloudflare IP位址範圍是否均已列入白名單——104.16.0.0/12、172.64.0.16.0.0/12, 172.64.0.0/13, 162.158.0.0/15, ，以及完整的補充清單——可解決大多數案例。
錯誤 522：連線逾時
錯誤 522 表示 Cloudflare 已成功與來源伺服器建立 TCP 連接，但在設定的逾時時限內（預設為 100 秒）未收到任何 HTTP 回應。這表明源伺服器雖然接受了連接，卻未能做出回應——這通常暗示著存在應用層面的問題，而非網路阻塞所致。
導致此錯誤的原因包括：來源伺服器在接受連線後發生崩潰、資料庫查詢逾時、因資源耗盡而無法產生回應，或來源伺服器啟用了針對「Slowloris」式慢速攻擊的防護機制，從而導致連線過早關閉。
錯誤 523：來源站無法存取
錯誤 523 表示路由失敗－Cloudflare 無法將流量路由至來源站 IP 位址。此錯誤與 521 錯誤（來源站離線）的區別在於，它顯示問題出在網路層而非主機層。 BGP 路由故障、網路分區事件或來源站 IP 位址設定錯誤都可能導致此錯誤。
錯誤 524：發生超時
錯誤 524 表示連線已成功建立且請求已成功發送，但來源伺服器的回應時間超出了 Cloudflare 的逾時限制（免費版/專業版套餐為 100 秒，企業版套餐時間更長）。此類錯誤通常由應用程式效能問題引起，例如資料庫查詢緩慢、依賴外部 API，或計算資源不足。
診斷方法
第一階段：直接溯源測試
首先，在不依賴 Cloudflare 的情況下，驗證來源站的可存取性：
plain
# Basic connectivity
curl -I http://origin-ip/ --connect-timeout 10
# With host header to trigger correct virtual host
curl -I -H "Host: example.com" http://origin-ip/
# HTTPS with certificate validation disabled (for testing only)
curl -I -k -H "Host: example.com" https://origin-ip/成功確認源站功能正常；失敗則表示源站有問題，需進行伺服器層面的檢驗。
第二階段：Cloudflare 路徑測試
專門透過 Cloudflare 網路進行測試：
plain
# Via Cloudflare (should hit edge cache or origin)
curl -I https://www.example.com/
# With cache bypass to force origin connection
curl -I -H "Cache-Control: no-cache" https://www.example.com/Comparing direct-origin and through-Cloudflare behavior isolates where problems emerge.
第三階段：地域差異測試
Cloudflare 的 Anycast 路由機制意味著來自不同訪客的請求會被導向不同的資料中心。因此，某些問題可能僅影響特定區域，其成因可能包括：路由異常、來源伺服器針對特定區域的屏蔽，或特定資料中心內部的設定故障。
從不同地理位置進行測試，有助於揭示此類問題模式。 IPFLY 的住宅代理商網路能夠實現高度逼真的測試環境—透過連接至全球 190 多個國家/地區，模擬真實本地用戶的存取體驗。此外，靜態住宅代理能為特定區域提供穩定的測試存取點，從而協助偵測那些僅影響部分全球使用者群體、而對其他使用者無礙的地域性連線故障。
舉例而言，若歐洲用戶回饋遭遇存取錯誤，而北美用戶卻未受影響，此時透過 IPFLY 的歐洲住宅代理進行測試，不僅能確認故障的地域範圍，還能協助排查問題的具體根源：究竟是 Cloudflare 歐洲資料中心與來源伺服器之間的連接規則受阻，是區域性防火牆外屏蔽了特定的 Cloudflare IP 網段，還是特定路由特定的網路內部。
第四階段：IP 白名單驗證
當懷疑有防火牆阻斷時，進行全面的白名單驗證就顯得格外必要。驗證工作通常包括：
確認所有 Cloudflare IPv4 位址段均已獲準通行：包括 104.16.0.0/12、172.64.0.0/13、162.158.0.0/15、198.41.128.0/17，以及其他補充位址段。
若適用，需驗證對應的 IPv6 位址段（Cloudflare 擁有龐大的 IPv6 基礎架構）。
檢查近期規則更新是否在防火牆規則中引入了語法錯誤。
確認規則的執行順序－需警惕那些更具體的「拒絕」（DENY）規則是否被置於 Cloudflare 的「允許」（ALLOW）規則之前。
利用自動化驗證工具，可以系統性地探測 Cloudflare 各個 IP 位址段對來源站的可存取性，從而精準定位具體被阻斷的位址段，而非僅僅得出「正常」或「故障」這種非黑即白的二元結論。
常見配置錯誤
不完整的範圍更新
企業往往會將 Cloudflare 的「主要」IP 網段（104.16.0.0/12、172.64.0.0/13）列入白名單，卻遺漏了其補充網段。一旦 Cloudflare 透過這些較不常用的網段路由流量，便會引發神秘的間歇性故障——這些故障看似隨機，實則取決於具體由哪一個 Anycast 節點來回應請求。
限流衝突
Fail2ban、ModSecurity 及類似工具均透過統計每個 IP 位址的請求量來進行監控。鑑於所有流量在表面上均源自 Cloudflare 的 IP 位址，若採用過於激進的速率限制策略，極易引發“誤報”，從而導致 Cloudflare 服務被徹底屏蔽。因此，在進行配置時必須充分考慮到這種流量集中現象——具體做法包括將 Cloudflare 的 IP 位址列入速率限制的“白名單”，或適當調整相應的限制閾值。
TLS 憑證不符
Cloudflare 與來源伺服器建立連線時，會使用原始請求中的主機名稱作為 SNI 標識。如果來源伺服器提供的憑證所對應的主機名稱與實際不符，或者 Cloudflare 的 SSL 模式與來源伺服器的能力不匹配，就會導致 TLS 握手失敗。在「完全（嚴格）」模式下，來源伺服器必須配置有效的憑證；而在「靈活」模式下，雖然允許來源伺服器使用未加密連接，但其安全性相對較低。
DNS 解析問題
Cloudflare 會針對每項要求，將來源站主機名稱解析為 IP 位址。如果 DNS 回傳了多個 IP 位址，且其中部分不可用，Cloudflare 可能會在找到正常運作的伺服器之前，請嘗試連接那些失效的伺服器，從而導致延遲或錯誤。透過來源站監控和 DNS 健康檢查，可以有效避免此類情況的發生。
進階故障排除
資料包擷取分析
對於那些難以解開的疑難問題，在來源端進行資料包捕獲，即可揭示實際到達的內容。
plain
tcpdump -i eth0 host <cloudflare-ip> -w /tmp/cloudflare-traffic.pcap分析結果顯示了 SYN 封包是否到達（從而排除了網路阻斷的可能性）、TLS 握手是否完成，以及通訊中斷的具體位置。
Cloudflare Spectrum 與非 HTTP 協定
對於 HTTP/HTTPS 以外的 TCP 應用程序，Cloudflare Spectrum 可代理任意協定。相關的 IP 位址範圍考慮仍然適用，但診斷工具會有所不同——通常使用 telnet 或 nc 來檢測連接埠連通性，並使用特定協定的用戶端來進行應用程式測試。
已認證來源站拉取調試
在使用 TLS 用戶端認證時，憑證驗證失敗會導致連線在應用層處理之前即被阻斷。透過驗證憑證鏈、過期日期以及中間 CA 配置，即可解決此類問題。
解析度測試圖
即時緩解
當來源站的可存取性至關重要且故障排查時間緊迫時，暫時停用 Cloudflare 代理程式（即「灰雲」化 DNS 記錄）可以繞過故障路徑，從而直接向訪客暴露來源站 IP。儘管此舉會喪失 Cloudflare 提供的安全防護與效能最佳化優勢，但能在進行根本原因分析的同時，恢復服務的正常運作。
防火牆規則修正
大多數 521 錯誤可透過更新防火牆配置以允許所有 Cloudflare IP 範圍來解決。具體機制因情況而異：
- AWS 安全群組：為 Cloudflare CIDR 範圍新增連接埠 80/443 的入站規則
- iptables：在預設的 DROP 規則之前插入 ACCEPT 規則
- CSF/cPanel：將其新增至 /etc/csf/csf.allow 檔案中
- Azure NSG：使用 Cloudflare 服務標籤或明確的 IP 範圍建立入站安全性規則
長期架構改進
放棄基於 IP 的安全機制，轉而採用經身份驗證的拉取或基於隧道的連接方式，可有效防止此類問題再次發生。 Cloudflare Tunnel 無需配置入站防火牆規則，並提供自動故障轉移功能。基於憑證的驗證機制可確保—無論是否知道 IP 位址—僅 Cloudflare 能夠建立連線。
系統化故障排除
Cloudflare 與來源站之間的連接故障往往呈現出可預測的規律。透過系統化的診斷——即區分網路層與應用層、直接路徑與代理路徑、以及不同地理區域的差異——能夠迅速定位問題的根本原因。儘管對於許多架構而言，維護 IP 白名單仍然是必要的，但現代化的替代方案正日益普及，並有望徹底消除這一維運負擔。
對於那些仍沿用傳統配置的組織而言，從多元化的網路視角進行全面測試至關重要；這有助於驗證防護機制是否如預期般正常運作，且未誤攔任何正常的流量。
當遭遇 521 錯誤時，若需區分故障究竟源自於源站還是 Cloudflare 的攔截，從多元化的網路視角進行全面測試便顯得至關重要。 IPFLY 的代理基礎設施能為您提供所需的診斷能力。利用我們的住宅代理，您可以從全球 190 多個國家和地區測試網路連通性，從而判定故障是全球性的還是僅限於特定區域。部署我們的靜態住宅代理，即可從特定地理位置進行持續監控，在路由異常影響用戶之前將其及時捕獲。此外，您還可以利用我們的資料中心代理進行高吞吐量的負載測試，以驗證您的來源站是否能夠妥善承載 Cloudflare 轉送的龐大流量，避免因連線資源耗盡而引發故障。憑藉毫秒級的反應速度確保精準的時序測量、99.9% 的正常運行時間保障監控的可靠性、支援無限並發連接以實現全面測試，以及全天候（24/7）的技術支援協助解決複雜的診斷難題，IPFLY 將故障排查工作從盲目的猜測轉化為系統化的驗證過程。切勿讓那些撲朔迷離的 521 錯誤損害您的服務可用性——立即註冊 IPFLY，獲取您在 Cloudflare 故障排查工作中所需的多元化網路資源。
