Hallå! Idag ska vi prata om detta rätt koncept, hur virtuella värdar(Virtuella värdar) i nginx webbserver. Vi kommer att använda operativsystemet Ubuntu som ett exempel. För andra Linux-system kommer installationen att se väldigt lika ut. Denna instruktionsartikel kommer att vara av intresse främst för nybörjare webbansvariga och administratörer, eftersom de har oftast den här frågan.

En virtuell värd är...

Låt oss först definiera en virtuell värd. Så, virtuell värd är dela adressutrymmet för en webbserver, till exempel efter webbplatsnamn, vilket gör att flera webbplatser/applikationer kan köras på en fysisk server. I terminologin för nginx-dokumentation kallas den virtuella värden också "Serverblockering", men för mer likhet med Apache kommer jag att kalla det enhetligt, eftersom deras syfte är detsamma. Och en konvention till - låt oss kalla vad vi ska konfigurera en webbplats för enkelhetens skull.

Skapa en virtuell värd

Många av kommandona i denna manual kräver att din användare har sudoer-behörigheter på VPS. Därför, om du inte har dem, kommer du tyvärr knappast att kunna konfigurera virtuella värdar.

Förinställa

Nu ska jag säga en sak som alla behöver veta! För att konfigurera en virtuell värd i nginx behöver du nginx-webbservern installerad på din maskin. Captain Obvious är med oss! Om du redan har nginx installerat kan du säkert hoppa över det här steget och följa instruktionerna. Om du av någon anledning fortfarande inte har det på din maskin, skriv in kommandot i konsolen:

Sudo apt-get install -y nginx

Alternativ "-Y" vi lägger till kommandot apt-get för att inte svara ja-ja-ja på installationsprogrammets irriterande frågor, eftersom vi är säkra på att vi vill installera det här paketet och samtycker till användningen av det diskutrymme som det upptar. Om du fortfarande inte är säker på om du håller med om allt, lägg inte till det här alternativet.

Skapa en webbplatskatalog

Så, innan du skapar en virtuell värd, låt oss skapa en webbplatsmapp där vi kommer att placera alla filer som vår webbserver kommer att arbeta med.

Sökvägen till denna mapp i konfigurationen för den värd som skapas kommer att vara Dokumentrot, ett slags sammanhang, en isoleringspunkt, över vilken det är omöjligt att stiga från utsidan utan preliminära konfigurationsinställningar, och i förhållande till vilka sökvägar till de begärda filerna som byggs. Med option "-P" för kommandot mkdir behöver vi inte oroa oss för att skapa överordnade kataloger, de kommer att skapas automatiskt:

Sudo mkdir -p /var/www/mysite.ru/public_html

Här använder vi en riktig verifierad DNS-domän med korrekta poster som pekar på vår maskin. För att skapa en virtuell värd med en oregistrerad domän, till exempel för lokal utveckling, måste du göra en motsvarande post i filen / etc / hosts. Mer om detta i slutet av artikeln.

Åtkomsträttigheter

Nu har bara rotanvändaren rättigheter till vår skapade mapp. Vi måste ge tillstånd till katalogen för önskad användare, för att inte arbeta med henne konstant i superanvändarläget. Du kan ersätta "www-data"-användaren som används nedan med en annan, men som standard körs nginx som den här användaren.

Sudo chown -R www-data: www-data /var/www/mysite.ru/public_html

Låt oss nu göra det så att alla användare kan läsa våra nya filer:

Sudo chmod 755 / var / www

Vi menar att vi arbetar med en VPS där alla användare inte är med på något dåligt eller där det bara finns du. Därför kan vi ge 755 rättigheter till mappen / var / www. Om det i ditt fall är omöjligt att ge alla systemanvändare rätt att läsa den här katalogen, studera problemet med differentiering av rättigheter och konfigurera det själv.

Nu har du allt med rättigheterna klart!

Skapa en sida

Nu måste vi placera i vår mapp några statiska filer (HTML-sidor, bilder, skript, stilar, etc.) som vår server kommer att distribuera. Låt oss skapa en HTML-sida index.htm, som kommer att vara huvudsidan på vår webbplats:

Sudo nano /var/www/mysite.ru/public_html/index.htm

Och låt oss lägga till lite uppmärkning till det som kommer att visas för användaren:

Hurra! Du kunde konfigurera Virtual Host i nginx!

Spara och avsluta.

Skapa en virtuell värdkonfiguration

Vi har kommit till att skapa en konfigurationsfil för vår nya virtuella värd, som kommer att innehålla all information om webbplatsen som behövs för webbservern.

I nginx, i katalogen / etc / nginx / sites-available, finns det en mall för de genererade konfigurationerna. Låt oss kopiera det till vår webbplats:

Sudo cp / etc / nginx / sites-available / default /etc/nginx/sites-available/mysite.ru

Virtuell värdkonfiguration

Öppna en ny konfigurationsfil och du kommer att se all nödvändig information som du behöver fylla i.

Sudo nano /etc/nginx/sites-available/mysite.ru

Vi måste göra ändringar i nuvarande konfiguration... Som ett resultat, för vårt enkla fall, bör du få något i stil med följande:

Server (lyssna 80; root /var/www/mysite.ru/public_html; index index.html index.htm; server_name mysite.ru www.mysite.ru;)

Här måste du korrekt ange sökvägen till mappen med webbplatsens statistik och namnet på servern som du kommer åt din webbplats med. Om du anger sökvägen felaktigt eller inte anger den alls, kommer du inte att kunna konfigurera den virtuella värden. V som server _name, kan du också ange en IP-adress eller flera namn separerade med ett mellanslag, genom vilka värden kommer att vara tillgänglig, som vi gjorde.

Det var allt, vi är klara med den här filen. Spara den och stäng den.

Virtuell värdaktivering

Nginx har mappar som är tillgängliga för webbplatser och mappar som är aktiverade för webbplatser. Den första lagrar konfigurationerna för ALLA virtuella värdar som kan vara på denna server, och i den webbplatsaktiverade katalogen finns symboliska länkar till aktiva. Ingen förbjuder på webbplatser aktiverade att placera den ursprungliga konfigurationsfilen, men inte länken, men det kommer att vara mindre bekvämt, eftersom om det är nödvändigt att inaktivera den måste du antingen ta bort filen (då blir det problematiskt att ta med den tillbaka), eller flytta den till en annan katalog (då måste vi komma ihåg var vi flyttade). Det är mycket lättare att slå en symbolisk länk!

Därför måste vi nu, för att aktivera vår virtuella värd, skapa en symbolisk länk mellan katalogen som är tillgänglig för webbplatser, där vår konfigurationsfil finns, och webbplatsaktiverade. Apache har specialteam a2ensite. Det finns inget sådant kommando i nginx, så låt oss köra följande:

Sudo ln -s /etc/nginx/sites-available/mysite.ru /etc/nginx/sites-enabled/mysite.ru

För att undvika "konfliktande servernamnsfel" och se till att din webbplats betjänar nödvändig information, kan du ta bort standard från antalet aktiva värdar:

Sudo rm / etc / nginx / sites-enabled / default

Starta om

Vi har redan gått igenom många steg och nästan allt är uppställt. Låt oss nu ladda om vår webbserver för att ansöka ny konfiguration, men innan du gör detta är det bra att kontrollera att allt med konfigurationen är korrekt och att nginx förstår det korrekt. För att göra detta, kör nginx diagnostik med följande kommando:

Sudo nginx -t

En sådan kontroll är extremt nödvändig vid konfigurering på produktionsservrar, så att det inte händer att vi anropade omstartskommandot nginx, men det kunde inte starta på grund av en felaktig konfiguration, och alla våra virtuella värdar svarar inte.

Om du får något liknande som svar:

Nginx: konfigurationsfilen /etc/nginx/nginx.conf-syntaxen är ok nginx: konfigurationsfilen /etc/nginx/nginx.conf-testet lyckades

Då är allt bra med dig och du kan säkert starta om servern med kommandot:

Sudo service nginx omstart

V annat du måste titta på värdkonfigurationsfilen. Något du inte angav där.

Konfigurera lokala värdar

Om du angav en IP-adress som servernamn kan du hoppa över det här steget, eftersom du behöver ingen lokal värdkonfiguration, din virtuella värd fungerar utan den. Men om du vill arbeta med din virtuella värd utan ett riktigt domännamn kan du ställa in lokala värdar på din maskin. Som jag sa ovan är detta väldigt bekvämt, till exempel vid utveckling. Jag kan skapa mysite.dev, och den lokala instabila versionen av webbplatsen kommer att köras på den. För macOS och Linux-system, kör följande kommando:

Sudo nano / etc / värdar

Om du arbetar under Windows, bör filen från lokala värdar ligga ungefär längs denna väg C: \ Windows \ System32 \ drivrutiner \ etc \ värdar.

Lägg till en post om den nya lokala värden till filen. I vårt fall måste vi lägga till två poster, eftersom vi angav två domäner i server_name.

12.34.56.789 mysite.ru 12.34.56.789 www.mysite.ru

Nu, tills denna post raderas, kommer förfrågningar till mysite.ru att få information om denna värd från den här filen och omdirigera dig till din fjärrserver. Om servern är utplacerad lokalt måste du skriva "127.0.0.1" istället för "12.34.56.789".

Det är god praxis att ta bort värdposter efter att de har slutfört sin uppgift för att undvika framtida problem.

resultat

Nu kan vi se resultatet av vårt arbete! Ange adressen http://mysite.ru eller http://www.mysite.ru i webbläsaren och beundra huvudsidan vi har skapat från index.htm. Båda adresserna måste visa vår hemsida... Det är allt! Vår virtuella värd fungerar utmärkt.

Nginx är en populär och presterande webbserver och omvänd proxyserver.

Nginx har många fördelar, men dess inställningar är ganska komplexa och inte alltid tydliga för nybörjare. Denna manual guidar dig genom de grundläggande parametrarna, syntaxen och konfigurationsfilerna för Nginx.

Notera: Handledning gjord på Ubuntu 12.04.

Nginx kataloghierarki

Nginx lagrar konfigurationsfiler i katalogen / etc / nginx.

Denna katalog innehåller flera fler kataloger och modulära konfigurationsfiler.

cd / etc / nginx
ls -F

conf.d / koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available / win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled /

Apache-användare är redan bekanta med katalogerna med webbplatser som är tillgängliga och webbplatsaktiverade. Dessa kataloger definierar platskonfigurationer. Filer skapas och lagras vanligtvis på webbplatser som är tillgängliga; webbplatsaktiverade lagrar endast konfigurationer av aktiverade webbplatser. För att göra detta måste du skapa en symbolisk länk från webbplatser som är tillgängliga till webbplatser aktiverade.

Mappen conf.d kan också användas för att lagra konfigurationer. Varje .conf-fil kommer att läsas när Nginx startar. Syntaxen för sådana filer bör vara fri från fel.

Nästan alla överblivna filer lagras i / etc / nginx, som innehåller konfigurationsinformation för specifika processer eller ytterligare komponenter.

Den huvudsakliga Nginx-konfigurationsfilen är nginx.conf.

Nginx.conf filen

Filen nginx.conf läser de lämpliga konfigurationsfilerna och slår samman dem till en enda konfigurationsfil när servern startar.

Öppna filen:

sudo nano /etc/nginx/nginx.conf

användare www-data;
arbetarprocesser 4;
pid /var/run/nginx.pid;
evenemang (
worker_connections 768;
# multi_accept på;
}
http (
. . .

De första raderna satt allmän information om Nginx. Användaren www-datasträng anger användaren som servern startas med.

Pid-direktivet anger var PID för processer kommer att lagras för internt bruk. Raden worker_processes definierar antalet processer som Nginx kan stödja samtidigt.

I den här delen av filen kan du också ange loggar (till exempel definieras felloggen med direktivet error_log).

Allmän information om servern följs av händelsesektionen. Den hanterar hanteringen av Nginx-anslutningar. Det följs av http-blocket. Innan du fortsätter med dina webbserverkonfigurationer måste du förstå hur Nginx-konfigurationsfilen är formaterad.

Nginx konfigurationsfilstruktur

Nginx-konfigurationsfilen är uppdelad i block.

Det första blocket är händelser, följt av http, och den huvudsakliga konfigurationshierarkin börjar.

Konfigurationsdetaljerna för http-blocket är skiktade med hjälp av privata block som ärver egenskaper från blocket där de finns. http-blocket lagrar det mesta vanliga konfigurationer Nginx, som är uppdelade i serverblock, som i sin tur är uppdelade i platsblock.

När du konfigurerar Nginx är det viktigt att komma ihåg följande regel: ju högre konfigurationsnivå, desto fler block kommer att ärva den konfigurationen; ju lägre konfigurationsnivån är, desto mer "individuell" är den. Det vill säga om X-parametern ska användas i varje serverblock, måste en sådan parameter placeras i http-blocket.

Om du tittar noga på filen kommer du att märka att den innehåller många alternativ som avgör programmets beteende som helhet.

Till exempel, för att konfigurera filkomprimering, måste du ställa in följande parametrar:

gzip på;
gzip_disable "msie6";

Detta kommer att aktivera gzip-stöd för att komprimera data som skickas till klienten och inaktivera gzip för Internet Explorer 6 (eftersom den här webbläsaren inte stöder datakomprimering).

Om en parameter måste ha ett annat värde i flera serverblock, kan en sådan parameter ställas in på högsta nivå och sedan omdefinieras inom själva serverblocken. Som ett resultat kommer Nginx att köra parametern på lägsta nivån.

Denna nivå av konfigurationer undviker behovet av att hantera flera identiska filer. Dessutom, om du glömde att definiera lågnivåparametrar, kommer Nginx helt enkelt att köra standardparametrarna.

http-blocket i filen nginx.conf slutar så här:

inkludera /etc/nginx/conf.d/*.conf;
inkluderar / etc / nginx / sites-enabled / *;

Detta innebär att server- och platsblocken som definierar inställningarna för specifika webbplatser och webbadresser kommer att lagras utanför denna fil.

Detta gör att en modulär konfigurationsarkitektur kan upprätthållas där nya filer kan skapas för att betjäna nya webbplatser. Det låter dig också gruppera liknande filer tillsammans.

Stäng filen nginx.conf. Nu måste du undersöka inställningarna för enskilda webbplatser.

Nginx virtuella block

Serverblock i Nginx är analoga med Apaches virtuella värdar (men för bekvämlighets skull kallas de även virtuella värdar). I grund och botten är serverblock de tekniska egenskaperna hos enskilda webbplatser som finns på en enda server.

I katalogen som är tillgängliga för webbplatser kan du hitta standardserverblockfilen som följer med servern. Den här filen innehåller all information som krävs för att underhålla webbplatsen.

cd-sajter-tillgängliga
sudo nano standard

root / usr / share / nginx / www;
index index.html index.htm;
servernamn lokalvärd;
plats / (

}
plats / doc / (

alias / usr / share / doc /;
autoindex på;
tillåt 127.0.0.1;
förneka alla;

Filen är mycket väl kommenterad som standard, men i exemplet ovan har kommentarer utelämnats för enkelhetens skull och bekvämligheten.

Serverblocket innehåller alla inställningar, placerade mellan hängslen:

server (
. . .
}

Detta block finns i filen nginx.conf nära slutet av http-blocket som använder omfatta direktiv.

Rotdirektivet definierar katalogen där webbplatsens innehåll ska lagras. I den här katalogen kommer Nginx att leta efter filer som efterfrågas av användaren. Som standard är den här katalogen / usr / share / nginx / www.

Observera att alla rader slutar med semikolon. Detta är hur Nginx frikopplar ett direktiv från ett annat. Om det inte finns något semikolon kommer Nginx att läsa de två direktiven (eller flera direktiv) som ett direktiv med ytterligare argument.

Indexdirektivet definierar filerna som ska användas som ett index. Webbservern kommer att kontrollera filerna i den ordning de är listade. Om ingen sida har begärts kommer serverblocket att hitta och returnera filen index.html. Om den inte kan hitta den här filen kommer den att försöka analysera index.htm.

Server_name-direktivet

Direktivet server_name innehåller en lista över domännamn som kommer att betjänas av detta serverblock. Antalet domäner är obegränsat; Separera domäner i listan med mellanslag.

En asterisk (*) i början eller slutet av en domän anger ett namn med en mask, där asterisken matchar en del (eller flera delar) av namnet. Till exempel kommer * .example.com att matcha forum.example.com och www.animals.example.com.

Om den begärda webbadressen matchar flera server_name-direktiv kommer den först att svara med den som exakt matchar.

Om adressen inte hittar en matchning kommer den att leta efter det längsta maskerade namnet som slutar med en asterisk. Om den inte hittar ett sådant namn kommer den att returnera den första matchningen med vanliga uttryck.

Servernamn som använder reguljära uttryck börjar med en tilde (~). Tyvärr ligger det här ämnet utanför ramen för denna artikel.

Plats block

Platsen / raden anger att direktiven inom parentes kommer att gälla för alla begärda resurser som inte matchar några andra platsblock.

Sådana block kan innehålla en uri-sökväg (t.ex. / doc /). För att skapa en fullständig matchning mellan plats och uri, används symbolen =. ~-symbolen matchar reguljära uttryck.

Tilden aktiverar skiftlägeskänsligt läge och tilden med en asterisk aktiverar skiftlägeskänsligt läge.

Om begäran helt matchar platsblocket, stoppar servern sökningen och använder ett sådant block. Om servern inte hittar ett helt matchande platsblock jämför den URI:n med parametrarna för platsdirektiven. Nginx kommer att välja ett block som använder teckenkombinationen ^ ~ och matchar URI:n.

Om alternativet ^ ~ inte används kommer Nginx att välja den närmaste matchningen och utföra en sökning med reguljära uttryck för att försöka matcha ett av de tillgängliga mönstren. Om han hittar ett sådant uttryck, då använder han det. Om det inte finns något sådant uttryck använder servern den tidigare hittade URI-matchningen.

Som en slutsats bör det noteras att Nginx föredrar exakta matchningar. Om det inte finns någon sådan matchning letar den efter ett reguljärt uttryck och söker sedan efter URI. För att ändra prioritet för URI-sökningar, använd teckenkombinationen ^ ~.

Try_files-direktivet

Try_files-direktivet är mycket användbart verktyg som kontrollerar förekomsten av filer i den givna ordningen och använder den första filen som hittas för att behandla begäran.

Detta låter dig använda ytterligare parametrar för att definiera hur Nginx ska betjäna förfrågningar.

Det finns en rad i standardkonfigurationsfilen:

try_files $ uri $ uri / /index.html;

Detta betyder att när en förfrågan anländer serverad av ett platsblock, kommer Nginx först att försöka tjäna uri:n som en fil (detta beteende ställs in av $ uri-variabeln).

Om servern inte hittar en matchning för variabeln $ uri kommer den att försöka använda uri som en katalog.

Servern använder ett snedstreck i slutet för att kontrollera existensen av katalogen, till exempel $ uri /.

Om ingen fil eller katalog hittas kör Nginx standardfilen (i det här fallet index.html i serverblockets rotkatalog). Varje try_files-direktiv använder den sista parametern som en reserv, så denna fil måste finnas i systemet.

Om webbservern inte hittade matchningar i föregående parametrar kan den returnera en felsida. För detta används ett likhetstecken och en felkod.

Till exempel, om platsen/blocket inte kan hitta den begärda resursen, kan det returnera ett 404-fel istället för filen index.html:

try_files $ uri $ uri / = 404;

För att göra detta måste du sätta ett likhetstecken och ställa in felkoden som sista parameter (= 404).

Extra tillval

Aliasdirektivet tillåter Nginx att servera sidor i platsblocket utanför den angivna katalogen (till exempel utanför roten).

Till exempel, filer som begärs från / doc / kommer att serveras från / usr / share / doc /.

Autoindex on-direktivet möjliggör listning av Nginx-kataloger för det givna platsdirektivet.

Tillåt och neka raderna styr åtkomst till kataloger.

Slutsats

Nginx webbserver är funktionsrik och mycket presterande, men dess terminologi och parametrar kan vara förvirrande.

Genom att förstå och arbeta med Nginx-konfigurationer kan du dra full nytta av detta kraftfulla och lätta verktyg.

En av de mest populära webbservrarna

Nginx är mycket populärt bland webb- och proxyserveranvändare på grund av dess prestanda. Servern har många fördelar, men det kan vara svårt för en nybörjare att installera. Vi vill hjälpa dig att ta reda på konfigurationsfilerna, syntaxen och grundläggande Nginx-inställningar.

Kataloghierarki

Alla serverkonfigurationsfiler finns i katalogen / etc / nginx. Dessutom finns det flera fler mappar i katalogen, såväl som modulära konfigurationsfiler.

cd / etc / nginx
ls -F
conf.d / koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available / win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled /

Om du har använt Apache bör du känna till de kataloger som är aktiverade för webbplatser och som är tillgängliga för webbplatser. De bestämmer konfigurationen av webbplatserna. De genererade filerna lagras i den sista katalogen. Den webbplatsaktiverade mappen behövs för att lagra konfigurationer av endast aktiverade sidor. För att länka dem behöver du en symbolisk länk mellan mapparna. Konfigurationer kan också lagras i katalogen conf.d. Samtidigt, under Nginx-start, kommer varje fil med filtillägget .conf att läsas om igen. När du skriver konfigurationsfiler, skriv in koden korrekt och följ syntaxen. Alla andra filer finns i / etc / nginx. Konfiguratorn innehåller information om specifika processer samt ytterligare komponenter.

Den huvudsakliga Nginx-konfigurationsfilen är nginx.conf.

Den läser alla konfigurationsfiler och slår samman dem till en, vilket begärs när servern startar. Öppna filen med:

sudo nano /etc/nginx/nginx.conf

Följande rader visas på skärmen:

användare www-data;
arbetarprocesser 4;
pid /var/run/nginx.pid;
evenemang (
worker_connections 768;
# multi_accept på;
}
http (
. . .

Den första är en översikt över Nginx. Frasen användare www-data syftar på användaren som startar servern. Pid-direktivet anger var de interna PID-processerna finns. Raden worker_processes visar hur många processer Nginx kan köra samtidigt. Dessutom kan du ange loggar här (till exempel definieras felloggen med direktivet error_log). Nedan är evenemangssektionen. Det behövs för att hantera serveranslutningar. Efter det är http-blocket.

Nginx konfigurationsfilstruktur

Att förstå filformateringsstrukturen hjälper dig att bättre förstå din webbserverkonfiguration. Den är uppdelad i byggstenar. Konfigurationsdetaljerna för http-blocket är lagrade med hjälp av privata block. De ärver egenskaper från sin förälder, d.v.s. den där de finns. Detta block lagrar de flesta serverkonfigurationer. De är uppdelade i serverblock, inuti vilka platsen är belägen.

När du konfigurerar din Nginx-server, kom ihåg att ju lägre konfigurationsblocket är, desto färre objekt kommer att ärva egenskaper, och vice versa. Filen innehåller ett stort antal alternativ som ändrar driften av servern. Du kan till exempel ställa in komprimeringen av filer som skickas till klienten. För att göra detta, skriv parametrarna:

gzip på;
gzip_disable "msie6";

Tänk på att samma parameter kan anta olika värden i olika block. Ställ först in den överst och åsidosätt sedan parametern på önskad nivå. Om sista åtgärden kör inte, programmet kommer att ställa in värdena i automatiskt läge.

De sista raderna i filen nginx.conf är:

inkludera /etc/nginx/conf.d/*.conf;
inkluderar / etc / nginx / sites-enabled / *;

De indikerar att platsen och serverblocken är lagrade utanför denna fil. De definierar inställningarna för webbadresser och specifika filer. Denna struktur är nödvändig för att upprätthålla en modulär konfigurationsstruktur. Inuti den kommer du att kunna skapa nya kataloger, filer för olika webbplatser. Dessutom kan du gruppera liknande filer. Efter granskning kan du stänga filen nginx.conf.

Virtuella block

De är analoga med virtuella värdar i Apache. Serversektionsblocken inkluderar egenskaperna för enskilda webbplatser som finns på servern. I mappen som är tillgängliga för webbplatser hittar du standardserverblockfilen. Inuti den kan du hitta extern information som kan behövas när du underhåller webbplatser.

cd-sajter-tillgängliga
sudo nano standard
server (
root / usr / share / nginx / www;
index index.html index.htm;
servernamn lokalvärd;
plats / (
try_files $ uri $ uri / /index.html;
}
plats / doc / (
alias / usr / share / doc /;
autoindex på;
tillåt 127.0.0.1;
förneka alla;
}
}

I exemplet ovan togs kommentarer medvetet bort. Detta gjordes för läsbarheten. Inuti serverblocken finns inställningarna inneslutna i hängslen:

Detta block placeras med inkluderingsdirektivet i slutet av http som anges i filen nginx.conf. Rotdirektivet definierar katalogen där webbplatsens innehåll kommer att finnas. I den kommer programmet att söka efter filer som användaren kommer att begära. Standardsökvägen är / usr / share / nginx / www. Nginx separerar linjer eller direktiv från varandra med semikolon. Om du inte sätter ett skiljetecken läses flera rader som en. För att skriva reglerna som kommer att användas som ett index, använd indexdirektivet. Servern kontrollerar dem i den ordning de är listade. Om ingen av de tillgängliga sidorna efterfrågades av användaren kommer index.html att returneras. Om den inte finns där kommer servern att leta efter index.htm.

Server_name regel

Den innehåller en lista över domännamn som ska behandlas av serverblocket. Du kan skriva valfritt antal av dem, separera dem med mellanslag. Om du sätter * i slutet eller början av en domän kommer du att kunna ange ett namn med en mask. Asterisken matchar en del av namnet. Om du registrerar * .com.ua, kommer alla adresser till den angivna domänzon... Om adressen stämmer överens med beskrivningen av flera direktiv kommer den att svara med den som passar helt. Om det inte finns någon matchning blir svaret det längsta namnet som har en mask. Annars kommer reguljära uttryck att matchas. Servernamn som använder reguljära uttryck börjar med en tilde (~).

Plats block

Nästa i raden kommer vi att ha ett platsblock. Den används för att bestämma hur vissa förfrågningar hanteras. Om resurserna inte motsvarar några andra platsblock, kommer direktiven som anges inom parentes att tillämpas på dem. Dessa block kan innehålla en sökväg som / doc /. För att upprätta en fullständig överensstämmelse mellan uri och plats, används tecknet =. Om du använder tilden matchar de reguljära uttrycken. Du kan också ställa in skiftlägeskänsligheten genom att sätta ~. Om du lägger till en asterisk spelar fallet ingen roll.

Tänk på: när förfrågan matchar platsblocket kommer den att användas och sökningen stoppas. När matchningen är ofullständig kommer URI:n att jämföras med parametrarna i platsdirektiven. Ett block med kombinationen ^ ~ används för att matcha URI:n för blockvalet. Om detta alternativ inte använder, servern väljer den bästa matchningen och söker även med reguljära uttryck. Detta är nödvändigt för att välja en av de lämpliga mallarna. Om ett matchande uttryck hittas kommer det att användas. Annars kommer den tidigare URI-matchningen att tillämpas. Tänk dock på att Nginx gillar helmatcher mer. Om de inte finns där kommer den att börja söka efter reguljära uttryck och sedan med URI. Sökparitet anges av teckenkombinationen ^ ~.

Try_files regel

Det är ett mycket användbart verktyg som kan söka efter filer i en angiven ordning. Den tillämpar de första matchningskriterierna för att behandla begäran. du kan använda Extra tillval för att definiera hur servern ska betjäna förfrågningar. Konfiguratorn har en standardrad så här:

try_files $ uri $ uri / /index.html;

Vad betyder det? Om en förfrågan kommer in som betjänas av ett platsblock kommer servern först att försöka bearbeta uri:n som en fil. Detta tillhandahålls av variabeln $ uri. När det inte finns någon matchning kommer uri:n att behandlas som en katalog. Du kan kontrollera dess existens genom att lägga till ett snedstreck i slutet: $ uri /. Det finns situationer då varken filen eller katalogen kommer att hittas. I det här fallet kommer standardfilen index.html att laddas. Regeln try_files tillämpar den sista parametern som en reserv. Det är därför den här filen måste finnas i systemet. Men om inga matchningar hittas alls, kommer Nginx att returnera en felsida. För att ställa in det, skriv = och felkoden:

Ytterligare alternativ

Om du tillämpar aliasregeln kommer du till exempel att kunna visa sidor i platsblocket utanför rotkatalogen. När filer behövs från doc, kommer de att begäras från / usr / share / doc /. Dessutom börjar autoindex on-regeln lista serverkatalogerna för det angivna platsdirektivet. Om du skriver raderna neka och tillåt, kommer du att kunna ändra åtkomst till kataloger.

Som en slutsats bör det sägas att Nginx är ett mycket kraftfullt multifunktionellt verktyg. Men att få en bra förståelse för hur det fungerar kommer att ta tid och ansträngning. Om du förstår hur konfigurationer fungerar kan du njuta fullt ut av alla funktioner i programmet.

Övrig). Aktuell version, 0.6.x anses vara stabilt vad gäller tillförlitlighet, och utsläpp från 0.7-grenen anses vara instabila. Det är viktigt att notera att funktionaliteten för vissa moduler kommer att förändras, vilket gör att direktiven också kan ändras, så bakåtkompatibilitet i nginx upp till version 1.0.0 garanteras inte.

Varför är nginx så bra och varför älskar administratörer av högbelastningsprojekt det så mycket? Varför inte bara använda Apache?

Varför är Apache dåligt?

Först måste du förklara hur de i allmänhet fungerar. nätverksservrar... De som är bekanta med nätverksprogrammering vet att det i huvudsak finns tre modeller för serverdrift:

1. Konsekvent. Servern öppnar ett lyssningsuttag och väntar på att en anslutning ska visas (den är i ett blockerat tillstånd medan den väntar). När en anslutning kommer fram bearbetar servern den i samma sammanhang, stänger anslutningen och väntar på anslutningen igen. Uppenbarligen är detta långt ifrån det mesta Det bästa sättet, speciellt när arbetet med uppdragsgivaren pågår under lång tid och det finns många kopplingar. Dessutom har den sekventiella modellen många fler nackdelar (till exempel oförmågan att använda flera processorer), och i verkliga förhållanden används den praktiskt taget inte.
2. Multiprocess (flertrådig). Servern öppnar ett lyssningsuttag. När en anslutning anländer accepterar den den och skapar sedan (eller tar från poolen av tidigare skapade) en ny process eller tråd som kan arbeta med anslutningen så länge det behövs, och när arbetet är klart, avslutas eller återvända till poolen. Huvudtråden är under tiden redo att acceptera en ny anslutning. Detta är det mesta populär modell, eftersom det är relativt enkelt att implementera, tillåter komplexa och tidskrävande beräkningar för varje klient och använder alla tillgängliga processorer... Ett exempel på dess användning är Apache-webbservern. Men detta tillvägagångssätt har också nackdelar: när ett stort antal Samtidiga anslutningar skapar många trådar (eller ännu värre, processer), och operativsystemet slösar mycket resurser på kontextväxlar. Det är särskilt illa när kunder är väldigt långsamma att acceptera innehåll. Det visar sig hundratals trådar eller processer, upptagna med att bara skicka data till långsamma klienter, vilket skapar en extra belastning på OS-schemaläggaren, ökar antalet avbrott och förbrukar mycket minne.
3. Icke-blockerande uttag / State Machine. Servern fungerar inom en enda tråd, men använder icke-blockerande sockets och en pollingmekanism. De där. servern vid varje iteration av en oändlig slinga väljer från alla uttag den som är redo att ta emot/sända data med hjälp av välj ()-anropet. Efter att en socket har valts skickar servern data till den eller läser den, men väntar inte på bekräftelse, utan går in i initialtillståndet och väntar på en händelse på en annan socket, eller bearbetar nästa, där händelsen inträffade under bearbetningen av den föregående. Den här modellen mycket effektiv användning av processor och minne, men ganska svår att implementera. Dessutom, inom ramen för denna modell, måste bearbetningen av en händelse på en socket vara mycket snabb - annars kommer många händelser att ackumuleras i kön, och så småningom kommer den att svämma över. Så här fungerar nginx. Dessutom låter den dig starta flera arbetsprocesser (kallade arbetare), d.v.s. kan använda flera processorer.

Så, föreställ dig följande situation: 200 klienter med en 256 Kbps kanal är anslutna till en HTTP-server med en 1 Gbps kanal:

Vad händer i fallet med Apache? 200 trådar/processer skapas som genererar innehåll relativt snabbt (det kan vara både dynamiska sidor och statiska filer som läses från disk), men sakta ger det till klienter. Operativsystemet måste hantera en massa trådar och I/O-lås.

I en sådan situation spenderar Nginx en storleksordning mindre OS och minnesresurser på varje anslutning. Men här avslöjas begränsningen nätverksmodell nginx: den kan inte generera dynamiskt innehåll inom sig själv, eftersom detta kommer att leda till blockering inuti nginx. Naturligtvis finns det en lösning: nginx kan proxy för sådana förfrågningar (för att generera innehåll) till vilken annan webbserver som helst (till exempel samma Apache) eller till en FastCGI-server.

Låt oss betrakta funktionsmekanismen för nginx-paketet som "huvudservern" och Apache som servern för att generera dynamiskt innehåll:

Nginx accepterar anslutningen från klienten och läser hela begäran från den. Det bör noteras här att förrän nginx har läst hela begäran skickar den inte in den för "bearbetning". På grund av detta "bryts" vanligtvis nästan alla förloppsindikatorer för filuppladdningar - men det är möjligt att fixa dem med hjälp av tredjepartsmodulen upload_progress (detta kommer att kräva modifiering av applikationen).

Efter att nginx har läst hela svaret öppnas en anslutning till Apache. Den senare gör sitt jobb (genererar dynamiskt innehåll), varefter den skickar sitt svar till nginx, som buffrar det i minnet eller en temporär fil. Under tiden frigör Apache resurser. Vidare skickar nginx långsamt innehåll till klienten, samtidigt som de spenderar mindre resurser än Apache.

Detta schema kallas frontend + backend och används väldigt ofta.

Installation

Eftersom nginx har precis börjat bli populärt, det finns vissa problem med binära paket, så var beredd att kompilera det själv. Detta är vanligtvis inte ett problem, du behöver bara noggrant läsa utdata från kommandot. / Configure --help och välj de kompileringsalternativ du behöver, till exempel:

./konfigurera \
--Prefix = / opt / nginx-0.6.x \ # installationsprefix
--Conf-path = / etc / nginx / nginx.conf \ # plats för konfigurationsfil
-Pid-path = / var / run / nginx.pid \ # ... och pid-fil
-Användare = nginx \ # användarnamn under vilket nginx kommer att köras
—With-http_ssl_module —with-http_gzip_static_module —with-http_stub_status_module \ # lista över obligatoriska
—Utan-http_ssi_modul —without-http_userid_module —without-http_autoindex_module —without-http_geo_module —without-http_referer_module —without-http_memcached_module —without-http_limit_zone_module # ... och ej obligatoriska moduler

Efter konfigurationen bör du köra standarden make && make install, varefter du kan använda nginx.

Alternativt, i Gentoo kan du använda ebuilden från standardports-trädet; i RHEL / CentOS epel-förvaret (där nginx 0.6.x finns) eller srpm för version 0.7, som kan laddas ner härifrån: http://blogs.mail.ru/community/nginx; på Debian kan du använda paketet nginx från den instabila grenen.

Konfigurationsfil

nginx-konfigurationsfilen är mycket bekväm och intuitiv. Den kallas vanligtvis nginx.conf och ligger i $ prefix / conf / om platsen inte omdefinierades under kompileringen. Jag gillar att lägga det i / etc / nginx /, och det gör även utvecklarna av alla paket som nämns ovan.

Strukturen för konfigurationsfilen är som följer:

användare nginx; # användarnamn som nginx kommer att köras under
arbetarprocesser 1; # antal arbetsprocesser
evenemang (
<…># detta block specificerar pollingmekanismen som kommer att användas (se nedan) och högsta belopp möjliga kopplingar
}

Http (
<глобальные директивы http-сервера, например настройки таймаутов и т.п.>;
<почти все из них можно переопределить для отдельного виртуального хоста или локейшена>;

# beskrivning av servrar (det här är vad apache kallar VirtualHost)
server (
# serveradress och namn
lyssna *: 80;
servernamn aaa.bbb;

<Директивы сервера. Здесь обычно указывают расположение докуменов (root), редиректы и переопределяют глобальные настройки>;

# och så här kan du definiera plats, för vilken du också kan åsidosätta nästan alla direktiv som anges på mer globala nivåer
plats / abcd / (
<директивы>;
}
# Dessutom kan du skapa plats med reguljärt uttryck, så här:
plats ~ \ .php $ (
<директивы>;
}
}

# annan server
server (
lyssna *: 80;
servernamn ccc.bbb;

<директивы>
}
}

Observera att varje direktiv måste sluta med semikolon.
Omvänd proxy och FastCGI

Så ovan undersökte vi fördelarna med frontend + backend-schemat, listade ut installationen, strukturen och syntaxen för konfigurationsfilen, överväg nu hur man implementerar omvänd proxy i nginx.

Det är väldigt enkelt! Till exempel så här:

plats / (
proxy_pass http://1.2.3.4:8080;
}

I det här exemplet kommer alla förfrågningar till plats / att proxias till server 1.2.3.4, port 8080. Detta kan vara antingen apache eller någon annan http-server.

Det finns dock flera subtiliteter relaterade till det faktum att applikationen kommer att anta att för det första kommer alla förfrågningar till den från en IP-adress (vilket kan tolkas till exempel som ett försök till en DDoS-attack eller brute-force-attack) , och för det andra, tänk på att den körs på värd 1.2.3.4 och port 8080 (generera felaktiga omdirigeringar respektive absoluta länkar). För att undvika dessa problem utan att behöva skriva om programmet verkar följande konfiguration vara bekväm för mig:
Nginx lyssnar framänden på port 80.

Om backend (till exempel Apache) finns på samma värd som nginx, så "lyssnar" den på port 80 vid 127.0.0.1 eller en annan intern IP-adress.

I det här fallet ser nginx-konfigurationen ut så här:

server (
lyssna 4.3.2.1:80;
# ställ in värdhuvudet och X-Real-IP: för varje begäran som skickas till backend
proxy_set_header X-Real-IP $ remote_addr;
proxy_set_header Värd $ värd: $ proxy_port;
# eller "proxy_set_header Host $ host;" om programmet kommer att lägga till: 80 till alla länkar
}

För att applikationen ska kunna skilja mellan besökarnas IP-adresser måste du antingen installera modulen mod_extract_forwarded (om den körs Apache-server), eller modifiera programmet så att det tar information om användarens IP-adress från X-Real-IP HTTP-huvudet.

Ett annat backend-alternativ är att använda FastCGI. I detta fall nginx konfiguration kommer se ut ungefär så här:

server (
<…>

# plats dit förfrågningar om php-skript kommer att skickas
plats ~ .php $ (
fastcgi_pass 127.0.0.1:8888; # definiera adressen och porten för fastcgi-servern,
fastcgi_index index.php; # ... indexfil

# och några parametrar som måste skickas till fastcgi-servern så att den förstår vilket skript och med vilka parametrar som ska köras:
fastcgi_param SCRIPT_FILENAME / usr / www / html $ fastcgi_script_name; # skriptnamn
fastcgi_param QUERY_STRING $ query_string; # frågesträng
# och begäran parametrar:
fastcgi_param REQUEST_METHOD $ request_method;
fastcgi_param CONTENT_TYPE $ content_type;
fastcgi_param CONTENT_LENGTH $ content_length;
}

# på grund av att platser med reguljära uttryck har hög "prioritet" kommer alla icke-php-förfrågningar att hamna här.

plats / (
root / var / www / html /
}

Statik

För att minska belastningen på backend är det bättre att endast servera statiska filer via nginx - det klarar denna uppgift bättre, eftersom för varje begäran spenderar den betydligt mindre resurser (inget behov av att skapa en ny process, och nginx-processen brukar förbruka mindre minne och kan tjäna många anslutningar).

I konfigurationsfilen ser det ut så här:

server (
lyssna *: 80;
servernamn minserver.com;

Plats / (
proxy_pass


"> Http://127.0.0.1:80;

}

# anta att alla statiska filer finns i / filer
plats / filer / (
root / var / www / html /; # ange sökvägen till fs
går ut 14d; # lägg till Expires-huvudet:
error_page 404 = @tillbaka; # och om filen inte hittas, skicka den till den namngivna platsen @back
}

# förfrågningar från / filer, för vilka ingen fil hittades, skickas till backend, och den kan antingen generera önskad fil eller visa trevligt meddelande om felet
plats @tillbaka (
proxy_pass
"Titel =" http://127.0.0.1:80;

"> Http://127.0.0.1:80;

}

Om all statistik inte är placerad i en specifik katalog, använd ett reguljärt uttryck:

plats ~ * ^. + \. (jpg | jpeg | gif | png | ico | css | zip | tgz | gz | rar | bz2 | doc | xls | exe | pdf | ppt | txt | tar | wav | bmp | rtf | js) $ (
# liknande ovanstående, bara alla förfrågningar som slutar på ett av de angivna suffixen kommer att skickas till denna plats
root / var / www / html /;
error_page 404 = @tillbaka;
}

Tyvärr är nginx inte implementerat asynkront arbete med filer. Med andra ord är nginx-arbetaren blockerad på I/O-operationer. Så om du har många statiska filer och speciellt om de läses från olika diskar är det bättre att öka antalet arbetsprocesser (upp till ett antal som är 2-3 gånger fler än det totala antalet heads on disken). Detta leder naturligtvis till en ökning av belastningen på operativsystemet, men den totala prestandan ökar. För att arbeta med en typisk mängd statisk (inte ett särskilt stort antal relativt små filer: CSS, JavaScript, bilder) räcker det med ett eller två arbetsflöden.

Fortsättning följer

Länkar

Mer information om nginx finns här:

Nginx är en webbserver och e-postproxyserver som har varit allmänt tillgänglig sedan 2004. Utvecklingen av projektet började 2002, på ryska låter namnet som engine-ex. Skapandet av händerna på den berömda programmeraren Igor Sysoev, Nginx var ursprungligen avsedd för Rambler. Den är designad för operativsystem som tillhör den Unix-liknande gruppen. Sammansättningen testades framgångsrikt på OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. På Microsoft plattform Windows Nginx började arbeta med releasen av den binära versionen 0.7.52.

Statistik för mars 2011 visar att antalet webbplatser som betjänas av Nginx redan har passerat 22 miljoner-gränsen. Idag används Nginx av sådana välkända projekt som Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru och andra. Tillsammans med lighttpd används Nginx för att servera statiskt innehåll som genereras av en "obekväm" webbapplikation som körs under en annan webbserver.
Men innan vi går djupare in i naturen funktionella egenskaper Nginx - det kommer att vara användbart att komma ihåg vad en webbserver i allmänhet och en proxyserver i synnerhet är.

Webbserver och proxyserver

webbserverär en server som accepterar HTTP-förfrågningar från webbläsare och andra klienter och utfärdar HTTP-svar till dem. De senare brukar presenteras HTML-sida, mediaström, bild, fil, annan data. En webbserver förstås som både mjukvara som utför webbserverfunktioner och hårdvara. Utbytet av data och begärd information sker via HTTP-protokollet.

Listan ytterligare funktioner webbservrar inkluderar: auktorisering och autentisering av användare, loggning av deras förfrågningar till resurser, HTTPS-stöd för säker växling med klienter och andra. Den mest använda webbservern i Unix-liknande operativsystem är Apache. Den tredje raden i listan över klientinställningar är för närvarande upptagen av Nginx.

Proxyserver låter kunderna hantera sökfrågor Till nätverkstjänster i indirekt form. Det vill säga, det är en server som är specialiserad på att vidarebefordra klientförfrågningar till andra servrar. Genom att ansluta till en proxyserver och begära en resurs på en annan server kan klienten upprätthålla anonymitet och skydda datorn från nätverksattacker. Proxyservern utfärdar den begärda informationen till klienten antingen från sin egen cache (om någon) eller tar emot den från den angivna servern. I vissa fall (för att uppnå ovanstående mål) kan serverns svar, som klientens begäran, ändras av proxyservern.

Den enklaste proxyservern anses vara Network Address Translator eller NAT. År 2000 byggdes proxy NAT in i Windows-distributionen. Proxyservrar, som alla fenomen, har två sidor av myntet, det vill säga de kan användas både på gott och ont. Till exempel, med deras hjälp döljer de som fruktar sanktioner för sina olämpliga handlingar på nätverket sina IP-adresser ...

Funktionellt utbud av Nginx:

• serverservice av indexfiler, statiska frågor, generering av deskriptorer för öppen cache, lista över filer;
• accelererad proxy, elementär lastfördelning, feltolerans;
• stöd för cachning under accelererad proxy och FastCGI;
• stöd för FastCGI (accelererad) och memcachade servrar;
• modularitet, filter, inklusive "resume" (byte-intervall) och komprimering (gzip);
• HTTP-autentisering, fragmenterade svar, SSI-filter;
• parallell exekvering av flera underförfrågningar på sidan som behandlas genom FastCGI eller proxy i SSI-filtret;
• StartTLS och SSL-stöd;
• förmågan att stödja inbäddad Perl;
• enkel autentisering (ANVÄNDARE / PASS, LOGGA IN);
• serveromdirigering (IMAP / POP3 proxy) användare till IMAP / POP3 backend med hjälp av extern server autentisering (HTTP).

För dem som inte är bekanta med denna terminologi kan beskrivningen av funktionaliteten hos Nginx verka ganska vag. Men när det kommer till sätt att konkret använda denna webbserver - kommer den att börja blekna lite i taget.

Arkitektur och konfiguration

Arbetsprocesser i Nginx betjänar samtidigt många anslutningar och förser dem med OS-anrop ( operativ system) epoll (Linux), välj och kqueue (FreeBSD). Data som tas emot från klienten analyseras av en tillståndsmaskin. Den analyserade begäran hanteras av den konfigurationsspecificerade modulkedjan. Bildandet av ett svar till klienten sker i buffertar, som kan peka på en del av en fil eller lagra data i minnet. Sekvensen för dataöverföring till klienten bestäms av kedjorna i vilka buffertarna är grupperade.

Strukturellt är Nginx HTTP-servern uppdelad i virtuella servrar, som i sin tur är uppdelade i platser. Virtuell server eller så kan direktivet användas för att ange portar och adresser för att acceptera anslutningar. Plats kan anges med en exakt URI, en del av en URI eller ett reguljärt uttryck. För on-the-fly minneshantering är pooler en sekvens av förvalda minnesblock. Ett block som initialt allokerats för poolen har en längd på 1 till 16 kilobyte. Det är uppdelat i områden - ockuperade och obesatta. När det senare fylls, tillhandahålls valet av ett nytt objekt genom bildandet av ett nytt block.

Geografisk klassificering av klienter efter deras IP-adress utförs i Nginx med hjälp av en speciell modul. Radix-trädsystemet låter dig snabbt arbeta med IP-adresser och tar upp ett minimum av minne.

Fördelarna med Nginx

Nginx anses vara en mycket snabb HTTP-server. Istället för eller tillsammans med Apache, används Nginx för att påskynda bearbetningen av förfrågningar och minska belastningen på servern. Faktum är att de stora möjligheter som den modulära Apache-arkitekturen tillhandahåller inte krävs av de flesta användare. Att betala för denna outnyttjade funktionalitet är en betydande kostnad. systemresurser... För vanliga webbplatser är det som regel en tydlig dominans av statiska filer (bilder, stilfiler, JavaScript) och inte skript. Ingen speciell funktionalitet krävs för att överföra dessa filer till resursbesökaren, eftersom uppgiften är mycket enkel. Detta innebär att webbservern för att behandla sådana förfrågningar måste vara enkel och lätt, som Nginx.

Sätt att använda Nginx

På en separat port/IP. Om resursen är full av bilder eller filer för nedladdning kan Nginx konfigureras på en separat port eller IP och servera statiskt innehåll genom den. För att göra detta måste du dock mixtra lite med att ändra länkar på sajten. Med ett stort antal förfrågningar till statiska filer är det vettigt att skapa en separat server och installera Nginx på den.

Accelererad proxy... Med det här alternativet går alla besöksförfrågningar först till Nginx. Nginx hanterar förfrågningar om statiska filer (som en bild, vanlig HTML, JavaScript eller CSS-fil) på egen hand. Om användaren kontaktar ett visst skript vidarebefordrar han begäran till Apache-avdelningen. Du behöver inte göra några transformationer med webbplatskoden.

Om kanalen från servern till besökaren och vice versa är långsam kan denna användning av Nginx ge ytterligare effekt. Begäran som tas emot från besökaren skickas till Nginx för bearbetning av Apache. Efter att ha bearbetat begäran dirigerar Apache Nginx-sidan och avslutar anslutningen med en känsla av prestation. Nginx kan nu skicka en sida till en användare så länge det behövs, praktiskt taget utan att förbruka systemresurser. Apache arbete i dess ställe skulle det åtföljas av en orimligt hög belastning på minnet vid nästan tomgångsarbete. Förresten, det här användningsfallet för Nginx har ett annat namn: "Frontend till Apache".

Nginx plus FastCGI. Apache kanske inte behövs alls om tolken av språket som webbplatsens skript är skrivna på stöder FastCGI-teknik. Sådana språk inkluderar till exempel PHP, Perl och ett antal andra. Men i det här fallet kan du behöva ändra skriptkoderna.

Det finns många detaljerade material om hur man installerar och konfigurerar Nginx på nätverket. Du kan lära dig mer om Nginx på webbplatsen för dess utvecklare Igor Sysoev.