標籤:
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的支援作進一步調查。
參考資料
MTR /路由跟蹤診斷和使用
捲曲
https://support.cloudflare.com/hc/en-us/articles/200171906-Error-522
CloudFlare Support - Error 522: Connection timed out 錯誤522:連線逾時