Meer dan 50% van het verkeer wereldwijd wordt bediend door Apache- en Nginx-technologie– webservers die open zijn broncode. Nginx voert de frontend-functie uit, Apache voert de backend-functie uit. Nginx is de eerste die gebruikersverzoeken accepteert en hierop reageert met de benodigde inhoud: afbeeldingen, bestanden, scripts. Heavy Apache houdt zich hier op zijn beurt niet mee bezig, maar verwerkt de dynamiek. Nginx-proxyverzoeken en retourantwoorden. Deze combinatie is geweldig voor grote sites die door veel gebruikers worden bezocht. Voor kleine sites dit stel zal de productiviteit niet verhogen. Apache en Nginx verminderen de belasting van de server in het algemeen vanwege het feit dat Nginx verwerkt statische inhoud, terwijl Apache dynamische inhoud verwerkt.

Apache en Nginx mogen niet als uitwisselbare technologieën worden beschouwd, ook al hebben ze veel vergelijkbare kenmerken. Elke webserver heeft zijn eigen voordelen en het gebruik ervan hangt af van de taak die moet worden uitgevoerd. In dit artikel Laten we elke technologie bekijken, afhankelijk van het toepassingsgebied. Het artikel zal nuttig zijn voor eigenaren van virtuele en speciale fysieke servers.

Functioneel en snel, Nginx werd uitgebracht in 2004 en begon na deze release aan populariteit te winnen. Vanwege het lichte gewicht en de schaalbaarheid werkt het goed op elke hardware. Nginx wordt op twee manieren gebruikt: als webserver of als proxy.

Wat doet Nginx als webserver?

• creëert automatisch cachedescriptors en bestandslijsten, onderhoudt indexbestanden en statische zoekopdrachten;
• versnelt fouttolerantie, proxying en taakverdeling;
• cachet met FastCGI en versnelt proxying;
• ondersteunt SSL;
• ondersteunt Perl;
• heeft filters en modulariteit;
• verifieert HTTP en filtert SSL.

Als een Nginx-proxy:

• volledige levering van StartTLS en SSL;
• gemakkelijke authenticatie (USER/PASS, LOGIN);
• gebruikt een externe HTTP-server om door te sturen naar de POP3/IMAP-backend.

Zoals je kunt zien, voert Nginx veel functies uit zonder het systeem te overbelasten. Volgens officiële gegevens wordt de technologie gebruikt door meer dan 56 miljoen sites over de hele wereld (bijvoorbeeld Rambler, Yandex, Mail, Begun, WordPress.com, vk.com, Facebook, Rutracker.org), maar Nginx is inferieur aan Apache in populariteit. Waarom is Apache zo populair?

Apache-webserver – platformonafhankelijk software, opgericht in 1995. Dankzij uitgebreide documentatie en goede integratie met software van derden heeft Apache enorm aan populariteit gewonnen. Ondersteunt de volgende besturingssystemen: Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS. .

Voordelen van Apache-webserver:

• steun programmeertalen PHP, Python, Ruby, Perl, ASP, Tcl;
• gemak van het aansluiten van externe modules;
• technologische ondersteuning CGI en FastCGI;
• de aanwezigheid van mechanismen die de veiligheid en differentiatie van gegevenstoegang garanderen;
• de mogelijkheid om een ​​DBMS te gebruiken voor gebruikersauthenticatie;
• flexibele en betrouwbare systeemconfiguratie;
• geschikt voor toepassingen die dit vereisen krachtig cryptografische bescherming gegevens;
• mogelijkheid tot creëren gebruikersmappen voor de website;
• mogelijkheid om virtuele hosts te configureren, met behulp waarvan op één fysieke server je kunt verschillende virtuele maken;
• houdt logboeken bij van wat er op uw server gebeurt;
• actief feedback met ontwikkelaars en tijdige oplossing van softwarefouten.

Maar ondanks alle voordelen Apache-webserver enigszins moeilijk op te zetten en te bedienen, dus niet elke beginner zal er mee om kunnen gaan. Maar als uw project deze specifieke software nodig heeft, dan zult u dat ook doen juiste keuze ten gunste van Apache.

Wilt u beveiligen PHP-werk op de server? Meer details hierover.

Nadat je de voor- en nadelen van Apache en Nginx kent, kun je kiezen nuttige oplossingen voor uw website, afhankelijk van de doelen die u nastreeft. Maar Misschien heb je de combinatie Apache+Nginx nodig bereiken beste resultaat. Nginx wordt bijvoorbeeld vóór Apache vaak gebruikt als een reverse proxy. Met deze combinatie kunt u veel concurrerende verzoeken afhandelen en sorteert ze. De verzoeken die Nginx niet kan afhandelen, worden naar Apache gestuurd, waardoor de belasting van Apache wordt verminderd. In dit geval neemt de fouttolerantie toe. Voordat u een webserver kiest, moet u verplichte tests uitvoeren op de prestaties en mogelijkheden van elke oplossing.

Voor meer informatie over alle technologieën die door HyperHost-hosting worden ondersteund, gaat u naar.

Dit artikel is bedoeld om algemene bekendheid te geven met de mogelijkheden van het combineren van Apache- en Nginx-webservers. Meer meer informatie V.

Als u onze hulp nodig heeft, neem dan contact met ons op!

Wij beantwoorden graag al uw vragen over het opzetten van webservers. Bovendien kunt u bij ons altijd gratis administratie krijgen. Is het allemaal technische ondersteuning hosters zijn hetzelfde? Over de kenmerken van gratis en betaald beheer in een speciale.

17247 keer Vandaag 8 keer bekeken

• Vertaling

NGINX is terecht een van de beste servers op het gebied van prestaties, en dit is allemaal te danken aan zijn interne structuur. Hoewel veel web- en applicatieservers een eenvoudig multi-threaded model gebruiken, onderscheidt NGINX zich van de massa door zijn niet-triviale, op gebeurtenissen gebaseerde architectuur, waardoor het gemakkelijk kan worden geschaald naar honderdduizenden gelijktijdige verbindingen.

Een statusmachine in NGINX is in wezen een reeks instructies voor het verwerken van een verzoek. De meeste webservers vervullen dezelfde functie, maar het verschil zit hem in de implementatie.

Staatsmachine-apparaat

Een eindige toestandsmachine kan worden gezien als de regels voor het schaken. Elke HTTP-transactie is een schaakspel. Aan de ene kant van het schaakbord is de webserver een grootmeester die zeer snel beslissingen neemt. Aan de andere kant staat een externe client, een browser, die via een relatief traag netwerk een site of applicatie opvraagt.

De spelregels kunnen echter zeer complex zijn. De webserver moet bijvoorbeeld mogelijk communiceren met andere bronnen (proxyverzoeken aan de backend) of contact opnemen met een authenticatieserver. Modules van derden kunnen de verwerking verder compliceren.

Staatsmachine blokkeren

Denk aan onze definitie van een proces of thread als een op zichzelf staande reeks instructies die het besturingssysteem de uitvoering kan toewijzen aan een specifieke processorkern. De meeste webservers en webapplicaties gebruiken een model waarbij ze schaken met één proces of thread per verbinding. Elk proces of elke thread bevat instructies om één spel volledig te spelen. Al die tijd is het proces dat op de server draait het grootste deel van zijn tijd geblokkeerd, wachtend op de volgende zet van de client.

1. Het webserverproces wacht op nieuwe verbindingen (nieuwe batches geïnitieerd door clients) op luistersockets.
2. Nadat hij een nieuwe verbinding heeft ontvangen, speelt hij het spel, blokkeert na elke zet, wachtend op een reactie van de klant.
3. Wanneer een game wordt gespeeld, wacht het webserverproces mogelijk tot de client de volgende game start (dit komt overeen met langlevende keepalive-verbindingen). Als de verbinding is verbroken (de client is vertrokken of er is een time-out opgetreden), keert het proces terug naar het ontmoeten van nieuwe clients op de luisteraansluitingen.

Een belangrijk punt om op te merken is dat elke actieve HTTP-verbinding (elke batch) een afzonderlijk proces of thread (grootmeester) vereist. Deze architectuur is eenvoudig en gemakkelijk uit te breiden met modules van derden(nieuwe “regels”). Er is echter sprake van een enorme onbalans: een vrij lichte HTTP-verbinding, vertegenwoordigd door een bestandsdescriptor en een kleine hoeveelheid geheugen, correleert met afzonderlijk proces of een stroom, een voldoende zwaar voorwerp erin besturingssysteem. Dit is handig bij het programmeren, maar erg verspillend.

NGINX als een echte grootmeester

Je hebt waarschijnlijk wel eens gehoord van simultane speelsessies, waarbij één grootmeester op meerdere schaakvelden speelt met tientallen tegenstanders tegelijk?

Kiril Georgiev speelde 360 ​​wedstrijden parallel op een toernooi in Bulgarije. Zijn eindresultaat was: 284 overwinningen, 70 gelijke spelen en 6 nederlagen.

Op dezelfde manier speelt het NGINX-werkproces schaak. Elk werkproces (onthoud - meestal slechts één per computerkern) is een grootmeester die in staat is honderden (in feite honderdduizenden) spellen tegelijkertijd te spelen.

1. Het werkproces luistert naar gebeurtenissen op luistersockets en verbindingssockets.
2. Gebeurtenissen vinden plaats op sockets en het proces verwerkt deze:
   • Een gebeurtenis op de luisteraansluiting betekent dat nieuwe klant om het spel te starten. Het werkproces maakt een nieuwe verbindingssocket aan.
   • Een gebeurtenis op de verbindingssocket geeft aan dat de client een zet heeft gedaan. De workflow reageert onmiddellijk op hem.

Workflow-verwerking netwerk verkeer, blokkeert nooit, wachtend op de volgende zet van de tegenstander (cliënt). Nadat het proces zijn zet heeft gedaan, verplaatst het zich onmiddellijk naar andere borden waar spelers op een zet wachten, of ontmoet nieuwe spelers aan de deur.

Waarom is dit sneller dan een blokkerende multi-threaded architectuur?

Elke nieuwe verbinding ontstaat bestandsbeschrijving en verbruikt een kleine hoeveelheid geheugen tijdens het werkproces. Dit is een zeer lage verbindingsoverhead. NGINX-processen kunnen gebonden blijven aan specifieke processorkernen. Contextwisselingen gebeuren vrij zelden en meestal als er geen werk meer te doen is.

De blokkeringsaanpak, met een apart proces per verbinding, vergt relatief veel extra middelen, en contextwisselingen van het ene proces naar het andere komen veel vaker voor.

Aanvullende informatie over dit onderwerp is ook te vinden in het artikel over NGINX-architectuur van Andrey Alekseev, vice-president ontwikkeling en medeoprichter van NGINX, Inc.

Met een adequate systeemconfiguratie kan NGINX goed worden geschaald naar vele honderdduizenden parallelle HTTP-verbindingen per werkproces en absorbeert het met vertrouwen uitbarstingen van verkeer (massa's nieuwe spelers).

Configuratie en uitvoerbare code bijwerken

De low-worker-architectuur van NGINX maakt het mogelijk om de configuratie en zelfs de eigen uitvoerbare code vrij efficiënt in een mum van tijd bij te werken.

Het updaten van de NGINX-configuratie is een zeer eenvoudige, lichtgewicht en betrouwbare procedure. Het bestaat uit het eenvoudigweg verzenden van een SIGHUP-signaal naar het masterproces.

Wanneer een werkproces een SIGHUP ontvangt, voert het verschillende bewerkingen uit:

1. Herlaadt de configuratie en spawnt nieuw setje werkprocessen. Deze nieuwe werkprocessen beginnen onmiddellijk met het accepteren van verbindingen en het verwerken van verkeer (met behulp van de nieuwe instellingen).
2. Signaleert dat oude workflows netjes eindigen. Ze accepteren geen nieuwe verbindingen meer. Zodra de huidige HTTP-verzoeken zijn voltooid, worden de verbindingen gesloten (geen slepende keep-alive-verbindingen). Zodra alle verbindingen zijn gesloten, eindigt het werkproces.

Deze procedure kan een lichte toename van de belasting van de processor en het geheugen veroorzaken, maar over het algemeen is dit vrijwel onmerkbaar vergeleken met de kosten voor het verwerken van actieve verbindingen. Je kunt de configuratie meerdere keren per seconde herladen (en er zijn nogal wat NGINX-gebruikers die dit doen). In zeldzame gevallen kunnen er problemen optreden wanneer te veel generaties NGINX-werkprocessen wachten op het sluiten van verbindingen, maar deze worden snel opgelost.

Update uitvoerbare code NGINX is de Heilige Graal hoge beschikbaarheid diensten. U kunt de server direct updaten, zonder verlies van verbindingen, downtime van bronnen of enige onderbreking van de klantenservice.

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.

Tijdens Nginx-instellingen belangrijk om te onthouden 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 er een parameter zou moeten zijn andere betekenis in meerdere serverblokken, dan kan een dergelijke parameter worden ingesteld 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 genoemd virtuele gastheren). In wezen zijn serverblokken dat wel technische specificaties afzonderlijke websites die op dezelfde 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 er naar het meeste gezocht lange naam met een masker dat 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, selecteert Nginx de dichtstbijzijnde overeenkomst en voert een zoekopdracht in reguliere expressies uit om te proberen een van de overeenkomsten te matchen beschikbare sjablonen. 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 dergelijke overeenkomsten zijn, wordt er naar gezocht reguliere expressie en zoekt vervolgens op 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.

IN configuratiebestand standaard is er een 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.

Afgehandeld hebben Nginx-configuraties en zodra u leert hoe u ze moet gebruiken, profiteert u van alle voordelen van dit krachtige en lichtgewicht hulpmiddel.

Trefwoorden: ,