Jak naprawić błąd Cloudflare 520: Kompletny przewodnik diagnostyczny i rozwiązywania problemów

Błąd Cloudflare 520 to kod statusu HTTP zwracany, gdy sieć brzegowa Cloudflare otrzymuje pustą, nieoczekiwaną lub w inny sposób niemożliwą do zinterpretowania odpowiedź z serwera źródłowego. W przeciwieństwie do błędów 502 lub 504, które wskazują na przekroczenie limitu czasu bramy lub błąd bramy, błąd 520 jest zbiorczym kodem Cloudflare dla odpowiedzi wykraczających poza jakąkolwiek rozpoznaną specyfikację HTTP — co oznacza, że serwer źródłowy technicznie odpowiedział, ale to, co odesłał, było nieprawidłowe, obcięte lub strukturalnie zniekształcone.

Z praktycznego punktu widzenia błąd 520 oznacza, że połączenie TCP między Cloudflare a serwerem źródłowym zostało nawiązane, ale uzgadnianie na poziomie HTTP nie powiodło się. Użytkownik widzi stronę błędu z brandingiem Cloudflare z komunikatem „Web server is returning an unknown error” — a Twoja witryna jest dla niego faktycznie niedostępna.

Co wywołuje błąd 520: wyjaśnienie przyczyn źródłowych

Zrozumienie dokładnego trybu awarii jest niezbędne przed wprowadzeniem jakichkolwiek zmian w konfiguracji. Błąd 520 nie jest pojedynczym problemem — jest klasą objawów. Poniższe przyczyny są najczęstsze, uszeregowane według częstotliwości występowania w środowiskach produkcyjnych.

Serwer źródłowy zwraca pustą treść odpowiedzi bez linii statusu HTTP. Jest to najczęstszy wyzwalacz. Apache lub Nginx może ulec awarii w trakcie odpowiedzi, pozostawiając Cloudflare z otwartym gniazdem TCP, do którego nie napływają żadne dane.

Zapora sieciowa lub oprogramowanie zabezpieczające blokuje zakresy IP Cloudflare. Narzędzia takie jak ModSecurity, Fail2Ban, CSF (ConfigServer Security & Firewall) lub wtyczki warstwy aplikacji, takie jak Wordfence, mogą po cichu odrzucać pakiety z wychodzących adresów IP Cloudflare, powodując resetowanie połączenia bez właściwej odpowiedzi HTTP.

Niezgodność uzgadniania SSL/TLS między Cloudflare a serwerem źródłowym. Jeśli Cloudflare jest ustawiony w trybie „Full (Strict)”, ale serwer źródłowy ma wygasły, samopodpisany lub błędnie skonfigurowany certyfikat, negocjacja TLS kończy się niepowodzeniem przed wymianą jakichkolwiek danych HTTP.

Zniekształcone lub zbyt duże nagłówki odpowiedzi HTTP. Cloudflare narzuca twardy limit 32 KB na nagłówki odpowiedzi. Każdy pojedynczy nagłówek lub łączny zestaw nagłówków przekraczający ten limit powoduje błąd 520. Jest to częsty przypadek brzegowy w przypadku źle napisanych aplikacji PHP, które zrzucają duże dane sesji lub dane debugowania do nagłówków.

Awaria procesu serwera źródłowego lub zabicie przez OOM (Out-of-Memory). Jeśli proces roboczy serwera WWW (np. worker Nginx lub pula PHP-FPM) zostanie zabity przez mechanizm OOM killer systemu Linux w trakcie obsługi żądania, połączenie zostaje gwałtownie przerwane.

Wyjątki na poziomie aplikacji przed wysłaniem nagłówków. Krytyczny błąd PHP, nieobsłużony wyjątek Pythona lub awaria Node.js, która wystąpi przed wywołaniem res.writeHead(), skutkuje pustą odpowiedzią, której Cloudflare nie może przetworzyć.

Resetowanie połączenia przez serwer źródłowy (TCP RST). Serwer źródłowy aktywnie resetuje połączenie TCP, co Cloudflare interpretuje jako nieznaną odpowiedź.

Błąd 520 a inne błędy Cloudflare 5xx

Odróżnienie błędu 520 od podobnych błędów Cloudflare zapobiega marnowaniu wysiłku diagnostycznego.

Jeśli widzisz błąd 521, proces serwera WWW nie działa. Jeśli widzisz błąd 524, aplikacja działa, ale jest zbyt wolna. Jeśli widzisz błąd 520, serwer działa i odpowiada — ale to, co odsyła, jest uszkodzone.

Krok po kroku: naprawa błędu 520

Krok 1: Weryfikacja stanu serwera źródłowego i łączności

Przed wprowadzaniem zmian w Cloudflare upewnij się, że serwer źródłowy działa i demon serwera WWW jest uruchomiony.

Sprawdź, czy proces serwera WWW jest aktywny:

# For Nginx
sudo systemctl status nginx

# For Apache
sudo systemctl status apache2

# For LiteSpeed
sudo systemctl status lsws

Przetestuj bezpośrednią łączność z IP serwera źródłowego, omijając proxy Cloudflare. Pobierz IP serwera źródłowego z panelu DNS Cloudflare, a następnie przetestuj je bezpośrednio:

curl -I --resolve yourdomain.com:80:YOUR_ORIGIN_IP http://yourdomain.com/
curl -I --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/

Jeśli curl zwraca prawidłowy status HTTP (200, 301 itp.), serwer źródłowy działa, a problem leży w warstwie komunikacji między Cloudflare a serwerem źródłowym. Jeśli curl zwraca pustą odpowiedź lub reset połączenia, problem leży po stronie serwera źródłowego.

Sprawdź obciążenie zasobów systemowych:

# Memory usage
free -h

# CPU load
uptime

# Check for OOM kills in the last boot
dmesg | grep -i "oom|killed process"

# Check for PHP-FPM pool exhaustion
sudo systemctl status php8.1-fpm

Krok 2: Sprawdzenie dzienników błędów serwera źródłowego

Dzienniki serwera źródłowego są najcenniejszym źródłem diagnostycznym. Nie pomijaj tego kroku.

Dla Nginx:

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/nginx/access.log

Dla Apache:

sudo tail -n 100 /var/log/apache2/error.log
sudo tail -n 100 /var/log/apache2/access.log

Szukaj w szczególności:

• Wpisów na poziomie [crit] lub [emerg]

upstream prematurely closed connection (Nginx + PHP-FPM)
Premature end of script headers (Apache + CGI/PHP)
worker_connections are not enough (osiągnięto limit workerów Nginx)
Krytycznych błędów PHP zapisanych w dzienniku błędów serwera WWW

Porównaj znaczniki czasu w dziennikach z momentami wystąpienia błędów 520. Panel Cloudflare w sekcji Analytics > Traffic pokazuje znaczniki czasu skoków błędów 520, których możesz użyć do korelacji.
Krok 3: Dodanie zakresów IP Cloudflare do białej listy zapory sieciowej
Jeśli zapora sieciowa blokuje wychodzące adresy IP Cloudflare, połączenie zostanie zresetowane po cichu. Cloudflare publikuje swoje aktualne zakresy IP pod adresem https://www.cloudflare.com/ips/.
Dla UFW (Ubuntu/Debian):
# Download Cloudflare IPv4 ranges and whitelist them
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

# Repeat for IPv6
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

sudo ufw reload
Dla CSF (ConfigServer Firewall):
Dodaj zakresy IP Cloudflare do /etc/csf/csf.allow, a następnie uruchom ponownie CSF:
sudo csf -r
Dla ModSecurity: Jeśli podejrzewasz, że ModSecurity jest przyczyną problemu, sprawdź jego dziennik audytu:
sudo tail -n 200 /var/log/modsec_audit.log
Szukaj dopasowań reguł dla adresów IP Cloudflare. Możesz dodać adresy IP Cloudflare do białej listy w konfiguracji ModSecurity lub ustawić dyrektywę SecRemoteRules, aby je wykluczyć.
Ważna uwaga: Nigdy nie wyłączaj trwale zapory sieciowej ani ModSecurity. Dodaj do białej listy tylko opublikowane zakresy IP Cloudflare i natychmiast ponownie włącz wszystkie mechanizmy zabezpieczeń po zakończeniu testów.
Krok 4: Audyt i naprawa nagłówków odpowiedzi HTTP
Zniekształcone lub zbyt duże nagłówki są często pomijaną przyczyną błędów 520. Użyj curl z pełnym wyjściem, aby sprawdzić dokładnie, co wysyła serwer źródłowy:
curl -v --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/ 2>&1 | head -80
Zwróć uwagę na:

Nagłówki zawierające znaki spoza ASCII lub znaki sterujące
Nagłówki Set-Cookie z bardzo długimi wartościami (częste w przypadku błędnych konfiguracji sesji PHP)
Brakujące lub zniekształcone nagłówki Content-Type

• Zduplikowane nagłówki Content-Length z konfliktującymi wartościami

Jeśli uruchamiasz aplikację PHP, sprawdź php.ini pod kątem ustawień output_buffering. Wyłączony bufor wyjściowy w połączeniu z krytycznym błędem w trakcie odpowiedzi może spowodować częściową transmisję nagłówków.

Szczególnie w przypadku witryn WordPress: Wtyczki wstrzykujące duże ilości danych do nagłówków HTTP (niektóre wtyczki zabezpieczające lub buforujące tak robią) mogą przekroczyć limit 32 KB Cloudflare. Przeprowadź audyt aktywnych wtyczek i przetestuj w trybie bezpiecznym.

Krok 5: Weryfikacja konfiguracji SSL/TLS w Cloudflare

Niezgodność SSL między Cloudflare a serwerem źródłowym jest częstym źródłem błędów klasy 520, które maskują się jako ogólny nieznany błąd.

Przejdź do Cloudflare Dashboard > SSL/TLS > Overview i sprawdź tryb szyfrowania:

Jeśli serwer źródłowy używa certyfikatu samopodpisanego, a Cloudflare jest ustawiony na tryb Full (Strict), uzgadnianie TLS zakończy się niepowodzeniem. Zainstaluj ważny certyfikat na serwerze źródłowym (bezpłatny certyfikat Let’s Encrypt wystarczy) lub tymczasowo przełącz się na tryb Full, dopóki nie naprawisz certyfikatu.

Jeśli potrzebujesz prawidłowo zaufanego certyfikatu dla swojego serwera źródłowego, certyfikaty SSL od zaufanego CA całkowicie eliminują problem certyfikatów samopodpisanych i są kompatybilne z trybem Full (Strict) Cloudflare.

Krok 6: Wstrzymanie proxy Cloudflare w celu ukierunkowanej diagnostyki

Tymczasowe usunięcie Cloudflare ze ścieżki żądania pozwala ustalić, czy problem leży w konfiguracji Cloudflare, czy na serwerze źródłowym.

Metoda 1: Wyłączenie proxy dla konkretnego rekordu DNS

W panelu DNS Cloudflare kliknij ikonę pomarańczowej chmury obok rekordu A lub CNAME, aby zmienić ją na szarą. Spowoduje to ominięcie proxy Cloudflare przy zachowaniu rozwiązywania DNS przez Cloudflare. Propagacja DNS trwa do 5 minut.

Metoda 2: Globalne wstrzymanie Cloudflare dla domeny

Przejdź do Cloudflare Dashboard > Overview > Advanced Actions > Pause Cloudflare on Site. Spowoduje to kierowanie całego ruchu bezpośrednio do serwera źródłowego.

Po wstrzymaniu przetestuj swoją witrynę. Jeśli ładuje się poprawnie, problem leży w konfiguracji Cloudflare. Jeśli nadal nie działa, problem leży na serwerze źródłowym niezależnie od Cloudflare.

Ponownie włącz Cloudflare natychmiast po zakończeniu testów — wstrzymany Cloudflare oznacza, że Twoja witryna traci ochronę DDoS, buforowanie CDN i pokrycie WAF.

Krok 7: Sprawdzenie poprawności rekordów DNS

Błędnie skonfigurowany rekord DNS A wskazujący na nieprawidłowy lub nieaktualny adres IP powoduje, że Cloudflare kieruje ruch proxy do niewłaściwego serwera, który zwróci nieoczekiwaną odpowiedź.

W panelu DNS Cloudflare:

• Sprawdź, czy rekord A dla domeny głównej (@) wskazuje na aktualny adres IP serwera źródłowego
• Sprawdź, czy CNAME dla www jest poprawnie rozwiązywany
• Jeśli niedawno migrowałeś serwery, upewnij się, że stary adres IP nie jest już nigdzie przywoływany

Potwierdź, na jaki adres IP Cloudflare faktycznie kieruje ruch:

dig +short yourdomain.com @1.1.1.1

Porównaj to z faktycznym adresem IP serwera źródłowego. Jeśli się różnią, zaktualizuj rekord DNS w Cloudflare.

Krok 8: Skalowanie zasobów serwera źródłowego

Jeśli serwer źródłowy jest stale pod dużym obciążeniem, błędy 520 będą występować sporadycznie podczas skoków ruchu, gdy procesy robocze zostaną wyczerpane i połączenia zostaną przerwane.

Diagnozowanie wyczerpania zasobów:

# Check Nginx worker connections
sudo nginx -T | grep worker_connections

# Check PHP-FPM pool limits
cat /etc/php/8.1/fpm/pool.d/www.conf | grep -E "pm.|max_children"

# Monitor real-time connections
ss -s

Opcje dostrajania bez modernizacji sprzętu:

• Zwiększ worker_connections w /etc/nginx/nginx.conf
• Zwiększ pm.max_children w konfiguracji puli PHP-FPM
• Włącz dyrektywę keepalive Nginx dla połączeń upstream
• Zaimplementuj buforowanie obiektów (Redis lub Memcached), aby zmniejszyć obciążenie bazy danych
• Włącz regułę strony Cloudflare Cache Everything, aby odciążyć dostarczanie zasobów statycznych

W przypadku aplikacji, które przerosły infrastrukturę współdzieloną, migracja do środowiska hostingu VPS daje pełną kontrolę nad limitami procesów roboczych, alokacją pamięci i dostrajaniem TCP na poziomie jądra — czego nie ma w planach współdzielonych.

Jeśli Twoja aplikacja obsługuje intensywne obliczeniowo zadania (wnioskowanie ML, przetwarzanie wideo, operacje na dużych zbiorach danych), które powodują sporadyczne awarie workerów, hosting GPU odciąża te zadania od procesów serwera WWW, eliminując częste źródło awarii w trakcie odpowiedzi.

Krok 9: Przegląd reguł zapory sieciowej i zabezpieczeń Cloudflare

Własne funkcje bezpieczeństwa Cloudflare mogą czasami zakłócać prawidłową komunikację z serwerem źródłowym, szczególnie jeśli niestandardowe reguły zapory sieciowej lub reguły WAF są błędnie skonfigurowane.

Sprawdź Cloudflare Dashboard > Security > WAF > Custom Rules pod kątem reguł, które mogą przechwytywać żądania przed dotarciem do serwera źródłowego. Sprawdź również Security > Settings > Browser Integrity Check — w rzadkich przypadkach może to powodować nieoczekiwane zachowanie w przypadku niektórych agentów użytkownika lub zautomatyzowanych żądań.

Przejrzyj dziennik Security > Events, aby sprawdzić, czy Cloudflare blokuje lub kwestionuje żądania, które powinny docierać do serwera źródłowego.

Krok 10: Eskalacja do dostawcy hostingu lub wsparcia Cloudflare

Jeśli wszystkie powyższe kroki zostały wyczerpane bez rozwiązania problemu, eskaluj z precyzyjnymi informacjami.

Kontaktując się z dostawcą hostingu, podaj:

• Dokładne znaczniki czasu wystąpień błędów 520 (z Cloudflare Analytics)
• Odpowiednie fragmenty dziennika błędów serwera WWW
• Wynik polecenia curl -v dla IP serwera źródłowego
• Aktualne metryki wykorzystania zasobów (CPU, RAM, liczba połączeń)

Dostawcy zarządzający infrastrukturą na serwerach dedykowanych mogą przeprowadzać diagnostykę na poziomie jądra, przechwytywanie pakietów (tcpdump) i inspekcję na poziomie gniazd, co nie jest dostępne w środowiskach współdzielonych.

Kontaktując się ze wsparciem Cloudflare, dołącz:

• Ray ID ze strony błędu 520 (widoczny w kodzie HTML błędu Cloudflare)
• Plik HAR przechwycony z Chrome DevTools podczas błędu
• Aktualny tryb SSL/TLS i wszelkie niestandardowe reguły zapory sieciowej

Ray ID jest kluczowy — pozwala inżynierom Cloudflare pobrać dokładny wpis dziennika węzła brzegowego dla nieudanego żądania.

Zaawansowana diagnostyka: przechwytywanie dokładnej awarii za pomocą tcpdump

W przypadku trwałych lub sporadycznych błędów 520, które nie poddają się standardowemu rozwiązywaniu problemów, przechwytywanie pakietów na serwerze źródłowym ujawnia dokładnie to, co dzieje się na warstwie TCP/HTTP, gdy Cloudflare się łączy.

# Capture traffic from Cloudflare IPs on port 443
sudo tcpdump -i eth0 -w /tmp/cloudflare_capture.pcap 'src net 103.21.244.0/22 or src net 103.22.200.0/22 or src net 103.31.4.0/22 or src net 104.16.0.0/13 or src net 104.24.0.0/14' and port 443

Otwórz wynikowy plik .pcap w Wireshark i filtruj według tcp.flags.reset == 1, aby zidentyfikować pakiety TCP RST, które wskazują, że serwer źródłowy aktywnie resetuje połączenia. Filtruj według http, aby sprawdzić wszelkie częściowe odpowiedzi HTTP wysyłane przez serwer.

Ten poziom analizy definitywnie identyfikuje, czy błąd 520 jest spowodowany przez RST zapory sieciowej, awarię aplikacji w trakcie odpowiedzi, czy błąd TLS.

Zapobieganie błędowi 520: środki proaktywne

Reaktywne rozwiązywanie problemów jest kosztowne. Poniższe środki znacząco zmniejszają prawdopodobieństwo wystąpienia błędów 520.

Wdrożenie kontroli stanu Cloudflare. W sekcji Traffic > Health Checks skonfiguruj kontrolę stanu dla serwera źródłowego. Cloudflare powiadomi Cię, zanim użytkownicy zaczną widzieć błędy 520.

Włącz funkcję Always Online Cloudflare (w sekcji Caching > Configuration). Choć nie naprawia podstawowego problemu, serwuje buforowane wersje stron użytkownikom podczas awarii serwera źródłowego, zapobiegając całkowitej przerwie w świadczeniu usług.

Skonfiguruj monitorowanie serwera źródłowego za pomocą narzędzi takich jak UptimeRobot, Pingdom lub rozwiązania hostowanego samodzielnie, jak Uptime Kuma. Monitoruj bezpośrednio adres IP serwera źródłowego (nie domenę proxowaną przez Cloudflare), aby wykrywać awarie serwera źródłowego niezależnie od Cloudflare.

Zautomatyzuj dodawanie adresów IP Cloudflare do białej listy. Zakresy IP Cloudflare zmieniają się od czasu do czasu. Użyj zadania cron, aby odświeżać białą listę zapory sieciowej:

# /etc/cron.weekly/update-cloudflare-ips
#!/bin/bash
CF_IPS=$(curl -s https://www.cloudflare.com/ips-v4)
# Add logic to update UFW/CSF/iptables rules

Użyj funkcji Authenticated Origin Pulls Cloudflare. Ta funkcja konfiguruje serwer źródłowy tak, aby akceptował tylko połączenia HTTPS prezentujące certyfikat klienta Cloudflare, blokując wszelkie żądania bezpośrednio do serwera źródłowego omijające proxy. Eliminuje to również klasę błędów 520 spowodowanych przez ruch spoza Cloudflare trafiający na serwer źródłowy i wyzwalający odpowiedzi oprogramowania zabezpieczającego.

Dla zespołów zarządzających wieloma domenami i aplikacjami internetowymi, VPS z cPanel zapewnia scentralizowany dostęp do dzienników, zarządzanie zaporą sieciową i zarządzanie certyfikatami SSL dla wszystkich hostowanych domen — znacząco skracając czas diagnostyki błędów 520.

Macierz decyzyjna: diagnozowanie konkretnego scenariusza błędu 520

Lista kontrolna kluczowych wniosków technicznych

Przed eskalacją do wsparcia potwierdź, że wykonałeś każdy z poniższych kroków:

• Zweryfikowano, że proces serwera WWW jest uruchomiony (systemctl status)
• Przetestowano bezpośrednią łączność z serwerem źródłowym za pomocą curl -v --resolve z pominięciem Cloudflare
• Przejrzano dzienniki błędów serwera źródłowego dla dokładnych znaczników czasu zdarzeń 520
• Potwierdzono, że zakresy IP Cloudflare są na białej liście we wszystkich aktywnych zaporach sieciowych (UFW, CSF, iptables, ModSecurity)
• Sprawdzono, że nagłówki odpowiedzi mają mniej niż 32 KB i nie zawierają zniekształconych wartości
• Potwierdzono, że tryb SSL/TLS Cloudflare odpowiada typowi certyfikatu serwera źródłowego
• Zweryfikowano, że rekordy DNS A wskazują na prawidłowy, aktualny adres IP serwera źródłowego
• Sprawdzono pamięć systemową i CPU pod kątem zabić OOM lub wyczerpania zasobów
• Przechwycono Ray ID ze strony błędu 520 do eskalacji wsparcia Cloudflare
• Przejrzano dziennik zdarzeń bezpieczeństwa Cloudflare pod kątem zakłóceń reguł WAF

Często zadawane pytania

Jaka jest różnica między błędem Cloudflare 520 a błędem 521?

Błąd 521 oznacza, że Cloudflare pomyślnie dotarł do adresu IP serwera źródłowego, ale proces serwera WWW odmówił połączenia TCP — zazwyczaj dlatego, że Nginx lub Apache nie działa. Błąd 520 oznacza, że połączenie TCP zostało nawiązane, ale odpowiedź HTTP była pusta, obcięta lub zniekształcona. Jeśli widzisz błąd 521, uruchom serwer WWW. Jeśli widzisz błąd 520, serwer działa, ale wysyła uszkodzone odpowiedzi.

Czy błąd 520 może być spowodowany przez sam Cloudflare, a nie przez serwer źródłowy?

Rzadko, ale tak. Problemy z węzłem brzegowym Cloudflare mogą powodować błędy 520, które nie są odtwarzalne przy bezpośrednim dostępie do serwera źródłowego. Sprawdź cloudflarestatus.com pod kątem aktywnych incydentów. Jeśli serwer źródłowy odpowiada poprawnie przez bezpośrednie curl i strona statusu Cloudflare pokazuje aktywny incydent, poczekaj na jego rozwiązanie przez Cloudflare zamiast wprowadzać zmiany na serwerze.

Dlaczego błąd 520 występuje tylko sporadycznie, a nie konsekwentnie?

Sporadyczne błędy 520 prawie zawsze wskazują na wyczerpanie zasobów — pule workerów PHP-FPM kończą dostępne procesy potomne, Nginx osiąga limity worker_connections, lub mechanizm OOM killer systemu Linux kończy procesy pod presją pamięci. Warunki te występują podczas skoków obciążenia i ustępują, gdy ruch spada, tworząc sporadyczny wzorzec. Konsekwentne błędy 520 wskazują na problem z konfiguracją.

Czy wstrzymanie Cloudflare naprawia błąd 520?

Wstrzymanie Cloudflare usuwa go ze ścieżki żądania, więc jeśli Twoja witryna działa po wstrzymaniu, problem leży w konfiguracji Cloudflare (tryb SSL, reguły WAF, rekordy DNS). Jeśli witryna nadal nie działa po wstrzymaniu, problem leży na serwerze źródłowym. Wstrzymanie Cloudflare jest krokiem diagnostycznym, a nie naprawą — usuwa ochronę DDoS i buforowanie CDN podczas aktywności.

Jak znaleźć Ray ID, aby zgłosić błąd 520 do Cloudflare?

Ray ID jest wyświetlany na dole strony błędu 520 Cloudflare pokazywanej użytkownikom. Wygląda jak 16-znakowy ciąg szesnastkowy (np. 7a3f2b9c1d4e8f0a). Można go również znaleźć w nagłówku odpowiedzi CF-Ray, widocznym w Chrome DevTools na karcie Network. Zawsze dołączaj ten identyfikator podczas otwierania zgłoszenia do wsparcia Cloudflare — pozwala inżynierom Cloudflare pobrać dokładny wpis dziennika brzegowego dla nieudanego żądania.