Nginx is een populaire en krachtige webserver en reverse proxy.

Nginx heeft veel voordelen, maar de instellingen zijn behoorlijk complex en niet altijd duidelijk voor beginners. Deze handleiding zal u helpen de basisparameters, syntaxis en configuratiebestanden van Nginx te begrijpen.

Opmerking: Deze tutorial is gemaakt op Ubuntu 12.04.

Nginx-directoryhiërarchie

Nginx slaat configuratiebestanden op in de map /etc/nginx.

Deze map bevat nog een aantal mappen en modulaire configuratiebestanden.

cd /etc/nginx
ls-F

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

Apache-gebruikers zijn al bekend met de mappen die beschikbaar zijn voor sites en sites die geschikt zijn voor sites. Deze mappen definiëren siteconfiguraties. Bestanden worden meestal gemaakt en opgeslagen op beschikbare sites; sites-enabled slaat alleen configuraties van ingeschakelde sites op. Om dit te doen, moet je creëren symbolische link van sites die beschikbaar zijn tot sites die ingeschakeld zijn.

De map conf.d kan ook worden gebruikt om configuraties op te slaan. Elk bestand met de extensie .conf wordt gelezen wanneer Nginx start. De syntaxis van dergelijke bestanden mag geen fouten bevatten.

Bijna alle overige bestanden worden opgeslagen in /etc/nginx, dat configuratie-informatie bevat voor specifieke processen of aanvullende componenten.

Het belangrijkste Nginx-configuratiebestand is nginx.conf.

nginx.conf-bestand

Het bestand nginx.conf leest de overeenkomstige configuratiebestanden en combineert deze tot enkel bestand configuraties bij het opstarten van de server.

Open het bestand:

sudo nano /etc/nginx/nginx.conf

gebruiker www-data;
werkprocessen 4;
pid /var/run/nginx.pid;
evenementen (
werkerverbindingen 768;
#multi_accept aan;
}
http(
. . .

De eerste regels geven algemene informatie over Nginx. De lijngebruiker www-data specificeert de gebruiker waarmee de server wordt gestart.

De pid-richtlijn specificeert waar het moet worden opgeslagen Verwerk PID's voor intern gebruik. De worker_processes regel bepaalt het aantal processen dat Nginx tegelijkertijd kan ondersteunen.

U kunt ook logboeken opgeven in dit deel van het bestand (het foutenlogboek wordt bijvoorbeeld gedefinieerd met behulp van de error_log-instructie).

Voor algemene informatie over de server volgt de evenementensectie. Het beheert de afhandeling van Nginx-verbindingen. Het wordt gevolgd door het http-blok. Voordat we verder gaan met webserverconfiguraties, moeten we begrijpen hoe het Nginx-configuratiebestand is geformatteerd.

Nginx-configuratiebestandsstructuur

Het Nginx-configuratiebestand is verdeeld in blokken.

Het eerste blok bestaat uit gebeurtenissen, gevolgd door http en de hoofdhiërarchie van configuraties begint.

De configuratiedetails van een http-blok zijn gelaagd met behulp van gesloten blokken die eigenschappen overnemen van het blok waarin ze zich bevinden. Het http-blok slaat de meeste algemene Nginx-configuraties op, die zijn onderverdeeld in serverblokken, die op hun beurt zijn onderverdeeld in locatieblokken.

Het is belangrijk om te onthouden bij het instellen van Nginx volgende regel: hoe hoger het configuratieniveau, hoe meer blokken deze configuratie erven; hoe lager het configuratieniveau, hoe ‘individueler’ het is. Dat wil zeggen: als de X-parameter in elk serverblok moet worden gebruikt, dan moet een dergelijke parameter in het http-blok worden geplaatst.

Als je het bestand goed bekijkt, zul je merken dat het veel opties bevat die het gedrag van het programma als geheel bepalen.

Om bijvoorbeeld bestandscompressie te configureren, moet u de volgende parameters instellen:

gzip aan;
gzip_disable "msie6";

Hierdoor wordt gzip-ondersteuning ingeschakeld voor het comprimeren van gegevens die naar de client worden verzonden en wordt gzip voor uitgeschakeld Internet Explorer 6 (omdat deze browser geen datacompressie ondersteunt).

Als een parameter in meerdere serverblokken een andere waarde moet hebben, dan kan zo'n parameter worden ingeschakeld hoogste niveau en negeer het vervolgens binnen de serverblokken zelf. Als gevolg hiervan zal Nginx de parameter op het laagste niveau uitvoeren.

Deze gelaagdheid van configuraties vermijdt de noodzaak om meerdere identieke bestanden te beheren. Ook als u bent vergeten parameters op te definiëren laagste niveau, zal Nginx eenvoudigweg de standaardopties implementeren.

Het http-blok in het bestand nginx.conf eindigt als volgt:

omvatten /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Dit betekent dat de server- en locatieblokken, die instellingen voor specifieke sites en URL's definiëren, buiten dit bestand worden opgeslagen.

Dit maakt een modulaire configuratiearchitectuur mogelijk waarin nieuwe bestanden kunnen worden gemaakt om nieuwe sites te bedienen. Hiermee kunt u ook vergelijkbare bestanden groeperen.

Sluit het bestand nginx.conf. Nu moet je de instellingen van individuele sites bestuderen.

Nginx virtuele blokken

Serverblokken in Nginx zijn analoog aan virtuele blokken Apache-hosts(maar voor het gemak worden ze ook wel virtuele hosts genoemd). In wezen zijn serverblokken de technische kenmerken van individuele websites die op één server worden gehost.

In de map die beschikbaar is voor sites kunt u het standaard serverblokbestand vinden dat bij de server wordt geleverd. Dit bestand bevat alle benodigde gegevens voor het onderhouden van de site.

cd-sites-beschikbaar
sudo nano standaard

root /usr/share/nginx/www;
index index.html index.htm;
servernaam localhost;
locatie/(

}
locatie /doc/ (

alias /usr/share/doc/;
auto-index aan;
sta 127.0.0.1 toe;
alles ontkennen;

Het standaardbestand is zeer goed voorzien van commentaar, maar in het bovenstaande voorbeeld zijn de opmerkingen voor de eenvoud en gemak weggelaten.

Het serverblok bevat alle instellingen die tussen de accolades zijn geplaatst:

server(
. . .
}

Dit blok wordt in het bestand nginx.conf aan het einde van het http-blok geplaatst met behulp van de include-richtlijn.

De rootrichtlijn specificeert de map waarin de inhoud van de site wordt opgeslagen. Nginx zal in deze map zoeken naar bestanden die door de gebruiker zijn opgevraagd. Standaard is dit /usr/share/nginx/www.

Let op: alle regels eindigen met een puntkomma. Dit is hoe Nginx de ene richtlijn van de andere scheidt. Als er geen puntkomma is, zal Nginx de twee richtlijnen (of meerdere richtlijnen) lezen als één richtlijn met aanvullende argumenten.

De indexrichtlijn specificeert de bestanden die als index zullen worden gebruikt. De webserver controleert de bestanden in de volgorde waarin ze worden vermeld. Als er geen pagina is opgevraagd, zal het serverblok het index.html-bestand vinden en retourneren. Als het dat bestand niet kan vinden, zal het proberen index.htm te verwerken.

server_name-richtlijn

De servernaamrichtlijn bevat een lijst met domeinnamen die door dit serverblok worden bediend. Het aantal domeinen is onbeperkt; domeinen in de lijst moeten worden gescheiden door spaties.

Een asterisk (*) aan het begin of einde van een domein specificeert een naam met een masker, waarbij de asterisk overeenkomt met een deel (of meerdere delen) van de naam. De naam *.example.com komt bijvoorbeeld overeen met de namen forum.example.com en www.animals.example.com.

Als de opgevraagde URL overeenkomt met meer dan één server_name-instructie, zal deze eerst reageren met de URL die exact overeenkomt.

Als het adres geen overeenkomsten vindt, wordt gezocht naar de langste gemaskeerde naam die eindigt met een asterisk. Als een dergelijke naam niet wordt gevonden, wordt de eerste reguliere expressie-overeenkomst geretourneerd.

Servernamen die reguliere expressies gebruiken, beginnen met een tilde (~). Helaas, dit onderwerp valt buiten het bestek van dit artikel.

Locatie blokken

De locatie/regel geeft aan dat de richtlijnen tussen haakjes van toepassing zijn op alle aangevraagde bronnen die niet overeenkomen met andere locatieblokken.

Dergelijke blokken kunnen een uri-pad bevatten (bijvoorbeeld /doc/). Om een ​​volledige match tussen locatie en uri tot stand te brengen, wordt het =-symbool gebruikt. Het ~-teken komt overeen met reguliere expressies.

De tilde maakt de hoofdlettergevoelige modus mogelijk, terwijl de tilde met een asterisk de hoofdletterongevoelige modus inschakelt.

Als het verzoek volledig overeenkomt met het locatieblok, stopt de server met zoeken en gebruikt een dergelijk blok. Als de server geen volledig overeenkomend locatieblok vindt, vergelijkt hij de URI met de parameters van de locatierichtlijnen. Nginx selecteert een blok dat de tekencombinatie ^~ gebruikt en dat overeenkomt met de URI.

Als de ^~ optie niet wordt gebruikt, zal Nginx de dichtstbijzijnde match selecteren en een reguliere expressie-zoekopdracht uitvoeren om te proberen een van de beschikbare patronen te matchen. Als hij zo'n uitdrukking vindt, gebruikt hij die. Als een dergelijke expressie niet bestaat, gebruikt de server de eerder gevonden URI-overeenkomst.

Als laatste opmerking: Nginx geeft de voorkeur aan exacte overeenkomsten. Als er geen overeenkomsten zijn, zoekt het naar een reguliere expressie en doorzoekt vervolgens de URI. Om de zoekprioriteit van een URI te wijzigen, gebruikt u de tekencombinatie ^~.

try_files richtlijn

De try_files richtlijn is erg handig hulpmiddel, dat in een bepaalde volgorde controleert op bestanden en het eerste gevonden bestand gebruikt om het verzoek te verwerken.

Hierdoor kunt u gebruiken aanvullende parameters bepaal hoe Nginx verzoeken zal behandelen.

Het standaardconfiguratiebestand heeft de regel:

try_files $uri $uri/ /index.html;

Dit betekent dat wanneer een verzoek wordt ontvangen dat wordt bediend door een locatieblok, Nginx eerst zal proberen de uri als bestand aan te bieden (dit gedrag wordt ingesteld door de variabele $uri).

Als de server geen overeenkomst vindt voor de $uri-variabele, zal hij proberen de uri als map te gebruiken.

Met behulp van een afsluitende slash controleert de server of er een map bestaat, bijvoorbeeld $uri/.

Als er geen bestand of map wordt gevonden, voert Nginx het standaardbestand uit (in in dit geval dit is index.html in de hoofdmap van het serverblok). Elke try_files-richtlijn gebruikt de laatste parameter als fallback, dus het bestand moet op het systeem bestaan.

Als de webserver geen overeenkomst vindt in de vorige parameters, kan deze een foutpagina retourneren. Gebruik hiervoor het gelijkteken en de foutcode.

Als de locatie/het blok de gevraagde bron bijvoorbeeld niet kan vinden, retourneert deze mogelijk een 404-fout in plaats van een index.html-bestand:

try_files $uri $uri/ =404;

Om dit te doen, moet u een gelijkteken plaatsen en de foutcode als laatste parameter instellen (=404).

Extra opties

Met de aliasrichtlijn kan Nginx locatieblokpagina's buiten een bepaalde map (bijvoorbeeld buiten de root) aanbieden.

Bestanden die zijn opgevraagd bij /doc/ worden bijvoorbeeld aangeboden vanuit /usr/share/doc/.

Met de autoindex on-richtlijn kunt u de weergave van Nginx-mappen voor een bepaalde locatie-richtlijn inschakelen.

De regels voor toestaan ​​en weigeren bepalen de toegang tot mappen.

Conclusie

De Nginx-webserver is rijk aan functies en zeer krachtig, maar de terminologie en opties kunnen verwarrend zijn.

Zodra u Nginx-configuraties begrijpt en leert hoe u ermee kunt werken, krijgt u alle voordelen van deze krachtige en lichtgewicht tool.

Trefwoorden: ,

Hallo! Vandaag zullen we hierover praten het juiste concept, Hoe virtuele gastheren op de nginx-webserver. We nemen de operatiekamer als voorbeeld Ubuntu-systeem. Voor andere Linux-systemen zal de opzet erg op elkaar lijken. Dit instructieartikel zal vooral interessant zijn voor beginnende webmasters en beheerders, omdat... zij hebben deze vraag het vaakst.

Een virtuele host is...

Laten we eerst een virtuele host definiëren. Dus, virtuele gastheer is verdeling van de adresruimte van de webserver, bijvoorbeeld op sitenaam, zodat u meerdere websites/applicaties op één kunt uitvoeren fysieke server. In nginx-documentatieterminologie wordt ook een virtuele host genoemd "Serverblokkeren", maar om het meer op Apache te laten lijken, zal ik het uniform noemen, omdat hun doel is hetzelfde. En nog een overeenkomst: laten we voor de eenvoud een site noemen die we gaan configureren.

Een virtuele host maken

Voor veel van de opdrachten in deze handleiding is vereist dat uw gebruiker sudoer-rechten op de VPS heeft. Als u deze niet heeft, is het helaas onwaarschijnlijk dat u virtuele hosts kunt instellen.

Voorinstelling

Nu zal ik je iets vertellen dat iedereen moet weten! Om een ​​virtuele host in nginx in te stellen, hebt u een nginx-webserver nodig die op uw machine is geïnstalleerd. Kapitein Duidelijk is bij ons! Als je nginx al hebt geïnstalleerd, kun je deze stap veilig overslaan en verder gaan volgens de instructies. Als u het om de een of andere reden nog steeds niet op uw computer heeft staan, voert u de opdracht in de console in:

Sudo apt-get install -ynginx

Optie "-y" apt-get-opdracht We voegen dit toe om geen ja-ja-ja te antwoorden op de vervelende vragen van het installatieprogramma, omdat we er zeker van zijn dat we dit pakket willen installeren en akkoord gaan met het gebruik van de schijfruimte die het in beslag neemt. Als u nog steeds niet zeker weet of u het met alles eens bent, voeg deze optie dan niet toe.

Een sitemap maken

Laten we dus, voordat we een virtuele host maken, een sitemap maken waarin we alle bestanden plaatsen waarmee onze webserver zal werken.

Het pad naar deze map in de configuratie aangemaakte gastheer zullen Documentwortel, een soort context, een isolatiepunt, waarboven je niet van buitenaf kunt stijgen zonder eerst de configuratie in te stellen en relatief ten opzichte van welke paden naar de opgevraagde bestanden worden gebouwd. Met optie "-P" bij mkdir-opdrachten we hoeven ons geen zorgen te maken over het maken van bovenliggende mappen, deze worden automatisch aangemaakt:

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

Hier gebruiken we een echt geverifieerd DNS-domein met correcte records die naar onze machine verwijzen. Om een ​​virtuele host met een niet-geregistreerd domein aan te maken, bijvoorbeeld voor lokale ontwikkeling, moet u de juiste gegevens invoeren in het bestand /etc/hosts. Meer details hierover vindt u aan het einde van het artikel.

Toegangsrechten

Nu heeft alleen de rootgebruiker rechten op onze gemaakte map. We moeten rechten op de directory geven aan de gewenste gebruiker, om er niet voortdurend mee te werken in de superuser-modus. U kunt de hieronder gebruikte "www-data"-gebruiker vervangen door een andere, maar nginx wordt standaard als deze gebruiker uitgevoerd.

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

Laten we er nu voor zorgen dat alle gebruikers onze nieuwe bestanden kunnen lezen:

Sudo chmod 755 /var/www

We bedoelen dat we werken met een VPS waarop alle gebruikers niets slechts doen of waarop alleen jij staat. Daarom kunnen we machtigingen 755 geven aan de map /var/www. Als het in uw geval onmogelijk is om alle gebruikers van het systeem rechten te geven om deze map te lezen, bestudeer dan de kwestie van het differentiëren van rechten en stel deze zelf in.

Nu bent u helemaal klaar met uw rechten!

Een pagina maken

Nu moeten we een aantal statische bestanden (HTML-pagina's, afbeeldingen, scripts, stijlen, enz.) in onze map plaatsen die onze server zal distribueren. Laten we een HTML-pagina index.htm maken, die de hoofdpagina van onze site zal zijn:

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

En voeg er wat markeringen aan toe die aan de gebruiker worden getoond:

Hoera! Je kon Virtual Host in nginx configureren!

Opslaan en afsluiten.

Een virtuele hostconfiguratie maken

We zijn op het punt gekomen om ons nieuwe virtuele hostconfiguratiebestand te maken, dat alle site-informatie zal bevatten die de webserver nodig heeft.

In nginx bevindt zich in de map /etc/nginx/sites-available een sjabloon voor de configuraties die moeten worden gemaakt. Laten we het kopiëren voor onze site:

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

Virtuele hostconfiguratie

Open nieuw bestand configuratie en u ziet alle benodigde informatie die u moet invullen.

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

We moeten wijzigingen aanbrengen in de huidige configuratie. Het resultaat voor ons eenvoudige geval zou ongeveer zo moeten zijn:

Server ( luister 80; root /var/www/mijnsite.ru/public_html; index index.html index.htm; servernaam mijnsite.ru www.mijnsite.ru; )

Hier moet u het pad naar de map met sitestatistieken en de naam van de server waarmee u toegang krijgt tot uw site correct opgeven. Als u het pad onjuist of helemaal niet opgeeft, kunt u de virtuele host niet configureren. Als servernaam kunt u ook een IP-adres of meerdere namen opgeven, gescheiden door een spatie, waarmee de host toegankelijk zal zijn, zoals wij deden.

Dat is alles, we zijn klaar met dit bestand. Sla het op en sluit het.

Virtuele hostactivering

Nginx heeft mappen die beschikbaar zijn voor sites en mappen die voor sites zijn ingeschakeld. De eerste slaat de configuraties op van ALLE virtuele hosts die zich op een bepaalde server kunnen bevinden, en de directory met sites bevat symbolische links naar actieve. Niemand verbiedt het plaatsen van het originele configuratiebestand in sites-enabled in plaats van in een link, maar dit zal minder handig zijn, omdat als het nodig is om het uit te schakelen, moet je het bestand verwijderen (dan zal het problematisch zijn om het weer in te schakelen) of het naar een andere map verplaatsen (dan moeten we onthouden waar we het naartoe hebben verplaatst). Het is veel gemakkelijker om een ​​symbolische link te laten crashen!

Daarom moeten we, om onze virtuele host te activeren, een symbolische link creëren tussen de directory die beschikbaar is voor sites, waar ons configuratiebestand zich bevindt, en sites die ingeschakeld zijn. Apache heeft het hiervoor speciaal elftal a2ensite. Er bestaat niet zo'n commando in nginx, dus laten we het volgende doen:

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

Om "conflicterende servernaamfouten" te voorkomen en er zeker van te zijn dat uw site wordt weergegeven noodzakelijke informatie, kunt u de standaardhost verwijderen uit de lijst met actieve hosts:

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

Opnieuw opstarten

We hebben al heel wat stappen doorlopen en vrijwel alles ingericht. Laten we nu onze webserver opnieuw opstarten zodat deze de nieuwe configuratie toepast, maar daarvoor is het een goede gewoonte om te controleren of alles met de configuratie correct is en dat nginx het correct begrijpt. Om dit te doen, moet u nginx diagnostics uitvoeren met de volgende opdracht:

Sudo nginx -t

Een dergelijke controle is uiterst noodzakelijk bij het configureren op productieservers, zodat niet blijkt dat we het nginx restart-commando hebben gebeld, maar door een onjuiste configuratie niet kon starten en al onze virtuele hosts niet reageren.

Als het antwoord dat u heeft ontvangen er ongeveer zo uitziet:

Nginx: de configuratie bestand /etc/nginx/nginx.conf syntaxis is ok nginx: configuratiebestand /etc/nginx/nginx.conf test is succesvol

Dan is alles in orde en kun je de server veilig opnieuw opstarten met het commando:

Sudo-service nginx opnieuw opstarten

Anders moet u naar het hostconfiguratiebestand kijken. Daar gaf je aan dat er iets mis was.

Lokale hosts instellen

Als u een IP-adres als servernaam hebt opgegeven, kunt u deze stap overslaan, omdat U hoeft geen lokale host te configureren; uw virtuele host werkt zonder deze. Maar als u met uw virtuele host wilt werken zonder een echte domeinnaam, kunt u localhosts op uw machine instellen. Zoals ik hierboven al zei, is dit erg handig, bijvoorbeeld tijdens de ontwikkeling. Ik kan mysite.dev maken, en er zal een lokale onstabiele versie van de site op draaien. Voor MacOS- en Linux-systemen moet u de volgende opdracht uitvoeren:

Sudo nano /etc/hosts

Als u onder Windows werkt, moet het bestand van lokale hosts zich ongeveer op dit pad bevinden: C:\Windows\System32\drivers\etc\hosts.

Voeg een vermelding over de nieuwe lokale host toe aan het bestand. In ons geval moeten we twee records toevoegen, omdat in servernaam hebben we twee domeinen opgegeven.

12.34.56.789 mijnsite.ru 12.34.56.789 www.mijnsite.ru

Totdat dit bericht wordt verwijderd, zullen verzoeken aan mysite.ru informatie ontvangen over deze gastheer uit dit bestand en wordt u doorgestuurd naar uw externe server. Als de server lokaal wordt geïmplementeerd, moet u “127.0.0.1” schrijven in plaats van “12.34.56.789”.

Om toekomstige problemen te voorkomen, is het een goede gewoonte om hostvermeldingen te verwijderen nadat ze hun doel hebben bereikt.

Resultaten

Nu kunnen we de resultaten van ons werk zien! Voer het adres http://mysite.ru of http://www.mysite.ru in de browser in en bewonder de creatie die we hebben gemaakt startpagina th van index.htm. Beide adressen moeten onze startpagina weergeven. Dat is het! Onze virtuele host werkt prima.

Een speciale op Nginx gebaseerde webserver is een geweldige manier om de prestaties van websites te verbeteren. Het heeft eenvoudigweg geen gelijke in de snelheid van het verwerken van statische inhoud: het kan gemakkelijk enkele duizenden weerstaan gelijktijdige verbindingen en kan eenvoudig worden geoptimaliseerd en aangepast aan elke configuratie. Echter? Nginx fungeert als front-end voor Apache en blijkt het meest kwetsbare punt van de hele webinfrastructuur te zijn, dus er moet speciale aandacht worden besteed aan nginx-beveiliging.

Dit artikel is een soort educatief programma, of, als je wilt, een samenvatting van alle technieken om de nginx-beveiliging te vergroten. Het zal geen theorie, een beschrijving van de basisprincipes van het opzetten van een webserver en andere pluisjes bevatten. In plaats daarvan ontvangt u een uitgebreide praktisch materiaal, waarin alle basisstappen worden beschreven die moeten worden genomen om een ​​echt veilige webserver te hebben.

Installatie

Het nginx-pakket is in vooraf gecompileerde vorm beschikbaar voor elke distributie. Door de server echter zelf te bouwen, kunt u deze compacter en betrouwbaarder maken, en krijgt u ook de mogelijkheid om de begroetingsregel van de webserver te veranderen om dwaze scriptkinderen te ontmoedigen.

Wijzig de begroetingsregel van de webserver

Download de nginx-bronnen, open het bestand src/http/ngx_http_header_filter_module.c en zoek de volgende twee regels:

static char ngx_http_server_string = "Server: nginx" CRLF;
static char ngx_http_server_full_string = "Server: " NGINX_VER CRLF;

Vervang ze door iets als dit:

static char ngx_http_server_string = "Server: ][ Webserver"CRLF;
static char ngx_http_server_full_string = "Server: ][ Webserver" CRLF;

Verwijder alle nginx-modules die u niet gebruikt

Sommige nginx-modules maken tijdens het compileren rechtstreeks verbinding met de webserver, en elk daarvan is vol potentieel gevaar. Misschien wordt er in de toekomst een kwetsbaarheid in een van hen gevonden en loopt uw ​​server gevaar. Uitschakelen onnodige modules, kunt u het risico dat een dergelijke situatie zich voordoet aanzienlijk verminderen.

Bouw met behulp van de volgende opdrachten:

# ./configure --zonder-http_autoindex_module --zonder-http_ssi_module
#maken
#maak installatie

Op deze manier krijg je nginx met vooraf uitgeschakelde (en in de meeste gevallen nutteloze) SSI (Server Side Inclusief) en Autoindex-modules. Om erachter te komen welke modules veilig van de webserver kunnen worden verwijderd, voert u het configuratiescript uit met de vlag '-help'.

Laten we nginx.conf ontleden

Na nginx-installaties geconfigureerd moeten worden. Er stond al materiaal dat dit proces beschrijft op de pagina's van het tijdschrift, maar we zullen bij het onderwerp van het artikel blijven en praten over manieren om de serverbeveiliging te vergroten.

Schakel het weergeven van de serverversie op alle foutpagina's uit

Voeg de regel “server_tokens off” toe aan het nginx.conf-bestand. Dit dwingt nginx om informatie over het type en de versie van de webserver te verbergen op pagina's die zijn gegenereerd als reactie op ongeldig verzoek cliënt.

Zorg voor bescherming tegen stackverstoring

Voeg de volgende regels toe aan de serversectie:

# vi /etc/nginx/nginx.conf

# Maximale grootte buffer voor het opslaan van de hoofdtekst van het clientverzoek
client_body_buffer_size 1K;
# Maximale buffergrootte voor het opslaan van headers van clientverzoeken
client_header_buffer_size 1k;
# De maximale grootte van de hoofdtekst van het clientverzoek, gespecificeerd in het headerveld Content-Length. Als de server bestandsuploads moet ondersteunen, moet deze waarde worden verhoogd
client_max_body_size 1k;
# Aantal en grootte van buffers voor het lezen van de header van grote klantverzoeken
grote_client_header_buffers 2 1k;

Besteed aandacht aan de richtlijn large_client_header_buffers. Standaard wijst nginx vier buffers toe om de URI-string op te slaan, waarvan de grootte gelijk is aan de grootte van een geheugenpagina (voor x86 is dit 4 KB). Buffers worden vrijgegeven telkens wanneer de verbinding na het verwerken van een verzoek in de keep-alive-status komt. Twee buffers van 1 KB kunnen URI's opslaan die slechts 2 KB lang zijn, wat bots en DoS-aanvallen helpt bestrijden.

Voeg de volgende regels toe om de prestaties te verbeteren:

# vi /etc/nginx/nginx.conf

# Time-out tijdens het lezen van de hoofdtekst van het klantverzoek
client_body_time-out 10;
# Time-out tijdens het lezen van de header van het clientverzoek
client_header_time-out 10;
# Time-out waarna de keep-alive-verbinding met de client niet vanaf de serverzijde wordt gesloten
keepalive_timeout 5 5;
# Time-out bij het verzenden van een antwoord naar de client
verzend_time-out 10;

Beheer het aantal gelijktijdige verbindingen

Om de webserver te beschermen tegen overbelasting en pogingen om een ​​DoS-aanval uit te voeren, voegt u de volgende regels toe aan de configuratie:

# vi /etc/nginx/nginx.conf

# We beschrijven de zone (slimits) waarin sessiestatussen worden opgeslagen. Een zone van 1 MB kan ongeveer 32.000 toestanden opslaan, we stellen de grootte ervan in op 5 MB
limit_zone slimits $binary_remote_addr 5m;
# Stel het maximale aantal gelijktijdige verbindingen voor één sessie in. In wezen specificeert dit aantal het maximale aantal verbindingen vanaf één IP
limit_conn slimits 5;

De eerste richtlijn moet in de HTTP-sectie staan, de tweede in de locatiesectie. Wanneer het aantal verbindingen de limieten overschrijdt, ontvangt de klant een bericht “Service niet beschikbaar” met code 503.

Sta alleen verbindingen met uw domein toe

Hackers kunnen bots gebruiken om subnetten te scannen en kwetsbare webservers te vinden. Normaal gesproken doorkruisen bots eenvoudigweg IP-adresbereiken op zoek naar open 80 poorten en sturen ze een HEAD-verzoek om informatie over de webserver (of startpagina) te verkrijgen. U kunt een dergelijke scan eenvoudig voorkomen door de toegang tot de server op IP-adres te verbieden (voeg toe aan de locatie-subsectie):

# vi /etc/nginx/nginx.conf

if ($host !~ ^(host.com|www.host.com)$) (
retour 444;
}

Beperk het aantal beschikbare methoden voor toegang tot de webserver

Sommige bots gebruiken verschillende methoden toegang krijgen tot de server om te proberen het type en/of de penetratie ervan te bepalen, maar in RFC-document 2616 wordt duidelijk gesteld dat de webserver deze niet allemaal hoeft te implementeren, en dat niet-ondersteunde methoden eenvoudigweg niet kunnen worden verwerkt. Tegenwoordig zijn alleen de methoden GET (documentverzoek), HEAD (serverheaderverzoek) en POST (documentpublicatieverzoek) nog in gebruik, dus alle andere kunnen pijnloos worden uitgeschakeld door de volgende regels in het servergedeelte van het configuratiebestand te plaatsen:

# vi /etc/nginx/nginx.conf

if ($request_method !~ ^(GET|HEAD|POST)$) (
retour 444;
}

Schakel de bots uit

Een andere manier om bots, scanners en andere boze geesten te blokkeren is gebaseerd op het bepalen van het type client (user-agent). Het is niet erg effectief, omdat de meeste bots zich op volledig legitieme browsers richten, maar in sommige gevallen blijft het nuttig:

# vi /etc/nginx/nginx.conf

# Blokkeer downloadmanagers
if ($http_user_agent ~* LWP::Simple|BBBike|wget) (
retour 403;
}
# Blokkeer sommige soorten bots
if ($http_user_agent ~* msnbot|scrapbot) (
retour 403;
}

Blokkeer verwijzerspam

Als uw site weblogs publiceert in een openbaar toegankelijke vorm, kunt u gemakkelijk het slachtoffer worden van Referrer-spam (wanneer spambots contact opnemen met uw server, waarbij de referrer in de header wordt aangegeven: het adres van de geadverteerde site). Dit soort spam kan de SEO-beoordelingen van een webpagina gemakkelijk verpesten, dus deze moet absoluut worden geblokkeerd. Eén manier om dit te doen is door de meest voorkomende woorden op de adressen van geadverteerde sites op de zwarte lijst te zetten.

# vi /etc/nginx/nginx.conf

# Serversectie
if ($http_referer ~* (babes|te koop|meisje|sieraden|love|nudit|organic|poker|porn|sex|tiener))
{
retour 403;
}

Hotlink blokkeren

Een hotlink is het opnemen van een afbeelding (of andere inhoud) van een andere site op een pagina. In wezen is dit diefstal, omdat de afbeelding waaraan u meer dan een uur van uw vrije tijd hebt besteed, niet alleen vrijelijk door anderen wordt gebruikt, maar ook uw webserver belast zonder dat er bezoekers naar toe komen. Om hotlinks tegen te gaan, volstaat het om ervoor te zorgen dat afbeeldingen alleen naar de klant worden verzonden als hij erom heeft gevraagd terwijl hij al op de site was (met andere woorden: de header van het verwijzende verzoek moet de naam van uw site bevatten). Voeg de volgende regels toe aan het servergedeelte van het nginx.conf-configuratiebestand (host.com is het adres van uw website):

# vi /etc/nginx/nginx.conf

locatie /afbeeldingen/ (
valid_referers geen geblokkeerde www.host.com host.com;
if ($invalid_referer) (
retour 403;
}
}

Als alternatief kunt u de server zo configureren dat deze een speciale banner retourneert met een bericht over diefstal in plaats van de gevraagde afbeelding. Om dit te doen, vervangt u de regel “return 403” door de regel:

herschrijf ^/images/uploads.*\.(gif|jpg|jpeg|png)$ http://www.host.com/banned.jpg laatste

Bescherm belangrijke mappen tegen vreemden

Net als elke andere webserver kunt u met nginx de toegang tot mappen regelen op basis van IP-adressen en wachtwoorden. Deze functie kan worden gebruikt om bepaalde delen van de site te blokkeren nieuwsgierige ogen. Om bijvoorbeeld de URI te verwijderen buitenwereld:

# vi /etc/nginx/nginx.conf

locatie /uploads/ (
# Sta alleen toegang toe tot machines op het lokale netwerk
sta 192.168.1.0/24 toe;
# Laten we alle anderen vermoorden
alles ontkennen;
}

Nu hebben alleen lokale netwerkgebruikers toegang tot documenten in de uploadmap. Om een ​​wachtwoord in te stellen zul je complexere stappen moeten doorlopen. Eerst moet je een wachtwoordbestand maken dat privé is voor nginx en de benodigde gebruikers eraan toevoegen (laten we bijvoorbeeld de admin-gebruiker toevoegen):

# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd beheerder

# vi /etc/nginx/nginx.conf

locatie /beheerder/ (
auth_basic "Beperkt";
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}

Nieuwe gebruikers kunnen worden toegevoegd met behulp van de volgende opdracht:

# htpasswd -s /etc/nginx/.htpasswd/passwd gebruiker

Gebruik SSL

Als uw site werkt met privégebruikersgegevens, zoals creditcardnummers, wachtwoorden van andere services, of toegang biedt tot andere belangrijke informatie, wat zou kunnen worden lekkernij voor derden: zorg voor encryptie. Nginx werkt goed met SSL en deze functie mag niet worden verwaarloosd.

Volg een paar eenvoudige stappen om SSL-codering in te stellen met nginx. Eerst moet u een certificaat maken met behulp van de volgende reeks opdrachten:

# cd /etc/nginx
# openssl genrsa -des3 -out server.key 1024
# openssl req -new -key server.key -out server.csr
# cp server.key server.key.org
# openssl rsa -in server.key.org -uit server.key
# openssl x509 -req -dagen 365 -in server.csr -signkey server.key -out server.crt

Beschrijf vervolgens het certificaat in het nginx-configuratiebestand:

# vi /etc/nginx/nginx.conf

server(
servernaam host.com;
luister 443;
ssl aan;
ssl_certificaat /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
access_log /etc/nginx/logs/ssl.access.log;
error_log /etc/nginx/logs/ssl.error.log;
}

Hierna kunt u de webserver opnieuw opstarten:

# /etc/init.d/nginx herladen

Zonder ondersteuning van de website zelf is het uiteraard zinloos om dit te doen.

Andere manieren

Stel de juiste waarden in voor systeemvariabelen

Open het bestand /etc/sysctl.conf en plaats de volgende regels daarin:

# vi /etc/sysctl.conf

# Bescherming tegen smurfaanvallen
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Bescherming tegen ongeldige ICMP-berichten
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Bescherming tegen SYN-overstroming
net.ipv4.tcp_syncookies = 1
# Schakel bronroutering uit
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Bescherming tegen spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Wij zijn geen router
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Schakel ExecShield in
kernel.exec-schild = 1
kernel.randomize_va_space = 1
# Uitbreiding van het bereik van beschikbare poorten
net.ipv4.ip_local_port_range = 2000 65000
# Vergroot de maximale grootte van TCP-buffers
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1

Plaats de hoofdmap van de webserver op een speciale partitie

Door de hoofdmap van de webserver in een speciale partitie te plaatsen en de plaatsing ervan te verbieden uitvoerbare bestanden en apparaatbestanden beschermt u de rest van het systeem tegen iedereen die toegang kan krijgen tot de root van de webserver. In dit geval zou de vermelding in het bestand /etc/fstab er ongeveer zo uit moeten zien:

/dev/sda5 /nginx ext4 standaardwaarden,nosuid,noexec,nodev 1 2

Plaats nginx in een chroot/jail-omgeving

Met elk modern *nix-systeem kunt u de applicatie vergrendelen in een geïsoleerde uitvoeringsomgeving. In Linux kun je hiervoor KVM-, Xen-, OpenVZ- en VServer-technologieën gebruiken, in FreeBSD - Jail, in Solaris - Zones. Als geen van deze technologieën beschikbaar is, kun je nginx in een klassieke chroot plaatsen, die, hoewel veel kwetsbaarder, de meeste hackers kan tegenhouden.

Installeer SELinux-regels om nginx te beschermen

Een goed alternatief voor geïsoleerde uitvoeringsomgevingen zijn lokale systemen tools voor inbraakdetectie en -preventie zoals SELinux of AppArmor. Als ze correct zijn geconfigureerd, kunnen ze pogingen om de webserver te hacken voorkomen. Standaard is geen van deze geconfigureerd om in combinatie met nginx te werken, binnen het raamwerk van het project SELinuxNginx(http://sf.net/projects/selinuxnginx/) regels voor SELinux zijn gemaakt die iedereen kan gebruiken. Het enige dat overblijft is het downloaden en installeren van:

# tar -zxvf se-ngix_1_0_10.tar.gz
# cd se-ngix_1_0_10/nginx
#maken
# /usr/sbin/semodule -i nginx.pp

Firewall-opstelling

Normaal gesproken wordt nginx geïnstalleerd op speciale machines die klaar zijn voor hoge belasting, dus het is vaak de enige netwerkservice die op de server draait. Om de server te beveiligen, volstaat het om een ​​compleet klein setje regels die de poorten 80, 110 en 143 openen (als nginx natuurlijk ook zou moeten werken als een IMAP/POP3-proxy) en al het andere afsluiten voor de buitenwereld.

Beperk het aantal verbindingen met behulp van een firewall

Voor een weinig belaste website is het een goed idee om het aantal verbindingspogingen vanaf één IP-adres per minuut te beperken. Dit kan u beschermen tegen bepaalde soorten DoS-aanvallen en brute kracht. Op Linux kan dit gedaan worden met behulp van de standaard iptables/netfilter statusmodule:

# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-M staat --staat NIEUW -m recent --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NIEUW -m recent --update \
--seconden 60 --hitaantal 15 -j DROP

De regels verlagen de limiet op het aantal verbindingen van één IP per minuut naar 15. Hetzelfde kan worden gedaan met pf:

# vi /etc/pf.conf

webserver_ip = "1.1.1.1"
tafel volharden
blokkeer snel vanaf
geef $ext_if proto tcp door aan $webserver_ip \
poort www vlaggen S/SA status behouden \
(max-src-conn 100, max-src-conn-snelheid 15/60,\
overbelasting doorspoelen)

Naast de limiet op het aantal opeenvolgende verbindingen (15 per minuut), stelt deze regel een extra limiet op het aantal gelijktijdige verbindingen gelijk aan 100.

PHP-installatie

Als je nginx gebruikt in combinatie met PHP, vergeet dan niet om het ook te configureren. Zo zou het configuratiebestand /etc/php/php.ini van de beveiligde server eruit moeten zien:

# vi /etc/php/php.ini

# Schakel gevaarlijke functies uit
uitschakelen_functies = phpinfo, systeem, mail, exec
# Maximale uitvoeringstijd van scripts
max_execution_time = 30
# Maximale tijd die het script kan besteden aan het verwerken van aanvraaggegevens
max_invoer_tijd = 60
# Maximale hoeveelheid geheugen toegewezen aan elk script
geheugen_limiet = 8M
# Maximale gegevensgrootte die naar het script wordt verzonden met behulp van de POST-methode
post_max_size = 8M
# Maximale grootte van geüploade bestanden
upload_max_filesize = 2M
# Toon geen PHP-scriptfouten aan gebruikers
display_errors = Uit
# Schakel Veilige modus in
safe_mode = Aan
# Schakel SQL Veilige modus in
sql.safe_mode = Aan
# Sta toe dat externe opdrachten alleen in deze map worden uitgevoerd
safe_mode_exec_dir = /pad/naar/beschermd/map
# Bescherm tegen informatielekken over PHP
bloot_php = Uit
# Wij houden logboeken bij
log_errors = Aan
# Voorkom het openen van externe bestanden
allow_url_fopen = Uit

Conclusies

Door de aanbevelingen uit dit artikel toe te passen, krijgt u een veel veiligere webserver. Maar houd er rekening mee dat niet alle technieken geschikt zijn voor uw configuratie. Brute force-beveiliging, gebaseerd op het verkleinen van de grootte van buffers die door nginx zijn toegewezen voor het verwerken van clientverzoeken, kan bijvoorbeeld leiden tot een afname van de prestaties en in sommige gevallen tot fouten bij het verwerken van verzoeken. Het beperken van het aantal verbindingen zal ernstige gevolgen hebben voor de prestaties van zelfs een matig geladen website, maar zal gunstig zijn als de pagina weinig verkeer heeft. Controleer altijd hoe de wijzigingen die u aanbrengt de prestaties en de algehele gezondheid van de webpagina beïnvloeden.

Over de held van de dag

Nginx is een van de krachtigste en populairste webservers ter wereld. Volgens Netcraft wordt het gebruikt om meer dan 12 miljoen websites over de hele wereld te ondersteunen, waaronder mastodons als Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Librusec en Taba.ru. Slimme architectuur, gebaseerd op multiplexverbindingen met behulp van systeemoproepen select, epoll (Linux), kqueue (FreeBSD) en een geheugenbeheermechanisme gebaseerd op pools (kleine buffers van 1 tot 16 KB), zorgen ervoor dat nginx zelfs onder zeer hoge belasting niet doorzakt, en is bestand tegen meer dan 10.000 gelijktijdige verbindingen (de zogenaamde C10K-probleem). Oorspronkelijk geschreven door Igor Sysoev voor Rambler en geopend in 2004 onder een BSD-achtige licentie.

Vandaag kijken we naar het opzetten van een virtuele host die een site met statische inhoud bedient. Dat wil zeggen, geen CGI, Perl, PHP of wat dan ook. Alle in het artikel genoemde voorbeelden verwijzen naar en zijn getest Debian Linux 5,0 Lenny. Eigenaren van andere systemen mogen hierdoor op geen enkele manier in verwarring worden gebracht, aangezien alleen de paden naar de configuratiebestanden kunnen veranderen, terwijl de inhoud ervan van toepassing is op elk systeem waarop Nginx draait.

Methode voor het opslaan van configuratiebestanden

Zoals je je misschien nog herinnert uit het vorige artikel, in de bestanden Nginx-configuraties U kunt de richtlijn gebruiken erbij betrekken, die de inhoud van andere bestanden in het hoofdconfiguratiebestand kan bevatten. Deze aanpak biedt beheerders extra flexibiliteit bij de serverconfiguratie, wat vaak tijd en moeite bespaart.

Als je het gemerkt hebt, in het hoofdconfiguratiebestand /etc/nginx/nginx.conf geen woord over configuratie virtuele servers. Er wordt helemaal niets gezegd over waar de root van het serverdocument zich bevindt, op welke poort de server moet luisteren naar inkomende verbindingen, enz. De voorlaatste regel in het configuratiebestand is echter de volgende:

Inclusief /etc/nginx/sites-enabled/*;

Dat wil zeggen, uit de catalogus /etc/nginx/sites-enabled de inhoud van alle bestanden wordt gelezen en toegepast op de huidige serverconfiguratie. Als u in de genoemde map kijkt, ziet u daar één bestand standaard, wat een symbolische link naar het bestand is /etc/nginx/sites-available/default. Ook heel handige aanpak: je moet plotseling een virtuele host uitschakelen, je verwijdert eenvoudigweg de symbolische link en je hoeft het bestand niet heen en weer te verplaatsen.

Een virtuele server creëren

Voor de “zuiverheid van het experiment” stel ik voor om de symbolische link die bij de distributie wordt geleverd, te verwijderen /etc/nginx/sites-enabled/default en begin, om zo te zeggen, met een schone lei.

Maak een bestand /etc/nginx/sites-available/myvhost met de volgende inhoud:

Server ( luister 80; servernaam mijnvhost; access_log /var/log/nginx/myvhost.log; locatie / ( root /var/www/myvhost/; index index.htm index.html; autoindex aan; ) )

Dit is zichzelf eenvoudige configuratie virtuele server in Nginx. Nu over de parameters die in volgorde worden gebruikt.

Eerste optie server, gevolgd door beugel, begint een nieuw gedeelte. Het staat in de secties server en beschrijft de configuraties van alle virtuele servers in Nginx.

Optie luisteren we vertellen Nginx het poortnummer waarop onze virtuele server naar verbindingen moet luisteren. De standaardwaarde van deze optie is 80 , en in het gegeven voorbeeld is de waarde alleen voor de duidelijkheid gedefinieerd. Met deze optie kunt u ook niet alleen het poortnummer opgeven, maar ook het adres van de netwerkinterface waaraan u wilt “koppelen” deze server. In de volgende twee voorbeelden 'hangt' de server bijvoorbeeld op alle TCP/IP-interfaces die beschikbaar zijn in het systeem, op poort 8080:

Luister 8080 luister *:8080

In het volgende voorbeeld wordt een virtuele server gekoppeld aan een specifiek netwerkinterface met IP-adres 192.168.0.1, luisterend naar inkomende verbindingen op poort 8080:

Luister 192.168.0.1:8080

Optie servernaam definieert de virtuele servernaam die wordt gebruikt wanneer de webserver de HTTP-header parseert Gastheer, afkomstig van de klant. Het is deze optie die de configuratie van op naam gebaseerde virtuele hosts implementeert. Zo zal een fragment van de configuratie van twee virtuele hosts op één server er bijvoorbeeld zo uitzien:

Server ( ... luister 80; servernaam voorbeeld-1.com ... ) server ( ... luister 80; servernaam voorbeeld-2.com ... )

De optie servernaam kan meer dan één parameter hebben, zodat u aliassen voor uw server kunt definiëren, bijvoorbeeld:

Servernaam voorbeeld-1.com www.voorbeeld-1.com www1.voorbeeld-1.com

U kunt ook het sterretje gebruiken om een ​​willekeurige reeks tekens in de servernaam te vervangen:

Servernaam voorbeeld-1.com *.voorbeeld-1.com

Met parameter toegang_log we ontmoetten elkaar. De waarde van deze parameter bepaalt de locatie en het formaat van het logbestand voor toegang tot de serverinhoud.

Optie locatie verdient aandacht in een aparte opmerking, dus in dit artikel zullen we slechts in beperkte mate ingaan op de betekenis en mogelijkheden ervan, voor zover voldoende voor het configureren van een statische webserver. Met behulp van de locatieoptie kunt u het gedrag van de server aanpassen, afhankelijk van de URI-waarde die u van de client ontvangt. De sectie dus server kan verschillende geneste locatiesecties bevatten die de configuratie beschrijven op basis van een deel van de URI. In het voorbeeld aan het begin van het artikel is slechts één locatie gedefinieerd, die overeenkomt met elke URI die van de client wordt ontvangen, aangezien elke URI een slash-teken bevat.

Als u er bijvoorbeeld voor moet zorgen dat wanneer een subtekenreeks in een URI wordt gevonden /afbeeldingen/, Nginx heeft geen toegang gekregen tot de hoofdmap van de server, maar heeft gezocht naar bestanden in de map /mnt/server2/var/www/images/, kunt u de volgende twee locaties definiëren:

Locatie / ( root /var/www/myvhost/; ) locatie /images/ ( root /mnt/server2/var/www/; )

In de bovenstaande locatievoorbeelden wordt gezocht naar een subtekenreeks binnen een URI-tekenreeks. Dat wil zeggen: de subtekenreeks /afbeeldingen/ zal worden gevonden als in http://server/afbeeldingen/, En http://server/mijn/images/. Als je Nginx nodig hebt om te zoeken nauwkeurig correspondentie, hiervoor kunt u het symbool gebruiken "=" , waardoor de server op deze manier moet zoeken:

Locatie = /images/ ( root /mnt/server2/var/www/; )

Ook kunt u de substring definiëren waarmee u dit moet doen beginnen URI. Hiervoor wordt een constructie van twee symbolen gebruikt "^~" :

Locatie ^~ /afbeeldingen/ ( ... )

Reguliere expressies worden uiteraard ondersteund en bieden meer flexibiliteit bij het beschrijven van de locatie. De volgende locatie komt overeen met alle URI's die aan het einde namen bevatten grafische bestanden(niet hoofdlettergevoelig):

Locatie ~* \.(gif|jpg|jpeg)$ ( ... )

Hetzelfde, maar hoofdlettergevoelig:

Locatie ~ \.(gif|jpg|jpeg)$ ( ... )

En een beetje over de volgorde van verwerking van locatieopties in Nginx. In tegenstelling tot wat velen op het eerste gezicht denken, maakt het helemaal niet uit (behalve voor reguliere expressies natuurlijk) in welke volgorde de locaties in het configuratiebestand zijn gedefinieerd. Hoe u ze ook verwisselt, het resultaat zal hetzelfde zijn. Bij het zoeken naar de gewenste locatie volgt Nginx het volgende algoritme:

1. Zoekt naar een regel die begint met "=" . Zodra een dergelijke regel wordt gevonden, wordt het verdere zoeken stopgezet.
2. Er wordt gezocht naar “reguliere” regels, d.w.z. niet-reguliere expressies. Als er onder hen een regel wordt gevonden die begint met "^~" , wordt verder zoeken gestopt.
3. Reguliere expressies worden verwerkt in de volgorde waarin ze in het configuratiebestand verschijnen.
4. Indien er een match wordt gevonden volgens punt 3, dan wordt deze locatie gebruikt, anders wordt de locatie gevonden in punt 2 gebruikt.

Optie wortel de waarde ervan definieert het pad naar de hoofdmap van de virtuele serverdocumenten op het bestandssysteem.

De optie gebruiken index u kunt de namen definiëren van de indexdocumentbestanden die Nginx aan klanten zal "geven" als toegang tot de map is gevraagd. Als er geen dergelijk bestand in de map staat en de optie voor deze locatie is uitgeschakeld autoindex, waarna de client als reactie een HTTP-code ontvangt 403 , wat aangeeft dat de toegang is geweigerd.

Optie autoindex configureert het gedrag van Nginx als het gevraagde indexbestand niet in de map wordt gevonden. Als de waarde van de autoindex-optie, zoals in het bovenstaande voorbeeld, is "op", dan zal de server de inhoud van de directory terugsturen naar de client in de vorm van een HTML-lijst met bestanden. Autoindex is standaard uitgeschakeld, dus wees er voorzichtig mee en zorg ervoor dat u niet per ongeluk kritieke informatie plaatst die iedereen kan zien.

De server opnieuw opstarten

Nu het configuratiebestand klaar is, moet u er vanuit de directory een symbolische link naar maken /etc/nginx/sites-enabled/ zodat wanneer Nginx opnieuw wordt opgestart, het de inhoud ervan in de configuratie zal opnemen:

# ln -s /etc/nginx/sites-available/myvhost /etc/nginx/sites-enabled/myvhost

# mkdir /var/www/myvhost

Het enige dat overblijft is het opnieuw opstarten van de server:

# /etc/init.d/nginx opnieuw opstarten

En als alle instellingen zonder fouten zijn voltooid, kunt u via een webbrowser verbinding maken met uw eerste virtuele Nginx-server en een lege index van bestanden in de hoofdmap van de server bekijken. Probeer een paar statische HTML-bestanden in de map te plaatsen /var/www/myshost en open ze vervolgens vanuit uw browser.

In het volgende artikel zullen we kijken naar de SSL-serverconfiguratie in Nginx.

Het onderwerp van het correct configureren van nginx is erg uitgebreid, en ik ben bang dat het niet past in het raamwerk van één artikel over Habré. In deze tekst probeerde ik erover te praten algemene structuur config, wellicht komen er later meer interessante kleine dingen en bijzonderheden. :)

Een goed startpunt voor het opzetten van nginx is de configuratie die bij de distributie wordt geleverd, maar veel van de mogelijkheden van deze server worden daarin niet eens genoemd. Veel meer gedetailleerd voorbeeld beschikbaar op de website van Igor Sysoev: sysoev.ru/nginx/docs/example.html. Laten we echter beter proberen onze configuratie helemaal opnieuw op te bouwen, met bridge en dichteressen. :)

Laten we beginnen met algemene instellingen. Eerst geven we de gebruiker aan namens wie nginx zal draaien (het is slecht om als root te werken, iedereen weet het :))

Laten we nu nginx vertellen hoeveel werkprocessen er moeten worden gegenereerd. Gebruikelijk, goede keuze er is een aantal processen gelijk aan het aantal processorkernen op uw server, maar het is de moeite waard om met deze instelling te experimenteren. Indien verwacht hoge belasting naar een harde schijf, kunt u voor elke fysieke harde schijf één proces uitvoeren, aangezien al het werk nog steeds wordt beperkt door de prestaties ervan.

Werknemersprocessen 2;

Laten we verduidelijken waar we foutenlogboeken moeten schrijven. Vervolgens kan deze parameter voor individuele virtuele servers worden overschreven, zodat alleen “algemene” fouten, bijvoorbeeld gerelateerd aan het opstarten van de server, in dit logboek verschijnen.

Error_log /spool/logs/nginx/nginx.error_log kennisgeving; # Het meldingsniveau "kennisgeving" kan uiteraard worden gewijzigd

Nu komt het zeer interessante gedeelte ‘evenementen’. Daarin kunt u het maximale aantal verbindingen instellen dat één werkproces tegelijkertijd zal verwerken, en de methode die zal worden gebruikt om asynchrone meldingen te ontvangen over gebeurtenissen in het besturingssysteem. Uiteraard kunt u alleen die methoden selecteren die beschikbaar zijn op uw besturingssysteem en zijn opgenomen tijdens de compilatie.

Deze instellingen kunnen een aanzienlijke impact hebben op de prestaties van uw server. Ze moeten afzonderlijk worden geselecteerd, afhankelijk van het besturingssysteem en de hardware. Ik kan slechts een paar algemene regels geven.

Modules voor het werken met gebeurtenissen:
- select en poll zijn meestal langzamer en belasten de processor behoorlijk zwaar, maar ze zijn bijna overal beschikbaar en werken bijna altijd;
- kqueue en epoll - efficiënter, maar alleen beschikbaar op respectievelijk FreeBSD en Linux 2.6;
- rtsig - mooi effectieve methode, en wordt zelfs ondersteund door zeer oude Linux-versies, maar kan problemen veroorzaken wanneer groot aantal verbindingen;
- /dev/poll - voor zover ik weet werkt het in wat exotischere systemen, zoals Solaris, en is daar behoorlijk effectief;

worker_connections-parameter:
- Het totale maximale aantal klanten dat wordt bediend, is gelijk aan worker_processes * worker_connections;
- Soms kunnen ze inwerken positieve kant zelfs de meest extreme waarden, zoals 128 processen, 128 verbindingen per proces of 1 proces, maar met de parameter worker_connections=16384. In het laatste geval zult u echter hoogstwaarschijnlijk het besturingssysteem moeten afstemmen.

Evenementen (
werkerverbindingen 2048;
gebruik kqueue; # We hebben BSD :)
}

Het volgende gedeelte is het grootste en bevat de meest interessante dingen. Dit is een beschrijving van virtuele servers en enkele parameters die voor alle servers gelden. Ik zal de standaardinstellingen weglaten die in elke configuratie voorkomen, zoals paden naar logboeken.

Http(
# Alle onderstaande code bevindt zich in deze sectie %)
# ...
}

Binnen deze sectie kunnen er enkele behoorlijk interessante parameters zijn.

De sendfile systeemaanroep is relatief nieuw voor Linux. Hiermee kunt u gegevens naar het netwerk verzenden zonder deze naar de adresruimte van de toepassing te hoeven kopiëren. In veel gevallen verbetert dit de serverprestaties aanzienlijk, dus het is het beste om altijd de optie sendfile in te schakelen.

De parameter keepalive_timeout is verantwoordelijk voor maximale tijd het onderhouden van een keepalive-verbinding als de gebruiker er niets via aanvraagt. Bedenk hoe uw site verzoeken verzendt en pas deze instelling aan. Voor sites die actief gebruik maken van AJAX is het beter om de verbinding langer te behouden; voor statische pagina's die gebruikers lang zullen lezen is het beter om de verbinding vroegtijdig te verbreken. Houd er rekening mee dat u, door een inactieve keepalive-verbinding te onderhouden, een verbinding tot stand brengt die op een andere manier kan worden gebruikt. :)

Keepalive_timeout 15;

Afzonderlijk is het de moeite waard om de nginx-proxy-instellingen te benadrukken. Meestal wordt nginx juist als proxyserver gebruikt, en dienovereenkomstig hebben ze dat behoorlijk grote waarde. In het bijzonder is het zinvol om de buffergrootte voor proxy-aanvragen niet kleiner in te stellen dan de verwachte responsgrootte van de backend-server. Bij langzame (of omgekeerd: zeer snelle) backends is het zinvol om de time-outs voor het wachten op een reactie van de backend te wijzigen. Houd er rekening mee dat hoe langer deze time-outs duren, hoe langer uw gebruikers zullen wachten op een reactie als de backend traag is.

Proxy_buffers 8 64k;
proxy_intercept_errors ingeschakeld;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;

Een kleine truc. In het geval dat nginx meer dan één virtuele host bedient, is het zinvol om een ​​“standaard virtuele host” te creëren die verzoeken verwerkt in gevallen waarin de server geen ander alternatief kan vinden met behulp van de Host-header in het clientverzoek.

# standaard virtuele host
server(
luister 80 standaard;
servernaam localhost;
alles ontkennen;
}

Dit kan worden gevolgd door één (of meerdere) “server”-secties. Elk van hen beschrijft een virtuele host (meestal op naam gebaseerd). Voor eigenaren van veel sites op één hosting, of voor hosters, kan er zoiets als een richtlijn bestaan

Inclusief /spool/users/nginx/*.conf;

De rest zal hoogstwaarschijnlijk hun virtuele host rechtstreeks in de hoofdconfiguratie beschrijven.

Server (
luister 80;

# Houd er rekening mee dat de server_name-richtlijn meerdere namen tegelijkertijd kan specificeren.
servernaam mijnserver.ru mijnserver.com;
access_log /spool/logs/nginx/myserver.access_log getimed;
error_log /spool/logs/nginx/myserver.error_log waarschuwing;
# ...

Laten we de standaardcodering voor uitvoer instellen.

Tekenset utf-8;

En laten we zeggen dat we geen verzoeken willen accepteren van klanten die langer zijn dan 1 megabyte.

Klant_max_lichaamsgrootte 1m;

Laten we SSI inschakelen voor de server en vragen om niet meer dan 1 kilobyte te reserveren voor SSI-variabelen.

Si op;
ssi_waarde_lengte 1024;

En ten slotte zullen we twee locaties beschrijven, waarvan er één naar de backend zal leiden, naar Apache die op poort 9999 draait, en de tweede statische afbeeldingen zal verzenden vanaf de lokale locatie. bestandssysteem. Voor twee locaties heeft dit weinig zin, maar voor een groter aantal is het ook zinvol om direct een variabele te definiëren waarin de hoofdmap van de server wordt opgeslagen, en deze vervolgens te gebruiken in locatiebeschrijvingen.