Błąd Cloudflare 522: przekroczono limit czasu - przyczyny i naprawa

Co oznacza błąd 522

Każde żądanie przekazywane przez Cloudflare zaczyna się od otwarcia przez Cloudflare połączenia TCP do Twojego serwera źródłowego, zanim będzie mogło wysłać samo żądanie HTTP. Błąd 522 pojawia się, gdy ten handshake, SYN TCP i oczekiwany w odpowiedzi SYN-ACK, nie kończy się w oknie czasowym Cloudflare. Serwer źródłowy może być zbyt przeciążony, żeby przyjąć nowe połączenia, zapora może po cichu porzucać pakiety zamiast je odrzucać, albo trasa sieciowa między Cloudflare a serwerem źródłowym może być zatłoczona.

Różni się to od błędu 521, gdzie serwer źródłowy aktywnie odmawia połączenia, i od błędu 524, gdzie połączenie TCP się udaje, ale sama odpowiedź HTTP nigdy nie przychodzi na czas. Błąd 522 to konkretnie awaria na etapie handshake'u, zanim jakiekolwiek żądanie HTTP zostanie w ogóle wysłane.

Jak pojawia się błąd 522

Odwiedzający widzą stronę Cloudflare, "Error 522: connection timed out", z Ray ID. Żądanie curl pod domenę pokazuje ten sam status po mniej więcej oknie czasowym Cloudflare:

curl -I https://example.com
HTTP/2 522

Ponieważ handshake TCP nigdy się nie zakończył, żadne żądanie nie dotarło do Twojej aplikacji, więc logi aplikacji są zwykle puste dla okresu awarii. Zamiast tego przyjrzyj się metrykom na poziomie połączeń: obciążenie serwera i CPU w chwili błędów, liczbę połączeń nawiązanych i oczekujących (ss -s albo netstat -an | grep SYN_RECV) oraz logi zapory albo load balancera pod kątem porzuconych albo odfiltrowanych pakietów na danym porcie.

Co powoduje błąd 522

• Serwer źródłowy jest przeciążony i nie może wystarczająco szybko przyjmować nowych połączeń. Wysokie CPU, pełna kolejka backlogu połączeń albo wyczerpana pula workerów, wszystko to produkuje ten efekt.
• Zapora albo grupa bezpieczeństwa po cichu porzuca pakiety SYN Cloudflare zamiast wysłać reset TCP. Porzucenie wygląda z perspektywy Cloudflare identycznie jak wolny albo martwy serwer, podczas gdy reset zamiast tego wyprodukowałby błąd 521.
• TCP keepalive jest wyłączony na serwerze źródłowym, co zwiększa rotację połączeń i szansę, że nowy handshake trafi w moment, gdy serwer jest zbyt zajęty, żeby go przyjąć.
• Adres IP serwera źródłowego nie jest poprawnie dodany do listy dopuszczonych tam, gdzie sieć wymaga jawnej listy dopuszczonych zamiast prostej reguły zapory, więc żądania Cloudflare są filtrowane, zanim dotrą do nasłuchującego gniazda.
• Zatory sieciowe albo utrata pakietów między Cloudflare a serwerem źródłowym, częstsze przy serwerach źródłowych za hostingiem klasy konsumenckiej albo mocno przewymiarowanym.

522 kontra 524

Oba kody to timeouty, ale zdarzają się w różnych punktach żądania. Błąd 522 zdarza się, zanim jakiekolwiek żądanie HTTP zostanie wysłane: sam handshake TCP nigdy się nie kończy. Błąd 524 zdarza się po nim: połączenie TCP się udaje i Cloudflare wysyła żądanie HTTP, ale serwer źródłowy nie odsyła pełnej odpowiedzi w ciągu 100 sekund. 524 zwykle wskazuje na wolną aplikację, na przykład endpoint generujący raport, długie zapytanie do bazy danych albo żądanie uruchamiane przez cron, które zasadnie trwa minuty. Naprawą 524 jest niemal zawsze przyspieszenie endpointu albo przeniesienie wolnej pracy poza cykl żądanie-odpowiedź do zadania w tle, o którego wynik klient odpytuje; plany Cloudflare Enterprise mogą też podnieść limit 100 sekund dla konkretnych tras, ale to leczy objaw, nie sam wolny endpoint.

Jak rozpoznać, kto zawinił

522 niemal zawsze pochodzi z serwera źródłowego albo jego okolicy, bo własna sieć Cloudflare jest wysoko dostępna i rzadko jest źródłem timeoutu handshake'u. Użyteczne pytanie brzmi, czy serwer źródłowy w ogóle nie działa, czy tylko zmaga się z obciążeniem z określonych regionów. Najszybszym sposobem sprawdzenia jest uruchomienie kontroli HTTP z kilku lokalizacji naraz: kontrola HTTP HostTrackera odpytuje domenę z punktów kontrolnych w wielu krajach i raportuje każdy z osobna, więc wzorzec, w którym niektóre lokalizacje przekraczają limit czasu, a inne kończą się sukcesem, wskazuje na przeciążony serwer obsługujący część żądań, ale nie wszystkie, podczas gdy jednolity timeout wszędzie wskazuje na całkowicie martwy serwer źródłowy albo zaporę porzucającą każde połączenie.

Jak naprawić błąd 522

Jeśli jesteś odwiedzającym

1. Przeładuj po krótkiej chwili. Chwilowy skok obciążenia albo krótka usterka sieciowa często ustępuje sama.
2. Sprawdź stronę statusu witryny, jeśli taką ma, pod kątem znanego incydentu.
3. Nie ma nic do naprawienia po Twojej stronie. Timeout dzieje się między Cloudflare a własnym serwerem witryny, nie w Twojej przeglądarce ani w Twoim połączeniu z Cloudflare.

Jeśli prowadzisz witrynę

1. Sprawdź obciążenie serwera i dostępną pojemność połączeń w chwili awarii: CPU, pamięć i skonfigurowane limity połączeń albo workerów serwera WWW (na przykład worker_connections w nginx).
2. Potwierdź, że Twoja zapora albo grupa bezpieczeństwa dopuszcza opublikowane zakresy IP Cloudflare na danym porcie i że odrzuca resetem zamiast po cichu porzucać pakiety, co przynajmniej zamienia 522 w łatwiejszy do zdiagnozowania 521.
3. Włącz TCP keepalive na serwerze WWW serwera źródłowego i na każdym load balancerze przed nim, i sprawdź, czy ustawienia keepalive na poziomie systemu operacyjnego nie zostały na wartościach domyślnych znacznie dłuższych, niż faktycznie potrzebuje połączenie.
4. Jeśli Twój hosting albo sieć w chmurze wymaga jawnej listy dopuszczonych IP oddzielnej od zapory, potwierdź, że IP serwera źródłowego jest na niej.
5. Zmierz surowy handshake bezpośrednio wobec serwera źródłowego, omijając Cloudflare, żeby zobaczyć, czy opóźnienie leży w ogóle w dotarciu do Twojego serwera:

   curl -v -H "Host: example.com" --connect-timeout 5 https://ORIGIN_IP/

   Połączenie, które tu wisi, potwierdza, że sam serwer źródłowy wolno przyjmuje połączenia, nie coś specyficznego dla Cloudflare.
6. Dla wolnych pojedynczych endpointów, a nie ogólnie przeciążonego serwera, przenieś długo trwającą pracę (raporty, eksporty, zadania wsadowe) poza ścieżkę żądania do zadania w tle, o które klient odpytuje albo o którym jest powiadamiany, a podniesienie limitu czasu w Cloudflare Enterprise rozważ tylko jako rozwiązanie tymczasowe dla tras, których nie da się szybko przyspieszyć.

Jak temu zapobiec

Serwer, który zawodzi handshake tylko pod szczytowym obciążeniem, przejdzie każdą ręczną kontrolę, jaką sam uruchomisz, bo mało prawdopodobne jest, żebyś testował go dokładnie w momencie, gdy się zmaga. Kontrola HTTP działająca według harmonogramu spoza Twojej sieci wyłapuje to okno awarii nawet wtedy, gdy nikt nie patrzy, a uruchamianie jej z wielu krajów pokazuje, czy spowolnienie to globalna pojemność, czy regionalna trasa sieciowa.

Powiązane błędy

• Błąd Cloudflare 520: nieznany błąd - serwer źródłowy odpowiedział, ale odpowiedź była nieużyteczna.
• Błąd Cloudflare 521: serwer WWW nie działa - serwer źródłowy odmówił połączenia zamiast nie odpowiadać.
• Błędy serwera 5xx - ogólna rodzina kodów statusu.
• 502 Bad Gateway - wersja niedotycząca konkretnie Cloudflare awarii upstreama.

Najczęściej zadawane pytania

Jak długo Cloudflare czeka, zanim pokaże błąd 522?

Około 15 sekund na handshake TCP. Jeśli serwer źródłowy nie zaakceptował połączenia do tego czasu, Cloudflare rezygnuje i zwraca odwiedzającemu 522.

Czy 522 to to samo co wyłączenie mojego serwera?

Nie zawsze. Może też oznaczać, że serwer działa, ale jest zbyt zajęty, żeby na czas przyjąć nowe połączenie, albo że zapora porzuca próbę połączenia bez wysyłania resetu.

Dlaczego zapora porzuca połączenie zamiast je odrzucić?

Niektóre domyślne konfiguracje zapory albo grupy bezpieczeństwa po cichu odrzucają pakiety niepasujące do reguły dopuszczającej, zamiast wysyłać reset TCP. To ciche porzucenie zamienia to, co mogłoby być szybkim, wyraźnym 521, w wolniejszy, bardziej niejednoznaczny 522.

Czy 522 oznacza, że muszę rozbudować serwer?

Niekoniecznie. Zanim zaczniesz skalować, sprawdź, czy keepalive jest wyłączony, czy zapora po cichu porzuca zakresy Cloudflare, i czy limity połączeń w konfiguracji serwera WWW nie są ustawione niżej, niż faktycznie wymaga ruch.

Jaka jest różnica między 522 a 524?

522 to niepowodzenie nawet w dokończeniu handshake'u TCP. 524 to zakończone połączenie, w którym sama odpowiedź HTTP zajmuje zbyt dużo czasu, zwykle z powodu wolnej logiki aplikacji, a nie problemu sieciowego czy pojemnościowego.

Czy pojedyncze wolne zapytanie do bazy danych może spowodować 522?

Nie bezpośrednio, bo 522 zdarza się, zanim jakiekolwiek żądanie zostanie wysłane. Wolne zapytanie prędzej wyprodukuje 524, gdzie połączenie się udało, ale odpowiedź zbyt długo docierała.