Jak wdrożyć Cloudflare na stronę

Cloudflare pozwala przyspieszyć stronę, poprawić bezpieczeństwo i uprościć zarządzanie ruchem bez zmian w kodzie. Wdrożenie polega głównie na przeniesieniu obsługi domeny do panelu dostawcy i właściwej konfiguracji polityk ruchu. Poniższa instrukcja prowadzi krok po kroku: od przygotowania i migracji rekordów, przez włączenie certyfikatów, optymalizację wydajności, aż po zabezpieczenia i testy. Dzięki temu unikniesz przestojów i od początku skorzystasz z najważniejszych funkcji platformy.

Przygotowanie i plan wdrożenia

Cel i minimalny plan działania

Zanim przełączysz domenę, przygotuj krótki, spisany plan. Dobrze zdefiniuj, co chcesz osiągnąć: szybkość ładowania, ochronę przed atakami, łatwiejsze zarządzanie rekordami, a może izolację zaplecza administracyjnego. Dla typowej witryny produkcyjnej bez przestoju plan obejmie: inwentaryzację rekordów DNS, eksport strefy z dotychczasowego panelu, dodanie domeny do Cloudflare, weryfikację importu, przełączenie serwerów nazw, konfigurację certyfikatów i reguł, a na końcu testy krawędziowe i monitorowanie.

Inwentaryzacja rekordów i zależności

Zrób pełny przegląd usług powiązanych z domeną. Zweryfikuj:

• Rekordy A/AAAA (adresy IPv4/IPv6), CNAME, MX (poczta), TXT (SPF, DKIM, DMARC), SRV, CAA i ewentualne NS w subdomenach.
• Systemy logowania SSO, webhooki, endpointy API, integracje płatności, usługi pocztowe i subdomeny zapleczowe (np. panel, staging).
• Certyfikaty, które obecnie działają na serwerze źródłowym i sposób ich odnowień (cron, ACME).

Warto wykonać eksport strefy w formacie BIND z obecnego panelu i zachować jako kopię. Sprawdź także TTL najważniejszych rekordów. Jeśli musisz zminimalizować czas propagacji, obniż je zawczasu (np. do 300 s), poczekaj na propagację i dopiero wtedy planuj przełączenie.

Wybór planu i funkcji

Dla większości stron startową bazą jest plan bezpłatny, który zapewnia globalną CDN, podstawowy firewall, kompresję, cache statyk i obsługę HTTP/2/3. Jeżeli obsługujesz duże API, aplikacje SPA lub serwisy o wysokim profilu ryzyka, rozważ płatne funkcje: reguły WAF klasy enterprise, Rate Limiting z większym limitem, Workers (logika na krawędzi), Argo (szybsze trasy) czy Tiered Cache. Zaplanuj budżet i zespół, który będzie utrzymywał konfigurację na dłużej.

Środowisko testowe i okno zmian

Najbezpieczniej jest przygotować środowisko staging w subdomenie i przećwiczyć cały proces tam. W produkcji zaplanuj okno zmian w godzinach mniejszego ruchu, przygotuj plan wycofania (rollback) i listę kontroli jakości po przełączeniu. Ustal osobę odpowiedzialną za komunikację z zespołem i dostawcami (rejestratorem domeny, hostingiem).

Delegacja domeny i kontrola ruchu

Dodanie domeny i import strefy

W panelu Cloudflare dodaj domenę. System przeskanuje aktualną strefę i zaproponuje import rekordów. Porównaj import z własnym eksportem BIND: czy wszystkie rekordy A/AAAA, CNAME, MX, TXT zostały zachowane, a wartości TTL są akceptowalne. Zwróć uwagę na aliasy, subdomeny techniczne (np. _acme-challenge), rekordy dla usług społecznych i weryfikacyjnych.

Proxy a tylko rozwiązywanie

W Cloudflare każdy rekord może być objęty ruchem przez proxy (pomarańczowa chmurka) albo działać jako zwykły resolver (szara chmurka). Proxy zapewnia ochronę i przyspieszenie, ale nie zawsze jest właściwe. Rekordy pocztowe (MX) i wpisy używane przez SMTP/IMAP powinny pozostać bez proxy. Dla A/AAAA/CNAME wskazujących na web warto włączyć proxy, aby korzystać z krawędziowego buforowania, kompresji i ochrony aplikacyjnej.

Zmiana serwerów nazw u rejestratora

Po zatwierdzeniu strefy otrzymasz parę serwerów nazw (Nameserver), które należy wprowadzić w panelu rejestratora domeny. Zmiana deleguje cały autorytet strefy do Cloudflare. Po zapisaniu poczekaj na propagację (zwykle od kilku minut do 24 godzin). W tym czasie nie zmieniaj równolegle rekordów u starego operatora, aby uniknąć rozjazdu.

Weryfikacja propagacji i ruchu

Sprawdź propagację poleceniami dig/nslookup z różnych lokalizacji. Następnie sprawdź, czy ruch HTTP trafia do krawędzi Cloudflare: wykonaj curl -I domena.pl i poszukaj nagłówków cf-ray oraz serwera krawędzi. Jeśli widzisz hosting źródłowy, to rekord może nie mieć włączonego proxy. Jeżeli wszystko działa, przejdź do certyfikatów i polityk HTTP.

Konfiguracja protokołów i bezpieczeństwa

Certyfikaty i tryby szyfrowania

W zakładce bezpieczeństwa wybierz tryb szyfrowania: Flexible, Full lub Full (strict). Zalecaną opcją jest Full (strict), który wymaga ważnego certyfikatu na serwerze źródłowym. Możesz zainstalować darmowy certyfikat origin od Cloudflare lub użyć Let’s Encrypt. Dzięki temu negocjacja TLS do originu będzie w pełni weryfikowana.

Po stronie krawędzi Cloudflare automatycznie wystawi certyfikaty dla Twojej domeny. Włącz wymuszanie HTTPS, a jeśli aplikacja jest gotowa, skonfiguruj HSTS z ostrożnym, stopniowym wydłużaniem max-age. Użyj również Automatic HTTPS Rewrites, aby zredukować mieszane treści.

Wymuszenie HTTPS i polityki przeglądarki

Aktywuj Always Use HTTPS, a następnie przetestuj witrynę pod kątem zasobów ładujących się z protokołem http. W razie potrzeby włącz przepisywanie linków i zaktualizuj konfigurację serwera, aby unikać bezwzględnych adresów bez wskazania https. HSTS wdrażaj ostrożnie: najpierw krótki czas (np. 5 minut), potem 1 dzień, tydzień, miesiąc.

Zapora aplikacyjna i reguły

Włącz reguły zarządzane przez dostawcę i dostosuj ich czułość do profilu aplikacji. Dopasuj wyjątki dla endpointów API, webhooków i panelu administracyjnego. Zdefiniuj własne reguły blokujące nietypowe metody, podejrzane nagłówki lub parametry. To trzon ochrony zapewnianej przez WAF, który filtruje ruch przed dotarciem do serwera źródłowego.

Ochrona przed nadużyciami i botami

Włącz Rate Limiting dla wrażliwych endpointów (logowanie, rejestracja, wyszukiwanie), stosuj captche/wyzwania i wykrywaj anomalie. Dla sekcji administracyjnych rozważ politykę dostępu opartą na adresach IP lub kraju, a także rozwiązania bez-captcha. Jeśli masz specyficzny ruch automatyczny, naucz reguły by go akceptowały, a resztę ograniczaj.

Odporność na ataki wolumetryczne

Cloudflare filtruje ataki warstw 3/4, a także wiele ataków aplikacyjnych. Skonfiguruj tryb „Under Attack” na czas intensywnych kampanii, monitoruj wykresy ruchu i nośności. Zadbaj o stabilność originu: odpowiednie limity połączeń, keep-alive, zasoby systemowe i reguły na load balancerze. Odpowiednie przygotowanie zmniejszy ryzyko przerwy nawet przy poważnych atakach DDoS.

Wydajność, buforowanie i optymalizacje

Zasady buforowania i kontrola nagłówków

Skonfiguruj zasady buforowania tak, by statyki były serwowane z krawędzi, a treści dynamiczne pozostały świeże. Cloudflare rozróżnia czas życia zasobu po stronie przeglądarki i po stronie krawędzi. Określą to nagłówki Cache-Control i Expires. Tam, gdzie to możliwe, pozwól na długie czasy życia i wersjonuj zasoby po nazwie pliku. Dla stron dynamicznych rozważ krótkie czasy oraz precyzyjne unieważnianie.

Przydatne są zasady Cache Rules oraz selektywny „Cache Everything” na trasach, gdzie odpowiedź jest identyczna dla wielu użytkowników. Wyklucz panele administracyjne i koszyk/składanie zamówień. Testuj nagłówek CF-Cache-Status w odpowiedziach (HIT, MISS, BYPASS) i sprawdzaj, czy buforowanie działa zgodnie z oczekiwaniami. Pamiętaj, że posiadanie wydajnej warstwy cache to najszybszy sposób na obniżenie TTFB.

Uszczelnienie HTTP i kompresja

Włącz minifikację JS/CSS/HTML, kompresję Brotli, Early Hints oraz prioritetyzację zasobów. Tryby HTTP/2 i obsługa HTTP/3 z QUIC poprawiają wydajność w trudnych sieciach mobilnych. Rozważ ostrożnie mechanizmy takie jak Rocket Loader dla ciężkich witryn JS – potrafią pomóc, ale wymagają testów kompatybilności. Usuwaj zbędne wtyczki, ładuj skrypty asynchronicznie, stosuj preconnect/preload do kluczowych domen.

Optymalizacja obrazów i mediów

Dopasuj rozmiar i format obrazów do urządzeń końcowych. Funkcje konwersji do nowoczesnych formatów (AVIF/WebP), skalowanie na krawędzi, leniwe ładowanie oraz inteligentne zastępniki zwiększają LCP i TTI. Dla wideo używaj strumieniowania z adaptacyjną przepływnością i segmentacją. Kontroluj nagłówki cache dla mediów, by rzadko zmieniane treści trafiały do krawędzi i zostały tam jak najdłużej.

Reguły dla aplikacji i platform

W witrynach CMS zadbaj o wyjątki: ominięcie buforowania dla panelu i koszyka, krótkie TTL dla stron dynamicznych, a długie dla zasobów wersjonowanych. Warto włączyć funkcje dedykowane dla popularnych platform, np. APO dla WordPress: pozwala serwować pełne strony z krawędzi i respektować czyszczenie cache z poziomu CMS. Przy dużej skali sprawdź Tiered Cache i rezerwę bufora, a przy globalnej publiczności rozważ geograficzne reguły preferencji i prefetchu.

Testy, utrzymanie i rozwiązywanie problemów

Kontrola nagłówków i ścieżki żądania

Po migracji testuj kluczowe adresy: strona główna, logowanie, płatności, panel. Użyj curl -I oraz narzędzi deweloperskich przeglądarki, by sprawdzić nagłówki odpowiedzi: CF-Cache-Status, CF-Ray, Server, Age, Content-Encoding, vary. Zwróć uwagę, czy wymuszenie HTTPS działa, czy nie pojawiają się mieszane treści i czy cookies mają właściwe atrybuty (Secure, HttpOnly, SameSite). Dla API kontroluj CORS i nagłówki Vary.

Diagnostyka DNS i propagacji

Używaj dig/nslookup, by sprawdzić, które serwery odpowiadają i jakie adresy IP są rozwiązywane w poszczególnych regionach. Różnice regionalne podczas propagacji są normalne. Gdy widzisz niespójności, sprawdź, czy rekord jest proxowany, czy tylko rozwiązywany. Pamiętaj, że rekordy MX i inne niewebowe zwykle powinny pozostać bez proxy.

Typowe błędy i ich przyczyny

• 521/520 – serwer źródłowy nie odpowiada lub zwraca błąd niestandardowy. Sprawdź firewall hostingu, blokady IP, logi aplikacji.
• 522 – timeout przy łączeniu z originem. Zweryfikuj połączenia łączące, obciążenie, limity i routing.
• 523/530 – problem z rozwiązywaniem adresu originu. Rekordy A/AAAA/CNAME mogą być niewłaściwe.
• 525 – błąd negocjacji SSL do originu. Certyfikat, szyfry lub protokoły są niezgodne.
• 526 – nieważny certyfikat przy trybie Full (strict). Zainstaluj poprawny certyfikat na originie lub użyj certyfikatu origin.

Tryb deweloperski i unieważnianie

Gdy wdrażasz zmiany frontendu, włącz tryb Development, by pominąć buforowanie na krawędzi przez 3 godziny. Po publikacji wyczyść selektywnie zasoby: po URL, prefiksie lub tagu. Unikaj globalnego purge, jeśli nie jest konieczny – to obciąża krawędź i degraduje metryki chwilowo. Testuj zmiany w prywatnym oknie przeglądarki lub z wyłączonymi rozszerzeniami.

Wyłączanie i obejścia w razie problemów

Jeśli potrzebujesz szybko wykluczyć wpływ krawędzi, użyj opcji „Pause” dla strefy, przełącz wybrane rekordy na tryb bez proxy lub wpisz rekordy do pliku hosts na własnym komputerze i testuj origin bezpośrednio. To pozwala odróżnić problem aplikacji od konfiguracji krawędziowej. Utrzymuj prostą regułę: najpierw sprawdź origin (czy działa), potem trasę i dopiero na końcu polityki chmurowe.

Monitorowanie i higiena bezpieczeństwa

Skonfiguruj alerty dotyczące dostępności, nietypowego wzrostu błędów, spadku hit-rate’u cache oraz wzmożonej aktywności firewall. Analizuj wykresy ruchu – szczególnie piki żądań i wzory botów. W panelu konta korzystaj z polityki najmniejszych uprawnień, oddzielnych tokenów API i uwierzytelniania wieloskładnikowego. Regularnie przeglądaj reguły i dzienniki, aby usuwać wyjątki, które przestały być potrzebne.

Migracje bez przestoju i dobre praktyki

Aby zminimalizować ryzyko, planuj rollout etapowy. Zacznij od mniej krytycznych subdomen, potem przenieś główne. Dla aplikacji o dużym ruchu przygotuj plan cięcia ruchu i powrotu, testy obciążeniowe i spójność cache. Dokumentuj wszystkie zmiany, a po migracji utrzymuj runbook: jak diagnozować 5xx, co zrobić przy spadku wydajności, jakie limity i reguły są kluczowe. Regularnie audytuj ustawienia i aktualizuj je wraz z ewolucją aplikacji.