Cloudflare dla WordPressa: pełna optymalizacja

Cloudflare to najlepsza darmowa rzecz, jaką możesz zrobić dla swojego WordPressa. Dla 90% stron plan Free wystarcza — daje CDN, cache, SSL, podstawowy WAF. W tym poście pokazuję pełną konfigurację, którą stosuję u każdego klienta.

Co Cloudflare daje ci za darmo

| Funkcja | Plan Free | Plan Pro ($20/m) | |---------|-----------|------------------| | CDN (cache statycznych zasobów) | ✅ | ✅ | | Universal SSL | ✅ | ✅ | | Podstawowy WAF (3 reguły) | ✅ | ✅ | | Rate limiting (1 reguła) | ✅ | 5 reguł | | DDoS protection (L3/L4) | ✅ | ✅ | | Bot Fight Mode | ✅ | ✅ zaawansowany | | Page Rules | 3 | 20 | | Workers (serverless) | 100k/dzień | 10M/dzień | | APO (HTML cache) | ❌ ($5/m) | ✅ w cenie Pro | | Image Resizing | ❌ | ✅ | | Web Analytics | ❌ | ✅ |

Moja rekomendacja: dla blogów i małych stron — Free + APO ($5/m) łącznie $5/miesiąc. Dla e-commerce i SaaS — Pro ($20/m).

Krok 1: Dodanie strony do Cloudflare

# 1. Załóż konto na cloudflare.com
# 2. Dodaj domenę → Cloudflare skanuje DNS records
# 3. Zmień nameservery u rejestratora (np. OVH, nazwa.pl) na:
#    ada.ns.cloudflare.com
#    bob.ns.cloudflare.com
#    (Cloudflare poda ci właściwe)
# 4. Poczekaj 24-48h na propagację DNS

Po propagacji cały ruch idzie przez Cloudflare. Twój serwer (origin) nie jest już bezpośrednio widoczny z internetu — atakujący widzi tylko IP Cloudflare. To już jest podstawowa ochrona DDoS.

Krok 2: SSL/TLS

Crypto → SSL/TLS ustaw na Full (strict). To wymusza HTTPS end-to-end (Cloudflare ↔ origin) z walidacją certyfikatu.

SSL/TLS → Overview → Full (strict)

Dlaczego nie "Flexible"? Flexible szyfruje tylko Cloudflare ↔ user, ale Cloudflare ↔ origin leci po HTTP. Ktoś w sieci origin providera może podsłuchać.

Na originie (serwer) potrzebujesz ważnego certyfikatu SSL. Najprościej: Let's Encrypt przez Certbot:

# Na serwerze origin
sudo apt install certbot python3-certbot-apache  # dla Apache
# lub
sudo apt install certbot python3-certbot-nginx  # dla Nginx

sudo certbot --nginx -d example.com -d www.example.com
# lub
sudo certbot --apache -d example.com -d www.example.com

Certbot automatycznie odnawia certyfikat co 60 dni.

Krok 3: Cache configuration

Caching → Configuration:

Caching Level: Standard
Browser Cache TTL: 4 hours
Crawler Hints: ON
Always Online: ON

Standard cache level cache'uje wszystko co się da z wyjątkiem dynamicznych endpointów. Dla WP bez APO to cache'uje CSS, JS, obrazy, fonty — czyli 80% requestów.

Page Rules (darmowe: 3 reguły)

Page Rules to najpotężniejsza funkcja darmowego planu. Trzy reguły, które dają najwięcej:

# Reguła 1: Cache HTML dla zalogowanych użytkowników - WYŁĄCZ
URL: *example.com/wp-admin*
Cache Level: Bypass
Security Level: High

# Reguła 2: Cache HTML dla postów (24h)
URL: *example.com/*
Cache Level: Cache Everything
Edge Cache TTL: 1 day
Browser Cache TTL: 4 hours

Cache Everything cache'uje HTML na edge Cloudflare. Bez APO to działa tylko wtedy, gdy Cloudflare widzi cache-control headers z origin. WordPress ich domyślnie nie wysyła — potrzebujesz pluginu Cloudflare (oficjalny) lub WP Super Cache.

Plugin Cloudflare dla WordPressa

# Zainstaluj oficjalny plugin Cloudflare
wp plugin install cloudflare --activate

# Włącz automatic cache purge przy update
# Ustaw API token w ustawieniach pluginu

Plugin dodaje też auto-purge cache przy publikacji posta. Bez tego musisz ręcznie klikać "Purge Cache" w Cloudflare po każdym update.

Krok 4: Performance optimizations

Speed → Optimization:

Auto Minify: HTML, CSS, JS (✓)
Brotli: ON
Early Hints: ON
Rocket Loader: ON (testuj, czasem psuje JS)

Auto Minify kompresuje CSS/JS/HTML w locie. Dla większości stron to zysk 10-20% na rozmiarze plików. Wyjątek: strony z inline critical CSS — minify może zepsuć kolejność.

Brotli to nowoczesna kompresja (lepsza niż gzip). Obsługiwana przez 95% przeglądarek. Daje 15-20% mniejsze transfer niż gzip.

Rocket Loader ładuje JS asynchronicznie. Dla prostych stron przyspiesza render. Dla skomplikowanych aplikacji (WooCommerce z dużą ilością JS) może powodować błędy — testuj.

Krok 5: Security (WAF + Bot Fight Mode)

Security → WAF → Managed Rules: włącz Cloudflare Managed Ruleset. To darmowy zestaw reguł chroniących przed znanymi atakami (SQL injection, XSS, PHP exploits). Zero konfiguracji, zero fałszywych alarmów na typowej stronie WP.

Security → Bots → Bot Fight Mode: włącz.

Security → Settings → Challenge Passage: 30 minutes.

Trzy custom WAF rules, które dodaję

# Reguła 1: Blokada XML-RPC (często atakowany)
Expression: http.request.uri.path contains "/xmlrpc.php"
Action: Block

# Reguła 2: Ochrona wp-login (rate limit)
Expression: http.request.uri.path contains "/wp-login.php"
Rate limit: 5 requests per 10 seconds
Action: Managed Challenge

# Reguła 3: Blokada skanerów User-Agent
Expression: 
  (http.user_agent contains "nikto") or
  (http.user_agent contains "sqlmap") or
  (http.user_agent contains "masscan")
Action: Block

XML-RPC to stary protokół WP (odpowiednik SOAP), dziś praktycznie zbędny, ale boty go atakują bo /xmlrpc.php ma proste metody "sprawdź czy hasło jest poprawne". Blokada = zero brute-force prób na tym endpoincie.

Krok 6: APO (HTML cache) - opcjonalne $5/m

APO to najważniejsza optymalizacja dla WP. Cache'uje HTML na edge Cloudflare. Bez APO HTML generuje origin (PHP + MySQL) przy każdym requeście. Z APO — HTML leci z najbliższego edge node Cloudflare.

Włączenie APO:

1. Cloudflare Dashboard → Speed → Optimization → APO
2. Włącz (koszt $5/m/site dla planu Free, darmowe w Pro)
3. Zainstaluj plugin Cloudflare w WP, podaj API token
4. Włącz "Auto-Purge on Update" w pluginie

Realne wyniki (z moich ostatnich 8 projektów):

| Metryka | Bez APO | Z APO | |---------|---------|-------| | TTFB (cache miss) | 600-1200ms | 400-800ms (origin) | | TTFB (cache hit) | 400-600ms | 30-80ms | | LCP (Largest Contentful Paint) | 2.5-4.0s | 1.2-2.0s | | Load time (P75) | 4.5-6.0s | 1.5-2.5s | | Ruch na originie | 100% | 5-15% |

To są liczby, które widziałem, nie marketingowe obietnice. Dla stron z >5k odsłon dziennie APO zwraca się w tydzień (mniej ruchu na serwerze = tańszy hosting).

Krok 7: Rate Limiting

Security → WAF → Rate Limit Rules (darmowy plan: 1 reguła):

URL: *example.com/wp-login.php
Rate: 5 requests per 10 seconds
Action: Block for 600 seconds

To chroni przed brute-force atakami na hasło. Bez tego bot próbuje 1000 kombinacji hasła na sekundę z jednego IP.

Dla planu Pro masz 5 reguł. Moja typowa konfiguracja:

1. /wp-login.php — 5 req/10s
2. /wp-admin/admin-ajax.php — 20 req/10s (dla AJAX)
3. /wp-json/* — 30 req/10s (dla REST API)
4. Global — 200 req/10s per IP (profilaktyka)

Krok 8: DNS — nie eksponuj origin IP

Krytyczny błąd: Twój serwer origin ma IP. Ktoś może je skanować bezpośrednio, omijając Cloudflare. Rozwiązanie:

1. Wymuś ruch przez Cloudflare: W Cloudflare DNS wyłącz proxy dla recordów A (pomarańczowa chmurka → szara chmurka dla origin). Ustaw origin IP w firewallu serwera na akceptuj tylko IP Cloudflare.

2. Ukryj origin IP za Cloudflare Tunnel (darmowe):

   # Na serwerze origin
   sudo cloudflared service install <tunnel-token>
   

3. Nie wysyłaj origin IP w emailach (SMTP header leak). Ustaw wp-config.php:

   // Wyłącz leaky Server header
   header_remove('X-Powered-By');
   header_remove('Server');
   

Krok 9: Monitoring i testowanie

# Sprawdź czy ruch idzie przez Cloudflare
curl -I https://example.com
# Szukaj: server: cloudflare

# Sprawdź cache status
curl -I https://example.com | grep -i cf-cache-status
# HIT / MISS / DYNAMIC / BYPASS / EXPIRED

# Test z różnych lokalizacji (darmowe)
# https://www.webpagetest.org
# https://tools.pingdom.com

# Cloudflare Web Analytics (darmowe dla Pro)
# Dashboard → Analytics → Web Analytics

Diagnostyka cache miss

Gdy widzisz dużo cf-cache-status: DYNAMIC, sprawdź:

• Query string w URL — Cloudflare domyślnie nie cache'uje URL-i z ?utm_source=.... Page Rule z "Ignore Query String" fix to.
• Cookie WP — gdy user jest zalogowany, Cloudflare nie cache'uje. Dla niezalogowanych: działa.
• Header Vary — jeśli origin wysyła Vary: User-Agent, cache dzieli się na N wariantów. W WP dodaj Vary: Accept-Encoding zamiast.

Częste błędy w konfiguracji

1. Włączenie "Cache Everything" bez Page Rule dla wp-admin

Efekt: zalogowani użytkownicy widzą buforowaną wersję strony, nikt nie może się zalogować. Fix: Page Rule z "Cache Level: Bypass" dla /wp-admin/* i /wp-login.php.

2. Wyłączenie proxy w DNS

Gdy user wyłączy pomarańczową chmurkę (proxy) na record A, ruch idzie bezpośrednio do origin. Zero ochrony, zero cache. Zawsze proxy=on dla głównej domeny i subdomen (www, cdn, itd.).

3. Brak Cloudflare pluginu w WP

Bez pluginu cache się nie czyści po update posta. User publikuje artykuł, nadal widzi starą wersję do 24h. Fix: plugin + auto-purge.

Co dalej

• WordPress REST API w praktyce
• Własny serwer mailowy
• BTRFS + snapshoty na Arch/CachyOS

Jeśli chcesz, żebym skonfigurował ci Cloudflare (z Cloudflare Tunnel dla ukrycia origin IP, optymalnym cache i WAF) — napisz do mnie. Robota na 1-2 dni, koszt od 800 PLN.