Aller au contenu

NGINX-MOD

Comme vous le savez peut-être, notre dépôt contient la dernière version stable de NGINX ainsi qu'un large éventail de modules dynamiques pour celui-ci.

Cependant, certaines personnes axées sur la performance cherchent toujours à accélérer ce qui est déjà rapide - c'est-à-dire NGINX lui-même.

Il existe des correctifs open-source pour cela, principalement par Cloudflare, pour améliorer encore les choses. Pour éviter des tracas à de nombreuses personnes qui dépendent d'une compilation manuelle, nous construisons ce NGINX mieux corrigé en tant que package compatible avec tous les modules NGINX que nous avons ! Son nom officiel est NGINX-MOD.

NGINX-MOD est basé sur le dernier NGINX stable avec les ajouts suivants :

  • Support HTTP/3 sans couture : Profitez de connexions web plus rapides et plus fiables avec le protocole HTTP/3 à la pointe de la technologie.
  • Compression HPACK HTTP/2 améliorée : Améliorez les performances de votre site web grâce à une compression d'en-tête optimisée, garantissant un transfert de données plus rapide.
  • Gestion dynamique des enregistrements TLS : Améliorez à la fois la sécurité et la vitesse avec des enregistrements TLS gérés dynamiquement, s'adaptant aux besoins de votre site en temps réel.
  • Limitation de débit avancée : Obtenez un contrôle précis sur le trafic avec le ngx_http_limit_req_module étendu, vous permettant de définir des limites de requêtes sur une base horaire, quotidienne, hebdomadaire ou annuelle.
  • Surveillance active de la santé : Maintenez un temps de disponibilité et une fiabilité élevés avec des vérifications de santé en temps réel de vos serveurs en amont. En savoir plus
  • Fonctionnalités de sécurité améliorées : Protégez les informations de votre serveur en désactivant l'affichage du nom du logiciel NGINX dans l'en-tête Server : et les pages d'erreur.
  • Proxy SSL sécurisé avec la méthode CONNECT : Gérez et proxy les requêtes SSL en utilisant la méthode CONNECT, garantissant une transmission de données sécurisée et efficace.
  • Support du mode sombre : Support automatique du mode sombre pour les pages d'erreur NGINX.
  • Émulation de l'en-tête Host pour HTTP/3 : Le $http_host est initialisé à partir de l'autorité, offrant une meilleure compatibilité avec les applications qui dépendent de l'en-tête Host.

Passez à GetPageSpeed aujourd'hui et tirez pleinement parti de ces fonctionnalités avancées de NGINX-MOD pour optimiser les performances, la sécurité et la fiabilité de votre site web !

Plus d'informations sur ces correctifs dans la documentation ci-dessous.

Comment installer NGINX-MOD

dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install dnf-plugins-core
dnf config-manager --disable getpagespeed-extras-mainline
dnf config-manager --enable getpagespeed-extras-nginx-mod
dnf -y install nginx-mod
systemctl enable --now nginx

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y install nginx-mod
systemctl enable --now nginx

dnf -y install https://extras.getpagespeed.com/release-latest.rpm
amazon-linux-extras install epel
yum -y install yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y install nginx-mod
systemctl enable --now nginx

Comment passer à NGINX-MOD depuis notre NGINX régulier

Si vous utilisiez notre version régulière de NGINX, vous pouvez exécuter une série de commandes pour passer à NGINX-MOD sans affecter les modules installés ou la configuration :

yum -y install https://extras.getpagespeed.com/release-latest.rpm yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y update nginx
service nginx upgrade

Modules pour NGINX-MOD

NGINX-MOD est entièrement compatible avec plus de 50 packages de modules NGINX dans notre dépôt de base. Vous pouvez donc les installer comme d'habitude, par exemple :

dnf -y install nginx-module-pagespeed

Vérifications de santé actives

Caractéristiques clés des vérifications de santé actives

  • Support multi-protocole : HTTP, TCP, SSL Hello, MySQL, AJP, FastCGI.
  • Vérifications personnalisables : Intervalle, délai d'attente, seuils de succès/échec.
  • Tableau de bord d'état : Surveillance en temps réel via HTML, CSV ou JSON.
  • Ajustements dynamiques : Marquez les serveurs comme en ligne/hors ligne en fonction des vérifications de santé.

Bases de configuration pour les vérifications de santé actives

Exemple : Vérification de santé HTTP

http {
  upstream backend {
    server 192.168.1.10:80;
    server 192.168.1.11:80;

    # Configuration de vérification de santé
    check interval=5s rise=2 fall=3 timeout=4s type=http;
    check_http_send "GET /health HTTP/1.1\r\nHost: example.com\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
  }

  server {
    listen 80;
    location / {
      proxy_pass http://backend;
    }

    # Tableau de bord d'état de santé (accès restreint)
    location /status {
      check_status html;
      allow 10.0.0.0/8;  # IP autorisées
      deny all;
      access_log off;
    }
  }
}

Explication :

  • check :
  • interval=5s : Vérifiez toutes les 5 secondes.
  • rise=2 : Marquez le serveur "en ligne" après 2 succès consécutifs.
  • fall=3 : Marquez le serveur "hors ligne" après 3 échecs consécutifs.
  • type=http : Utilisez des vérifications HTTP.
  • check_http_send : Requête HTTP personnalisée envoyée aux serveurs en amont.
  • check_http_expect_alive : Considérez les réponses HTTP 2xx/3xx comme saines.
  • check_status : Expose un tableau de bord à /status au format HTML.

Référence des directives de vérifications de santé actives

Directives principales

Directive Syntaxe Par défaut Description
check interval=ms [fall=count] [rise=count] [timeout=ms] [type=protocol] [default_down=true\|false] [port=number] interval=30s fall=5 rise=2 timeout=1s type=tcp default_down=true Configure les paramètres de vérification de santé.
check_http_send "HTTP_REQUEST" "GET / HTTP/1.0\r\n\r\n" Requête HTTP personnalisée pour les vérifications type=http.
check_http_expect_alive http_2xx \| http_3xx \| ... http_2xx \| http_3xx Codes d'état HTTP indiquant un serveur sain.

Directives avancées

Directive But
check_keepalive_requests Nombre de requêtes par connexion (par défaut : 1).
check_fastcgi_param Paramètres FastCGI personnalisés pour les vérifications type=fastcgi.
check_shm_size Taille de la mémoire partagée pour les vérifications de santé (par défaut : 1M).

Types de vérifications de santé actives

1. type=http

  • Utilisation : 
    check type=http;
check_http_send "HEAD /health HTTP/1.1\r\nHost: example.com\r\n\r\n";
check_http_expect_alive http_200 http_302;
  • Codes de réponse : Configurez les statuts acceptables (par exemple, http_2xx).

2. type=tcp

  • Vérification simple de connexion TCP : 
    check interval=10s type=tcp;

3. type=mysql

  • Valide la disponibilité du serveur MySQL : 
    check type=mysql port=3306;

4. type=fastcgi

  • Paramètres FastCGI personnalisés : 
    check type=fastcgi;
check_fastcgi_param "REQUEST_METHOD" "GET";
check_fastcgi_param "SCRIPT_FILENAME" "index.php";

Configuration de la page d'état

Configuration de l'endpoint

location /status {
  check_status [html|csv|json];  # Par défaut : html
  allow 192.168.1.0/24;         # Restreindre l'accès
  deny all;
}

Paramètres de requête

  • format : Remplacez le format de sortie (par exemple, /status?format=json).
  • status : Filtrer les serveurs par statut (par exemple, /status?status=down).

Exemples de sorties

  • HTML : Tableau interactif avec l'état des serveurs.
  • JSON : Format lisible par machine pour l'automatisation.
  • CSV : Valeurs séparées par des virgules simplifiées.

Dépannage et meilleures pratiques pour les vérifications de santé actives

Problèmes courants

  1. Mémoire partagée épuisée :

  2. Solution : Augmentez check_shm_size dans le bloc http : 

    http {
  check_shm_size 10M;  # Par défaut : 1M
}

  3. Faux positifs/négatifs :

  4. Ajustez les seuils rise/fall et validez les requêtes check_http_send.

  5. Erreurs de délai d'attente :

  6. Augmentez le timeout si les serveurs en amont répondent lentement.

Conseils de sécurité

  • Restreignez l'accès à l'endpoint /status en utilisant allow/deny.
  • Utilisez HTTPS pour la page d'état si des données sensibles sont exposées.

Les vérifications actives fonctionnent sans problème avec ip_hash, least_conn et des modules tiers comme sticky ou fair.

Patch ngx_http_limit_req_module

Certains utilisateurs de NGINX cherchent à définir une limitation de débit d'une fois par jour pour des ressources spécifiques. Cela n'est pas possible avec le NGINX standard. Notre patch permet une configuration de limitation de débit plus fine. Exemples :

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/h; # 1 requête par heure
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/d; # 1 requête par jour
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/w; # 1 requête par semaine
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/M; # 1 requête par mois
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/Y; # 1 requête par an

Il est important de noter que la taille de mémoire de votre zone définie doit permettre de conserver les anciennes entrées IP avant que le taux défini ne s'applique.

Par exemple, vous avez défini une zone de 10m et 1r/d pour une ressource particulière. 10m peut stocker environ 160 000 adresses IP. Donc, si quelqu'un visite votre ressource limitée par le taux, et que votre trafic vers celle-ci dépasse 160K visiteurs uniques en 24 heures, alors le même visiteur ne peut théoriquement pas être limité par le taux dans la même journée, car les informations concernant son adresse IP seront expulsées de la mémoire après qu'un nombre suffisant de visiteurs ait visité la ressource.

Cette note s'applique également à la configuration du module standard, mais dans une moindre mesure.

Ainsi, les règles de base sont :

  • Vous devez probablement augmenter la zone de mémoire, si votre trafic est suffisant pour pouvoir expulser les anciennes adresses IP "trop tôt"
  • Cela est plus approprié pour limiter le débit de ressources spécifiques, et non de l'ensemble du site web

Qu'est-ce que le patch HPACK

Le patch HPACK implémente full HPACK dans NGINX. En résumé, cela permet de compresser les en-têtes HTTP.

Qu'est-ce que le support de la méthode CONNECT

NGINX-MOD fournit un support pour la requête de méthode CONNECT. Cette méthode est principalement utilisée pour établir des tunnels SSL à travers des serveurs proxy.

Pour activer et configurer, veuillez vous référer aux directives proxy_connect.

Directives de configuration de NGINX-MOD

Il existe certaines directives de configuration dans cette version, qui ne sont pas disponibles dans les versions régulières. Documentons-les ici.

L'ensemble suivant de directives de configuration est ajouté par le patch enregistrements TLS dynamiques.

ssl_dyn_rec_enable on|off

Pour activer ou désactiver les enregistrements TLS dynamiques.

ssl_dyn_rec_size_lo

La taille de l'enregistrement TLS à commencer. Par défaut, 1369 octets (conçu pour contenir l'ensemble de l'enregistrement dans un seul segment TCP : 1369 = 1500 - 40 (IPv6) - 20 (TCP) - 10 (Temps) - 61 (Surcharge maximale TLS)) ssl_dyn_rec_size_hi : la taille de l'enregistrement TLS à atteindre. Par défaut, 4229 octets (conçu pour contenir l'ensemble de l'enregistrement dans 3 segments TCP)

ssl_dyn_rec_threshold

Le nombre d'enregistrements à envoyer avant de changer la taille de l'enregistrement.

Parce que nous construisons avec la dernière version d'OpenSSL :

ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] [TLSv1.3];

Pas une nouvelle directive. Mais puisque nous construisons avec la version stable la plus récente d'OpenSSL, cela permet d'utiliser la valeur TLSv1.3.

Masquer les informations sur le logiciel

Par défaut, NGINX ne prend en charge que server_tokens off; ce qui renvoie toujours nginx dans l'en-tête Server: et dans les pages d'erreur. Avec NGINX-MOD, vous pouvez spécifier une nouvelle valeur none, ce qui fera en sorte que NGINX cesse d'émettre sa présence sur le serveur :

server_tokens none;

Vérification

Pour vérifier comment vous bénéficiez de NGINX-MOD, vous pouvez exécuter quelques tests.

Vérifiez la compression des en-têtes HTTP/2

yum install nghttp2
h2load https://example.com -n 2 | tail -6 |head -1

Exemple de sortie :

traffic: 71.46KB (73170) total, 637B (637) headers (space savings 78.68%), 70.61KB (72304) data

Si vous voyez une économie d'espace de 50 % ou plus, cela signifie que la compression HPACK complète est utilisée.

Comment revenir à NGINX stable

Revenir au package stable tout en préservant la configuration existante :

yum-config-manager --disable getpagespeed-extras-nginx-mod
MOD_PKGS=$(rpm -qa --queryformat '%{NAME}\n' | grep nginx-mod | grep -v nginx-module)
rpm --erase --justdb --nodeps ${MOD_PKGS}
STABLE_PKGS=$(echo ${MOD_PKGS} | sed 's@nginx-mod@nginx@g')
yum -y install ${STABLE_PKGS}
yum history sync

Ces commandes désactiveront le dépôt NGINX-MOD et remplaceront tous les packages nginx-mod* par leurs équivalents du dépôt de base, rétrogradant ainsi à NGINX stable.

Remarques de compatibilité

  • NGINX-MOD n'est actuellement pas compatible avec le panneau de contrôle Plesk