Reverse proxy to warstwa pośrednia między użytkownikiem a serwerem backendowym. W kontekście WordPress — serwer (najczęściej Nginx), który przyjmuje żądania klientów, przetwarza je (terminacja SSL, cache, nagłówki bezpieczeństwa) i przekazuje do backendu (Apache z PHP-FPM, drugi Nginx lub kontener Docker z WordPress). Dla użytkownika jest niewidoczny. Dla wydajności i bezpieczeństwa strony — fundamentalny. W tym artykule wyjaśniamy, czym dokładnie jest reverse proxy, jakie ma zastosowania w hostingu WordPress, jak go skonfigurować na Nginx i Apache oraz jakich pułapek unikać.
Czym jest reverse proxy i jak działa
Reverse proxy to serwer pośredniczący po stronie serwera, nie klienta. Forward proxy chroni klienta (VPN, korporacyjny firewall), reverse proxy chroni serwer. Klient nie wie, że komunikuje się z pośrednikiem — widzi jedynie docelową domenę.
Proxy „odwrotne"
Zwykły (forward) proxy działa w imieniu klienta — ukrywa klienta przed serwerem. Reverse proxy działa w imieniu serwera — ukrywa backend przed klientem. Użytkownik łączy się z proxy, myśląc, że to docelowy serwer. Proxy decyduje: zwrócić odpowiedź z cache, przekazać żądanie do backendu, odrzucić je lub przekierować.
Przepływ żądania
Użytkownik → DNS → Reverse proxy (port 80/443) → Backend (port wewnętrzny). Proxy dodaje nagłówki przekazujące informacje o oryginalnym żądaniu: X-Forwarded-For (IP klienta), X-Real-IP (prawdziwy adres), X-Forwarded-Proto (HTTP czy HTTPS). Backend na podstawie tych nagłówków odtwarza kontekst oryginalnego połączenia.
Reverse proxy vs forward proxy vs CDN
Forward proxy: działa po stronie klienta — VPN, korporacyjne firewalle, anonimizacja. CDN: rozproszona sieć cache na setkach lokalizacji na świecie (Cloudflare, Fastly, CloudFront). Reverse proxy: jedna warstwa przed backendem, na tym samym serwerze lub w tej samej sieci. CDN to w istocie globalnie rozproszony reverse proxy.
Popularne reverse proxy
Nginx — najpopularniejszy reverse proxy, świetny do cache i terminacji SSL. Apache z mod_proxy — pełnoprawna opcja, popularna w konfiguracjach hybrydowych. HAProxy — dedykowany load balancer i proxy o najwyższej wydajności. Varnish — specjalizowany cache proxy. Traefik — proxy dla kontenerów Docker i Kubernetes. Cloudflare — reverse proxy as a service z wbudowanym CDN.
Zastosowania reverse proxy w praktyce
Reverse proxy nie jest technologią dla samej technologii — rozwiązuje konkretne problemy wydajności, bezpieczeństwa i architektury. Oto najczęstsze scenariusze w kontekście hostingu WordPress i aplikacji webowych.
Terminacja SSL
Proxy obsługuje szyfrowanie TLS — backend komunikuje się po zwykłym HTTP. Korzyści: odciążenie backendu z kosztownych operacji kryptograficznych, centralizacja zarządzania certyfikatami (jeden punkt odnowienia Let's Encrypt dla wielu backendów), możliwość kierowania ruchu na podstawie SNI do różnych backendów.
Cache odpowiedzi
Nginx FastCGI cache, Varnish, Apache mod_cache — proxy zwraca odpowiedź z pamięci lub dysku bez angażowania PHP. Nawet 1-sekundowy cache eliminuje powtarzające się żądania do backendu. Kluczowe dla stron WordPress z dużym ruchem — setki tysięcy żądań obsłużonych bez uruchamiania PHP-FPM. Cache na proxy to najszybsza warstwa cache w całym stosie.
Load balancing
Rozkładanie ruchu między wieloma backendami. Algorytmy: round-robin (kolejno), least connections (do najmniej obciążonego), ip_hash (klient zawsze do tego samego backendu), sticky sessions (na podstawie cookie). Eliminacja single point of failure — jeśli jeden backend padnie, proxy kieruje ruch do pozostałych. Więcej o Nginx jako load balancerze w artykule Nginx w hostingu WordPress.
Wiele aplikacji pod jedną domeną
WordPress na /blog, główna aplikacja (React, Shopify, custom) na /, API na /api — reverse proxy kieruje żądania do różnych backendów na podstawie ścieżki URL. Jedna domena, wiele serwerów — bez penalty SEO za subdomeny. Link equity i autorytet domeny skonsolidowane pod jednym adresem.
Ochrona backendu
Backend nie jest eksponowany bezpośrednio do internetu — jego IP jest ukryte za proxy. Proxy filtruje ruch: rate limiting na /wp-login.php, blokowanie botów, nagłówki bezpieczeństwa (HSTS, CSP, X-Frame-Options), walidacja żądań. Atakujący widzi IP proxy, nie backendu — nie może bezpośrednio atakować serwera aplikacyjnego.
Migracje i A/B testing
Proxy kieruje procent ruchu do nowego backendu (canary deployment) — 5% ruchu na nowy serwer, 95% na stary. Migracja WordPress na nowy serwer bez downtime — proxy przełącza ruch po weryfikacji. Blue-green deployment: dwa identyczne backendy, proxy przełącza między nimi w sekundę. Testowanie nowej wersji strony na części użytkowników bez ryzyka.
Reverse proxy i WordPress — konfiguracja i pułapki
WordPress za reverse proxy wymaga specyficznej konfiguracji — bez niej pojawiają się pętle przekierowań, błędne IP w logach i problemy z HTTPS. Poniżej najczęstsze pułapki i ich rozwiązania.
$_SERVER['HTTPS'] na podstawie X-Forwarded-Proto w wp-config.php — pętla przekierowań lub mixed content. Typowy snippet: if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on'; }set_real_ip_from i real_ip_header X-Forwarded-For w Nginx, lub mod_remoteip z RemoteIPHeader X-Forwarded-For w Apache.wordpress_logged_in_*, stron koszyka WooCommerce (/cart/, /checkout/, /my-account/), żądań POST i stron z tokenami CSRF. Bez tej logiki zalogowany administrator może zobaczyć cache strony publicznej — lub odwrotnie.$request_uri). Niespójność trailing slash między proxy a backendem powoduje nieskończone przekierowania 301. W Nginx dyrektywa proxy_pass http://backend (bez slasha) vs proxy_pass http://backend/ (ze slashem) daje diametralnie różne rezultaty — pierwszy przekazuje pełny URI, drugi go modyfikuje.proxy_set_header Host $host; w Nginx — bez tego backend może nie rozpoznać domeny i zwrócić domyślny VirtualHost zamiast właściwej strony WordPress. Kluczowe w konfiguracjach multi-site (WordPress Multisite) i multi-domain, gdzie backend obsługuje wiele domen z jednego serwera.Upgrade i Connection: upgrade w konfiguracji proxy. Bez nich połączenie websocket nie zostanie ustanowione i plugin nie zadziała — przegladarka otrzyma błąd 400 lub połączenie zostanie zamknięte.Nginx jako reverse proxy — typowa konfiguracja
Nginx to najpopularniejszy reverse proxy dla WordPress. Asynchroniczna architektura sprawia, że obsługa tysięcy jednoczesnych połączeń proxy jest lekka i wydajna. Poniżej kluczowe elementy konfiguracji. Więcej o Nginx w artykule Nginx w hostingu WordPress.
proxy_pass http://backend; w połączeniu z nagłówkami: Host, X-Real-IP, X-Forwarded-For, X-Forwarded-Proto. Blok upstream definiuje adres(y) backendu. Dla połączeń z PHP-FPM na tym samym serwerze — unix socket jest szybszy niż TCP.proxy_cache_path definiuje lokalizację i rozmiar cache. proxy_cache_key — klucz cache (zwykle scheme + host + URI). proxy_cache_valid 200 60m; — czas cache dla odpowiedzi 200. proxy_cache_bypass na podstawie cookie WordPress pomija cache dla zalogowanych. Nagłówek X-Cache-Status (HIT/MISS/BYPASS) pomaga w debugowaniu.limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m; — ochrona /wp-login.php i /xmlrpc.php przed brute force na poziomie proxy, zanim żądanie dotrze do PHP. Atakujący jest blokowany przez Nginx bez obciążania backendu — to wielokrotnie wydajniejsze niż blokowanie na poziomie WordPress czy PHP.location ~* \.(css|js|png|jpg|webp|woff2)$ serwowany przez Nginx bezpośrednio z dysku lub cache, bez przekazywania do backendu Apache/PHP-FPM. Nagłówki expires i wyłączone logowanie (access_log off;). Drastyczne odciążenie backendu — pliki statyczne to zwykle ponad 80% żądań.proxy_next_upstream error timeout http_502 http_504; — jeśli backend zwraca błąd, proxy automatycznie próbuje kolejny serwer z bloku upstream. keepalive 32; w bloku upstream minimalizuje overhead nawiązywania nowych połączeń TCP do backendu. Od Nginx 1.30 keepalive do upstream jest włączony domyślnie.Apache jako reverse proxy (mod_proxy)
Apache z modułem mod_proxy to pełnoprawny reverse proxy — mniej popularny w tej roli niż Nginx, ale doskonały w konfiguracjach hybrydowych i środowiskach, gdzie Apache jest już zainstalowany. Więcej o Apache w artykule Apache w hostingu WordPress.
ProxyPass / http://backend/ przekazuje żądania do backendu. ProxyPassReverse przepisuje nagłówki Location w odpowiedziach — bez tego przekierowania z backendu wskazywałyby na wewnętrzny adres zamiast publicznej domeny. Konfiguracja w bloku <VirtualHost>.byrequests (round-robin), bytraffic (po ruchu), bybusyness (do najmniej zajętego). Manager GUI (/balancer-manager) do zarządzania workerami w runtime. Mniej wydajny niż Nginx/HAProxy przy ekstremalnym ruchu, ale wystarczający dla większości konfiguracji WordPress.Kiedy reverse proxy ma sens, a kiedy to overengineering
Reverse proxy nie jest potrzebny każdej stronie WordPress. Oto scenariusze, w których warto go wdrożyć — i sytuacje, gdy dodatkowa warstwa to niepotrzebna złożoność.
/blog + custom app na / + API na /api — reverse proxy to jedyny sposób na jedną domenę bez subdomen. Konsolidacja autorytetu domeny, spójny UX, brak problemów z cookie cross-domain.Podsumowanie
Reverse proxy to fundamentalny element nowoczesnej architektury hostingowej — szczególnie dla stron WordPress o wysokim ruchu, wymaganiach bezpieczeństwa lub złożonej architekturze wieloserwerowej. Terminacja SSL, cache odpowiedzi, load balancing, ochrona backendu i łączenie wielu aplikacji pod jedną domeną to najczęstsze zastosowania. WordPress za reverse proxy wymaga starannej konfiguracji nagłówków (X-Forwarded-Proto, X-Real-IP, Host) i logiki bypass cache dla zalogowanych użytkowników. Nginx i Apache to dwa najpopularniejsze reverse proxy — każdy z własnymi mocnymi stronami.
W WebOptimo projektujemy i wdrażamy konfiguracje reverse proxy pod WordPress i WooCommerce w ramach administracji serwerami i hostingu WordPress. Konfigurujemy Nginx i Apache jako reverse proxy, wdrażamy cache, load balancing i terminację SSL. Jeśli Twoja strona wymaga bardziej zaawansowanej architektury — skontaktuj się z nami lub sprawdź ofertę opieki WordPress.
Najczęstsze pytania o reverse proxy i WordPress
Tak — Cloudflare działa jako globalnie rozproszony reverse proxy. Przyjmuje żądania użytkowników, przetwarza je (cache, WAF, DDoS protection, optymalizacja) i przekazuje do Twojego serwera. Różnica wobec lokalnego reverse proxy: Cloudflare działa w setkach lokalizacji na świecie, co czyni go jednocześnie CDN-em i reverse proxy as a service.
W prawidłowej konfiguracji — nie, wręcz przyspiesza. Cache na poziomie proxy eliminuje konieczność generowania strony przez PHP przy każdym żądaniu. Terminacja SSL na proxy odciąża backend. Dodatkowy hop sieciowy (proxy → backend) dodaje mikrosekundy, co jest pomijalne wobec zysków z cache i odciążenia backendu.
Sprawdź nagłówki odpowiedzi HTTP — nagłówki takie jak X-Cache, X-Cache-Status, Via, X-Served-By, CF-Ray (Cloudflare) lub Server wskazujący inny serwer niż backend to sygnały obecności reverse proxy. Narzędzia: curl -I w terminalu, przeglądarka DevTools (zakładka Network) lub narzędzia online jak SecurityHeaders.com.
Dla małego sklepu — nie jest konieczny. Dla sklepu z dużym ruchem, wieloma backendami lub wymagającego integracji z innymi aplikacjami pod jedną domeną — tak. Reverse proxy z cache znacząco odciąża serwer przy stronach katalogowych i produktowych, jednocześnie pomijając cache dla koszyka, checkout i panelu klienta.
Nie zastępuje — uzupełnia. Reverse proxy działa lokalnie, na tym samym serwerze lub w tej samej sieci co backend. CDN dystrybuuje treści na serwery edge na całym świecie, skracając dystans fizyczny do użytkownika. Optymalna konfiguracja: reverse proxy na serwerze + CDN (np. Cloudflare, Fastly) dla globalnego zasięgu.