Cloudflare – czym jest i jak działa w praktyce

Większość osób, które słyszą o Cloudflare po raz pierwszy, myśli: „jakiś CDN”. To prawda, ale tylko fragment prawdy. Przez lata pracy z WordPressem na różnych środowiskach – od taniego hostingu współdzielonego po dedykowane VPS-y – używamy Cloudflare regularnie i w bardzo różnych konfiguracjach. To narzędzie, które przy rozsądnej konfiguracji robi realną różnicę. Przy złej konfiguracji potrafi skutecznie ukryć problemy, które i tak wyjdą na jaw, tylko w gorszym momencie.

Co Cloudflare właściwie robi

Cloudflare działa jako odwrotny proxy (reverse proxy) stojący między użytkownikiem a Twoim serwerem. Kiedy ktoś wpisuje adres Twojej strony, zapytanie DNS trafia do Cloudflare, a nie bezpośrednio do Twojego hostingu. Cloudflare obsługuje połączenie, filtruje ruch, serwuje zasoby z cache i dopiero w razie potrzeby przekazuje żądanie do Twojego serwera.

To oznacza, że Twój serwer przestaje być bezpośrednio widoczny. Przynajmniej w teorii – jeśli ktoś wcześniej zebrał Twoje prawdziwe IP, ta ochrona jest iluzoryczna. Ale to osobny temat.

Żeby korzystać z Cloudflare, trzeba przenieść do nich obsługę DNS dla domeny. To jeden z tych kroków, który przy migracji stron bywa pomijany, a potem generuje problemy z propagacją i konfiguracją SSL.

CDN i cache – pierwsze zastosowanie, które wszyscy znają

Cloudflare posiada sieć serwerów brzegowych rozmieszczonych na całym świecie (edge nodes). Statyczne zasoby – obrazki, CSS, JavaScript, fonty – mogą być serwowane z lokalizacji geograficznie bliskiej użytkownikowi, zamiast lecieć za każdym razem do serwera, który stoi w jednym konkretnym centrum danych.

W praktyce, przy WordPressie z dużą ilością mediów, jest to odczuwalne. Strona dla użytkownika z Niemiec wczytuje obrazki szybciej, bo nie muszą za każdym razem przechodzić przez serwer we Frankfurcie albo Amsterdamie – jeśli plik jest już w cache Cloudflare, idzie bezpośrednio.

Tylko uwaga: Cloudflare nie cachuje domyślnie stron HTML. Cachuje zasoby statyczne. Żeby cache obejmował całe strony WordPress, trzeba skonfigurować odpowiednie reguły w Page Rules lub Cache Rules albo użyć wtyczki (jak Cloudflare APO dla WordPressa). Bez tego ludzie mówią „mamy CDN” i są zdziwieni, że czas odpowiedzi serwera nie spadł ani trochę.

Ochrona przed DDoS i botami

To jeden z powodów, dla których klienci do nas trafiają po fakcie.

Mieliśmy przypadki, gdzie sklep WooCommerce był atakowany zapytaniami do strony koszyka lub logowania – tysiące żądań na minutę, serwer padał, klientów nie było. Hosting współdzielony przy pierwszym takim ataku zwykle po prostu wyłącza stronę albo wysyła maila z prośbą o przeniesienie na droższy plan.

Cloudflare ma warstwy ochrony DDoS, które działają automatycznie. Filtrują ruch zanim dotrze do serwera. Na poziomie darmowym jest to dość podstawowe, ale już chroni przed znaczną częścią typowych ataków volumetrycznych. Na wyższych planach dostępny jest WAF (Web Application Firewall) z regułami specyficznymi dla WordPressa – blokowanie prób eksploitacji znanych podatności w wtyczkach.

Na poziomie darmowym też jest użyteczny element: Bot Fight Mode i możliwość ręcznego tworzenia reguł firewall (Firewall Rules / WAF Custom Rules). Możemy np. zablokować dostęp do /wp-login.php dla konkretnych krajów, z których nie pochodzi żaden nasz klient, albo wymusić challenge CAPTCHA przy próbie logowania. To samo można zrobić przez Fail2Ban po stronie serwera, ale Cloudflare blokuje ruch zanim w ogóle dotrze do Nginx czy Apache.

SSL i HTTPS – coś, co musi działać poprawnie

Cloudflare wystawia certyfikat SSL między użytkownikiem a Cloudflare. Brzmi świetnie. Ale między Cloudflare a Twoim serwerem połączenie może być nieszyfrowane – jeśli ktoś ustawi tryb Flexible SSL.

To jeden z najczęstszych błędów konfiguracyjnych. Strona pokazuje zieloną kłódkę, klient jest zadowolony, a w rzeczywistości dane między Cloudflare a serwerem lecą po HTTP. W przypadku sklepów, formularzy z danymi osobowymi – to realny problem bezpieczeństwa.

Prawidłowo należy ustawić tryb Full (strict) i mieć ważny certyfikat na serwerze – Let’s Encrypt działa idealnie. Przy migracjach stron sprawdzamy to zawsze, bo zastane konfiguracje potrafią zaskakiwać.

Zarządzanie DNS

Po przeniesieniu domeny pod Cloudflare zarządzanie rekordami DNS przenosi się do panelu Cloudflare. I tu jest zaleta: zmiany propagują się błyskawicznie (TTL rzędu 5 minut zamiast 24 godzin przy standardowych konfiguracjach). Przy migracjach WordPress – z serwera A na serwer B – to ogromne ułatwienie.

Poza tym Cloudflare pozwala ukryć prawdziwy adres IP serwera za tzw. proxied rekordami. Rekordy A i AAAA dla domeny pokazują IP Cloudflare, a nie Twojego serwera. Jeśli chcesz wyłączyć tę ochronę dla konkretnego rekordu (np. subdomena dla maila), robisz to jednym kliknięciem.

Wydajność – nie tylko CDN

Poza CDN Cloudflare oferuje kilka funkcji wpływających na szybkość strony:

Minifikacja – CSS, JS, HTML mogą być minifikowane automatycznie. W teorii dobry pomysł, w praktyce przy niektórych motywach i wtyczkach generuje błędy. Zawsze testujemy po włączeniu.

HTTP/2 i HTTP/3 – Cloudflare obsługuje nowoczesne protokoły nawet jeśli serwer docelowy ich nie wspiera. Przy starym hostingu z Apache na HTTP/1.1 to realna różnica dla stron z wieloma zasobami.

Early Hints (103) – możliwość wysyłania nagłówków zanim serwer skończy generować odpowiedź. Coraz bardziej dostępne i realnie wpływające na LCP i TTFB.

Rocket Loader – asynchroniczne ładowanie JavaScriptu. Często psuje rzeczy. Używamy z ostrożnością, zawsze sprawdzamy na stagingu.

Polish – kompresja i konwersja obrazków do WebP. Działa, ale jeśli masz już skonfigurowaną konwersję po stronie WordPressa (np. przez Imagify albo ShortPixel), dublowanie może być zbędne.

Cloudflare a WordPress – kilka rzeczy, o których warto wiedzieć

Przy aktywnym cache Cloudflare należy zadbać o czyszczenie cache po aktualizacjach. Bez tego użytkownicy widzą stare wersje stron po opublikowaniu zmian. Cloudflare ma API i webhooks, które można podpiąć do procesu deploymentu albo do wtyczki cache WordPress.

Używając WP-CLI do masowych aktualizacji wtyczek, dodajemy do skryptu wywołanie Cloudflare API do purge cache. Inaczej klient dzwoni i pyta, dlaczego zmiany nie są widoczne.

Drugi drażliwy punkt: IP użytkowników w logach WordPress. Przy Cloudflare jako proxy, WordPress widzi IP Cloudflare, nie użytkownika. Jeśli masz jakiś mechanizm oparty na IP (wtyczka bezpieczeństwa, geoblocking, logi dostępu), musisz skonfigurować przywracanie prawdziwego IP przez nagłówek CF-Connecting-IP. Po stronie Nginx ustawiamy to przez moduł ngx_http_realip_module.

Kiedy Cloudflare nie jest rozwiązaniem problemu

Cloudflare nie naprawi wolnej strony, która jest wolna dlatego, że ma niezoptymalizowane zapytania do bazy danych, źle napisaną wtyczkę albo PHP 7.2 na przeciążonym hostingu współdzielonym. Schowa problem pod warstwą cache, ale przy pierwszym żądaniu omijającym cache (np. zalogowany użytkownik, koszyk WooCommerce) wszystkie problemy wrócą.

Spotykamy to regularnie. Ktoś włącza Cloudflare, GTmetrix pokazuje lepsze wyniki, klient jest zadowolony. Potem przychodzi aktualizacja, cache jest wyczyszczony albo ruch trafia do nieprzewidywalnych URLi bez cache – i serwer znowu dyszy.

Cloudflare to warstwa na istniejącą infrastrukturę, nie zastępstwo za porządną konfigurację serwera.

Plany i co z nich realnie wynika

Darmowy plan Cloudflare jest naprawdę użyteczny. Obejmuje CDN, podstawowy DDoS, zarządzanie DNS, SSL, podstawowe reguły WAF. Dla większości małych i średnich stron WordPress to wystarczający punkt startowy.

Plan Pro (25 USD miesięcznie) dodaje m.in. rozszerzone reguły WAF, optymalizacje obrazków, lepszy priorytet wsparcia. Dla e-commerce i stron z ruchem rzędu kilkudziesięciu tysięcy sesji miesięcznie warto rozważyć.

Cloudflare APO (Automatic Platform Optimization) dla WordPressa to osobna usługa (5 USD miesięcznie, darmowa dla Pro i wyżej), która cachuje strony HTML łącznie z zawartością dynamiczną. Realnie skraca TTFB nawet dla zalogowanych użytkowników. Używamy przy projektach, gdzie wydajność frontendowa jest priorytetem.

Podsumowanie praktyczne

Cloudflare warto wdrożyć prawie zawsze – nie dlatego, że to modne, ale dlatego, że większość jego funkcji działa od razu i nie kosztuje nic. Dobry punkt startowy to:

Przejście na Full (strict) SSL
Włączenie Bot Fight Mode
Reguły blokujące /wp-login.php dla nieużywanych krajów
Skonfigurowany purge cache po zmianach w WordPress
Prawdziwe IP użytkowników przywrócone w konfiguracji serwera

To nie jest lista na tydzień. Przy sprawnej konfiguracji – godzina roboty.

Natomiast jeśli strona ma problemy z wydajnością albo bezpieczeństwem po stronie serwera, Cloudflare jest uzupełnieniem, nie rozwiązaniem. Najpierw należy naprawić infrastrukturę, potem nakładać kolejne warstwy.