Jak krok za krokem nastavit reverzní proxy server s Nginx

Nastavení reverzní proxy s Nginx se stalo téměř povinným, pokud chcete, aby vaše webové aplikace byly bezpečnější, škálovatelnější a snadněji spravovatelné . Nepotřebujete k tomu masivní infrastrukturu: i s jednou nebo dvěma službami si všimnete rozdílu ve výkonu a organizaci.

V této příručce si ukážeme, jak Nginx funguje jako prostředník mezi klienty a vašimi aplikacemi, jak se integruje s Apache, .NET, Docker a kontejnerovými službami, které konfigurační direktivy jsou skutečně důležité a jak doladit vše na moderních linuxových serverech , jako je Ubuntu , včetně HTTPS, vyvažování zátěže, ukládání do mezipaměti a některých optimalizací zabezpečení.

Co je reverzní proxy Nginx a jakou roli hraje ve vaší architektuře?

Když mluvíme o Nginxu, mnoho lidí si představí pouze webový server pro obsluhu statických stránek, ale po léta byl jedním z jeho klíčových využití vysoce výkonný reverzní proxy server . V této roli se nachází před jedním nebo více backendovými servery (Apache, .NET aplikace, Docker kontejnery, Gunicorn pro Python , Node.js atd.) a Nginx je ten, kdo přijímá všechny požadavky klientů.

Místo přímého připojení prohlížeče k vaší aplikaci se toto připojení vždy navazuje na Nginx. Odtud Nginx sám rozhoduje, jak s každým požadavkem naloží: zda může obsah poskytnout sám (například statické soubory), nebo zda jej má odeslat ke zpracování na konkrétní backend a poté vrátit odpověď klientovi.

Tato střední vrstva nabízí jasné výhody: skrývá skutečné IP adresy interních serverů, centralizuje používání TLS certifikátů, aplikuje bezpečnostní pravidla na jednom místě a výrazně zjednodušuje nasazení nových aplikací. Nginx navíc dokáže zpracovat tisíce souběžných připojení s velmi nízkou spotřebou zdrojů , což je ideální pro scénáře s vysokým provozem.

Ve složitějších prostředích se Nginx používá také jako vyvažovač zátěže a brána k architekturám Kubernetes, jako ingress controller nebo jako API brána, kde se stará o směrování požadavků do mikroslužeb a vynucuje zásady, jako je ukládání do mezipaměti, limity rychlosti nebo ověřování.

Jak Nginx zpracovává požadavky jako reverzní proxy

Když klient odešle HTTP nebo HTTPS požadavek na vaši doménu, tento požadavek se nejprve dostane na server, na kterém běží Nginx. Od tohoto okamžiku je základní postup následující: Nginx analyzuje URL, hlavičky, metodu a hostitele.najít blok server a blok location který nejlépe odpovídá a rozhodne, co s požadavkem udělat.

Pokud je požadovaný zdroj statický (obrázky, CSS, JS, soubory ke stažení atd.), Nginx jej obvykle načítá přímo ze souborového systému nebo dokonce ze své interní mezipaměti, což výrazně zkracuje dobu odezvy a zabraňuje backendům v plýtvání časem obsahem, který nepotřebují zpracovávat.

Pokud však požadavek vyžaduje obchodní logiku (například stránku generovanou WordPressem, .NET Core API nebo aplikaci Jenkins), Nginx tento požadavek přepošle na jeden z backendových serverů nakonfigurovaných pomocí direktivy. proxy_passČeká na odpověď a vrací ji klientovi, jako by přišla přímo z Nginxu.

Toto přesměrování není náhodné: Nginx dokáže použít několik algoritmů pro vyvažování zátěže. Nejjednodušší je round-robin , který rozděluje požadavky v pořadí mezi všechny uzly. Můžete také použít least_conn (který odešle požadavek na backend s nejmenším počtem aktivních připojení) nebo ip_hash , který udržuje každého klienta připojeného ke stejnému serveru, aby se udržovaly relace, aniž by je bylo nutné sdílet mezi instancemi.

V pokročilých prostředích můžete věci ještě dále doladit pomocí map, proměnných a dalších modulů: můžete se rozhodovat na základě záhlaví, typu obsahu, tras, domén nebo dokonce vlastního kódu, který rozšiřuje logiku směrování . Aspekt reverzní proxy se v konečném důsledku neomezuje pouze na „přeposílání provozu“, ale spíše zahrnuje inteligentní řízení toho, jak požadavky cestují v rámci vaší infrastruktury.

Předpoklady před připojením Nginxu jako reverzní proxy

Než začnete s úpravami konfigurací, je dobré se ujistit, že splňujete určité základní požadavky, abyste se vyhnuli problémům. Minimálně potřebujete server s root nebo sudo přístupem (obvykle VPS nebo cloudový server), kde si můžete nainstalovat Nginx a spravovat jeho služby.

Je také důležité mít jedna nebo více domén odkazujících na veřejnou IP adresu ze serveru Nginx. Je možné pracovat pouze s IP adresou, ale pro reálná prostředí a za účelem SEOPro certifikáty TLS a prohlížení je běžné používat názvy domén a subdomény: například example.com, jenkins.example.com, api.example.com, Etc.

Kromě toho musíte mít již v provozu back-endové servery, které budou za proxy: může to být Apache, aplikace ASP.NET Core na portu 5000, Dockerizované služby, WordPress na jiném serveru nebo cokoli jiného, ​​co naslouchá na HTTP/HTTPS a zpracovává požadavky.

Na úrovni sítě se ujistěte, že systémový firewall povoluje příchozí provoz na portech 80 (HTTP) a 443 (HTTPS) . V Ubuntu s UFW stačí pouhé povolení profilu „Nginx Full“ k otevření obou portů bez nutnosti ručního definování pravidel.

Nakonec je užitečné mít základní znalosti syntaxe Nginx a pokud budete zobrazovat šifrovaný obsah, mít platné certifikáty TLS (například od Let's Encrypt) pro domény, které budete používat, abyste mohli ukončit HTTPS připojení v Nginx a chránit provoz od klienta.

Instalace Nginxu a základní konfigurační struktura

Na distribucích jako Ubuntu je instalace Nginx prakticky otázkou několika příkazů . Obvyklý postup je nejprve aktualizovat systémové balíčky a poté nainstalovat webový server pomocí správce balíčků, takže získáte stabilní verzi, která je dobře integrována se systemd.

Po instalaci Nginx spustí démona, který je spravován pomocí systemctlMůžete zkontrolovat jeho stav, spustit ho, zastavit ho, restartovat ho nebo povolit jeho spuštění se systémem. Tento servisní model umožňuje, aby se Nginx i backendové aplikace chovaly jako procesy na pozadí, které se spouštějí automaticky po restartu stroje.

Hlavní konfigurace se nachází v /etc/nginx/nginx.confAle v praxi se tento soubor téměř nikdy moc nemění. Obsahuje další klíčové soubory a adresáře, jako například /etc/nginx/conf.d/ a binom /etc/nginx/sites-available / /etc/nginx/sites-enabled, kde jsou uloženy definice virtuálních webů.

Typickou filozofií je vytvořit konfigurační soubor pro každou doménu nebo službu v sites-available a poté jej povolte symbolickým odkazem v sites-enabledTo vám umožňuje snadno aktivovat nebo deaktivovat weby bez nutnosti mazat jejich soubory a Udržujte konfiguraci organizovanou i na serverech s mnoha různými službami..

V rámci těchto souborů vynikají dva základní bloky. Blok server, který definuje každý virtuální server (doménu, port, certifikáty, protokoly) a bloky location, které řídí, jak zacházet se specifickými trasami: obsluha statických serverů, proxying, přesměrování, ukládání do mezipaměti atd.

Konfigurace Nginxu jako jednoduchého reverzního proxy serveru

Pro začátek se základy jednoduše definujte blok server který naslouchá na portu 80 pro vaši doménu a uvnitř blok location který posílá veškerý provoz do příslušného backendu. V praxi to dělá z Nginxu jeden vstupní bod do vaší aplikace.

Jádro konfigurace proxy se opírá o direktivu proxy_passToto označuje interní URL adresu backendového serveru. Může ukazovat na IP adresu a port, interní doménu nebo blok. upstream která seskupuje několik serverů v závislosti na složitosti vaší architektury.

Spolu s proxy_pass Je klíčové pracovat s proxy_set_header zachovat relevantní informace z původního požadavku: požadovaný hostitel, skutečná IP adresa klienta nebo schéma (HTTP/HTTPS). Tyto hlavičky (Host, X-Real-IP, X-Forwarded-For, X-Forwarded-Protoatd.) povolit backend Správně zaznamenávat provoz, generovat konzistentní absolutní URL a může aplikovat logiku na základě původu zákazníka.

Dále je v téměř jakémkoli seriózním prostředí vhodné spravovat časové limity proxy pomocí direktiv, jako například proxy_connect_timeout, proxy_send_timeout y proxy_read_timeoutJejich úprava pomáhá zabránit pádům serveru způsobeným pomalým připojením nebo dlouhými procesy, zejména při náročných operacích nebo příkazech na pozadí, které trvají dlouhou dobu odezvy.

Vyvažování zátěže a správa více backendů

Když vaše aplikace začne růst nebo máte vysoké požadavky na dostupnost, Nginx může fungovat jako vyrovnávač zátěže před více backendyK tomu je definován blok. upstream kde jsou uvedeny servery, které budou součástí cílového poolu.

V rámci daného bloku upstream Můžete přidat další direktivy: váhy pro upřednostnění určitých uzlů, algoritmy distribuce požadavkůParametry keepalive pro udržování trvalého připojení atd. Cílem je efektivně distribuovat příchozí provoz, aniž by se jeden server stal úzkým hrdlem.

Jakmile je skupina definována, proxy_pass bloku server Odkazuje na název nadřazeného serveru, nikoli na konkrétní IP adresu. Odtud je každý příchozí požadavek odeslán na jeden z backendů podle zvolené strategie vyvažování zátěže, takže Přidání nebo odebrání jednoho z těchto uzlů zahrnuje pouze úpravu upstreamového bloku., aniž byste se dotkli ostatních nastavení.

Stejný přístup se bezproblémově integruje s prostředími Docker nebo Swarm, kde každá služba zpřístupňuje interní port a Nginx je spravuje externě. Je také běžné seskupovat aplikace jako Jenkins, GitLab, SonarQube nebo Nexus, každou ve vlastním kontejneru, a nechat Nginx centralizovat veškerý externí přístup z jednoho bodu.

Pokud je vaše infrastruktura distribuována na více počítačích, proxy tohoto typu umožňuje izolovat služby v různých instancích s vyhrazenými zdroji a zároveň nabízet okolnímu světu jednu doménu nebo sadu dobře organizovaných domén .

Správa statického obsahu, ukládání do mezipaměti a výkon

Jednou z největších silných stránek Nginxu ve srovnání s jinými servery je jeho efektivita při poskytování statického obsahu. Efektivní využití této vlastnosti v scénáři reverzní proxy zahrnuje definování bloques location specifické pro statické trasyaby nebyly odesílány do backendu, pokud to není nezbytně nutné.

V těchto blocích můžete zadat cestu k lokálnímu adresáři, kam ukládáte soubory, přidat hlavičky s dlouhou dobou platnosti a povolit mechanismy komprese a ukládání do mezipaměti. To umožňuje prohlížeči uživatele uchovávat zdroje déle a zabraňuje tomu, aby Nginx musel cokoli přepočítávat pokaždé, když jsou vyžádány soubory, které se téměř nemění.

Nginx navíc umožňuje pokročilejší systém ukládání do mezipaměti přímo v proxy serveru pomocí direktiv, jako například proxy_cache y proxy_cache_pathMůžete definovat zónu mezipaměti disku s maximální velikostí, dobou nečinnosti a úrovněmi adresářů pro ukládání odpovědí a poté tuto mezipaměť aktivovat v blocích proxy pro vaše backendy.

V kombinaci s dynamickými backendy (například WordPress nebo aplikace v PHP, .NET nebo Pythonu) je výsledkem to, že nejčastější odpovědi jsou zobrazovány z mezipaměti Nginx, aniž by je backend musel přepočítávat . To se promítá do menšího zatížení CPU a paměti, rychlejší doby odezvy a větší kapacity pro zvládání špičkových provozních dat.

Pokud váš projekt obsahuje mnoho opakujících se zdrojů, jako jsou úryvky HTML, které se zobrazují na různých stránkách, můžete se také spolehnout na externí nástroje, jako je Varnish, nebo použití ESI (Edge Side Includes) v kombinaci s reverzními proxy, které dále urychlí doručování modulárního obsahu.

Zabezpečení: Ukončení TLS, firewally a hlavičky

Jedním z hlavních důvodů pro umístění reverzní proxy před vaše servery je posílení bezpečnosti. Směrováním všech externích připojení přes Nginx můžete centralizovat zásady šifrování, filtrování a ochrany, aniž byste je museli replikovat na každém jednotlivém backendu.

Jasným příkladem je ukončení TLS: certifikáty a klíče jsou nainstalovány na Nginxu a nakonfigurovány pro příjem HTTPS provozu na portu 443. Interně můžete s backendy komunikovat čistě pomocí HTTP, pokud chcete, což zjednodušuje jejich konfiguraci. Externě však uživatel vidí zabezpečené, šifrované připojení s podporou moderních protokolů, jako je TLS 1.3 a aktualizovaných šifrovacích sad.

Přesunutí šifrování na proxy snižuje zátěž vašich aplikací, které již nemusí při každém připojení vyjednávat certifikáty ani šifrovací algoritmy. Pokud zpracováváte velmi vysoké objemy provozu a chcete dále zlepšit výkon, můžete dokonce začlenit moduly nebo hardware optimalizované pro SSL/TLS.

Kromě šifrování je běžné definovat bezpečnostní opěrky hlavy v globální konfiguraci nebo v konkrétních blocích: omezení Content-Security-PolicyOchrana XSS, blokování sniffingu typů MIME, kontrola HSTSpravidla X-Frame-OptionsMimo jiné. To vše posiluje zabezpečení vaší aplikace, aniž by bylo nutné upravovat zdrojový kód.

Pokud k této vrstvě přidáte dobře nakonfigurovaný firewall (například UFW na Ubuntu) a ochranné systémy proti DDoS útokům, jako je omezení požadavků na IP adresu nebo integrace s externími službami, získáte poměrně solidní bariéru, která filtruje běžné útoky dříve, než se dostanou k vašim aplikačním serverům.

Integrace s Dockerem, Gunicornem a dalšími aplikačními servery

V mnoha současných scénářích aplikace neběží přímo na hostitelském systému, ale uvnitř kontejnerů nebo za dedikovanými servery. Nginx se do tohoto přístupu obzvláště dobře hodí, protože neběží uvnitř kontejneru, ale jednoduše komunikuje přes HTTP pomocí portu, který každá služba zpřístupňuje.

Například v aplikaci v Pythonu je velmi běžné, že skutečným aplikačním serverem je Gunicorn, který naslouchá na interním portu (například 8000) a spravuje několik pracovních procesů. Nginx, který se nachází vpředu, je zodpovědný za příjem veřejného provozu, správu TLS, komprese, časových limitů a ukládání do mezipaměti a předávání pouze „čistých“ požadavků Gunicorn , který se zaměřuje na provádění aplikační logiky.

Něco podobného se děje s aplikacemi v Javě, Node.js nebo Ruby, které používají specializované aplikační servery. Nginx funguje jako společná fasáda pro všechny z nich a umožňuje uživatelům přístup k jedné doméně nebo několika dobře organizovaným subdoménám, zatímco interně každá služba běží ve vlastním prostředí s technologickým stackem, který nejlépe vyhovuje jejím potřebám.

Ve světě .NET, když nasazujete aplikace ASP.NET Core na Linuxu, obvykle naslouchají na portech jako 5000 nebo 5001. Obvykle se dodržuje tento vzorec: Spusťte aplikaci jako službu nebo démona spravovaného systemd a nakonfigurujte Nginx tak, aby přesměrovával provoz z portu 80 nebo 443 na tento interní port. Tímto způsobem uživatel jednoduše přistupuje http://localhost nebo do veřejné domény a nevidí ani jedno číslo portu.

Když dojde k chybě (například backend se zhroutí nebo nenaslouchá na správném portu), Nginx obvykle vrátí chybu kód 502 Špatná bránaProhlížení chybových protokolů Nginx a používání nástrojů, jako je netstat Chcete-li zkontrolovat, které porty naslouchají, můžete za chodu diagnostikovat, zda je problém s proxy nebo aplikací, což diagnostický úkol výrazně usnadňuje.

Používání Nginxu s WordPressem a dalšími CMS přes reverzní proxy

Dalším běžným případem použití je, když chcete kombinovat hlavní web, který není na WordPressu, s blogem na WordPressuale uchovávají se pod stejnou doménou a v podadresáři místo v subdoméně. Například s example.com obsluhováno nástupištěm A a example.com/blog obsluhováno WordPressem na jiném serveru.

Z hlediska SEO a organizace obsahu mnoho administrátorů dává přednost používání podadresářů namísto subdomén, i když na technické úrovni Google prohlašovat, že s oběma zachází podobně. Reverzní proxy s Nginxem umožňuje právě to: že žádosti o /blog jsou odesílány na jiný hostitel nebo IP adresu, zatímco doména orientovaná pro uživatele zůstává stejná.

K dosažení tohoto cíle je nakonfigurován blok. location který zachytí daný podadresář a provede proxy_pass na adresu externě hostovaného blogu s přidáním příslušných hlaviček, aby backend rozpoznal skutečného klienta a případně schéma HTTPS.

Zároveň se v instalaci WordPressu za proxy upraví URL adresy webu a domovské stránky tak, aby odkazovaly na hlavní doménu s podadresářem, a upraví se i některé proměnné prostředí ($_SERVER['HTTP_HOST'], REQUEST_URIatd.) pro vyhněte se smyčkám přesměrování nebo nekonzistentním trasám.

Tento vzorec lze opakovat tolikrát, kolikrát potřebujete: internetové obchody v podadresářích, interní panely, SPA aplikace atd., každý hostovaný kdekoli preferujete, ale vše obsluhované pod stejnou doménou díky funkci reverzní proxy Nginxu.

Monitorování, protokolování a řešení problémů

Jednou z dalších výhod centralizace provozu v Nginxu je, že máte jeden úhel pohledu, ze kterého můžete sledovat, co se děje. Server generuje protokoly přístupu a chyb /var/log/nginx/které shromažďují jak příchozí požadavky, tak i selhání, ke kterým dochází při komunikaci s backendy.

Přístupové protokoly ukazují, které zdroje byly vyžádány, z jaké IP adresy, s jakým stavovým kódem a jak dlouho trvalo jejich poskytnutí. Z toho můžete identifikovat obzvláště pomalé trasy, opakující se chyby nebo špičky v provozu v určitých časech – což je velmi užitečné pro doladění pravidel ukládání do mezipaměti, limitů rychlosti nebo rozhodnutí o škálování.

Chybové protokoly jsou na druhou stranu klíčové, když se vyskytnou problémy s chybami 502, 503 nebo jiné problémy s interní komunikací. Obvykle obsahují zprávy jako „nelze se připojit k upstreamu“, „vypršel časový limit“ nebo „syntaxické chyby v konfiguračních souborech“, což usnadňuje nalezení příčiny chyby bez nutnosti pátrat naslepo.

Kromě logování lze Nginx integrovat s externími monitorovacími nástroji, a to jak na úrovni serveru (CPU, paměť, disk), tak i zaměřenými na HTTP metriky (doby odezvy, počet aktivních připojení, chybovost). To poskytuje komplexní pohled na chování proxy a služeb, které chrání , což je zásadní při správě webů nebo aplikací s vysokou návštěvností.

Díky kombinaci kvalitních protokolů, upozornění a několika základních příkazů pro kontrolu stavu služeb je mnohem snazší udržovat infrastrukturu v dobrém stavu a rychle reagovat, pokud dojde k incidentu, který ovlivní dostupnost nebo výkon.

Díky všem výše uvedeným faktorům je Nginx, používaný jako reverzní proxy, ústřední součástí mnoha moderních architektur: zlepšuje výkon obsluhou statických souborů a ukládáním do mezipaměti, posiluje zabezpečení skrytím backendů a centralizací šifrovacích politik, usnadňuje nasazení více aplikací v rámci stejné domény a poskytuje jednotný bod pro monitorování a kontrolu nad provozem vstupujícím a vystupujícím z vaší platformy.