Reverse proxy (odwrotne proxy) to serwer, który stoi z przodu — przed Twoimi serwerami aplikacji — i udaje, że to on jest właściwą aplikacją. Klient (przeglądarka, aplikacja mobilna) łączy się z reverse proxy, a ten przyjmuje żądanie i przekazuje je dalej do jednego z serwerów backendowych. Odpowiedź wraca tą samą drogą. Z punktu widzenia klienta istnieje jeden serwer, choć za kulisami może ich być pięćdziesiąt. To kluczowa różnica względem zwykłego (forward) proxy: tamten działa po stronie klienta i ukrywa jego, reverse proxy działa po stronie serwera i ukrywa infrastrukturę.
Do czego to służy
Reverse proxy to scyzoryk szwajcarski wejścia do systemu. Najczęstsze zadania to load balancing (rozkładanie ruchu na wiele backendów, żeby żaden się nie udławił), terminacja TLS/SSL (proxy obsługuje cały HTTPS, a backend gada zwykłym HTTP po stronie wewnętrznej), cache’owanie odpowiedzi (statyka i powtarzalne zapytania nie męczą aplikacji) oraz kompresja gzip/brotli.
Dochodzi do tego warstwa bezpieczeństwa: proxy ukrywa adresy IP i topologię backendu, może filtrować ruch (WAF), ograniczać liczbę żądań (rate limiting) i zatrzymywać prostsze ataki, zanim dotrą do aplikacji. Bywa też pojedynczym punktem, w którym wpinasz logowanie, metryki i nagłówki bezpieczeństwa — zamiast pilnować tego w każdym serwisie z osobna.
Przykład z praktyki
Najpopularniejsze narzędzia to Nginx, HAProxy, Caddy i Traefik (ten ostatni lubiany w świecie kontenerów). Minimalny reverse proxy w Nginx wygląda tak:
location / { proxy_pass http://127.0.0.1:3000; }— przekazuje ruch do aplikacji nasłuchującej lokalnie na porcie 3000 (np. Node czy Pythona).proxy_set_header X-Forwarded-For $remote_addr;— przekazuje prawdziwe IP klienta dalej, bo bez tego backend zobaczy tylko adres proxy.
Typowy układ: Nginx słucha na 443, kończy TLS, a za nim siedzą trzy instancje aplikacji, między które rozkłada ruch.
Na co uważać
Najczęstszy błąd początkujących to zgubione IP klienta — aplikacja loguje adres proxy zamiast użytkownika. Trzeba przekazać X-Forwarded-For i X-Forwarded-Proto, a w aplikacji ufać tym nagłówkom (np. trust proxy w Express). Drugi klasyk to 502 Bad Gateway, gdy backend nie odpowiada albo proxy puka pod zły port. I pamiętaj: reverse proxy łatwo zamienia się w single point of failure — jeśli pada, pada cała brama. W produkcji stawia się go więc redundantnie.
Pojęcia powiązane: forward proxy, load balancer, terminacja TLS/SSL, API gateway, CDN, WAF, upstream, Nginx, HAProxy.