Błąd Cloudflare 520: co oznacza i jak go naprawić

Co oznacza błąd 520

Cloudflare siedzi między odwiedzającym a Twoim serwerem WWW jako reverse proxy. Przy normalnym żądaniu otwiera połączenie TCP do Twojego serwera źródłowego, wysyła żądanie i przekazuje dalej dowolną odpowiedź HTTP, jaka wraca. Błąd 520 pojawia się, gdy ten ostatni krok zawodzi: połączenie TCP się udaje, ale bajty, które przychodzą potem, nie parsują się jako poprawna odpowiedź HTTP, albo żadne bajty w ogóle nie docierają, zanim połączenie się zamknie.

To stawia 520 w innej kategorii niż pozostałe kody 5xx Cloudflare. Błąd 521 oznacza, że serwer źródłowy wprost odmówił połączenia. Błąd 522 oznacza, że próba połączenia przekroczyła limit czasu. Błąd 520 oznacza, że serwer źródłowy coś powiedział, a Cloudflare nie umiało tego zrozumieć ani przekazać dalej.

Jak pojawia się błąd 520

W przeglądarce Cloudflare pokazuje własną stronę błędu, "Error 520: web server returned an unknown error", razem z Ray ID, który będzie Ci potrzebny, jeśli skontaktujesz się ze wsparciem Cloudflare. Zwykłe żądanie curl pod domenę pokazuje ten sam kod statusu:

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

Po stronie Cloudflare zakładki Security albo Analytics w panelu pokazują skok liczby odpowiedzi 5xx, a konta Enterprise z dostępem do Logpull albo Logpush mogą pobrać konkretne edge colo i Ray ID dla każdego nieudanego żądania. Nic z tego nie mówi jednak, co faktycznie wysłał serwer źródłowy, więc kolejnym miejscem do sprawdzenia jest Twój własny serwer.

Na serwerze źródłowym sprawdź logi serwera WWW i aplikacji pod tym samym znacznikiem czasu co awarie. Szukaj restartu procesu, naruszenia ochrony pamięci, zabicia procesu z powodu braku pamięci w logu systemowym (dmesg albo journalctl -k) albo błędu aplikacji, który przerwał żądanie w połowie odpowiedzi. Jeśli logi aplikacji nie pokazują niczego niezwykłego, problem to raczej odpowiedź, która technicznie się zakończyła, ale złamała regułę HTTP, na przykład zbyt duży nagłówek.

Co powoduje błąd 520

• Proces serwera źródłowego zawiesił się albo zrestartował podczas obsługi żądania. Połączenie zamyka się, zanim wyjdzie pełna odpowiedź. To najczęstsza przyczyna.
• Serwer źródłowy zresetował połączenie TCP (RST) zamiast zamknąć je czysto. Serwery aplikacji pod presją pamięci albo osiągające limit czasu workera często tak robią.
• Nagłówki odpowiedzi przekraczają limit 16 KB Cloudflare. Duży nagłówek set-cookie, stos nagłówków debugowania albo obszerne nagłówki CORS mogą przepchnąć sumę powyżej tego, co Cloudflare zaakceptuje.
• Zbyt duże ciasteczko albo połączony nagłówek ciasteczek. Dane sesji, ciasteczka śledzące albo źle skonfigurowany magazyn ciasteczek mogą z czasem urosnąć powyżej limitów przeglądarki i proxy.
• Brakująca albo wadliwa linia statusu. Niektóre frameworki zwracają surowy ciąg błędu zamiast poprawnej odpowiedzi HTTP, gdy nieobsłużony wyjątek dociera do warstwy serwera WWW.
• Serwer źródłowy zwrócił dane inne niż HTTP na porcie HTTP(S). Zdarza się to po źle skonfigurowanym reverse proxy, błędnym mapowaniu portów albo usłudze, która zajmuje port, zanim zrobi to prawdziwy serwer WWW.
• Urządzenie zabezpieczające albo WAF przed serwerem źródłowym zabiło połączenie w połowie odpowiedzi. Niektóre lokalne WAF-y i load balancery kończą połączenia, które naruszają regułę, co z perspektywy Cloudflare wygląda identycznie jak awaria.

Jak rozpoznać, kto zawinił

Skoro Cloudflare faktycznie dostało odpowiedź z serwera źródłowego, błąd 520 to mocny sygnał, że problem leży po stronie serwera źródłowego, a nie w sieci Cloudflare, w odróżnieniu od błędu 521 czy 522, gdzie samo połączenie zawiodło. Otwartym pytaniem zwykle jest, czy dotyczy to każdego odwiedzającego, czy tylko niektórych.

Najszybszym sposobem, żeby to rozdzielić, jest uruchomienie kontroli HTTP z kilku lokalizacji naraz. Jeśli kontrola publicznej domeny zawodzi ze wszystkich lokalizacji w tym samym czasie, gdy użytkownicy zgłaszają błąd, sam serwer źródłowy nie działa albo zawiesza się dla wszystkich, nie tylko dla jednego centrum danych na brzegu sieci. Jeśli zawodzi tylko sporadycznie albo z konkretnych regionów, serwer źródłowy może być przeciążony ruchem z tego regionu, albo zaangażowana jest warstwa cache'owania albo load balancingu obecna tylko w części Twojej konfiguracji. Kontrola HTTP HostTrackera działa z punktów kontrolnych w wielu krajach i raportuje wynik każdego z osobna, co jest szczegółem, którego pojedynczy curl z Twojego własnego biurka Ci nie da.

Możesz też całkowicie odizolować serwer źródłowy od Cloudflare, łącząc się bezpośrednio z nagłówkiem Host domeny, omijając sieć brzegową, żeby dowolny błąd, jaki zobaczysz, był bezsprzecznie błędem serwera źródłowego:

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

Zastąp ORIGIN_IP prawdziwym adresem IP swojego serwera. Jeśli to bezpośrednie żądanie też zawodzi albo zwraca tę samą zepsutą odpowiedź, wina po stronie serwera źródłowego jest potwierdzona.

Jak naprawić błąd 520

Jeśli jesteś odwiedzającym

1. Przeładuj stronę po minucie lub dwóch. Wiele błędów 520 pochodzi z krótkiej awarii albo restartu, po którym własny nadzorca procesu witryny automatycznie się regeneruje.
2. Wypróbuj okno prywatne albo incognito, albo inną sieć. To wyklucza nieaktualny lokalny cache albo źle zachowujące się rozszerzenie przeglądarki, choć błąd 520 rzadko jest spowodowany czymś po Twojej stronie.
3. Sprawdź, czy witryna publikuje własną stronę statusu, jeśli taką ma, pod kątem znanej awarii.
4. Nie ma nic do skonfigurowania po Twojej stronie, żeby naprawić 520. Jest generowany przez własny serwer witryny, nie przez Twoją przeglądarkę, dostawcę internetu ani resolver DNS.

Jeśli prowadzisz witrynę

1. Sprawdź logi serwera WWW i aplikacji na serwerze źródłowym pod dokładnym znacznikiem czasu awarii, szukając awarii, nieobsłużonego wyjątku albo restartu workera.
2. Omiń Cloudflare i odpytaj serwer źródłowy bezpośrednio z nagłówkiem Host (pokazane wyżej), albo użyj opcji Cloudflare "Pause Cloudflare on Site", żeby potwierdzić, że odpowiedź jest zepsuta niezależnie od proxy.
3. Zmierz rozmiar swoich nagłówków odpowiedzi i ciasteczek. Jeden duży nagłówek set-cookie albo stos nagłówków debugowania zostawionych na produkcji może przepchnąć sumę powyżej 16 KB; przytnij to, czego nie potrzebujesz, i przenieś duże dane sesji po stronie serwera.
4. Sprawdź wadliwe odpowiedzi: reverse proxy albo load balancer wskazujący na złego upstreama, aplikację zwracającą czysty tekst na porcie HTTP albo brakującą linię statusu z domyślnej obsługi błędów frameworka.
5. Sprawdź wyczerpanie zasobów na serwerze źródłowym: limity pamięci, limity puli połączeń albo menedżer procesów (systemd, pm2, pula workerów Gunicorn albo uWSGI) utknięty w pętli restartów.
6. Jeśli między internetem a Twoim serwerem aplikacji stoi WAF, proxy antywirusowe albo load balancer, sprawdź jego własne logi pod kątem połączeń porzuconych albo zresetowanych w tym samym czasie.

Jak temu zapobiec

Błąd 520 zwykle pojawia się najpierw jako zgłoszenie do wsparcia, nie jako alert, bo nic na serwerze źródłowym niekoniecznie loguje nieudany handshake z brzegiem sieci Cloudflare tak, jak loguje wyjątek aplikacji. Zewnętrzna kontrola dostępności działająca spoza Twojej własnej sieci wyłapuje tę samą awarię, którą widzi odwiedzający, z tego samego punktu obserwacji, zanim ktoś będzie musiał ją zgłosić. Uruchamianie kontroli z wielu krajów pokazuje też od razu, czy 520 jest globalne, czy ograniczone do jednego regionu, co decyduje, od czego zacząć debugowanie.

Powiązane błędy

• Błąd Cloudflare 521: serwer WWW nie działa - serwer źródłowy odmówił połączenia zamiast odpowiedzieć.
• Błąd Cloudflare 522: przekroczono limit czasu połączenia - handshake TCP z serwerem źródłowym nigdy się nie zakończył.
• Błędy serwera 5xx - ogólna rodzina kodów statusu.
• 502 Bad Gateway - wersja niedotycząca konkretnie Cloudflare tej samej nieprawidłowej odpowiedzi upstreama.

Najczęściej zadawane pytania

Czy błąd 520 to wina Cloudflare, czy moja?

Prawie zawsze serwera źródłowego. Cloudflare otrzymało odpowiedź i nie potrafiło jej zrozumieć ani przekazać dalej, co oznacza, że to serwer źródłowy, nie sieć Cloudflare, wyprodukował zepsutą odpowiedź.

Czy błąd 520 oznacza, że cała moja witryna nie działa?

Niekoniecznie. Oznacza, że konkretne żądanie, które go wywołało, zawiodło. Jeśli serwer źródłowy zawiesza się pod obciążeniem, może serwować 520 dla niektórych żądań i normalne odpowiedzi dla innych, dopóki podstawowy problem nie zostanie naprawiony.

Czy mogę naprawić błąd 520 wyłącznie z panelu Cloudflare?

Rzadko. Skoro przyczyna jest niemal zawsze po stronie serwera źródłowego, ustawienia w panelu nie naprawią zawieszającej się aplikacji ani zbyt dużego nagłówka odpowiedzi. Wyjątkiem jest sprawdzenie, czy tryb SSL/TLS i ustawienia serwera źródłowego pasują do tego, co Twój serwer faktycznie robi, co przynajmniej wyklucza błędną konfigurację po stronie Cloudflare.

Jaka jest różnica między błędem 520 a zwykłym 502 Bad Gateway?

502 to ogólny status HTTP dla nieprawidłowej odpowiedzi z serwera upstream, używany przez dowolne reverse proxy. Cloudflare używa 520 konkretnie jako własnej kategorii zbiorczej dla odpowiedzi tak zepsutej, że nie pasuje do żadnego innego nazwanego kodu 5xx Cloudflare, dlatego pojawia się strona błędu Cloudflare i Ray ID zamiast ogólnej strony 502.

Czy duże ciasteczko naprawdę może spowodować 520?

Tak. Cloudflare egzekwuje limit całkowitego rozmiaru nagłówków odpowiedzi, obecnie około 16 KB, a ciasteczka wliczają się do tego limitu. Aplikacja, która ciągle dopisuje do ciasteczka sesyjnego, albo ustawia jednocześnie kilka dużych ciasteczek, może przekroczyć ten limit i wywołać 520 nawet wtedy, gdy sama aplikacja nie ma żadnego błędu.

Czy ponowna próba naprawi problem?

Czasami, jeśli przyczyną była przejściowa awaria albo restart na serwerze źródłowym, po którym system się już zregenerował. Jeśli serwer źródłowy konsekwentnie wysyła zepsute odpowiedzi, na przykład z powodu zbyt dużego nagłówka przy każdym żądaniu, ponawianie próby nie pomoże, dopóki serwer źródłowy nie zostanie naprawiony.