522錯誤意味着我們無法在所有到達原點Web服務器。
這方面有幾個主要原因：
- 原始服務器太超載回應。
- 源Web服務器具有擋住了我們的請求的防火牆，或者數據包被主機的網絡內下降。
- 源Web服務器脫機，或與我們不正確的DNS設置為它的IP地址設置（即離我們的要求是送錯了地方）。
- 還有我們和原始Web服務器之間的網絡路由問題。
- 起源服務器保持連接禁用。
在所有這些情況下，這是值得檢查原點Web服務器是活動的，才去進一步這里接受HTTP請求，同時也與我們在您的帳戶的DNS設置正確。
原始服務器太超載回應
確保源服務器不會過載。如果是，它可能是丟棄請求。一般來說，要檢查一個好處是平均負載。在Linux / Unix上，你可以通過在命令行上的“W”運行命令，或使用'頂'命令檢查檢查。什么構成根據負載值可以根據計算機並在其上運行的軟件上，但一般來說過10-20的平均負載左右可能意味着該服務器超載不同的高負荷。這是最適合您的主機或這個系統管理員來檢查，如果你不確定。
起源有防火牆（或速率限制器），它擋住了我們的請求
這是間歇522錯誤的最常見的原因。關鍵的事情要檢查最初是 -
- 請確保你沒有在.htaccess，iptables的，或您的防火牆阻止CloudFlare的IP地址。
- 確保您的托管服務提供商是不是速率限制或阻止來自CloudFlare的IP地址IP請求，並要求他們在白名單地址中提到的IP地址http://www.cloudflare.com/ips
當流量通過CloudFlare的一個網站，原點將首先看到的要求從我們走來。大多數通過CloudFlare的網站的要求會出現只來自我們的IP地址了一把。正因為如此，這往往引發防火牆和IP率限制器從我們這里塊請求，認為該網站受到攻擊。CPHulk（附帶的cPanel）和其他服務已經知道做到這一點。前阻止這種情況的發生，確保中提到的IP地址，這里 已經被列入白名單，或者完全禁用速率限制。
有CloudFlare的和原始Web服務器之間的網絡路由問題
這是更困難比其他原因，排除故障，並最好以確保其他潛在原因已被排除出檢查在此之前。如果您認為是這樣的話，請提出與我們的支持團隊支持票。有用的信息，為用戶提供這將是─
- 迄今已簽什么樣的信息。
- 港鐵或traceroute的從服務器到我們其中一個IP地址，最好是你已經看到在過去離我們請求的IP地址之一。你可以找到如何運行的地鐵或跟蹤路由信息在這里。
原始服務器保活已禁用
CloudFlare的使用的Keep-Alive標頭以提高性能。禁用它將導致從連接失敗，並在某些情況下返回522s。此功能默認情況下，在大多數主要的Web服務器的當前版本，因此，除非你明確禁用它，這不應該是一個問題。
究竟是什么觸發522錯誤？
當CloudFlare的無法建立一個TCP連接到該網站的原始服務器522錯誤響應返回。
當有人訪問啟用CloudFlare的專用網站，一個連接的CloudFlare和網站的源服務器之間建立的。要建立連接，TCP使用三次握手。
- SYN：CloudFlare的發送三個SYN包到源服務器。
- SYN + ACK：在響應中，源服務器用SYN + ACK應答。
- ACK：最后的CloudFlare發送一個ACK返回給源服務器。
在這一點上，CloudFlare的和源服務器都已經收到的連接確認和建立通信。如果源服務器沒有在15秒內發送一個SYN + ACK回的CloudFlare，將出現522錯誤，並關閉連接。
這里是示出一個成功的TCP握手的圖：
這里是在未從原始服務器15秒內返回的SYN + ACK，觸發522超時的例子：
當起源與SYN + ACK響應並建立TCP連接，但從來沒有響應90秒（524條件的ACK請求中的ACK請求發生了522超時另一個條件，但等待時間過長發送響應）。下面是一個例子，詳細說明這樣的情景：
檢查與您的服務器管理員這些條件或托管服務提供商是解決這些錯誤的最好方法。如果有網絡問題，一個跟蹤路由從網站起源或地鐵可能是有用的（與下文）。
如果繼續看排除上述可能性，並解決該問題后，522錯誤，請聯系CloudFlare的支持作進一步調查。
參考資料
https://support.cloudflare.com/hc/en-us/articles/200171906-Error-522