Les blocs de configuration du serveur Web Nginx incluent : 1. Configurer le serveur virtuel ; 2. Configurer l'emplacement 3. Utiliser des variables ; 4. Renvoyer des codes d'état spécifiques ; Réécrire la réponse HTTP ; 7. Gérer les erreurs.
Les blocs de configuration du serveur Web Nginx sont :
1. Configurer le serveur virtuel
Le fichier de configuration NGINX doit contenir au moins une directive serveur pour définir le serveur virtuel. Lorsque NGINX traite une requête, il sélectionne d'abord le serveur virtuel qui répond à la requête.
Les serveurs virtuels sont définis par des directives de serveur dans le contexte http, par exemple :
http {
server {
# Server configuration
}
}Plusieurs directives de serveur peuvent être ajoutées au contexte http pour définir plusieurs serveurs virtuels.
Tutoriel recommandé : Tutoriel de démarrage rapide de Nginx
serverLe bloc de configuration comprend généralement une directive d'écoute pour spécifier le serveur sur lequel écouter les requêtes Adresse IP et port (ou socket et chemin de domaine Unix). Les adresses IPv4 et IPv6 sont acceptées ; placez les crochets (.
L'exemple suivant montre la configuration d'un serveur écoutant sur l'adresse IP 127.0.0.1 et le port 8080 : utilisez les ports standards. De même, si une adresse est omis, le serveur écoutera sur toutes les adresses. Si aucune directive d'écoute n'est incluse, le port "standard" est
et le port "par défaut" est, en fonction des autorisations du superutilisateur. S'il existe plusieurs serveurs correspondant à l'adresse IP et au port demandés, NGINX testera le champ d'en-tête d'hôte demandé par rapport à la directive server_name dans le bloc serveur. Le paramètre server_name peut être un nom complet (exact) ou une expression régulière 80/tcp. 8000/tcpUn caractère générique est une chaîne contenant un astérisque (*) au début, à la fin ou les deux ; les astérisques correspondent à n'importe quelle séquence de caractères. NGINX utilise la syntaxe Perl pour les expressions régulières ; utilisez un tilde (~) avant eux. un nom exact.
server {
listen 127.0.0.1:8080;
# The rest of server configuration
}Si l'en-tête de l'hôte correspond à plusieurs noms, NGINX recherche les noms dans l'ordre suivant et utilise le premier Match pour en sélectionner un :
.Nom exact (nom exact complet)
Le caractère générique le plus long commençant par un astérisque, par exemple : * .example.org
Le caractère générique le plus long se terminant par un astérisque, tel que : mail.*
La première expression régulière correspondante (dans l'ordre dans lequel elles apparaissent dans le fichier de configuration)
Si le champ d'en-tête de l'hôte ne correspond pas au nom du serveur, NGINX acheminera la requête vers le serveur par défaut pour le port d'arrivée de la requête. Le serveur par défaut est le fichier de configuration nginx, sauf si vous incluez le paramètre listening_server dans la directive d'écoute. pour spécifier explicitement le serveur par défaut.
server {
listen 80;
server_name example.org www.example.org;
...
}:
server {
listen 80 default_server;
...
}/data/www/vhost12. 🎜>NGINX peut envoyer du trafic vers différents proxys ou servir différents fichiers en fonction de l'URI de la requête. Ces blocs sont définis à l'aide de la directive d'emplacement placée dans la directive du serveur /data/www/vhost2Par exemple, vous pouvez définir trois blocs d'emplacement pour instruire le serveur virtuel. pour envoyer certaines requêtes à un serveur proxy, envoyer d'autres requêtes à un autre serveur proxy et répondre aux requêtes restantes en transmettant des fichiers depuis le système de fichiers local.
Le test NGINX demande l'URI en fonction des paramètres de toutes les directives d'emplacement et applique les directives définies dans l'emplacement correspondant. Au sein de chaque bloc de localisation, il est généralement possible (à quelques exceptions près) de placer des directives de localisation supplémentaires pour affiner davantage le traitement d'un groupe spécifique de demandes. Remarque : Dans cet article du didacticiel, le mot emplacement fait référence à un contexte d'emplacement unique. La directive
location a deux types de paramètres : la chaîne de préfixe (nom de chemin) et l'expression régulière. Pour qu’un URI de requête corresponde à une chaîne de préfixe, il doit commencer par la chaîne de préfixe.
L'exemple d'emplacement suivant avec le paramètre pathname correspond à un URI de requête commençant par /some/path/, tel que
, qui ne correspond pas àcar
n'apparaît pas au début de cet URI.server {
listen 80;
server_name vhost1.com www.vhost1.com;
index index.html index.html;
root /data/www/vhost1;
access_log /var/log/vhost1.com.log;
}
server {
listen 80;
server_name vhost2.com www.vhost2.com;
index index.html index.html;
root /data/www/vhost2;
access_log /var/log/vhost2.com.log;
}location /some/path/ {
...
}/some/path/document.htmlÀ moins que le modificateur ^~ soit utilisé pour donner une priorité plus élevée à l'expression régulière. Parmi les chaînes de préfixes, NGINX choisit la chaîne la plus spécifique (c'est-à-dire la chaîne la plus longue et la plus complète). La logique exacte pour choisir où traiter les requêtes est donnée ci-dessous : /my-site/some/path/some/path
Testez la chaîne de préfixe pour tous les URI. Le modificateur
= (signe égal) définit une correspondance exacte entre l'URI et la chaîne de préfixe. Si une correspondance exacte est trouvée, la recherche s'arrête.
如果^~(插入符号)修饰符预先添加最长匹配前缀字符串，则不会检查正则表达式。
存储最长匹配的前缀字符串。
根据正则表达式测试URI。
断开第一个匹配的正则表达式并使用相应的位置。
如果没有正则表达式匹配，则使用与存储的前缀字符串相对应的位置。
=修饰符的典型用例是/(正斜杠)的请求。 如果请求/是频繁的，则指定=/作为location指令的参数加速处理，因为搜索匹配在第一次比较之后停止。
location = / {
...
}location上下文可以包含定义如何解析请求的指令 - 提供静态文件或将请求传递给代理的服务器。 在以下示例中，匹配第一个location上下文的请求将从/data/images目录中提供文件，并将匹配第二个位置的请求传递给承载 www.example.com 域内容的代理服务器。
server {
location /images/ {
root /data;
}
location / {
proxy_pass http://www.example.com;
}
}root指令指定要在其中搜索要提供的静态文件的文件系统路径。 与该位置相关联的请求URI将附加到路径，以获取要提供的静态文件的全名。 在上面的示例中，要响应/images/logo.png的请求，NGINX提供服务器本地实际对应文件是：/data/images/logo.png。
proxy_pass指令将请求传递给使用配置的URL访问代理服务器。然后将代理服务器的响应传回客户端。在上面的示例中，所有不以/images/开头的URI的请求都将被传递给代理的服务器(也就是：www.example.com)。
3. 使用变量
可以使用配置文件中的变量，使NGINX进程的请求根据定义的情况而有所不同。 变量是在运行时计算的命名值，用作指令的参数。 一个变量由它的名字开头的$(美元)符号表示。 变量根据NGINX的状态定义信息，例如正在处理的请求的属性。
有许多预定义的变量，如核心HTTP变量，您可以使用set，map和geo指令定义自定义变量。 大多数变量在运行时计算的，并包含与特定请求相关的信息。 例如，$remote_addr包含客户端IP地址，$uri保存当前的URI值。
4. 返回特定状态码
一些网站URI需要立即返回具有特定错误或重定向代码的响应，例如当页面被暂时移动或永久移动时。 最简单的方法是使用return指令。 例如返回未找到的404状态码：
location /wrong/url {
return 404;
}返回的第一个参数是响应代码。可选的第二个参数可以是重定向的URL(代码301,302,303和307)或在响应体中返回文本。 例如：
location /permanently/moved/url {
return 301 http://www.example.com/moved/here;
}返回指令可以包含在 location 和 server 上下文中。
重写URI请求
可以通过使用rewrite指令在请求处理期间多次修改请求URI，该指令具有一个可选参数和两个必需参数。 第一个(必需)参数是请求URI必须匹配的正则表达式。 第二个参数是用于替换匹配URI的URI。 可选的第三个参数是可以停止进一步重写指令的处理或发送重定向(代码301或302)的标志。例如：
location /users/ {
rewrite ^/users/(.*)$ /show?user=$1 break;
}如该示例所示，用户通过匹配正则表达式捕获第二个参数。
您可以在location 和 server上下文中包含多个rewrite指令。 NGINX按照它们发生的顺序逐个执行指令。 当选择该上下文时，server上下文中的rewrite指令将被执行一次。
在NGINX处理一组rewrite指令之后，它根据新的URI选择一个location上下文。 如果所选location块包含rewrite指令，则依次执行它们。 如果URI与其中任何一个匹配，则在处理所有定义的rewrite指令之后，将搜索新location块。
以下示例显示了与返回指令相结合的rewrite指令。
server {
...
rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;
rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra last;
return 403;
...
}此示例配置区分两组URI。 诸如/download/some/media/file之类的URI更改为/download/some/mp3/file.mp3。由于最后一个标志，所以跳过后续指令(第二次rewrite和return指令)，但NGINX继续处理该请求，该请求现在具有不同的URI。类似地，诸如/download/some/audio/file的URI被替换为/download/some/mp3/file.ra。 如果URI与rewrite指令不匹配，则NGINX将403错误代码返回给客户端。
有两个中断处理重写指令的参数：
last - 停止执行当前服务器或位置上下文中的重写指令，但是NGINX会搜索与重写的URI匹配的位置，并且应用新位置中的任何重写指令(URI可以再次更改，往下继续匹配)。
break - 像break指令一样，在当前上下文中停止处理重写指令，并取消搜索与新URI匹配的位置。新位置(location)块中的rewrite指令不执行。
5. 重写HTTP响应
有时您需要重写或更改HTTP响应中的内容，将一个字符串替换为另一个字符串。 您可以使用sub_filter指令来定义要应用的重写。 该指令支持变量和替代链，使更复杂的更改成为可能。
例如，您可以更改引用除代理服务器之外的绝对链接：
location / {
sub_filter /blog/ /blog-staging/;
sub_filter_once off;
}另一个示例将方法从http://更改为http://，并从请求头域替换本地主机地址到主机名。 sub_filter_once指令告诉NGINX在一个位置(location)内连续应用sub_filter伪指令：
location / {
sub_filter 'href="http://127.0.0.1:8080/' 'href="http://$host/';
sub_filter 'img src="http://127.0.0.1:8080/' 'img src="http://$host/';
sub_filter_once on;
}请注意，如果发生另一个sub_filter匹配，则使用sub_filter修改的响应部分将不再被替换。
处理错误
使用error_page指令，您可以配置NGINX返回自定义页面以及错误代码，替换响应中的其他错误代码，或将浏览器重定向到其他URI。 在以下示例中，error_page指令指定要返回404页面错误代码的页面(/404.html)。
error_page 404 /404.html;
请注意，此伪指令并不立即返回该错误(返回指令执行该操作)，而仅仅是指定发生时如何处理错误。 错误代码可以来自代理服务器，或者在NGINX处理期间发生(例如，当NGINX找不到客户端请求的文件时，显示404对应的结果)。
在以下示例中，当NGINX找不到页面时，它会将代码301替换为代码404，并将客户端重定向http:/example.com/new/path.html。 当客户端仍尝试访问其旧URI的页面时，此配置非常有用。 301代码通知浏览器页面已经永久移动，并且需要在返回时自动替换旧地址。
location /old/path.html {
error_page 404 =301 http:/example.com/new/path.html;
}以下配置是在未找到文件时将请求传递给后端的示例。 因为在error_page指令的等号之后没有指定状态代码，所以对客户机的响应具有代理服务器返回的状态代码(不一定是404)。
server {
...
location /images/ {
# Set the root directory to search for the file
root /data/www;
# Disable logging of errors related to file existence
open_file_cache_errors off;
# Make an internal redirect if the file is not found
error_page 404 = /fetch$uri;
}
location /fetch/ {
proxy_pass http://backend/;
}
}当没有找到文件时，error_page指令指示NGINX进行内部重定向。 error_page指令的最终参数中的$uri变量保存当前请求的URI，该URI在重定向中被传递。
例如，如果没有找到/images/some/file，它将被替换为/fetch/images/some/file，并且新的搜索位置(location)开始。最后请求最终在第二个location上下文中，并被代理到http://backend/。
如果没有找到文件，则open_file_cache_errors指令可防止写入错误消息。 因为丢失的文件可被正确地处理，但这不是必需的。
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
