CDN dla WordPress - konfiguracja Cloudflare krok po kroku

CDN (Content Delivery Network) to rozproszona sieć serwerów rozsianych po całym świecie, nazywanych węzłami edge. Zamiast pobierać każdy plik z Twojego jednego serwera w Polsce, przeglądarka odwiedzającego ściąga statyczne zasoby (obrazy, CSS, JavaScript, czcionki) z najbliższego geograficznie węzła. Krótszy dystans to mniejsze opóźnienie i szybsze ładowanie.

Cloudflare działa jako odwrotne proxy (reverse proxy). Po podpięciu domeny cały ruch przechodzi najpierw przez infrastrukturę Cloudflare, a dopiero potem trafia do Twojego serwera. Daje to kilka konkretnych korzyści:

• Szybkość – statyczne pliki serwowane z edge, bliżej użytkownika
• Odciążenie serwera – mniej zapytań trafia na hosting, bo Cloudflare odpowiada z cache
• Ochrona DDoS – ataki wolumetryczne są filtrowane zanim dotrą do serwera
• Oszczędność transferu – ruch obsłużony z cache nie zużywa limitu Twojego hostingu
• SEO – szybsze Core Web Vitals (LCP, INP) i stabilne SSL to pośredni sygnał rankingowy

W praktyce dla typowej strony WordPress największy zysk daje cache statycznych zasobów i kompresja Brotli, a nie samo skrócenie dystansu sieciowego.

Wbrew temu, co sugeruje większość poradników, CDN nie zawsze daje spektakularne przyspieszenie. Warto uczciwie rozróżnić scenariusze.

Mały zysk prędkości, głównie ochrona – jeśli masz polski hosting i wyłącznie polskich odbiorców, sygnał i tak biegnie kilkadziesiąt kilometrów. Cloudflare ma w Polsce węzły (m.in. Warszawa), więc geograficzny zysk jest niewielki. Tu CDN opłaca się głównie za ochronę DDoS, darmowy SSL i kompresję Brotli, a nie za samą prędkość.

Duży zysk – w tych przypadkach CDN realnie pomaga:

• Ruch globalny lub międzynarodowy – odbiorcy z różnych kontynentów dostają content z lokalnych węzłów
• Strony z dużą ilością mediów – galerie, portfolio, dużo grafiki; cache obrazów na edge zdejmuje obciążenie z serwera
• Słaby lub współdzielony hosting – odciążenie serwera bywa ważniejsze niż dystans
• Sklepy WooCommerce – ale tu konfiguracja musi być ostrożna (osobna sekcja niżej)

Jeśli zależy Ci na realnej wydajności, sam CDN to za mało – kluczowy jest też dobry hosting i optymalizacja samego WordPressa. CDN to warstwa, nie cudowny lek.

Rejestracja zajmuje kilka minut:

1. Wejdź na cloudflare.com i załóż darmowe konto (e-mail + hasło).
2. Kliknij Add a Site / Dodaj witrynę i wpisz swoją domenę bez www (np. `twojadomena.pl`).
3. Wybierz plan Free – w 90% przypadków w zupełności wystarczy.
4. Cloudflare automatycznie przeskanuje istniejące rekordy DNS.

Najważniejszy moment – sprawdzenie rekordów. Po skanie zobaczysz listę rekordów A, CNAME, MX, TXT. Zanim przejdziesz dalej, upewnij się że rekordy MX (poczta) zostały poprawnie zaimportowane. To najczęstszy błąd początkujących: po zmianie nameserwerów przestaje działać e-mail, bo brakuje rekordu MX albo SPF/DKIM (TXT). Porównaj listę z panelem rejestratora lub hostingu i ręcznie dodaj brakujące pozycje.

Wskazówka: rekord poczty (MX) oraz subdomena typu `mail.` powinny mieć szarą chmurkę (proxy OFF) – o tym w kolejnej sekcji.

Cloudflare przejmuje obsługę DNS, dlatego musisz wskazać jego serwery nazw u swojego rejestratora domeny.

1. Cloudflare poda Ci dwa adresy nameserwerów (np. `nora.ns.cloudflare.com` i `rick.ns.cloudflare.com`).
2. Zaloguj się do panelu rejestratora (tam gdzie kupiłeś domenę).
3. W ustawieniach DNS/serwerów nazw zastąp dotychczasowe nameservery tymi z Cloudflare.
4. Zapisz zmiany.

Czas propagacji jest orientacyjny i zależy od rejestratora oraz TTL. Zwykle aktywacja następuje w ciągu kilku godzin, choć teoretycznie pełna propagacja DNS może potrwać do 24-48 godzin. W praktyce dla większości polskich rejestratorów to kilka–kilkanaście godzin.

Jak zweryfikować aktywację: w panelu Cloudflare status domeny zmieni się na Active (zielony). Dostaniesz też e-mail z potwierdzeniem. Dopóki widzisz status Pending Nameserver Update, Cloudflare jeszcze nie przejął ruchu i ustawienia cache nie działają.

W zakładce DNS przy każdym rekordzie A i CNAME widzisz ikonę chmurki. To kluczowe rozróżnienie, które decyduje, co przechodzi przez infrastrukturę Cloudflare.

• Pomarańczowa chmurka (Proxied / proxy ON) – ruch przechodzi przez Cloudflare. Działa cache, CDN, ochrona DDoS, SSL Cloudflare, a prawdziwe IP serwera jest ukryte. To chcesz mieć na głównym rekordzie strony (`@` i `www`).
• Szara chmurka (DNS only / proxy OFF) – Cloudflare tylko rozwiązuje DNS, ruch idzie prosto do serwera. Brak cache i ochrony, ale też brak ingerencji.

Co zostawić na szarej chmurce:

• Rekordy MX i subdomeny pocztowe (`mail.`) – Cloudflare nie proxuje poczty
• Rekordy używane do weryfikacji domeny (część TXT)
• Subdomeny FTP/SSH lub paneli, jeśli wymagają bezpośredniego połączenia

Reguła: strona = pomarańczowa, poczta i usługi techniczne = szara. Pomylenie tego psuje e-mail albo wystawia serwer bezpośrednio.

To miejsce, w którym najwięcej osób popełnia błąd skutkujący pętlą przekierowań (ERR_TOO_MANY_REDIRECTS). W zakładce SSL/TLS masz cztery tryby:

• Off – brak szyfrowania, nie używać.
• Flexible – szyfrowanie tylko między użytkownikiem a Cloudflare; połączenie Cloudflare–serwer jest po HTTP. Najczęstsze źródło pętli przekierowań w WordPress, gdy strona ma wymuszony HTTPS. Unikaj.
• Full – szyfrowanie na obu odcinkach, ale akceptuje certyfikat self-signed na serwerze. Bezpieczne minimum.
• Full (Strict) – pełne szyfrowanie + walidacja certyfikatu serwera. Rekomendowane ustawienie, jeśli masz na hostingu ważny certyfikat (np. darmowy Let's Encrypt). Większość polskich hostingów wystawia go automatycznie.

Zalecana konfiguracja dla WordPress:

• Tryb Full (Strict) (lub Full, jeśli nie masz cert. na serwerze)
• Always Use HTTPS – ON (przekierowanie HTTP→HTTPS)
• Automatic HTTPS Rewrites – ON (naprawia mixed content)
• Minimum TLS Version – ustaw na 1.2 (1.0 i 1.1 są przestarzałe i niebezpieczne)

Jeśli po włączeniu pojawi się pętla – najpierw sprawdź, czy nie masz Flexible przy jednoczesnym wymuszaniu HTTPS we wtyczce/`.htaccess`. Zmiana na Full (Strict) zwykle rozwiązuje problem. Więcej o certyfikatach w naszym wpisie o SSL i HTTPS w WordPress.

Po aktywacji domeny przejdź do zakładek Caching i Speed, aby dostroić wydajność.

Caching:
- Caching Level – ustaw Standard (cache uwzględnia ciągi zapytań).
- Browser Cache TTL – ustaw na kilka dni do tygodnia (np. 1 dzień to bezpieczny start, dłuższy TTL dla stron rzadko zmienianych).
- Always Online – ON; gdy serwer padnie, Cloudflare pokaże zarchiwizowaną wersję strony.

Speed / Optimization:
- Brotli – ON (lepsza kompresja niż gzip, mniejszy transfer).
- Auto Minify – uwaga: w nowszych panelach Cloudflare ta opcja została wycofana, bo minifikację lepiej robi wtyczka cache w WordPress. Jeśli ją widzisz i nie używasz wtyczki – możesz włączyć dla CSS/JS/HTML, ale testuj.
- Rocket Loader – OSTROŻNIE. Asynchronicznie ładuje JavaScript, co bywa pomocne, ale często powoduje konflikty z motywami, sliderami, formularzami i skryptami płatności. Włączaj tylko, jeśli przetestujesz całą stronę po włączeniu. Domyślnie zalecam OFF.

Zasada: nie kumuluj minifikacji w dwóch miejscach (Cloudflare + wtyczka cache), bo podwójne przetwarzanie może zepsuć skrypty.

Domyślnie Cloudflare cache'uje tylko statyczne pliki, ale przy agresywnych ustawieniach lub cache HTML musisz jawnie wykluczyć obszary dynamiczne, inaczej zalogowani użytkownicy zobaczą cudzy widok.

Co bezwzględnie wyłączyć z cache (Bypass Cache):

• `/wp-admin/*` – panel administracyjny
• `wp-login.php` – strona logowania
• `/cart/`, `/checkout/`, `/my-account/` (koszyk, kasa, konto – WooCommerce)
• adresy z `wp-ajax` / `admin-ajax.php`

Ważna zmiana w panelu: klasyczne Page Rules są wygaszane, a Cloudflare migruje funkcjonalność do nowego silnika Rules → Cache Rules (oraz Configuration Rules). Na planie Free liczba darmowych Page Rules jest ograniczona (historycznie 3), dlatego nowe wykluczenia twórz raczej w Cache Rules. Jeśli widzisz jeszcze Page Rules – działają, ale docelowo przejdź na Cache Rules.

Przykład reguły Cache Rules: dla ścieżek zawierających `/cart/`, `/checkout/`, `/my-account/`, `wp-admin` ustaw Cache eligibility: Bypass cache. Dzięki temu sesje i koszyki klientów nigdy nie wpadną do cache edge.

Cloudflare i wtyczka cache nie wykluczają się – najlepiej działają razem. Cloudflare obsługuje warstwę sieci/edge, a wtyczka cache w WordPress generuje statyczny HTML i optymalizuje zasoby na poziomie serwera.

Najpopularniejsze wtyczki i jak współpracują z Cloudflare:

• LiteSpeed Cache – darmowa, świetna na hostingach z LiteSpeed; ma wbudowaną integrację z Cloudflare (czyszczenie cache przez API).
• WP Rocket – płatna, ale ma natywny moduł Cloudflare; po podaniu klucza API automatycznie czyści cache edge przy aktualizacji treści.
• W3 Total Cache – darmowa, rozbudowana, również obsługuje API Cloudflare w zakładce ustawień rozszerzeń.
• Oficjalna wtyczka Cloudflare – instaluje preset Optimized for WordPress, jednoklikowe purgowanie cache i Automatic Platform Optimization.

Konfiguracja połączenia API: w ustawieniach wtyczki podajesz adres e-mail konta Cloudflare i API Key lub bezpieczniejszy API Token (zalecany – z ograniczonymi uprawnieniami do konkretnej strefy). Dzięki temu po każdej zmianie wpisu wtyczka automatycznie wyczyści cache Cloudflare, więc odwiedzający zobaczą aktualną wersję.

Unikaj dublowania funkcji: jeśli minifikujesz w WP Rocket, nie włączaj jej w Cloudflare. Pomoc w doborze i konfiguracji wtyczek oferujemy w ramach opieki nad WordPress od 299 zł/mies.

Automatic Platform Optimization (APO) to płatny (lub wliczony w plan Pro) dodatek dedykowany WordPress. Jego główna przewaga: cache'uje cały HTML strony na edge, a nie tylko statyczne pliki. Efekt to drastycznie niższy TTFB, bo żądanie odwiedzającego w ogóle nie dochodzi do Twojego serwera PHP/MySQL.

Dla kogo APO się opłaca:
- Blogi, strony firmowe, portfolio – treść w większości statyczna, ogromny zysk prędkości
- Strony o globalnym ruchu, gdzie TTFB z serwera jest wysoki

Dla kogo APO jest ryzykowne:
- Sklepy WooCommerce i strony z dużą ilością treści dynamicznej (zalogowani użytkownicy, koszyk). APO rozpoznaje ciasteczka zalogowania i koszyka i omija cache dla tych sesji, ale wymaga to poprawnej konfiguracji – błąd może pokazać gościowi spersonalizowany widok.

Cache treści dynamicznej – zasada nadrzędna: nigdy nie cachuj stron, które różnią się per użytkownik. To koszyk, kasa, konto klienta, pulpit WP. APO i oficjalna wtyczka Cloudflare automatycznie respektują standardowe ciasteczka WooCommerce, ale przy nietypowych wtyczkach członkostwa zawsze przetestuj na koncie testowym.

Sklep to najtrudniejszy przypadek, bo cache jednej osoby nie może wyciec do drugiej. Oto konkretny zestaw zasad dla WooCommerce:

Bezwzględnie NIE cachować (Bypass cache w Cache Rules):
- `/cart/` – koszyk
- `/checkout/` – kasa
- `/my-account/` – panel klienta
- `wp-admin` i `wp-login.php`
- żądania `admin-ajax.php` / `wp-ajax`

Ciasteczka sesji klienta: WooCommerce ustawia ciasteczka takie jak `woocommerce_cart_hash`, `woocommerce_items_in_cart` oraz `wp_woocommerce_session_*`. Cache musi je respektować – obecność tych ciasteczek powinna oznaczać Bypass cache. Oficjalna wtyczka Cloudflare i APO robią to automatycznie; przy ręcznej konfiguracji ustaw regułę omijania cache po wykryciu ciasteczka sesji.

Strony produktów i kategorii można cachować – są takie same dla wszystkich. To one dają największy zysk wydajności w sklepie.

Ostrzeżenie: najgorszy możliwy błąd to zacachowanie koszyka lub kasy. Klient A widzi wtedy produkty klienta B, a zamówienia trafiają w złe miejsce. Zawsze testuj na dwóch przeglądarkach (zalogowany + tryb incognito) po wdrożeniu. Profesjonalne wdrożenie sklepu internetowego realizujemy od 8000 zł z poprawną konfiguracją cache od startu.

Dla zdecydowanej większości polskich stron WordPress plan Free w zupełności wystarcza: darmowy SSL, CDN, ochrona DDoS, Brotli, podstawowe Cache Rules.

Plan Pro (płatny miesięcznie) dokłada:
- WAF (Web Application Firewall) z gotowymi regułami chroniącymi WordPress przed znanymi exploitami (np. ataki na `xmlrpc.php`, próby SQL injection)
- Optymalizacja obrazów (Polish/Mirage) – automatyczna kompresja i lżejsze ładowanie grafiki na słabych łączach
- Nielimitowane Page Rules / rozbudowane Cache Rules
- Lepsze raportowanie i szybsze wsparcie

Kiedy warto dopłacić do Pro:
- Sklep WooCommerce lub strona z danymi klientów (WAF realnie podnosi bezpieczeństwo)
- Witryna często atakowana lub o dużym ruchu
- Dużo grafiki, gdzie optymalizacja obrazów daje wymierny zysk

Dla zwykłej strony wizytówki czy bloga firmowego Pro to zwykle zbędny koszt – lepiej te pieniądze przeznaczyć na dobry hosting.

Większość poradników obiecuje przyspieszenie, ale nie pokazuje, jak je zmierzyć. Oto konkretny mini-proces PRZED i PO:

1. Zmierz stan wyjściowy (przed Cloudflare):
- PageSpeed Insights (pagespeed.web.dev) – zanotuj wynik mobile i desktop oraz LCP
- GTmetrix – zapisz czas ładowania i wagę strony
- TTFB (Time To First Byte) – widoczny w GTmetrix lub zakładce Network w DevTools przeglądarki

2. Wdróż Cloudflare i odczekaj kilka godzin, aż cache się zapełni.

3. Zmierz ponownie te same adresy i porównaj. Najbardziej widoczna zmiana powinna być w TTFB (zwłaszcza z włączonym APO) i w czasie ładowania zasobów statycznych.

4. Sprawdź cache hit ratio – w panelu Cloudflare w zakładce Analytics → Caching zobaczysz procent żądań obsłużonych z cache (Cache Hit Ratio). Im wyżej, tym lepiej; zdrowa strona statyczna osiąga 90%+ na zasobach.

Powiązanie z SEO: poprawa Core Web Vitals (LCP, INP) realnie wpływa na pozycje w wynikach mobilnych Google. Mierz CWV w PageSpeed Insights i w raporcie Core Web Vitals w Search Console – to one liczą się dla rankingu, nie sztuczne wyniki laboratoryjne.

Błędy 520 / 521 / 522 – to błędy połączenia Cloudflare z Twoim serwerem:
- 521 – serwer odrzucił połączenie (down lub zablokowane IP Cloudflare przez firewall hostingu). Sprawdź, czy hosting nie blokuje zakresów IP Cloudflare i czy serwer działa.
- 522 – przekroczony czas połączenia (przeciążony serwer lub blokada portu). Kontakt z hostingiem.
- 520 – ogólny błąd, zwykle nietypowa odpowiedź serwera.

Pętla przekierowań (ERR_TOO_MANY_REDIRECTS) – prawie zawsze tryb SSL Flexible przy wymuszonym HTTPS. Zmień na Full (Strict).

Konflikt Rocket Loader – jeśli po włączeniu Cloudflare slidery, formularze lub menu przestały działać, wyłącz Rocket Loader.

Cache się nie odświeża – zmieniłeś treść, a widać starą wersję:
- Włącz Development Mode (Caching → Configuration) – na 3 godziny omija cache, idealne do prac na żywo.
- Albo użyj Purge Cache → Purge Everything, by wyczyścić całość. Do pojedynczych plików użyj Custom Purge.

Reguła ogólna: przy każdym dziwnym zachowaniu najpierw włącz Development Mode, żeby wykluczyć cache jako przyczynę.

To temat pomijany w większości poradników, a istotny. Gdy włączysz proxy (pomarańczowa chmurka), Twój serwer widzi w logach adresy IP Cloudflare, a nie realne IP odwiedzających. Skutki:

• statystyki i analityka pokazują kilka IP Cloudflare zamiast tysięcy użytkowników
• geolokalizacja przestaje działać
• wtyczki antyspamowe i firewall (np. Wordfence, Limit Login Attempts) blokują wszystkich lub nikogo, bo widzą jedno IP
• rate limiting i bany IP stają się bezużyteczne

Rozwiązanie: Cloudflare przekazuje prawdziwe IP w nagłówku `CF-Connecting-IP` (oraz `X-Forwarded-For`). Trzeba powiedzieć serwerowi/WordPressowi, żeby go odczytał:

• Wtyczka – większość wtyczek bezpieczeństwa (Wordfence) ma opcję Detect IP z nagłówka Cloudflare; włącz ją. Jest też dedykowana wtyczka Cloudflare, która ustawia to automatycznie.
• Konfiguracja serwera – na poziomie Nginx/Apache instaluje się moduł `mod_cloudflare` lub konfiguruje `set_real_ip_from` z zakresami IP Cloudflare. To najtrwalsze rozwiązanie, działa dla wszystkich aplikacji na serwerze.

Bez tego kroku Twoje statystyki i zabezpieczenia oparte o IP są bezużyteczne.

Cloudflare wygląda na proste narzędzie, ale jeden błędny przełącznik (Flexible SSL, zacachowany koszyk, Rocket Loader psujący formularz) potrafi rozłożyć stronę albo, co gorsza, sklep. Jeśli nie masz pewności, wolisz oddać to specjaliście.

W KC Mobile od 20+ lat budujemy i optymalizujemy strony oraz sklepy WordPress. Jako Google Partner łączymy wydajność z realnym efektem biznesowym:

• Strony internetowe na WordPress od 3000 zł, z poprawną konfiguracją CDN i cache od startu – zobacz ofertę stron internetowych i usług WordPress
• Sklepy WooCommerce od 8000 zł z bezpiecznym cache (koszyk i kasa nigdy nie wpadają do cache)
• Opieka nad WordPress od 299 zł/mies. – aktualizacje, backupy, monitoring wydajności
• Audyt cyfrowy strony, jeśli chcesz najpierw zdiagnozować, co spowalnia witrynę

Masz wolniej działającą stronę albo problem z konfiguracją Cloudflare? Skontaktuj się z nami – zdiagnozujemy wąskie gardła i wdrożymy CDN bez ryzyka pętli przekierowań czy wycieku sesji klientów.