Perché il tuo proxy aziendale sta cercando di risolvere un nome di servizio Compose

L'applicazione raggiunge internet tramite il suo proxy aziendale, ma http://catalog:8080/ fallisce e il proxy non riesce a risolvere «catalog». È possibile che quella richiesta non abbia mai usato il DNS interno di Docker.

Un client HTTP può selezionare il proprio proxy prima di stabilire una connessione diretta. Il proxy esterno riceve quindi un nome il cui significato esiste solo all'interno della rete Compose.

1. Usa il nome host nella richiesta. I servizi Compose sono individuabili per nome del servizio sulla rete appropriata. Aggiungi catalog alla configurazione di bypass supportata dal client consumatore invece di codificare un IP del container che può cambiare.
2. Preserva le eccezioni esistenti. Per un client consapevole dell'ambiente, unisci le voci pertinenti con l'elenco dell'organizzazione:

NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Controlla la libreria o l'eseguibile effettivo nell'immagine per la gestione di maiuscole e minuscole, la versione e la grammatica di corrispondenza. Non esiste un parser NO_PROXY universale. Un programma chiamato wget in un'immagine piccola non deve necessariamente comportarsi come GNU Wget.

Una volta che la richiesta sceglie l'instradamento diretto, controlla la rete condivisa del chiamante e del servizio, il servizio in ascolto e la porta del container. Una porta host pubblicata è un altro endpoint. Un bypass non può aggiungere un collegamento di rete mancante, così come ricreare una rete non può insegnare a un proxy esterno un nome Compose privato.

Mantieni la separazione prevista: le richieste interne usano il loro percorso interno; le richieste esterne mantengono il proxy approvato. Disabilitare globalmente il proxy può nascondere questo singolo guasto mentre rimuove la rotta necessaria per la prossima richiesta esterna.