Jan Mikoláš
Slovník pojmů
Reverse proxy
Reverse proxy je veřejná HTTP hranice před aplikací. Směruje provoz a předává technický kontext, ale nemá rozhodovat o oprávnění uživatele ani pravidlech objednávky.
Stručná definice
Server chránící a zpřístupňující backend, nikoli klienta.
Reverse proxy stojí mezi klientem a jednou nebo více backendovými službami. Klient komunikuje s veřejnou adresou proxy, která podle domény, cesty nebo pravidla vybere aplikaci, odešle jí požadavek a odpověď vrátí zpět. Backend tak nemusí mít vlastní veřejný port ani řešit každé TLS spojení přímo.
Název je důležitý: forward proxy zastupuje klienta při přístupu ven, zatímco reverse proxy zastupuje nebo chrání serverovou stranu. nginx, Traefik, Apache HTTP Server, cloudový load balancer nebo API gateway mohou tuto roli plnit různě široce. Konkrétní nástroj není podstatou principu.
K čemu se používá
Jedna kontrolovaná cesta k několika interním službám
Proxy soustředí technická HTTP rozhodnutí na místo před aplikačním runtime.
- HTTPS a přesměrování z HTTP pro web, administraci i API
- směrování app.example.cz, api.example.cz a administrace na různé služby
- skrytí portů PHP aplikace, Node.js služby, databáze a workeru ve vnitřní síti
- doručení statických souborů, základní cache a omezení velikosti požadavku
- předání důvěryhodné informace o původním hostiteli, schématu a klientské adrese
Praktický příklad
Web a API jako interní služby
E-shop má veřejný web a samostatné API. Reverse proxy přijme HTTPS na obou doménách a podle hostitele předá požadavek do odpovídající Docker služby. PostgreSQL, Redis a worker nemají veřejný port; na síti je dosáhne jen aplikace, která je potřebuje.
Příkladem je záměrně jednoduché nginx pravidlo. Zobrazuje hranici, ne úplnou produkční konfiguraci certifikátů, health checků a důvěryhodných IP adres předřazeného load balanceru.
server {
listen 443 ssl;
server_name api.example.cz;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://api:8080;
}
}Jak funguje
Cesta požadavku od internetu k backendu
Proxy překládá veřejný HTTP vstup do záměrně omezené cesty ke službě uvnitř infrastruktury.
- Klient se připojí Prohlížeč nebo API klient odešle požadavek na veřejnou doménu. Proxy přijímá spojení a u HTTPS provede TLS vrstvu.
- Výběr pravidla Podle hostitele, cesty, metody nebo jiné bezpečně definované podmínky vybere cílový backend či statickou odpověď.
- Předání kontextu Proxy nastaví potřebné hlavičky, například Host a X-Forwarded-Proto. Forwardované údaje od klienta nesmí backend považovat za důvěryhodné bez známého proxy řetězce.
- Komunikace s upstreamem Interní HTTP nebo FastCGI spojení dostane aplikace. Proxy sleduje timeouty, chyby a podle konfigurace může vybrat jinou zdravou instanci.
- Odpověď a logy Proxy vrátí odpověď, případně ji bufferuje nebo cacheuje. Access a error logy dávají společný pohled na hraniční provoz.
Hlavní části a pojmy
Proxy chrání síťovou a HTTP hranici.
Co přijde před aplikaci, musí mít přesně definovaný důvod a vztah k aplikaci.
Routing a upstream
Routing vybere službu; upstream je cílový server nebo skupina instancí. Přesměrování URL a load balancing mění provozní cestu, ne význam aplikačního příkazu.
TLS termination
Proxy může držet serverový certifikát a ukončit TLS na okraji infrastruktury. Spojení k backendu může být v důvěryhodné interní síti nebo opět šifrované podle modelu rizik.
Forwarded hlavičky
Aplikace za proxy potřebuje rozpoznat původní HTTPS nebo klientskou adresu. X-Forwarded-* či standardní Forwarded hlavičky mají význam jen z proxy, které aplikace zná a kterým důvěřuje.
Timeout, buffering a retry
Časový limit má odpovídat endpointu. Automatický retry zápisového HTTP požadavku může vytvořit duplicitní operaci, pokud API nemá idempotentní význam.
Cache a limity
Cache je vhodná jen pro bezpečně sdílitelný obsah s promyšlenou invalidací. Rate limit chrání kapacitu, ale nenahrazuje autentizaci, autorizaci ani validaci.
Vztah k ostatním nástrojům
Proxy je infrastruktura, aplikace zůstává aplikací.
Příbuzné technologie řeší jinou vrstvu téhož requestu.
- nginx
- Webový server a běžná implementace reverse proxy pro HTTP, FastCGI, statické soubory a limity.
- Docker
- Kontejnery dovolují držet backendy ve vnitřní síti; reverse proxy může být jediný veřejný kontejner.
- HTTPS a TLS
- TLS chrání spojení klienta s proxy. HTTPS nevypovídá samo o oprávnění k API operaci.
- REST API
- Proxy rozpozná cestu a předá request, ale API musí samo řešit zdroje, vstup, autorizaci a odpovědi.
Výhody a omezení
Centrální HTTP hranice usnadní provoz, ale přidá další vrstvu.
Přínosy
- jedno místo pro domény, HTTPS a část HTTP politiky
- backendové porty a databáze nejsou přímo vystavené internetu
- možnost směrovat více aplikací a sbírat jednotné provozní logy
- oddělení statického obsahu a aplikačního runtime
Omezení a časté chyby
- slepá důvěra v hlavičky poslané přímo klientem
- chybná cesta v proxy pravidle změní URI předané aplikaci
- příliš dlouhé timeouty nebo retry u zápisových endpointů
- cache personalizované odpovědi bez kontroly cookies a autorizace
- přesun business logiky a autorizace do konfigurace proxy
Kdy dává smysl
Když je potřeba řídit veřejný HTTP vstup nezávisle na runtime.
Reverse proxy je přirozená pro více domén, oddělené API a frontend, Docker prostředí nebo aplikaci s vlastním PHP-FPM či workery. Poskytuje jednotné místo pro TLS, přesměrování a přístup k interním službám, aniž by se musely otevírat jejich porty navenek.
Malý web na spravované platformě už může tuto vrstvu dostávat jako součást služby; vlastní konfigurace pak nemusí přinést hodnotu. I ve větší infrastruktuře má proxy zůstat přiměřená. Složitá pravidla pro objednávky, role nebo synchronizaci stavu patří do verzovaného a testovaného aplikačního kódu.
Na co myslet
Veřejná hranice má být minimální a dohledatelná.
Konfigurace se testuje spolu s aplikací, ne jen jako izolovaný soubor.
- publikovat jen potřebné porty a backendy držet v interní síti
- nastavit jasná pravidla hostitele, cesty, HTTPS a očekávaného přesměrování
- přepisovat nebo důvěřovat forwardovaným hlavičkám jen v kontrolovaném proxy řetězci
- volit timeouty a retry podle toho, zda endpoint čte nebo mění stav
- monitorovat stavové kódy, čas upstreamu, chyby TLS i odmítnuté požadavky
Časté otázky
Reverse proxy bez záměny odpovědností
Je reverse proxy totéž co load balancer?
Load balancing může být jedna funkce reverse proxy, když vybírá z více backendů. Reverse proxy ale může fungovat i před jedinou aplikací a řešit TLS, routing nebo statické soubory.
Může backend věřit X-Forwarded-For?
Jen pokud request přišel přes známý proxy řetězec, který klientem dodanou hodnotu bezpečně nahradí nebo správně zpracuje. Přímý klient může takovou hlavičku podvrhnout.
Nahradí HTTPS autentizaci uživatele?
Ne. TLS ověřuje obvykle server a chrání přenos. Aplikace musí dál ověřit relaci nebo token a vyhodnotit oprávnění k operaci.
Může proxy bezpečně opakovat požadavek po timeoutu?
Jen pokud je konkrétní operace bezpečně idempotentní a retry má jasně navržený význam. U zápisu by jinak mohl vzniknout duplicitní stav.
Jak navrhuji provoz aplikace
Veřejný vstup odděluji od interních služeb a dat.
U backendů řeším společně HTTP hranici, API, databázi, cache a workery tak, aby síťové odpovědnosti zůstaly čitelné.