Configuration commune de Nginx
Avant d'introduire la configuration de nginx, parlons brièvement de l'installation de nginx dans le système Linux. Suivez les étapes ci-dessous pour installer avec succès
Adresse de téléchargement de nginx : https://nginx.org/en/download.html
执行：yum -y install gcc gcc-c++ automake autoconf libtool make
Installer pcre : yum -y install pcre pcre-devel
安装zlib：yum -y install zlib zlib-devel
安装openssl ：yum -y install openssl openssl-devel
Décompression : tar -zvxf nginx-1.20.2.tar.gz
Entrez le répertoire racine nginx : cd /usr/local/nginx/nginx-1.20.2
Exécuter : **./configure**
compiler : faire
Installation : **faites l'installation**
Exécuter : cd /usr/local/nginx/sbin
Démarrez le service nginx : **./nginx**
Fermer le service nginx : ./nginx -s stop
Redémarrez le service nginx : ./nginx -s reload
Fichier de configuration de la détection : nginx -t -c ~/youSite.conf
Premier regard, supprimez les commentaires dans le fichier nginx.conf, la configuration la plus simple est la suivante :
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
élément de configuration de bloc
Dans le code ci-dessus, les événements, http, le serveur, l'emplacement, etc. sont tous des éléments de configuration de bloc. Les éléments de configuration de bloc peuvent être imbriqués. Le bloc intérieur hérite directement du bloc extérieur. En cas de conflit entre les configurations des blocs intérieur et extérieur, la configuration du bloc intérieur prévaut.
Format de syntaxe des éléments de configuration
配置项名
配置项值
1 配置项值
2 ...
;
Remarque : Un point-virgule est requis à la fin de chaque ligne de configuration
Nombre de processus de travail Nginx
Syntaxe : nombre de processus de travail ;
Par défaut : worker_processes 1 ;
Configuration normale : combien de processus doivent être configurés en fonction du nombre de cœurs de processeur.
Nombre maximum de connexions par worker
Syntaxe : numéro de worker_connections ;
Configurer un serveur Web statique avec le module principal HTTP
port d'écoute
语法： listen address:port[default(deprecated in 0.8.21)|default_server|
Par défaut : écouter 80 ;
Bloc de configuration : serveur
Vous ne pouvez ajouter une adresse IP, un port ou un nom d'hôte qu'après avoir écouté
nom d'hôte
Syntaxe : nom_serveur nom[…] ;
Par défaut : nom_serveur "" ;
Bloc de configuration : serveur
Utilisez l'élément de configuration server_name pour fournir différents services pour les demandes provenant de noms de domaine hôtes spécifiques, et la valeur de configuration server_name peut être une adresse IP
server_names_hash_bucket_size
语法 : server_names_hash_bucket_size size ;
Par défaut : server_names_hash_bucket_size 32|64|128 ;
Bloc de configuration : http, serveur, emplacement
Afin d'améliorer la capacité à trouver rapidement le nom du serveur correspondant, Nginx utilise une table de hachage pour stocker le nom du serveur. server_names_hash_bucket_size définit la taille de la mémoire occupée par chaque seau de hachage
nom_serveur_hash_max_size
语法： server_names_hash_max_size size ;
Par défaut : server_names_hash_max_size 512 ;
Bloc de configuration : http, serveur, emplacement
Plus le server_names_hash_max_size est grand, plus la mémoire sera consommée, mais le taux de collision de la clé de hachage sera réduit et la vitesse de récupération sera plus rapide.
Plus le server_names_hash_max_size est petit, plus la consommation de mémoire est petite, mais le taux de collision de la clé de hachage peut augmenter.
Gestion des noms d'hôtes redirigés
Syntaxe : nom_serveur_en_redirection on|off ;
Par défaut : server_name_in_redirect on ;
Bloc de configuration : http, serveur, emplacement
Lorsque vous utilisez on pour ouvrir, cela signifie que le premier nom d'hôte configuré dans nom_serveur sera utilisé pour remplacer l'en-tête Host dans la demande d'origine lors de la redirection de la demande.
Lorsque off est utilisé, cela signifie que l'en-tête Host de la demande elle-même est utilisée lors de la redirection de la demande.
emplacement
Syntaxe : emplacement[=| | *|^~|@]/uri/{…}
Bloc de configuration : serveur
location essaiera de faire correspondre l'expression /uri ci-dessus en fonction de l'URI dans la demande de l'utilisateur. Si cela peut correspondre, la configuration dans le bloc location{} sera sélectionnée pour traiter la demande de l'utilisateur. Bien sûr, il existe différentes méthodes de mise en correspondance. Voici les règles de mise en correspondance des lieux.
= indique que l'URI est utilisé comme une chaîne pour correspondre entièrement à l'URI dans le paramètre
location = / {#只有当用户请求是/时，才会使用该location下的配置
…
}
~ Indique que l'URI est sensible à la casse lors de la correspondance des lettres.
~* signifie ignorer la casse des lettres lors de la correspondance de l'URI.
^~ indique que seule la première moitié de l'URI doit être mise en correspondance avec le paramètre uri lors de la mise en correspondance de l'URI
location ^~ images {# 以images开始的请求都会匹配上
…
}
Les expressions régulières peuvent être utilisées dans le paramètre uri
location ~* \.(gif|jpg|jpeg)$ {# 匹配以.gif、.jpg、.jpeg结尾的请求
…
}
/ signifie correspondre à toutes les demandes
location / {# /可以匹配所有请求
…
}
Définition du chemin du fichier (couramment utilisé)
Définissez le chemin de la ressource en tant que racine
Syntaxe : chemin racine ;
Par défaut : racine html ;
Bloc de configuration : http, serveur, emplacement, si
Définit le répertoire racine des fichiers de ressources relatifs à la requête HTTP.
Dans la configuration suivante, s'il existe une requête URI est /download/index/test.html, le serveur Web renverra le contenu du fichier opt web html download/index/test.html sur le serveur.
location /download/ {
root optwebhtml;
}
Définir le chemin de la ressource en mode alias
Syntaxe : chemin d'alias ;
Bloc de configuration : emplacement
L'alias est également utilisé pour définir le chemin d'accès aux ressources du fichier. La différence entre lui et la racine réside dans la manière d'interpréter le paramètre uri immédiatement après l'emplacement, ce qui amènera l'alias et la racine à mapper les demandes des utilisateurs sur des fichiers de disque réels de différentes manières. Si l'URI d'une requête est /download/image/avator.jpg, et que le fichier auquel l'utilisateur souhaite réellement accéder se trouve dans usr local/usr/image/avator.jpg, alors si vous souhaitez utiliser un alias pour le définir, vous peut utiliser la méthode suivante :
location /download/image {
alias /usr/image/;
}
Si vous utilisez le paramètre racine, l'instruction est la suivante et l'URI d'accès devient /image/avator.jpg :
location /image {
root /usr/;
}
Des expressions régulières peuvent également être ajoutées après l'alias, et Nginx renverra le contenu du fichier usr local/nginx/conf/nginx.conf lors de l'accès à la requête vers /test/nginx.conf
location ~ ^/test/(\w+)\.(\w+)$ {
alias usrlocal/nginx/$2/$1.$2;
}
visiter la page d'accueil
Syntaxe : fichier d'index... ;
Par défaut : index index.html ;
Bloc de configuration : http, serveur, emplacement
L'index peut être suivi de plusieurs paramètres de fichier, et Nginx accédera à ces fichiers dans l'ordre, par exemple :
Nginx essaiera d'abord d'accéder au fichier path/index.php. S'il est accessible, il retournera directement le contenu du fichier pour terminer la requête, sinon il essaiera de retourner le contenu du fichier path html index.php , et ainsi de suite.
location {
root path;
index index.html htmlindex.php /index.php;
}
Rediriger les pages en fonction des codes de retour HTTP
语法： error_page code[code…][=|=answer-code]uri|@named_location
Bloc de configuration : http, serveur, emplacement, si
Lorsqu'un code d'erreur est renvoyé pour une requête, s'il correspond au code défini dans error_page, redirigez vers le nouvel URI. Par exemple:
error_page 404 404.html;
error_page 502 503 504 50x.html;
error_page 403 http://example.com/forbidden.html;
error_page 404 = @fetch;
Si vous ne souhaitez pas modifier l'URI, mais souhaitez simplement rediriger une telle demande vers un autre emplacement pour traitement, vous pouvez la définir comme ceci, et la demande qui renvoie 404 sera inversée par proxy vers le http://backend serveur en amont pour le traitement.
location / (
error_page 404 @fallback;
)
location @fallback (
proxy_pass http://backend;
)
try_files
Syntaxe : try_files path1[path2]uri ;
Bloc de configuration : serveur, emplacement
Après try_files, il doit y avoir plusieurs chemins, comme path1 path2..., et il doit y avoir un paramètre uri à la fin. La signification est la suivante : essayez d'accéder à chaque chemin dans l'ordre, et s'il peut être lu efficacement, retourner directement la demande de fin de fichier correspondant à ce chemin à l'utilisateur, sinon poursuivre la visite vers le bas. Si aucun fichier valide ne peut être trouvé pour tous les chemins, redirigez vers le dernier paramètre uri. Par conséquent, le dernier paramètre uri doit exister et doit être valide pour la redirection. Par exemple:
try_files systemmaintenance.html $uri $uri/index.html $uri.html @other;
location @other {
proxy_pass http://backend;
}
Allocation de ressources mémoire et disque
Le corps du paquet HTTP est uniquement stocké dans un fichier disque
语法： client_body_in_file_only on|clean|off ;
Par défaut : client_body_in_file_only désactivé ;
Bloc de configuration : http, serveur, emplacement
Lorsque la valeur n'est pas désactivée, le corps du paquet HTTP dans la demande de l'utilisateur est toujours stocké dans le fichier disque, même s'il ne contient que 0 octet, il sera stocké sous forme de fichier. Lorsque la requête se termine, si la configuration est activée, le fichier ne sera pas supprimé (cette configuration est généralement utilisée pour le débogage et la localisation des problèmes), mais s'il est configuré comme propre, le fichier sera supprimé.
Essayez d'écrire le corps du paquet HTTP dans une mémoire tampon
语法： client_body_in_single_buffer on|off ;
默认： client_body_in_single_buffer off ;
Bloc de configuration : http, serveur, emplacement
Le corps du paquet HTTP dans la demande de l'utilisateur est toujours stocké dans la mémoire tampon. Bien sûr, si la taille du corps du paquet HTTP dépasse la valeur définie par client_body_buffer_size, le corps du paquet sera toujours écrit sur le fichier disque.
Taille de la mémoire tampon pour stocker les en-têtes HTTP
语法： client_header_buffer_size taille ;
Par défaut : client_header_buffer_size 1k ;
Bloc de configuration : http, serveur
Les éléments de configuration ci-dessus définissent la taille de la mémoire tampon allouée par Nginx lors de la réception de la partie d'en-tête HTTP (y compris la ligne HTTP et l'en-tête HTTP) dans la demande de l'utilisateur dans des circonstances normales. Parfois, la partie d'en-tête HTTP dans la requête peut dépasser cette taille, alors le tampon défini par large_client_header_buffers prendra effet.
Taille de la mémoire tampon pour stocker de très gros en-têtes HTTP
语法 : taille du nombre large_client_header_buffers ;
Par défaut : large_client_header_buffers 48k ;
Bloc de configuration : http, serveur
Définit le nombre de tampons et la taille de chaque tampon pour que Nginx reçoive une requête d'en-tête HTTP surdimensionnée. Si la taille de la ligne de requête HTTP (telle que GET /index HTTP/1.1) dépasse le seul tampon ci-dessus, renvoie "Request URI too large" (414). Il y a généralement de nombreux en-têtes dans la requête, et la taille de chaque en-tête ne peut pas dépasser la taille d'un seul tampon, sinon "Mauvaise requête" (400) sera renvoyée. Bien sûr, la somme de la ligne de requête et de l'en-tête de requête ne peut pas dépasser le nombre de tampons * taille de tampon.
La taille de la mémoire tampon pour stocker le corps du paquet HTTP
语法： taille client_body_buffer_size ;
Par défaut : client_body_buffer_size 8k/16k ;
Bloc de configuration : http, serveur, emplacement
Les éléments de configuration ci-dessus définissent la taille de la mémoire tampon de Nginx recevant des paquets HTTP. C'est-à-dire que le corps du paquet HTTP le recevra d'abord dans le cache spécifié, puis décidera s'il doit l'écrire sur le disque. Si la requête de l'utilisateur contient l'en-tête HTTP Content-Length et que la longueur de l'identifiant est inférieure à la taille de mémoire tampon définie, Nginx réduira automatiquement la mémoire tampon utilisée par cette requête pour réduire la consommation de mémoire.
Paramètres de connexion Internet
Délai d'attente pour la lecture des en-têtes HTTP
Syntaxe : client_header_timeout time (unité par défaut : secondes)
Par défaut : client_header_timeout 60 ;
Bloc de configuration : http, serveur, emplacement
Une fois que le client a établi une connexion avec le serveur, il commencera à recevoir l'en-tête HTTP. Au cours de ce processus, si l'octet envoyé par le client n'est pas lu dans un intervalle de temps (période d'expiration), il sera considéré comme expiré et renvoyé à client. Réponse 408 ("Request timed out")
Délai d'attente pour la lecture du corps du paquet HTTP
Syntaxe : client_body_timeout time (unité par défaut : secondes) ;
Par défaut : client_body_timeout 60 ;
Bloc de configuration : http, serveur, emplacement
Délai d'attente pour l'envoi des réponses
Syntaxe : temps d'envoi_timeout ;
Par défaut : send_timeout 60 ;
Bloc de configuration : http, serveur, emplacement
Ce délai d'attente est le délai d'attente pour l'envoi de la réponse, c'est-à-dire que le serveur Nginx a envoyé un paquet de données au client, mais le client n'a pas reçu le paquet de données. Si une connexion dépasse le délai défini par send_timeout, Nginx fermera la connexion
délai d'attente keepalive
Syntaxe : keepalive_timeout time (unité par défaut : secondes) ;
Par défaut : keepalive_timeout 75 ;
Bloc de configuration : http, serveur, emplacement
Après qu'une connexion keepalive est inactive pendant un certain temps (la valeur par défaut est de 75 secondes), le serveur et le navigateur fermeront la connexion. Bien sûr, l'élément de configuration keepalive_timeout est utilisé pour contraindre le serveur Nginx, et Nginx transmettra également ce temps au navigateur conformément à la spécification, mais chaque navigateur peut avoir une stratégie différente pour rester en vie.
Le nombre maximum de requêtes autorisées sur une longue connexion keepalive
Syntaxe : keepalive_requests n ;
Par défaut : keepalive_requests 100 ;
Bloc de configuration : http, serveur, emplacement
Une connexion keepalive ne peut envoyer que 100 requêtes par défaut
Limitations sur les demandes des clients
Limiter les demandes des utilisateurs par nom de méthode HTTP
Syntaxe : méthode limit_except...{...}
Bloc de configuration : emplacement
Nginx limite les demandes des utilisateurs via le nom de méthode spécifié après limit_except. Les valeurs possibles pour le nom de la méthode incluent : GET, HEAD, POST, PUT, DELETE, MKCOL, COPY, MOVE, OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK ou PATCH. Par exemple:
limit_except GET {
allow 192.168.1.0/32;
deny all;
}
Remarque ; autoriser la méthode GET implique également d'autoriser la méthode HEAD. Par conséquent, ce code signifie que la méthode GET et la méthode HEAD sont interdites, mais que les autres méthodes HTTP sont autorisées.
La taille maximale du corps de la requête HTTP
Syntaxe : client_max_body_size taille ;
Par défaut : client_max_body_size 1 m ;
Bloc de configuration : http, serveur, emplacement
Lorsqu'un navigateur envoie une requête avec un corps de paquet HTTP volumineux, son en-tête aura un champ Content-Length et client_max_body_size est utilisé pour limiter la taille de la valeur affichée par Content-Length. Par conséquent, cette configuration de limitation du corps du package est très utile, car sans attendre que Nginx reçoive tous les corps du package HTTP - ce qui peut prendre beaucoup de temps - elle peut indiquer à l'utilisateur que la requête est trop volumineuse et ne peut pas être acceptée. Par exemple, lorsqu'un utilisateur essaie de télécharger un fichier de 10 Go, après avoir reçu l'en-tête, Nginx constate que la longueur du contenu dépasse la valeur définie par client_max_body_size et envoie directement une réponse 413 ("Request EntityToo Large") au client.
limite de taux sur les demandes
Syntaxe : limit_rate vitesse ;
Par défaut : limit_rate 0 ;
Bloc de configuration : http, serveur, emplacement, si
Cette configuration limite le nombre d'octets transférés par seconde sur les demandes des clients. La vitesse peut utiliser diverses unités mentionnées dans la section 2.2.4, et le paramètre par défaut est 0, ce qui signifie qu'il n'y a pas de limite de vitesse. Pour différents clients, vous pouvez utiliser le paramètre $limit_rate pour implémenter différentes stratégies de limitation de débit. Par exemple:
server {
if ($slow) {
set $limit_rate 4k;
}
}
limit_rate_after
Syntaxe : limit_rate_after time ;
Par défaut : limit_rate_after 1 m ;
Bloc de configuration : http, serveur, emplacement, si
Cette configuration signifie que Nginx commence à limiter le débit après que la longueur de la réponse envoyée au client dépasse limit_rate_after. Par exemple:
limit_rate_after 1m;
limit_rate 100k;
Configurer un serveur proxy inverse avec le module proxy HTTP
Le processus de transfert des demandes lorsque Nginx agit comme un serveur proxy inverse
Configuration de base du proxy inverse
proxy_pass
Syntaxe : URL proxy_pass ;
Bloc de configuration : emplacement, si
Cet élément de configuration renvoie par proxy inverse la requête en cours au serveur spécifié par le paramètre URL,
L'URL peut être sous la forme d'un nom d'hôte ou d'une adresse IP plus un port
proxy_pass http://localhost:8000/uri/;
Vous pouvez également utiliser le bloc en amont directement comme indiqué dans la section d'équilibrage de charge ci-dessus
upstream backend {
…
}
server {
location / {
proxy_pass http://backend;
}
}
Peut convertir HTTP en HTTPS plus sécurisé
proxy_pass https://192.168.0.1;
Configuration de base de l'équilibrage de charge
bloc amont
Syntaxe : nom en amont{...}
Bloc de configuration : http
Le bloc en amont définit un cluster de serveurs en amont, ce qui est pratique pour proxy_pass dans le proxy inverse. Par exemple:
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
location / {
proxy_pass http://backend;
}
}
rompre
Syntaxe : nom du serveur[paramètres] ;
Bloc de configuration : en amont
L'élément de configuration du serveur spécifie le nom d'un serveur en amont, qui peut être un nom de domaine, un port d'adresse IP, un identifiant UNIX, etc., suivi des paramètres suivants.
weight=number : définit le poids transmis à ce serveur en amont, la valeur par défaut est 1.
upstream backend {
server backend1.example.com weight=5;
server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
server unix:/tmp/backend3;
}
ip_hash
Syntaxe : ip_hash ;
Bloc de configuration : en amont
Calculez une clé basée sur l'adresse IP du client, prenez la clé en fonction du nombre de serveurs en amont dans le cluster en amont, puis transférez la demande au serveur en amont correspondant en fonction du résultat du module. Cela garantit que les demandes du même client ne sont transmises qu'au serveur en amont spécifié
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
server backend4.example.com;
}
Le contenu de cet article provient du livre "Compréhension approfondie du développement de modules Nginx et de l'analyse de l'architecture". Cet article n'est qu'un enregistrement de note d'étude. En cas d'infraction, veuillez me contacter pour supprimer l'article.