Begrip van Nginx Server en Locatieblokalgoritmen

Handleidingen

Introductie

Nginx is een van de meest populaire webservers ter wereld. Het kan succesvol hoge belastingen aan met veel gelijktijdige clientverbindingen, en kan functioneren als een webserver, een mailsysteem, of een omgekeerde proxyserver.

In deze handleiding zullen we enkele van de achterliggende details bespreken die bepalen hoe Nginx clientverzoeken verwerkt. Het begrijpen van deze ideeën kan helpen bij het wegnemen van het giswerk bij het ontwerpen van server- en locatieblokken en kan de verwerking van verzoeken minder onvoorspelbaar doen lijken.

Nginx Blok Configuraties

Nginx verdeelt logisch de configuraties die bedoeld zijn om verschillende inhoud te serveren in blokken, die in een hiërarchische structuur leven. Telkens wanneer een clientverzoek wordt gedaan, begint Nginx een proces om te bepalen welke configuratieblokken moeten worden gebruikt om het verzoek af te handelen. Dit besluitvormingsproces is wat we in deze handleiding zullen bespreken.

De belangrijkste blokken die we zullen bespreken zijn het server-blok en het locatie-blok.

A server block is a subset of Nginx’s configuration that defines a virtual server used to handle requests of a defined type. Administrators often configure multiple server blocks and decide which block should handle which connection based on the requested domain name, port, and IP address.

A location block lives within a server block and is used to define how Nginx should handle requests for different resources and URIs for the parent server. The URI space can be subdivided in whatever way the administrator likes using these blocks. It is an extremely flexible model.

Hoe Nginx beslist welke serverblok een verzoek zal afhandelen

Sinds Nginx de beheerder toestaat om meerdere serverblokken te definiëren die functioneren als afzonderlijke virtuele webserverinstanties, heeft het een procedure nodig om te bepalen welk van deze serverblokken zal worden gebruikt om aan een verzoek te voldoen.

Dit gebeurt via een gedefinieerd systeem van controles die worden gebruikt om de best mogelijke overeenkomst te vinden. De belangrijkste serverblokrichtlijnen waar Nginx zich tijdens dit proces op richt, zijn de listen-richtlijn en de server_name-richtlijn.

Het analyseren van de listen-richtlijn om mogelijke overeenkomsten te vinden

Eerst kijkt Nginx naar het IP-adres en de poort van het verzoek. Het vergelijkt dit met de listen-richtlijn van elke server om een lijst van de serverblokken op te bouwen die mogelijk het verzoek kunnen oplossen.

De listen directive definieert typisch het IP-adres en de poort waarop het serverblok zal reageren. Standaard krijgt elk serverblok dat geen listen directive bevat de luisterparameters van 0.0.0.0:80 (of 0.0.0.0:8080 als Nginx wordt uitgevoerd door een normale, niet-root gebruiker). Hierdoor kunnen deze blokken reageren op verzoeken op elk interface op poort 80, maar deze standaardwaarde weegt niet zwaar in het serverselectieproces.

De listen directive kan worden ingesteld op:

  • Een IP-adres/poort combinatie.
  • A lone IP address which will then listen on the default port 80.
  • A lone port which will listen to every interface on that port.
  • Het pad naar een Unix-socket.

De laatste optie heeft meestal alleen implicaties bij het doorgeven van verzoeken tussen verschillende servers.

Bij het proberen te bepalen naar welk serverblok een verzoek moet worden gestuurd, zal Nginx eerst proberen te beslissen op basis van de specificiteit van de listen directive met behulp van de volgende regels:

  • Nginx vertaalt alle “onvolledige” listen directives door ontbrekende waarden te vervangen door hun standaardwaarden, zodat elk blok kan worden geëvalueerd op basis van zijn IP-adres en poort. Enkele voorbeelden van deze vertalingen zijn:
    • Een blok zonder listen directive gebruikt de waarde 0.0.0.0:80.
    • Een blok ingesteld op een IP-adres 111.111.111.111 zonder poort wordt 111.111.111.111:80
    • Een blok ingesteld op poort 8888 zonder IP-adres wordt 0.0.0.0:8888
  • Nginx probeert vervolgens een lijst van serverblokken te verzamelen die het meest specifiek overeenkomen met het verzoek op basis van het IP-adres en de poort. Dit betekent dat elk blok dat functioneel 0.0.0.0 als zijn IP-adres gebruikt (om overeen te komen met elk interface), niet zal worden geselecteerd als er overeenkomende blokken zijn die een specifiek IP-adres vermelden. In elk geval moet de poort exact overeenkomen.
  • Als er slechts één meest specifieke overeenkomst is, zal dat serverblok worden gebruikt om het verzoek te bedienen. Als er meerdere serverblokken zijn met dezelfde mate van specificiteit die overeenkomen, begint Nginx vervolgens de server_name-instructie van elk serverblok te evalueren.

Het is belangrijk om te begrijpen dat Nginx alleen de server_name-instructie zal evalueren wanneer het onderscheid moet maken tussen serverblokken die overeenkomen met hetzelfde niveau van specificiteit in de listen-instructie. Als bijvoorbeeld example.com wordt gehost op poort 80 van 192.168.1.10, zal een verzoek voor example.com altijd worden bediend door het eerste blok in dit voorbeeld, ondanks de server_name-instructie in het tweede blok.

server {
    listen 192.168.1.10;

    . . .

}

server {
    listen 80;
    server_name example.com;

    . . .

}

In het geval dat meer dan één serverblok overeenkomt met gelijke specificiteit, is de volgende stap om de server_name-instructie te controleren.

Het ontleden van de server_name-instructie om een overeenkomst te kiezen

Vervolgens, om verzoeken verder te evalueren die even specifieke listen richtlijnen hebben, controleert Nginx de Host header van het verzoek. Deze waarde bevat het domein of het IP-adres waar de client daadwerkelijk toegang tot probeerde te krijgen.

Nginx probeert de beste overeenkomst te vinden voor de waarde die het vindt door te kijken naar de server_name richtlijn binnen elk van de serverblokken die nog steeds selectiekandidaten zijn. Nginx evalueert deze met behulp van de volgende formule:

  • Nginx zal eerst proberen een serverblok te vinden met een server_name die exact overeenkomt met de waarde in de Host header van het verzoek exact. Als dit wordt gevonden, wordt het bijbehorende blok gebruikt om het verzoek te bedienen. Als er meerdere exacte overeenkomsten zijn gevonden, wordt de eerste gebruikt.
  • Als er geen exacte overeenkomst wordt gevonden, zal Nginx vervolgens proberen een serverblok te vinden met een server_name die overeenkomt met een leidende wildcard (aangeduid met een * aan het begin van de naam in de configuratie). Als er een wordt gevonden, wordt dat blok gebruikt om het verzoek te bedienen. Als er meerdere overeenkomsten zijn gevonden, wordt de langste gebruikt om het verzoek te bedienen.
  • Als er geen overeenkomst wordt gevonden met een leidende wildcard, kijkt Nginx vervolgens naar een serverblok met een server_name die overeenkomt met een volgende wildcard (aangeduid met een servernaam die eindigt op een * in de configuratie). Als er een wordt gevonden, wordt dat blok gebruikt om het verzoek te bedienen. Als er meerdere overeenkomsten zijn gevonden, wordt de langste gebruikt om het verzoek te bedienen.
  • Als er geen overeenkomst wordt gevonden met een achtervoegsel-wildcard, evalueert Nginx vervolgens serverblokken die de server_name definiëren met behulp van reguliere expressies (aangegeven door een ~ voor de naam). De eerste server_name met een reguliere expressie die overeenkomt met de “Host” header zal worden gebruikt om het verzoek te bedienen.
  • Als er geen overeenkomst met een reguliere expressie wordt gevonden, selecteert Nginx vervolgens het standaardserverblok voor dat IP-adres en poort.

Elke combinatie van IP-adres/poort heeft een standaardserverblok dat wordt gebruikt wanneer er geen actie kan worden bepaald met behulp van de bovenstaande methoden. Voor een combinatie van IP-adres/poort is dit ofwel het eerste blok in de configuratie of het blok dat de default_server optie bevat als onderdeel van de listen directive (wat het eerstgevonden algoritme zou overschrijven). Er kan slechts één default_server verklaring per elk IP-adres/poortcombinatie zijn.

Voorbeelden

Als er een server_name is gedefinieerd die exact overeenkomt met de waarde van de Host header, wordt dat serverblok geselecteerd om het verzoek te verwerken.

In dit voorbeeld, als de Host header van het verzoek was ingesteld op host1.example.com, zou de tweede server worden geselecteerd:

server {
    listen 80;
    server_name *.example.com;

    . . .

}

server {
    listen 80;
    server_name host1.example.com;

    . . .

}

Als er geen exacte match wordt gevonden, controleert Nginx vervolgens of er een server_name is met een start-wildcard die past. De langste match die begint met een wildcard zal worden geselecteerd om aan het verzoek te voldoen.

In dit voorbeeld, als het verzoek een Host-header had van www.example.org, zou het tweede serverblok worden geselecteerd:

server {
    listen 80;
    server_name www.example.*;

    . . .

}

server {
    listen 80;
    server_name *.example.org;

    . . .

}

server {
    listen 80;
    server_name *.org;

    . . .

}

Als er geen match wordt gevonden met een begin-wildcard, zal Nginx vervolgens controleren of er een match bestaat met behulp van een wildcard aan het einde van de expressie. Op dit punt zal de langste match die eindigt met een wildcard worden geselecteerd om aan het verzoek te voldoen.

Bijvoorbeeld, als het verzoek een Host-header heeft die is ingesteld op www.example.com, zal het derde serverblok worden geselecteerd:

server {
    listen 80;
    server_name host1.example.com;

    . . .

}

server {
    listen 80;
    server_name example.com;

    . . .

}

server {
    listen 80;
    server_name www.example.*;

    . . .

}

Als er geen wildcard-overeenkomsten kunnen worden gevonden, zal Nginx vervolgens proberen overeenkomende server_name-instructies te vinden die reguliere expressies gebruiken. De eerste overeenkomende reguliere expressie zal worden geselecteerd om te reageren op het verzoek.

Bijvoorbeeld, als de Host-header van het verzoek is ingesteld op www.example.com, wordt het tweede serverblok geselecteerd om aan het verzoek te voldoen:

server {
    listen 80;
    server_name example.com;

    . . .

}

server {
    listen 80;
    server_name ~^(www|host1).*\.example\.com$;

    . . .

}

server {
    listen 80;
    server_name ~^(subdomain|set|www|host1).*\.example\.com$;

    . . .

}

Als geen van de bovenstaande stappen het verzoek kan vervullen, wordt het verzoek doorgestuurd naar de standaard server voor het overeenkomende IP-adres en poort.

Overeenkomende Locatieblokken

Vergelijkbaar met het proces dat Nginx gebruikt om het serverblok te selecteren dat een verzoek zal verwerken, heeft Nginx ook een vastgesteld algoritme om te beslissen welk locatieblok binnen de server moet worden gebruikt voor het afhandelen van verzoeken.

Syntaxis van Locatieblok

Voordat we bespreken hoe Nginx beslist welk locatieblok moet worden gebruikt om verzoeken af te handelen, laten we enkele syntaxis behandelen die je mogelijk tegenkomt in de definitie van locatieblokken. Locatieblokken bevinden zich binnen serverblokken (of andere locatieblokken) en worden gebruikt om te beslissen hoe het verzoek-URI (het deel van het verzoek dat na de domeinnaam of IP-adres/poort komt) moet worden verwerkt.

Locatieblokken hebben over het algemeen de volgende vorm:

location optional_modifier location_match {

    . . .

}

De location_match in het bovenstaande definieert waar Nginx het verzoek-URI tegen moet controleren. Het bestaan of niet-bestaan van de modifier in het bovenstaande voorbeeld beïnvloedt de manier waarop Nginx probeert het locatieblok te matchen. De onderstaande modifiers zullen ertoe leiden dat het bijbehorende locatieblok als volgt wordt geïnterpreteerd:

  • (geen): Als er geen modifiers aanwezig zijn, wordt de locatie geïnterpreteerd als een prefix-match. Dit betekent dat de opgegeven locatie wordt gematcht tegen het begin van het verzoek-URI om een match te bepalen.
  • =: Als een gelijkteken wordt gebruikt, wordt dit blok beschouwd als een match als het verzoek-URI exact overeenkomt met de opgegeven locatie.
  • ~: Als er een tilde-modifier aanwezig is, wordt deze locatie geïnterpreteerd als een hoofdlettergevoelige reguliere expressie-match.
  • ~*: Als er een tilde en asterisk-modifier worden gebruikt, zal het locatieblok worden geïnterpreteerd als een hoofdletterongevoelige reguliere expressie-match.
  • ^~: Als er een carat en tilde-modifier aanwezig is, en als dit blok wordt geselecteerd als de beste niet-reguliere expressie-match, zal er geen reguliere expressie-match plaatsvinden.

Voorbeelden die de syntaxis van het locatieblok demonstreren

Als voorbeeld van prefix-matching kan het volgende locatieblok worden geselecteerd om te reageren op verzoek-URI’s die lijken op /site, /site/page1/index.html of /site/index.html:

location /site {

    . . .

}

Als demonstratie van exacte verzoek-URI-matching, zal dit blok altijd worden gebruikt om te reageren op een verzoek-URI die lijkt op /page1. Het zal niet worden gebruikt om te reageren op een /page1/index.html verzoek-URI. Houd er rekening mee dat als dit blok wordt geselecteerd en het verzoek wordt vervuld met behulp van een indexpagina, er een interne omleiding zal plaatsvinden naar een andere locatie die de daadwerkelijke verwerker van het verzoek zal zijn:

location = /page1 {

    . . .

}

Als voorbeeld van een locatie die geïnterpreteerd moet worden als een hoofdlettergevoelige reguliere expressie, zou dit blok gebruikt kunnen worden om verzoeken voor /tortoise.jpg af te handelen, maar niet voor /FLOWER.PNG:

location ~ \.(jpe?g|png|gif|ico)$ {

    . . .

}

A block that would allow for case-insensitive matching similar to the above is shown below. Here, both /tortoise.jpg and /FLOWER.PNG could be handled by this block:

location ~* \.(jpe?g|png|gif|ico)$ {

    . . .

}

Tenslotte zou dit blok voorkomen dat reguliere expressieovereenkomsten plaatsvinden als het bepaalt dat het de beste niet-reguliere expressieovereenkomst is. Het zou verzoeken voor /costumes/ninja.html afhandelen:

location ^~ /costumes {

    . . .

}

Zoals je ziet, geven de modificatoren aan hoe het locatieblok moet worden geïnterpreteerd. Dit vertelt ons echter niet welk algoritme Nginx gebruikt om te beslissen welk locatieblok het verzoek moet ontvangen. Dat gaan we hierna bespreken.

Hoe Nginx Kiest Welke Locatie Te Gebruiken Om Verzoeken Af Te Handelen

Nginx kiest de locatie die zal worden gebruikt om een verzoek te bedienen op een vergelijkbare manier als hoe het een serverblok selecteert. Het doorloopt een proces dat bepaalt welk locatieblok het beste is voor elk gegeven verzoek. Het begrijpen van dit proces is een cruciale vereiste om Nginx betrouwbaar en nauwkeurig te kunnen configureren.

Met in gedachten de soorten locatieverklaringen die we hierboven hebben beschreven, evalueert Nginx de mogelijke locatiecontexten door de aanvraag-URI te vergelijken met elk van de locaties. Het doet dit met behulp van het volgende algoritme:

  • Nginx begint met het controleren van alle locatiematches op basis van een prefix (alle locatietypen die geen reguliere expressie bevatten). Het controleert elke locatie tegen de volledige aanvraag-URI.
  • Eerst zoekt Nginx naar een exacte match. Als een locatieblok met de = modifier wordt gevonden die exact overeenkomt met de aanvraag-URI, wordt dit locatieblok onmiddellijk geselecteerd om de aanvraag te verwerken.
  • Als er geen exacte (met de = modifier) locatieblokmatches worden gevonden, gaat Nginx verder met het evalueren van niet-exacte voorvoegsels. Het ontdekt de langste overeenkomende voorvoegsellocatie voor de gegeven aanvraag-URI, die vervolgens als volgt wordt geëvalueerd:
    • Als de langste overeenkomende voorvoegsellocatie de ^~ modifier heeft, zal Nginx onmiddellijk zijn zoekopdracht beëindigen en deze locatie selecteren om de aanvraag te verwerken.
    • Als de langste overeenkomende voorvoegsellocatie de ^~ modifier niet gebruikt, wordt de match door Nginx tijdelijk opgeslagen zodat de focus van de zoekopdracht kan worden verlegd.
  • Nadat de locatie met de langste overeenkomende prefix is bepaald en opgeslagen, gaat Nginx over tot het evalueren van de reguliere expressie-locaties (zowel hoofdlettergevoelig als hoofdletterongevoelig). Als er reguliere expressie-locaties binnen de langste overeenkomende prefixlocatie zijn, verplaatst Nginx die naar de top van zijn lijst met te controleren reguliere expressie-locaties. Nginx probeert vervolgens sequentieel overeen te komen met de reguliere expressie-locaties. De eerste reguliere expressie-locatie die overeenkomt met de aanvraag-URI wordt onmiddellijk geselecteerd om de aanvraag te verwerken.
  • Als er geen reguliere expressie-locaties worden gevonden die overeenkomen met de aanvraag-URI, wordt de eerder opgeslagen prefixlocatie geselecteerd om de aanvraag te verwerken.

Het is belangrijk om te begrijpen dat Nginx reguliere expressie-overeenkomsten standaard verkiest boven prefix-overeenkomsten. Nginx evalueert echter eerst prefix-locaties, zodat de beheerder deze neiging kan overschrijven door locaties te specificeren met behulp van de ‘=’ en ‘^~’ modifiers.

Het is ook belangrijk om op te merken dat, hoewel prefix-locaties over het algemeen worden geselecteerd op basis van de langste, meest specifieke overeenkomst, de evaluatie van reguliere expressies wordt gestopt wanneer de eerste overeenkomende locatie wordt gevonden. Dit betekent dat de positionering binnen de configuratie grote implicaties heeft voor reguliere expressie-locaties.

Tenslotte is het belangrijk om te begrijpen dat reguliere expressiematches binnen de langste voorvoegselmatch “de lijn zullen overslaan” wanneer Nginx regex-locaties evalueert. Deze zullen worden geëvalueerd, in volgorde, voordat een van de andere reguliere expressiematches worden overwogen. Maxim Dounin, een ongelooflijk behulpzame Nginx-ontwikkelaar, legt in dit bericht dit gedeelte van het selectiealgoritme uit.

Wanneer springt de evaluatie van een locatieblok naar andere locaties?

Over het algemeen, wanneer een locatieblok is geselecteerd om een verzoek te bedienen, wordt het verzoek volledig binnen die context afgehandeld vanaf dat moment. Alleen de geselecteerde locatie en de overgeërfde richtlijnen bepalen hoe het verzoek wordt verwerkt, zonder tussenkomst van zusterlocatieblokken.

Hoewel dit een algemene regel is die je in staat stelt om je locatieblokken op een voorspelbare manier te ontwerpen, is het belangrijk om te beseffen dat er momenten zijn waarop een nieuwe locatiezoekopdracht wordt gestart door bepaalde richtlijnen binnen de geselecteerde locatie. De uitzonderingen op de “slechts één locatieblok” regel kunnen gevolgen hebben voor hoe het verzoek daadwerkelijk wordt bediend en kunnen niet overeenkomen met de verwachtingen die je had bij het ontwerpen van je locatieblokken.

Sommige richtlijnen die kunnen leiden tot dit type interne omleiding zijn:

  • index
  • try_files
  • rewrite
  • error_page

Laten we deze kort doornemen.

De index richtlijn leidt altijd tot een interne omleiding als deze wordt gebruikt om het verzoek af te handelen. Exacte locatie-overeenkomsten worden vaak gebruikt om het selectieproces te versnellen door de uitvoering van het algoritme onmiddellijk te beëindigen. Als u echter een exacte locatie-overeenkomst maakt die een map is, is er een goede kans dat het verzoek wordt omgeleid naar een andere locatie voor daadwerkelijke verwerking.

In dit voorbeeld wordt de eerste locatie gematcht door een verzoek-URI van /exact, maar om het verzoek af te handelen, initieert de index richtlijn die is overgeërfd door het blok een interne omleiding naar het tweede blok:

index index.html;

location = /exact {

    . . .

}

location / {

    . . .

}

In het geval hierboven, als u echt wilt dat de uitvoering in het eerste blok blijft, zult u een andere methode moeten bedenken om aan het verzoek naar de map te voldoen. U zou bijvoorbeeld een ongeldige index kunnen instellen voor dat blok en autoindex inschakelen:

location = /exact {
    index nothing_will_match;
    autoindex on;
}

location  / {

    . . .

}

Dit is een manier om te voorkomen dat een index van context verandert, maar het is waarschijnlijk niet nuttig voor de meeste configuraties. Meestal kan een exacte overeenkomst met mappen nuttig zijn voor zaken als het herschrijven van het verzoek (wat ook resulteert in een nieuwe locatiezoekopdracht).

Nog een ander geval waarin de verwerkingslocatie opnieuw kan worden geëvalueerd, is met de try_files richtlijn. Deze richtlijn vertelt Nginx om te controleren op het bestaan van een genoemde reeks bestanden of mappen. De laatste parameter kan een URI zijn waarnaar Nginx een interne omleiding zal maken.

Overweeg de volgende configuratie:

root /var/www/main;
location / {
    try_files $uri $uri.html $uri/ /fallback/index.html;
}

location /fallback {
    root /var/www/another;
}

In het bovenstaande voorbeeld, als een verzoek wordt gedaan voor /blahblah, zal het eerste locatieblok aanvankelijk het verzoek ontvangen. Het zal proberen een bestand genaamd blahblah te vinden in de map /var/www/main. Als het er geen kan vinden, zal het vervolgens proberen een bestand genaamd blahblah.html te zoeken. Het zal dan proberen te zien of er een map genaamd blahblah/ is binnen de map /var/www/main. Als al deze pogingen mislukken, wordt er omgeleid naar /fallback/index.html. Dit zal een andere locatiezoektocht activeren die wordt opgevangen door het tweede locatieblok. Dit zal het bestand /var/www/another/fallback/index.html serveren.

Nog een instructie die kan leiden tot het doorgeven van een locatieblok, is de rewrite-instructie. Bij gebruik van de last-parameter bij de rewrite-instructie, of bij het helemaal niet gebruiken van een parameter, zal Nginx zoeken naar een nieuwe overeenkomende locatie op basis van de resultaten van de rewrite.

Bijvoorbeeld, als we het laatste voorbeeld aanpassen om een rewrite op te nemen, kunnen we zien dat het verzoek soms rechtstreeks naar de tweede locatie wordt doorgegeven zonder te vertrouwen op de try_files-instructie:

root /var/www/main;
location / {
    rewrite ^/rewriteme/(.*)$ /$1 last;
    try_files $uri $uri.html $uri/ /fallback/index.html;
}

location /fallback {
    root /var/www/another;
}

In het bovenstaande voorbeeld wordt een verzoek voor /rewriteme/hello aanvankelijk afgehandeld door het eerste locatieblok. Het zal worden herschreven naar /hello en er zal een locatie worden gezocht. In dit geval zal het opnieuw overeenkomen met de eerste locatie en worden verwerkt door de try_files zoals gebruikelijk, misschien teruggaan naar /fallback/index.html als er niets wordt gevonden (met behulp van de interne redirect van try_files die we hierboven hebben besproken).

Echter, als een verzoek wordt gedaan voor /rewriteme/fallback/hello, zal het eerste blok opnieuw overeenkomen. De herschrijving wordt opnieuw toegepast, wat deze keer resulteert in /fallback/hello. Het verzoek zal vervolgens worden afgehandeld door het tweede locatieblok.

A related situation happens with the return directive when sending the 301 or 302 status codes. The difference in this case is that it results in an entirely new request in the form of an externally visible redirect. This same situation can occur with the rewrite directive when using the redirect or permanent flags. However, these location searches shouldn’t be unexpected, since externally visible redirects always result in a new request.

De error_page directive kan leiden tot een interne redirect vergelijkbaar met die gecreëerd door try_files. Deze directive wordt gebruikt om te definiëren wat er moet gebeuren wanneer bepaalde statuscodes worden aangetroffen. Dit zal waarschijnlijk nooit worden uitgevoerd als try_files is ingesteld, aangezien die directive de hele levenscyclus van een verzoek afhandelt.

Beschouw dit voorbeeld:

root /var/www/main;

location / {
    error_page 404 /another/whoops.html;
}

location /another {
    root /var/www;
}

Elk verzoek (behalve diegene die beginnen met /another) zal worden afgehandeld door het eerste blok, dat bestanden serveert uit /var/www/main. Echter, als een bestand niet wordt gevonden (een 404-status), zal een interne redirect naar /another/whoops.html plaatsvinden, wat leidt tot een nieuwe locatiezoeking die uiteindelijk terechtkomt bij het tweede blok. Dit bestand zal worden geserveerd vanuit /var/www/another/whoops.html.

Zoals je kunt zien, kan het begrijpen van de omstandigheden waarin Nginx een nieuwe locatiezoeking start, helpen om het gedrag te voorspellen dat je zult zien bij het doen van verzoeken.

Conclusie

Het begrijpen van de manieren waarop Nginx clientverzoeken verwerkt, kan je taak als beheerder veel gemakkelijker maken. Je zult in staat zijn om te weten welke serverblok Nginx zal selecteren op basis van elk clientverzoek. Je zult ook kunnen vertellen hoe het locatieblok wordt geselecteerd op basis van de verzoek-URI. Over het algemeen geeft het kennen van de manier waarop Nginx verschillende blokken selecteert, je de mogelijkheid om de contexten te traceren die Nginx zal toepassen om elk verzoek te bedienen.

Source:
https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms