Slovník pojmů
nginx
nginx přijímá webový provoz, rozhoduje, kam jej předat, a může obsloužit část odpovědi sám. Správná konfigurace musí zachovat bezpečnostní i aplikační kontext požadavku.
Stručná definice
Webový server a proxy před aplikací, ne její náhrada.
nginx může přímo vracet obrázky, JavaScript, CSS a další statické soubory. Pro dynamickou část aplikace obvykle funguje jako reverse proxy: přijme HTTP požadavek od prohlížeče či klienta API a předá jej vybranému upstreamu, například PHP-FPM, Symfony API nebo Node.js službě.
nginx sám nespouští PHP kód. Pro PHP se používá FastCGI propojení s PHP-FPM; pro HTTP aplikaci se používá proxy_pass. Rozlišení je důležité pro konfiguraci cest, hlaviček, timeoutů i zabezpečení. Proxy určuje síťovou hranici, nikoli pravidla objednávky, oprávnění nebo doménovou logiku.
Použití
Kde nginx vytváří užitečnou HTTP hranici
Nejčastěji stojí mezi veřejným internetem a aplikací, aby na jednom místě řešil technické vlastnosti HTTP provozu.
- HTTPS certifikát a přesměrování z HTTP na HTTPS před PHP aplikací nebo API
- doručení veřejných statických souborů bez zatěžování aplikačního runtime
- směrování různých domén a cest na web, administraci nebo samostatné API
- předání požadavku do interní Docker sítě, aniž by byly publikované porty aplikace a databáze
- nastavení velikosti request body, timeoutů, hlaviček, logů, cache nebo základního rate limitingu
Praktický příklad
Veřejné API před PHP aplikací v Docker síti
API na api.example.cz přijímá HTTPS přes nginx. nginx doručuje případné veřejné soubory a všechny API požadavky posílá na službu app v interní síti. PostgreSQL ani Redis nemají zveřejněný port; přistupuje k nim pouze aplikace nebo určený worker.
Při importu objednávek je dlouhá práce spuštěná workerem, nikoli držená v jednom HTTP požadavku nginxu. Proxy má konzervativní timeouty pro běžné API a její log ukáže, zda požadavek odmítl limit, nebo zda odpověď nestihl vrátit samotný upstream.
upstream app_backend {
server app:8080;
}
server {
listen 443 ssl;
server_name api.example.cz;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://app_backend;
}
}
Jak funguje
Od veřejné adresy k odpovědi aplikace
Konfigurace vybírá virtuální server a location blok. Ten buď odpoví přímo, nebo zvolí interní službu, které požadavek předá.
- Příjem spojení nginx poslouchá na HTTP nebo HTTPS portu. U HTTPS použije serverový certifikát a může zde ukončit šifrované spojení; jeho platnost ověřuje klient.
- Server a location Podle jména hostitele a URI se vybere server blok a vhodný location. Pravidla mají být jednoznačná, zejména u prefixů, regulárních výrazů a přesměrování.
- Statický soubor nebo upstream Statický soubor nginx vrátí sám. Dynamický požadavek předá přes FastCGI nebo reverse proxy aplikačnímu procesu či skupině upstream serverů.
- Hlavičky a ochranné limity Proxy předává potřebný Host a informace o původním schématu či klientovi. Zároveň může odmítnout příliš velké tělo požadavku nebo omezit tempo opakovaných požadavků.
- Odpověď a observabilita Odpověď se vrací přes nginx klientovi. Access a error logy mají umožnit odlišit chybu proxy, aplikace i pomalého upstreamu.
Hlavní části
Konfigurace popisuje HTTP provoz a jeho hranice
Pojmy server, location a upstream popisují jinou úroveň než controller nebo databázový dotaz v aplikaci.
http, server a location
V kontextu http vznikají společná pravidla, server reprezentuje virtuální host a location určuje chování pro vybranou cestu. Příliš obecné pravidlo může omylem zachytit jinou URL.
Reverse proxy a upstream
proxy_pass předává HTTP požadavky jinému HTTP serveru. Upstream může seskupit více backendů pro rozložení zátěže, ale vyžaduje jasná pravidla pro health check a chování při chybě.
FastCGI pro PHP
PHP-FPM přijímá FastCGI požadavky, proto se nepoužívá jako běžné HTTP API. Konfigurace musí správně určit skript a nesmí umožnit spuštění nechtěných souborů z upload adresáře.
TLS a předané hlavičky
Aplikace za proxy potřebuje vědět, zda původní požadavek přišel přes HTTPS. Hlavičky X-Forwarded-* lze důvěřovat jen od vlastní, známé proxy; od klienta je lze podvrhnout.
Cache, buffering a limity
Proxy cache šetří upstream jen pro bezpečně zvolený sdílený obsah. Buffering, timeouty a limit_req ovlivňují odolnost provozu, ale nemají měnit význam business operace.
Vztah k ostatním nástrojům
nginx propojuje HTTP vrstvu s aplikací a provozem.
Často stojí před kontejnerem nebo PHP runtime, ale odpovědnost za aplikaci a data zůstává na dalších vrstvách.
- Docker
- nginx může být jedinou veřejně dostupnou službou v Docker síti a posílat požadavky interním jménem aplikace.
- Symfony
- Framework obslouží routu, validaci a business logiku; nginx zajistí, že se HTTP požadavek dostane do správného runtime.
- REST API
- Proxy může směrovat a omezovat provoz, ale návrh zdrojů, autentizace a chybových odpovědí patří do API.
- Rate limiting
- nginx umí technicky omezovat příchod požadavků. Sdílený limit mezi více instancemi nebo pravidlo podle uživatele ale vyžaduje promyšlenější návrh.
Výhody a omezení
Jedna HTTP hranice zjednoduší provoz, ale vyžaduje přesnou konfiguraci.
Přínosy
- centralizované HTTPS, směrování domén a základní HTTP politika
- rychlé doručení statických souborů bez PHP runtime
- skrytí interních portů a možnost směrovat více aplikací za jeden veřejný vstup
- jednotné access a error logy na rozhraní mezi klientem a aplikací
Na co pozor
- kombinace location a proxy_pass může při chybném lomítku změnit předávanou cestu
- důvěra ve vstupní X-Forwarded-* hlavičky umožní podvrhnout schéma či adresu klienta
- nevhodné timeouty, velikost těla nebo retry mohou poškodit dlouhý import či zápisovou operaci
- cache nesmí sdílet personalizovanou nebo stav měnící odpověď mezi uživateli
- rate limiting nenahrazuje autentizaci, autorizaci ani ochranu aplikace před všemi útoky
Hranice použití
Pro HTTP provoz, ne pro logiku aplikace.
nginx dává smysl, když PHP aplikace nebo API potřebuje veřejné HTTPS, více domén, statické soubory, oddělený aplikační runtime nebo jednotný vstup do Docker prostředí. Umožní držet databázi i interní workery mimo veřejnou síť a přitom obsloužit několik aplikací z jednoho místa.
Malá aplikace za spravovanou platformou už může mít proxy vyřešenou poskytovatelem a vlastní rozsáhlá konfigurace by jen přidala další místo pro chybu. Do nginx se také nemají přesouvat složité obchodní podmínky, volání externích API ani dlouhé importy; ty patří do aplikační služby nebo workeru.
Na co myslet
Provozní pravidla mají být konkrétní, měřitelná a minimální.
Dobrá konfigurace nejdříve omezuje veřejnou plochu a teprve potom přidává cache, limity nebo složitější směrování.
- pro každou doménu určit jasný server_name, TLS konfiguraci a očekávané přesměrování
- veřejně zpřístupnit jen statické adresáře určené pro klienta, ne celý projektový strom
- předávat aplikaci nutné hlavičky a důvěřovat forwardovaným hlavičkám jen z vlastního proxy řetězce
- nastavit timeouty, limity těla a buffering podle typu endpointu a reálných provozních dat
- cacheovat pouze odpovědi, u nichž je bezpečné sdílení a invalidace
- monitorovat stavové kódy, dobu odpovědi upstreamu a chyby odděleně od aplikačních logů
Časté otázky
Co nginx dělá mezi klientem a aplikací
Je nginx aplikační framework?
Není. Je to webový server a proxy pro HTTP provoz. Routy aplikace, validace vstupu a obchodní pravidla zůstávají v aplikačním kódu.
Potřebuje každá aplikace vlastní nginx?
Ne nutně. Spravovaná platforma, load balancer nebo jiná proxy může tuto roli zajišťovat už před aplikací. Záleží na tom, kdo odpovídá za HTTP a TLS hranici.
Může aplikace bez obav věřit X-Forwarded-For?
Jen pokud webový server odstraní klientem dodanou hodnotu a nastaví ji sám, případně pokud aplikace důvěřuje pouze známým IP adresám vlastních proxy.
Řeší nginx rate limiting bezpečnost aplikace?
Pomáhá snížit tempo provozu na HTTP hranici, ale nenahrazuje autentizaci, autorizaci, validaci vstupu ani ochranu proti chybám v aplikační logice.
Jak navrhuji běh aplikace
Veřejný HTTP vstup odděluji od aplikace a jejích interních služeb.
U backendů řeším spolupráci aplikace, databáze, cache, workerů a integračních služeb tak, aby byla síťová hranice srozumitelná a provoz šel dohledat.