Comment lire les journaux d'accès Nginx

Quand quelque chose ne fonctionne pas, le journal d'accès raconte une histoire. Qui a accédé au site. Ce qu'ils ont demandé. Quelles URL ont échoué. Quand un pic a commencé. J'ai utilisé ces étapes sur un projet réel et elles ont fonctionné. Les exemples ci-dessous peuvent être copiés et exécutés en toute sécurité, puis ajustés pour votre configuration.

Qu'est-ce que les journaux d'accès Nginx ?

Les journaux d'accès Nginx sont des fichiers texte qui enregistrent chaque requête HTTP que votre serveur web reçoit. Chaque ligne représente une requête et contient des détails tels que l'adresse IP du client, l'horodatage, la méthode HTTP, le chemin de l'URL, le code de statut, la taille de la réponse, et plus encore.

Ces journaux sont générés automatiquement par Nginx au fur et à mesure qu'il traite les requêtes. Chaque fois que quelqu'un visite votre site, clique sur un lien, soumet un formulaire ou même accède à une URL cassée, Nginx écrit une ligne dans le journal d'accès. Cela se produit en temps réel, donc le fichier journal ne cesse de croître.

Comment fonctionnent les journaux d'accès

Nginx utilise un format de journal configurable défini dans votre fichier nginx.conf. Le format par défaut ressemble à ceci :

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent"';

Cela crée des entrées de journal comme ceci :

192.168.1.100 - - [20/Aug/2025:10:30:45 +0000] "GET /blog/post HTTP/1.1" 200 1234 "https://example.com/" "Mozilla/5.0..."

De nombreuses configurations modernes utilisent un format plus détaillé de type JSON avec des paires clé=valeur, ce que supposent les exemples de cet article.

CDN vs Origine : Où chercher les journaux

Si vous utilisez un CDN (comme Cloudflare, CloudFront ou Fastly), il y a deux ensembles de journaux différents à considérer :

Journaux de périphérie du CDN : Affichent les requêtes des utilisateurs réels accédant au CDN. Ceux-ci contiennent les véritables adresses IP des clients, les agents utilisateurs et les emplacements géographiques.

Journaux du serveur d'origine (ce que cet article couvre) : Affichent les requêtes qui ont traversé le CDN jusqu'à votre serveur Nginx. Ces journaux montrent souvent l'adresse IP du CDN comme client, et non l'adresse IP de l'utilisateur final.

Pour le dépannage, vous voulez généralement d'abord les journaux du CDN. Ne consultez les journaux d'origine que lorsque vous avez besoin de voir ce qui a réellement atteint votre serveur ou lorsque vous dépanner des problèmes côté serveur.

Tous les exemples supposent des journaux clé=valeur (champs comme status="404" et request="GET /path HTTP/1.1"), et des fichiers sous /var/log/nginx/. Ajustez les noms si nécessaire.

Ce que vous allez apprendre

• Comment lire les journaux en direct et compressés en une seule fois
• Comment trouver les adresses IP principales et les URL défaillantes principales
• Comment extraire tout d'une adresse IP
• Comment zoomer sur une courte fenêtre temporelle
• Comment lier les journaux d'accès aux blocages WAF
• Comment garder les résultats rapides et utiles

Démarrage rapide

Lire tout, que le fichier soit .log ou .gz :

zgrep -h . /var/log/nginx/ssl-*.access.log*

Cette astuce zgrep gère à la fois les fichiers normaux et les fichiers archivés. Ajoutez des filtres après.

Outils que vous utiliserez

zgrep : Comme grep mais fonctionne sur les fichiers réguliers et les fichiers compressés (.gz). Parfait pour les fichiers journaux qui sont archivés et compressés.

awk : Un outil puissant de traitement de texte qui peut diviser les lignes par délimiteurs et extraire des champs spécifiques. Idéal pour analyser des formats de journaux structurés.

cut : Extrait des colonnes ou des champs spécifiques du texte. Utilisez -d pour spécifier un délimiteur (comme des guillemets ou des virgules) et -f pour choisir le numéro de champ souhaité.

Trouver les adresses IP principales derrière les tempêtes de 404

Lorsque les éditeurs signalent "beaucoup de liens brisés", commencez ici.

zgrep -h . /var/log/nginx/ssl-*.access.log* \
| awk -F'status="' '$2 ~ /^404"/' \
| awk -F'x_forwarded_for="' '{print $2}' \
| cut -d'"' -f1 | cut -d',' -f1 \
| LC_ALL=C sort | uniq -c | sort -nr | head

Pourquoi c'est utile. Vous voyez les pires contrevenants en premier. Si une adresse IP analyse des chemins aléatoires, vous la repérerez rapidement.

Voir tout ce qu'une seule adresse IP a fait

Pratique lorsque vous devez expliquer un blocage ou un pic provenant d'une seule source.

IP="112.134.209.112"
zgrep -h . /var/log/nginx/ssl-*.access.log* \
| grep -F 'x_forwarded_for="'$IP

Astuce. Dans certaines piles, l'adresse IP du client peut se trouver dans src ou src_ip. Si c'est le cas, remplacez le nom du champ dans le grep.

URL principales accédées par cette adresse IP (ignorer les chaînes de requête)

IP="112.134.209.112"
zgrep -h . /var/log/nginx/ssl-*.access.log* \
| grep -F 'x_forwarded_for="'$IP \
| awk -F'request="' '{print $2}' | cut -d'"' -f1 \
| awk '{print $2}' | cut -d'?' -f1 \
| LC_ALL=C sort | uniq -c | sort -nr | head

Pourquoi c'est utile. La suppression de la chaîne de requête regroupe "la même page avec des paramètres différents", ce qui rend les modèles évidents.

URL défaillantes principales par statut

404 :

zgrep -h . /var/log/nginx/ssl-*.access.log* \
| awk -F'status="' '$2 ~ /^404"/' \
| awk -F'request="' '{print $2}' | cut -d'"' -f1 \
| awk '{print $2}' | cut -d'?' -f1 \
| LC_ALL=C sort | uniq -c | sort -nr | head

5xx :

zgrep -h . /var/log/nginx/ssl-*.access.log* \
| awk -F'status="' '{split($2,a,"\""); if (a[1] ~ /^5[0-9][0-9]$/) print}' \
| awk -F'request="' '{print $2}' | cut -d'"' -f1 \
| awk '{print $2}' | cut -d'?' -f1 \
| LC_ALL=C sort | uniq -c | sort -nr | head

Pourquoi c'est utile. Cela vous donne une liste classée des chemins problématiques. Corrigez les cinq premiers et vous corrigez souvent la plupart des problèmes.

Zoomer sur une courte fenêtre temporelle

Lorsqu'un pic survient à une heure connue, vous voulez le avant et le après.

Simple et rapide (suffisant pour une fenêtre de 10 minutes dans la même heure) :

# Exemple : 09/Aug/2025 23:15–23:25
zgrep -h 'time_local="' /var/log/nginx/ssl-*.access.log* \
| egrep '09/Aug/2025:23:1[5-9]|09/Aug/2025:23:2[0-5]'

Envoyez le résultat à l'un des comptages ci-dessus.

Pourquoi c'est utile. Vous comparez le trafic juste avant et juste après un événement, ce qui est souvent tout ce dont vous avez besoin pour voir ce qui a changé.

Requêtes POST et gros corps

Les requêtes POST volumineuses vers un formulaire peuvent déclencher des règles WAF. Mesurez-les.

PATH_RE="/about/.*speaker-request-form"
zgrep -h . /var/log/nginx/ssl-*.access.log* \
| awk -F'request="' -v r="$PATH_RE" '
  { split($2,a,"\""); split(a[1],b," "); m=b[1]; u=b[2];
    if (m=="POST" && u ~ r) print }' \
| awk -F'request_length="' '{print $2}' | cut -d'"' -f1 \
| awk '{sum+=$1; c++} END{print "POST count="c, "avg_request_length=" (c?sum/c:0)}'

Pourquoi c'est utile. Si la taille moyenne des requêtes est élevée, votre WAF peut bloquer l'inspection. Vous avez maintenant des preuves et des chiffres.

Lier les journaux d'accès aux blocages WAF

1. Récupérez l'heure exacte et la règle de votre événement WAF.
2. Filtrez les journaux d'accès pour cette fenêtre en utilisant l'astuce de la "fenêtre temporelle".
3. Recherchez le même chemin, la même adresse IP ou une grande taille de requête (request_length).
4. Si la règle WAF concerne la taille du corps ou les limites d'inspection, confirmez avec l'analyse POST ci-dessus.

Cela boucle la boucle. Vous pouvez dire ce qui s'est passé et pourquoi.

Conseils de vitesse qui comptent

• Filtrez tôt. Ajoutez grep 'status="404"' avant de trier.
• Utilisez LC_ALL=C sort pour un tri plus rapide et stable.
• Supprimez les chaînes de requête pour regrouper les pages par chemin.
• Échantillonnez d'abord. Exécutez head sur un pipeline pour vérifier que vous découpez le bon champ.
• Documentez votre log_format dans le dépôt. Votre futur vous remerciera.

Pièges courants

• Compter par remote_addr lorsque votre application se trouve derrière un proxy. Utilisez x_forwarded_for ou votre champ d'adresse IP client réel.
• Supposer que tous les fichiers journaux utilisent le même format. Vérifiez votre log_format nginx.conf avant l'analyse.
• Oublier que les journaux archivés (fichiers .gz) nécessitent zgrep, pas grep.
• Utiliser des modèles regex complexes qui échouent lorsque les formats de journaux changent. Restez simple.

Points à retenir

Les journaux répondent rapidement à de vraies questions. Commencez par une question claire, envoyez uniquement ce dont vous avez besoin, et comptez. Liez ce que vous voyez dans Nginx à ce que votre WAF signale. Vous passerez de "quelque chose semblait lent" à "cette URL a échoué 2 379 fois depuis une adresse IP en dix minutes, et voici la solution".