Perché un proxy inverso restituisce un errore 502 dopo la ricostruzione di un container?
Un proxy inverso restituisce un errore 502 dopo la ricostruzione di un container quando non riesce più ad aprire una connessione valida verso l’upstream ricostruito.
La ricostruzione può sostituire il container, assegnare un nuovo indirizzo, scollegare o rinominare una rete Docker, modificare la porta esposta, ripristinare una configurazione incompleta oppure avviare il proxy prima che l’applicazione sia pronta. La diagnosi corretta inizia dal log degli errori del proxy e segue l’indirizzo upstream esatto dal proxy al container, invece di riavviare entrambi i servizi finché l’errore non scompare temporaneamente.
Conferma che l’errore 502 derivi da un problema di connessione all’upstream
Richiedi una volta il dominio interessato e annota il timestamp, lo stato del proxy, l’indirizzo upstream e il messaggio di errore completo. Distingui tra connessione rifiutata, host non trovato, timeout, connessione reimpostata, errore durante l’handshake TLS e risposta non valida.
Un errore 502 indica che il proxy non ha ricevuto una risposta upstream utilizzabile, ma il dettaglio dell’errore determina se la destinazione era assente, irraggiungibile, non in ascolto oppure utilizzava il protocollo sbagliato. Un’attuale guida alla risoluzione dei problemi di NGINX osserva che la ricostruzione di un container può lasciare il proxy a utilizzare un vecchio indirizzo backend finché la risoluzione dei nomi o la configurazione non vengono aggiornate.
Testa direttamente l’applicazione dall’host del proxy o dal container del proxy usando il nome upstream, l’indirizzo, la porta e il protocollo registrati nel log. Se la richiesta diretta fallisce allo stesso modo, concentra l’indagine sul percorso tra proxy e container, senza modificare il DNS pubblico o i certificati.
Confronta la destinazione upstream prima e dopo la ricostruzione
Controlla il nome del container ricostruito, il nome del servizio, l’IP interno, la porta esposta, la porta pubblicata, gli alias di rete e le reti collegate. Confrontali con la configurazione del proxy e con l’ultima destinazione funzionante.
Un problema di nginx-proxy descrive una ricostruzione che ha modificato l’IP del container applicativo mentre il proxy continuava a inviare le richieste all’upstream del container irraggiungibile. Il dominio pubblico era corretto, mentre era cambiata soltanto l’identità dell’upstream privato.
Preferisci un nome stabile del servizio Compose o un alias di rete all’IP del container. Se l’IP è assegnato intenzionalmente in modo fisso, verifica che il servizio ricostruito lo abbia effettivamente ricevuto e che nessun altro container possieda ora quell’indirizzo.
Verifica che il proxy e l’app condividano ancora una rete Docker
Elenca le reti collegate al proxy e all’applicazione e conferma che condividano almeno una rete definita dall’utente. La pubblicazione di una porta sull’host non rende automaticamente raggiungibile il nome del container da un’altra rete Docker isolata.
Un caso di rete Docker ha rilevato che lo spostamento di un servizio dipendente sulla rete appropriata ha eliminato immediatamente le risposte 502 ricorrenti, dimostrando come un percorso upstream irraggiungibile possa causare problemi anche quando tutti i container sono ancora in esecuzione.
Collega i servizi tramite Compose invece di usare comandi isolati, così la relazione sopravvive alle ricostruzioni. Testa la risoluzione DNS e la porta upstream dall’interno del container del proxy dopo aver ricreato lo stack.
Controlla la porta di ascolto interna e l’indirizzo di binding
Conferma che l’applicazione sia in ascolto sulla porta utilizzata dal proxy e su un indirizzo raggiungibile dalla rete dei container. Non confondere una porta pubblicata sull’host con la porta di ascolto interna del container.
Un proxy può connettersi solo dopo che l’app è associata a un indirizzo diverso dal loopback. Un servizio in ascolto su 127.0.0.1 all’interno del proprio container non è disponibile per il proxy, anche quando un comando di controllo locale ha esito positivo.
Controlla il log dell’applicazione, l’elenco dei socket e una richiesta diretta dal container del proxy. Se la porta rifiuta le connessioni, correggi il listener o la configurazione dell’app prima di aggiungere tentativi o timeout del proxy più lunghi.
Attendi che l’applicazione sia pronta invece di limitarti all’avvio del container
Un container ricostruito può essere in esecuzione mentre le migrazioni, il ripristino del database, il riscaldamento della cache o la generazione della configurazione impediscono ancora all’applicazione di accettare richieste. Confronta il timestamp del primo errore 502 con i log di stato e di avvio.
Una discussione sulla risoluzione dei problemi di Grist mostra come l’architettura Docker, le impostazioni dell’ambiente e la disponibilità dell’upstream possano combinarsi e causare errori 502 persistenti sul lato container dopo una ricostruzione.
Aggiungi un controllo dello stato significativo e fai in modo che il proxy o i servizi dipendenti attendano l’operazione necessaria ai client, non la semplice esistenza di un processo. Mantieni i tentativi entro limiti definiti, così un’app permanentemente non funzionante non sembrerà un avvio lento.
Aggiorna la risoluzione del proxy e ricostruisci il percorso stabile
Ricarica o ricrea il proxy dopo aver corretto il nome del servizio, la rete, la porta e lo stato di salute. Se il proxy risolve i nomi solo all’avvio, configura la risoluzione in esecuzione supportata oppure un ordine di riavvio prevedibile.
Il flusso di lavoro di ZimaSpace per isolare una dipendenza del container non funzionante fornisce la diagnosi complementare quando l’upstream si arresta ripetutamente invece di rimanere in buono stato.
La riparazione è completa solo quando il proxy risolve il nome del servizio dopo un’ulteriore ricostruzione, raggiunge la porta interna prevista, attende il completamento dell’avvio e serve il dominio senza modifiche manuali agli IP. Dopo la convalida, rimuovi le destinazioni temporanee con IP diretto e i collegamenti di rete non documentati.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
