10 błędów konfiguracji Cloudflare i jak ich uniknąć

Wprowadzenie – pomarańczowa chmurka to nie magiczny przełącznik

Schemat zwykle wygląda tak: rejestracja, zmiana serwerów nazw, pomarańczowa chmurka na rekordzie A i po chwili strona ładuje się szybciej, kłódka SSL świeci na zielono, wszyscy zadowoleni. Problem pojawia się później – okazuje się, że poczta przestała chodzić, certyfikat Let's Encrypt nie chce się odnowić, a panel WordPressa zwraca dziwne błędy.

Źródłem tych kłopotów najczęściej nie jest sam Cloudflare, tylko domyślne ustawienia, które rzadko są optymalne dla konkretnej strony. Pomarańczowa chmurka zmienia adres IP, pod którym widać serwer, sposób szyfrowania ruchu, nagłówki HTTP oraz to, co trafia do pamięci podręcznej. Każda z tych zmian może coś zepsuć, jeśli wprowadzi się ją bez zrozumienia.

Poniżej dziesięć najczęstszych błędów konfiguracji, ich typowe objawy i konkretne sposoby naprawy. Większość z nich da się rozwiązać w panelu Cloudflare w kilka minut, pod warunkiem że wiadomo, czego szukać.

1. Domyślny tryb SSL Flexible

Cloudflare domyślnie ustawia tryb SSL o nazwie Flexible. Z punktu widzenia przeglądarki wszystko wygląda dobrze: adres zaczyna się od HTTPS, kłódka jest zielona. Haczyk jest taki, że ruch między Cloudflare a serwerem leci wtedy zwykłym, nieszyfrowanym HTTP. Szyfrowana jest tylko pierwsza część trasy, od użytkownika do Cloudflare.

Jeśli serwer ze swojej strony wymusza HTTPS, powstaje pętla przekierowań. Cloudflare wysyła żądanie po HTTP, serwer odpowiada przekierowaniem na HTTPS, Cloudflare znów wysyła HTTP i tak w kółko. Po kilku obrotach przeglądarka się poddaje i pokazuje komunikat o zbyt wielu przekierowaniach (ERR_TOO_MANY_REDIRECTS).

Druga, poważniejsza konsekwencja dotyczy bezpieczeństwa. Dane logowania, ciasteczka sesji i nagłówki autoryzacyjne wędrują między Cloudflare a serwerem bez szyfrowania. Każdy, kto ma dostęp do sieci na tym odcinku, może je przechwycić. Z tego powodu oficjalna dokumentacja Cloudflare odradza tryb Flexible dla stron przetwarzających dane wrażliwe.

Rozwiązanie: w sekcji SSL/TLS przełącz tryb na Full (Strict). Jeśli serwer nie ma własnego certyfikatu, w zakładce Origin Server możesz wygenerować darmowy certyfikat pochodzenia od Cloudflare. Jest ważny piętnaście lat i działa wyłącznie przy włączonym proxy. W trybie Full (Strict) Cloudflare nie tylko szyfruje całą trasę, ale też weryfikuje certyfikat serwera i odrzuca połączenie, gdy jest on nieważny, wygasły albo nie pasuje do domeny.

2. Pomarańczowa chmurka na poczcie, SSH i FTP

Proxy Cloudflare obsługuje wyłącznie ruch HTTP i HTTPS, i to tylko na zamkniętej liście portów: 80, 443, 2053, 2083, 2087, 2096 oraz 8443. Gdy włączysz pomarańczową chmurkę na rekordzie poczty, SSH czy FTP, te usługi po prostu przestaną działać, bo ich protokoły nie są ruchem sieciowym, który proxy potrafi przepuścić.

Poczta to tu klasyk. Nowy użytkownik włącza proxy na wszystkich rekordach naraz, w przekonaniu, że „im więcej, tym bezpieczniej", a po godzinie nikt nie odbiera wiadomości. Protokoły poczty – SMTP do wysyłania oraz IMAP i POP3 do odbioru – nie przejdą przez standardowe proxy, ponieważ nie są oparte na HTTP.

Co istotne, samego rekordu MX Cloudflare nie pozwala objąć proxy, więc nie tędy zwykle przebiega błąd. Problem siedzi w rekordzie A lub CNAME wskazującym serwer poczty, na przykład mail.twojadomena.pl. To właśnie on bywa najczęstszą przyczyną kłopotów z pocztą po wdrożeniu Cloudflare.

Zasada jest prosta: pomarańczowa chmurka tylko dla strony WWW. Cała reszta – poczta, SSH, FTP, bazy danych – powinna zostać na szarej chmurce, czyli w trybie DNS only, w którym Cloudflare jedynie rozwiązuje nazwę i nie pośredniczy w ruchu. Jeśli naprawdę potrzebujesz ochrony proxy dla innych protokołów, służy do tego płatna usługa Cloudflare Spectrum, ale w typowej stronie firmowej zwykle nie jest potrzebna.

3. Brak adresów IP Cloudflare na firewallu serwera

Po włączeniu proxy Cloudflare przestaje łączyć się z serwerem z adresu odwiedzającego, a zaczyna z własnych adresów IP. Jeśli firewall serwera, zabezpieczenia hostingu, grupa zabezpieczeń w chmurze albo zapora systemowa blokują te adresy, połączenie nie dochodzi do skutku. Użytkownik widzi wtedy błąd 521 (Web Server Is Down) lub 523 (Origin Is Unreachable).

To moment, w którym wiele osób błędnie zakłada, że padł Cloudflare albo hosting. Tymczasem winna jest zapora po stronie serwera. Wystarczy dodać aktualne zakresy adresów IP Cloudflare do listy dozwolonych na portach 80 i 443. Pełną listę Cloudflare publikuje pod adresem cloudflare.com/ips, a ponieważ adresy bywają aktualizowane, warto co jakiś czas sprawdzić, czy lista jest nadal kompletna.

Dobry test diagnostyczny: jeśli strona działa bez zarzutu na szarej chmurce, a psuje się dokładnie po przełączeniu na pomarańczową, w pierwszej kolejności sprawdź firewall serwera źródłowego.

4. Serwer nie widzi prawdziwego adresu odwiedzającego

Kiedy Cloudflare stoi przed serwerem, wszystkie połączenia przychodzą z jego adresów. W efekcie logi serwera oraz mechanizmy oparte na adresie IP – wtyczki bezpieczeństwa pokroju Wordfence czy Limit Login Attempts, a także blokowanie po kraju – widzą wyłącznie adresy Cloudflare. Blokada geograficzna przestaje cokolwiek znaczyć, a analiza ataków staje się bezużyteczna, bo każdy ruch wygląda tak samo.

Prawdziwy adres użytkownika Cloudflare przekazuje w nagłówku CF-Connecting-IP. Żeby serwer z niego korzystał, trzeba go odpowiednio skonfigurować: w nginx służy do tego moduł realip, a w Apache moduł remoteip. Po ich ustawieniu logi i mechanizmy bezpieczeństwa znów operują na rzeczywistych adresach odwiedzających.

Ważne zastrzeżenie: odtwarzanie prawdziwego adresu jest bezpieczne tylko wtedy, gdy serwera nie da się osiągnąć z pominięciem Cloudflare. Jeśli ktoś potrafi połączyć się z serwerem bezpośrednio, może podstawić fałszywy nagłówek CF-Connecting-IP i podszyć się pod dowolny adres. Dlatego zanim włączysz odtwarzanie IP, upewnij się, że firewall przepuszcza wyłącznie ruch z adresów Cloudflare. Inaczej zamiast poprawić bezpieczeństwo, otworzysz furtkę do jego obejścia.

5. Mieszana treść i nieobsłużony nagłówek protokołu

Cloudflare zmienia sposób, w jaki aplikacja rozpoznaje, czy połączenie jest szyfrowane. Gdy odbiera od użytkownika HTTPS, ale do serwera przekazuje ruch po HTTP (tryb Flexible) albo nawet po HTTPS, wewnętrzna informacja PHP o szyfrowaniu połączenia może pozostać pusta. WordPress uznaje wtedy, że strona działa po HTTP, generuje odnośniki bez szyfrowania i powstaje tak zwana mieszana treść – część zasobów ładuje się po HTTPS, a część po HTTP. Skutkiem bywają ostrzeżenia przeglądarki i kolejne pętle przekierowań.

Rozwiązaniem jest odczytanie nagłówka X-Forwarded-Proto, który Cloudflare ustawia zawsze i który mówi, jakiego protokołu użył użytkownik. W WordPressie wystarczy krótki fragment konfiguracji w pliku ustawień, który na podstawie tego nagłówka informuje system, że połączenie jest szyfrowane. Podobnie jak przy odtwarzaniu adresu IP, działa to bezpiecznie tylko przy firewallu blokującym bezpośredni dostęp do serwera.

Pomocniczo warto włączyć w ustawieniach certyfikatów brzegowych funkcję Automatic HTTPS Rewrites. Automatycznie podmienia ona odnośniki HTTP na HTTPS w kodzie strony, co ogranicza problem mieszanej treści, choć nie zastępuje poprawnej obsługi nagłówka protokołu po stronie serwera.

6. Proxy w komunikacji serwer–serwer

Osobny rodzaj pętli powstaje, gdy dwie usługi komunikują się ze sobą przez domeny objęte proxy. Serwer wysyła żądanie na przykład do api.twojadomena.pl, która ma pomarańczową chmurkę, więc DNS zwraca adres Cloudflare. Cloudflare odbiera żądanie i próbuje połączyć się z serwerem docelowym, ale jeśli on również jest schowany za Cloudflare, DNS znów zwraca adres Cloudflare. Ruch krąży w kółko, aż pojawia się błąd 1000 z informacją, że DNS wskazuje na zabroniony adres IP.

To częsta pułapka w architekturze złożonej z wielu usług, gdzie front wywołuje API backendu, a obie domeny mają włączone proxy. Charakterystyczny objaw: bezpośrednie wywołanie z linii poleceń działa, ale przeglądarka dostaje przekroczenie czasu lub błąd.

Rozwiązanie: domeny służące wyłącznie do komunikacji między serwerami powinny mieć szarą chmurkę. Jeśli backendowe API nie potrzebuje cache, zapory WAF ani ochrony przed atakami wolumetrycznymi na poziomie Cloudflare, nie ma powodu obejmować go proxy. W środowiskach chmurowych jeszcze lepiej sprawdza się komunikacja wewnątrz prywatnej sieci, która w ogóle omija publiczny DNS.

7. Brak wykluczeń cache dla panelu i stron dynamicznych

Domyślnie Cloudflare nie buforuje kodu HTML – do pamięci podręcznej trafiają tylko zasoby statyczne, czyli arkusze stylów, skrypty i obrazki. Kłopoty zaczynają się dopiero po włączeniu agresywnego cache, najczęściej reguły Cache Everything na całej domenie, bez przemyślanych wyjątków.

Brak wykluczeń dla panelu administracyjnego, logowania, koszyka i API daje bardzo konkretne objawy:

• zmiany wprowadzone w panelu nie pojawiają się na stronie,
• zalogowani użytkownicy widzą wersję przeznaczoną dla anonimowych,
• w sklepie WooCommerce dwie osoby widzą nawzajem swoje koszyki,
• interfejs API zwraca nieaktualne, zapamiętane odpowiedzi.

Lekarstwem są reguły wyłączające z cache ścieżki panelu administracyjnego, strony logowania, koszyka i API oraz wszystkie strony powiązane z ciasteczkami sesji. W WooCommerce dochodzą do tego ciasteczka koszyka, takie jak woocommerce_items_in_cart i woocommerce_cart_hash, po których Cloudflare powinien rozpoznać, że danej odpowiedzi nie wolno zapamiętywać.

Uwaga na funkcję Rocket Loader. Domyślnie włączone, asynchroniczne ładowanie skryptów potrafi rozregulować panel administracyjny. Jeśli po podłączeniu Cloudflare panel WordPressa zaczyna zachowywać się dziwnie, wyłącz Rocket Loader dla ścieżki panelu i sprawdź, czy problem znika.

8. Proxy blokuje odnowienie certyfikatu Let's Encrypt

Let's Encrypt weryfikuje, czy domena należy do Ciebie, metodą HTTP-01: wysyła żądanie do specjalnej ścieżki w katalogu acme-challenge i oczekuje konkretnej odpowiedzi. Cloudflare może to żądanie przechwycić na kilka sposobów – przez wymuszone przekierowanie na HTTPS (funkcja Always Use HTTPS), regułę WAF, cache albo Workera. Wtedy weryfikacja się nie udaje, a certyfikat nie zostaje odnowiony.

Jeśli certyfikaty Let's Encrypt przestały się odnawiać dokładnie po włączeniu Cloudflare, najprawdopodobniej blokowana jest właśnie ta ścieżka. Problem nasila się przy łączeniu Cloudflare z platformami takimi jak Vercel czy Netlify.

Doraźnie wystarczy przełączyć rekord na szarą chmurkę, odnowić certyfikat i włączyć proxy z powrotem. Trwałe rozwiązanie to reguła omijająca ścieżkę acme-challenge – z wyłączonym przekierowaniem, cache, regułami WAF i Workerami. Alternatywą jest weryfikacja metodą DNS-01, czyli przez wpis w rekordzie TXT, która działa niezależnie od proxy i nie wymaga dostępu do katalogu na serwerze.

9. Aplikacje na nieobsługiwanych portach

Wracamy do listy portów, ale od innej strony. Standardowe proxy Cloudflare przyjmuje połączenia tylko na portach 80, 443, 2053, 2083, 2087, 2096 i 8443 – na planie darmowym i na planach płatnych poza Enterprise. Żaden inny port nie przejdzie przez proxy.

Jeśli aplikacja działa na porcie 3000, 5000, 8080, 8089, 9000 czy 4000, włączenie pomarańczowej chmurki sprawi, że ruch nie dotrze do serwera. Cloudflare po prostu nie nasłuchuje na tych portach i odpowie błędem 400 (Bad Request) albo przekroczeniem czasu.

Rozwiązanie: aplikacje na niestandardowych portach muszą zostać na szarej chmurce, chyba że wykupisz Cloudflare Spectrum, które obsługuje dowolne porty TCP i UDP. Bez tej usługi nie da się jednocześnie korzystać z ochrony proxy i wystawiać aplikacji na porcie spoza dozwolonej listy – trzeba wybrać jedno albo drugie.

10. Zbyt agresywne WAF i Under Attack Mode na stałe

Tryb Under Attack włączony na stałe sprawia, że każdy odwiedzający musi przejść przez stronę weryfikacji ze sprawdzeniem JavaScript, zanim zobaczy treść. Wydłuża to ładowanie i zniechęca użytkowników, szczególnie na telefonach. To narzędzie do reagowania na trwający atak, a nie ustawienie do trzymania włączonego przez cały czas.

Podobnie działa zbyt restrykcyjna zapora WAF. Blokuje nie tylko ataki, ale też legalny ruch. Najczęstsze skutki uboczne to:

• blokada robota Google, a w ślad za nią spadek pozycji w wyszukiwarce,
• formularze kontaktowe, które przestają działać po zablokowaniu żądań wysyłających dane,
• własne aplikacje, którym API zwraca odmowę dostępu (403 Forbidden).

Zamiast włączać wszystkie zabezpieczenia naraz, regularnie zaglądaj do sekcji Security Events w panelu Cloudflare. Widać tam, która reguła blokuje jaki ruch. Jeśli na liście pojawiają się legalne żądania, dodaj dla nich wyjątek dla konkretnej ścieżki lub parametru. Osobno warto przyjrzeć się funkcji Bot Fight Mode – bywa nadgorliwa i potrafi blokować narzędzia monitorujące, czytniki kanałów czy właśnie robota Google. Po jej włączeniu sprawdź logi, zanim uznasz konfigurację za skończoną.

Na koniec – sprawdzaj, zanim włączysz

Większość opisanych błędów ma wspólny mianownik: niezrozumienie, co tak naprawdę robi proxy Cloudflare. Pomarańczowa chmurka nie jest przełącznikiem „szybciej i bezpieczniej". Zmienia adres IP, pod którym widać stronę, sposób szyfrowania ruchu, nagłówki HTTP oraz to, co trafia do pamięci podręcznej. Każdy z tych elementów może coś usprawnić albo coś zepsuć, w zależności od reszty konfiguracji.

Praktyczny wniosek jest prosty: zanim włączysz kolejną opcję, sprawdź, co dokładnie zmienia. Jeśli coś przestaje działać tuż po przełączeniu na pomarańczową chmurkę, zacznij od trzech rzeczy – trybu SSL, firewalla serwera i rekordów, które nie powinny mieć proxy. Cloudflare ma obszerną dokumentację, tylko trzeba po nią sięgnąć, zamiast polegać na ustawieniach domyślnych.