Doba čtení: 11 minut
NGINX je primárně webový server a současně univerzální „edge“ proxy: umí fungovat jako reverzní proxy před aplikacemi, jako load balancer, HTTP cache, TLS terminátor a také jako TCP/UDP proxy (stream), případně jako mail proxy. Z hlediska návrhu jde o událostmi řízený (event-driven) server s neblokujícím I/O, navržený pro vysokou konkurenčnost a nízkou paměťovou režii na spojení; historicky cílil na C10k problém (tisíce souběžných spojení).
────────────────────────────────────────
-
Základní funkce a role NGINX v architektuře
────────────────────────────────────────
A) Web server pro statický obsah
NGINX umí velmi efektivně obsluhovat statické soubory (HTML, CSS, JS, obrázky, videa), včetně sendfile/zero-copy optimalizací na úrovni OS, cache hlaviček, range requestů, komprese (gzip, případně brotli přes 3rd-party modul) a řízení expirací. V praxi je to častý důvod, proč je NGINX nasazen „před“ aplikační server: statiku řeší on, aplikace jen dynamiku.
B) Reverzní proxy (HTTP reverse proxy)
To je dnes nejčastější nasazení. NGINX sedí na hraně (edge) a:
-
terminují TLS (HTTPS) a obslouží klienta,
-
rozhodne routování (host, path, hlavičky, cookies, geolokace, A/B, canary),
-
přepošle požadavek na backend (např. PHP-FPM, Node, Python, Go, Java, upstream cluster),
-
umí přidat/odebrat hlavičky, nastavit timeouts, bufferování, retry, healthchecky (částečně OSS, pokročileji v komerčních edicích), a chránit backend.
C) Load balancing (L7 i L4)
Na HTTP vrstvě řeší rozdělení provozu mezi více upstream serverů (round-robin, least_conn, ip_hash apod.), stickiness lze různě řešit (cookie, hash). Pro TCP/UDP (stream) funguje jako L4 balancer/proxy. Tím se z NGINX stává jednoduchý „traffic director“ pro horizontální škálování.
D) HTTP cache a akcelerace
NGINX umí plnohodnotnou cache pro odpovědi z backendu (proxy_cache), včetně cache revalidace, cache locku (ochrana proti thundering herd), key definice a oddělených cache zón. To je často nejrychlejší způsob, jak dramaticky snížit zátěž aplikace bez zásahu do kódu.
E) TLS terminace, bezpečnostní politika, rate limiting
NGINX se často používá jako bezpečnostní a výkonová brána:
-
TLS policy (min verze, cipher suite, HSTS, OCSP stapling),
-
omezení rychlosti (limit_req), omezení počtu spojení (limit_conn),
-
základní autentizace, mTLS, kontrola hlaviček, blokace metod,
-
jednoduché „anti-abuse“ řízení na edge ještě před backendem.
F) TCP/UDP proxy (stream)
Stream modul umožňuje proxyovat např. databáze (PostgreSQL/MySQL), Redis, SSH bastion přístup, MQTT, vlastní protokoly, UDP služby. Výhoda je centralizované řízení přístupu a jednotná observabilita na hraně.
G) Mail proxy
NGINX umí i mail proxy (IMAP/POP3/SMTP) – v běžných moderních webech méně časté, ale existuje jako modulární součást.
────────────────────────────────────────
2) Z čeho se NGINX skládá (procesy, event loop, konfigurace)
────────────────────────────────────────
A) Procesní model: master a workers
Klasický model je „master process“ + více „worker processů“. Master čte konfiguraci, spravuje lifecycle workerů, reaguje na signály (reload, stop) a provádí graceful reload bez pádu spojení (typicky). Workeři obsluhují provoz a běží v event loopu.
B) Event-driven, neblokující I/O
Workeři používají OS notifikace událostí (Linux epoll, BSD/macOS kqueue apod.). Díky tomu jeden worker obslouží mnoho souběžných spojení s malým overheadem, protože nealokuje thread per connection (typický rozdíl proti tradičním modelech).
C) Doplňkové procesy: cache manager/loader
Při zapnutém cache subsystému jsou běžné i cache manager a cache loader (správa cache, expirace, načítání metadat). To je důležité pro stabilní provoz cache bez degradace výkonu.
D) Konfigurační jazyk
NGINX má vlastní deklarativní konfiguraci (nginx.conf a include soubory) založenou na blocích (main, http, server, location, upstream, stream, mail). Klíčové je, že config je vyhodnocen při startu/reloadu; změna konfigurace se typicky aplikuje reloadem, ne „živě“ po jednotlivých directive.
E) Build a modulární architektura
NGINX je modulární. Část modulů je „standard“ v distribuovaných balících, část je volitelná při kompilaci, a část je možné přidat jako dynamický modul (load_module). V praxi je to kompromis: stabilita a výkon vs. potřeba specifických modulů.
────────────────────────────────────────
3) Moduly NGINX: typy a praktická mapa (co budeš reálně potkávat)
────────────────────────────────────────
Neužitečnější není vypsat 200 modulů, ale dát ti „mentální mapu“:
A) Jádro a event moduly
-
Core: základní runtime, memory pooly, logging, signály, start/reload.
-
Event modul pro konkrétní OS mechanismus (epoll/kqueue/…) – interně vybírá vhodnou implementaci.
B) HTTP vrstva (nejčastější)
-
Proxy a aplikační gateway moduly
-
ngx_http_proxy_module: reverzní proxy na HTTP upstreamy (typický backend).
-
ngx_http_fastcgi_module: napojení na PHP-FPM.
-
ngx_http_uwsgi_module, ngx_http_scgi_module: specifické gateway protokoly.
-
ngx_http_grpc_module: proxying gRPC.
-
upstream logika (upstream{}), keepalive do backendu.
-
TLS/SSL a protokolové moduly
-
ngx_http_ssl_module: TLS terminace.
-
HTTP/2, HTTP/3: moderní protokoly (viz níže u „současnost“).
-
Cache/akcelerace
-
proxy_cache (v rámci proxy modulu), cache zones, cache revalidace.
-
gzip/gunzip, ssi, sub_filter (užitečné, ale pozor na CPU a buffering).
-
Routing a transformace
-
rewrite, return, map, geo, try_files, internal redirect.
-
header manipulation: add_header, proxy_set_header, hide_header.
-
access control: allow/deny, auth_basic; auth_request (subrequest autorizace).
-
Limity, ochrana, stabilita
-
limit_req (rate limiting), limit_conn.
-
realip (při proxy chainu), logování proměnných, custom log_format.
-
health endpoints, status (v OSS typicky stub_status; v Plus pokročilejší API).
C) Stream modul (TCP/UDP)
-
ngx_stream_core_module + stream proxy funkce.
-
stream upstreamy, timeouts, load balancing na L4.
-
typicky pro DB, interní služby, VPN gateway, custom protokoly.
D) Mail modul (IMAP/POP3/SMTP proxy)
-
méně běžné, ale existuje jako samostatná „mail“ konfig sekce.
E) NJS (NGINX JavaScript) a rozšiřitelnost
NGINX má modul njs pro skriptování (např. manipulace s requesty, logikou, interní „edge“ skripty). To je cesta, jak dělat složitější logiku bez externího sidecaru; zároveň to zvyšuje složitost a riziko chyb (proto se to v kritických edge konfiguracích dávkuje opatrně). Aktuálně se njs dále vyvíjí a v lednu 2026 vyšla verze njs 0.9.5.
F) 3rd-party moduly
Běžné doplňky mimo upstream:
-
ModSecurity (WAF) integrace,
-
Brotli komprese,
-
RTMP (streamování) – historicky populární, ale ne „core“ webový standard.
Pointa: modulární skladba je výhoda i závazek. Každý extra modul zvyšuje plochu pro chyby, potřebu patchování a testování.
────────────────────────────────────────
4) Využití v praxi: typické topologie a co tím reálně získáš
────────────────────────────────────────
A) NGINX před aplikací (nejčastější)
Klient → NGINX (TLS, statika, cache, limit) → backend (PHP-FPM/Node/…) → DB
Zisky:
-
backend vidí méně provozu (cache, statika),
-
sjednotíš TLS politiku,
-
omezíš „abuse“ dřív, než dopadne na aplikaci,
-
zlepšíš latenci a stabilitu při špičkách.
B) NGINX jako load balancer pro cluster
Klient → NGINX → upstream pool (A,B,C)
Zisky:
-
horizontální škálování,
-
postupné releasy (blue/green, canary),
-
failover (s rozumným healthcheckem / timeouts).
C) NGINX jako L4 gateway
Klient/Service → NGINX stream → interní služba (DB, cache, message broker)
Zisky:
-
centrální audit a řízení přístupu,
-
možnost přidat TLS/mTLS i u interních služeb (dle implementace).
D) NGINX jako cache/accelerator pro obsah
Typicky pro e-commerce, news, katalogy:
-
microcaching (sekundy) dokáže dramaticky snížit špičky bez změn v aplikaci,
-
pozor na správnou cache key a cookie/varianty.
E) Multi-tenant hosting
NGINX je častý základ pro hostingové platformy: mnoho vhostů, centralizovaná pravidla, rozumná izolace přes upstreamy, a výkonově to drží při vysokém počtu domén.
────────────────────────────────────────
5) Historie: proč NGINX vznikl a jak se z něj stal standard
────────────────────────────────────────
-
Vývoj začal cca 2002, první veřejné vydání proběhlo 4. října 2004.
-
NGINX se profiloval jako řešení pro vysokou konkurenčnost a nízký overhead (C10k) a rychle se rozšířil zejména tam, kde tradiční modely web serverů narážely na limity.
-
Firma NGINX, Inc. vznikla 2011 a komerční větev NGINX Plus přidala enterprise funkce a podporu.
-
V březnu 2019 NGINX, Inc. koupila společnost F5, čímž se NGINX stal součástí širšího portfolia „application delivery“ a security.
-
Milník „NGINX 1.0“ byl oznámen v dubnu 2011.
────────────────────────────────────────
6) Současnost (stav k lednu 2026): verze, protokoly, HTTP/3, QUIC, trendy
────────────────────────────────────────
A) Dvě větve: mainline vs stable
NGINX Open Source se vydává ve dvou liniích: mainline (novinky + opravy) a stable (konzervativnější). Je to oficiálně popsaný model distribuce.
B) Aktuální vydání (k 22. 1. 2026)
Podle oficiální stránky ke stažení je k dispozici mainline 1.29.4 a stable 1.28.1.
C) HTTP/3 a QUIC v NGINX
-
V open-source větvi existuje modul ngx_http_v3_module poskytující experimentální podporu HTTP/3 (uvedeno přímo v dokumentaci modulu).
-
QUIC/HTTP/3 má vlastní dokumentační sekci a klade nároky na TLS knihovny; doporučený je OpenSSL 3.5.1+ pro plnohodnotnou podporu některých vlastností (např. early data), alternativně BoringSSL/LibreSSL/QuicTLS.
-
Z praxe to znamená: HTTP/3 v NGINX je reálně použitelné, ale stále vyžaduje pečlivý release management, testování a sledování security advisories. V changelogu stable větví jsou i konkrétní bezpečnostní opravy související s HTTP/3/QUIC.
D) NGINX Plus a HTTP/3
Komerční NGINX Plus uváděl „native“ podporu HTTP/3 a QUIC už v R30 (srpen 2023). To je důležité, protože Plus typicky přináší enterprise „dokončení“ funkcí dřív a s konzervativnějším support cyklem.
Aktuální tabulka release cyklu Plus ukazuje, že Plus vydání pokračují a mají definované období security/tech support.
E) njs a „edge logika“
Vývoj njs pokračuje; na hlavní stránce NGINX jsou uvedeny novinky njs 0.9.5 (leden 2026). To je signál, že NGINX posiluje schopnosti „logiky na hraně“ bez nutnosti externích komponent.
────────────────────────────────────────
7) Budoucí možnosti (realistické směry, ne sliby)
────────────────────────────────────────
Tady je potřeba rozlišit fakta vs. kvalifikovaný odhad. Fakta jsou: NGINX aktivně rozvíjí QUIC/HTTP/3 a njs a pravidelně vydává mainline/stable verze a bezpečnostní fixy.
„Budoucnost“ je ale vždy roadmapa a adopce trhu.
Pravděpodobné směry vývoje (odhad, založený na tom, co NGINX už publikuje a kam trh tlačí):
-
Dozrávání HTTP/3 v open-source větvi
Dokud dokumentace označuje HTTP/3 modul jako experimentální, bude trendem stabilizace, rozšiřování kompatibility TLS knihoven a snižování provozních rizik (bugfix/security cyklus pro QUIC je už vidět). -
Větší důraz na bezpečnost „na hraně“
I bez full WAF v jádře je zřejmé, že edge vrstvy řeší víc: rate limiting, mTLS, ECH/moderní TLS, lepší observabilita. Mainline release notes a novinky (např. ECH u mainline) ukazují, že TLS/protokolová vrstva se posouvá. -
Observabilita a provozní telemetrie
NGINX Plus má bohatší API a metriky; open-source svět dlouhodobě tlačí na standardizaci metrik (Prometheus) a trasování. Z pohledu produktu je očekávatelné další sbližování a lepší integrace standardních metrik/telemetrie (část se děje přes moduly a ekosystém). -
„Programmable“ edge (njs)
S tím, jak roste tlak na rychlou úpravu chování na hraně bez redeploy aplikace, poroste význam skriptovatelnosti (njs), ale současně i tlak na bezpečné guardrails (testování, linting, omezení scope). -
Lepší integrace s moderními deployment modely
NGINX je dlouhodobě všude (bare-metal, VM, kontejnery, Kubernetes ingress). Budoucí vývoj bude pragmatický: lepší ergonomie konfigurace, bezpečnější defaulty, jednodušší správa certifikátů a standardní integrační body (logy, metriky, service discovery). (Toto je odhad; konkrétní funkcionality se liší mezi OSS/Plus a dalšími produkty kolem NGINX.)
────────────────────────────────────────
8) …. „proč to používám“
────────────────────────────────────────
NGINX je efektivní, modulární a provozně osvědčená edge vrstva, která ti umožní oddělit transport (TLS/protokoly), routing a ochranu od aplikace, zrychlit doručování (statika/cache), stabilizovat špičky (limity/microcache) a škálovat (upstream/load balancing), přičemž moderní protokoly jako HTTP/3/QUIC jsou už dostupné, ale v OSS části stále s prvky „experimentálního“ režimu vyžadujícího pečlivé nasazení.
T.H.
