VPN attiva e localhost smette di funzionare: nome, proxy o bind?

Il tuo server di sviluppo ha risposto un minuto fa, e ora che il tunnel è attivo la richiesta va in timeout con un nome host che non hai mai digitato. Due meccanismi spiegano quasi tutti i casi, e dall'esterno sembrano identici. Un suffisso di ricerca trasforma un nome breve in uno aziendale, mentre un proxy invia il traffico loopback a un host che non può raggiungerlo. Separare i due costa una query e risparmia la regola del firewall che stavi per scrivere.

Quando localhost risolve nella zona aziendale

Controlla verso cosa risolve il nome mentre il tunnel è attivo, poi esegui la stessa query a tunnel disattivato e confronta le due risposte. L'indizio è un indirizzo nell'intervallo aziendale dove ti aspettavi 127.0.0.1. Un record come localhost.mycompany.corp batte la voce loopback appena il client aggiunge quel suffisso alla lista di ricerca, e la richiesta viaggia verso un host privato dove nulla ascolta su quella porta. Leggi la lista di ricerca invece di indovinarla, perché un client può aggiungere più di un dominio e l'ordine decide quale candidato viene provato per primo:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Sostituisci il nome host con l'indirizzo letterale nell'applicazione, nel client del database o nell'URL del notebook, poi ripeti la richiesta. Se il guasto sparisce avevi un problema di nomi e il tunnel era solo l'innesco. Se persiste, l'ascoltatore o la route è il prossimo sospetto e il nome era una falsa pista.

Impostazioni proxy che catturano loopback

Un proxy di sistema applicato quando il tunnel sale accetterà una richiesta verso 127.0.0.1 e la inoltrerà a un proxy remoto che non ha idea di cosa intendessi. Una lista di esclusione vuota trasforma una richiesta locale in remota, e il messaggio di errore raramente lo dice. Aggiungi gli indirizzi loopback alla lista di esclusione per tutta la sessione e non per un singolo comando, poi conferma che lo strumento la rispetti prima di concludere qualcosa sulla rete.

I framework applicativi leggono le proprie variabili d'ambiente e a volte il proprio file di configurazione, quindi un'esclusione che funziona per uno strumento non dimostra nulla per il successivo. I browser aggiungono una sfumatura: i browser basati su Chromium aggirano il proxy per loopback in modo implicito, e un token di esclusione può rimuovere questo comportamento. Controlla la decisione effettiva del proxy invece di presumere che l'impostazione del sistema operativo sia tutta la storia. Due comandi lo risolvono per qualunque cosa lanciata da una shell:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

L'indirizzo di bind decide chi può connettersi

Un server avviato su 127.0.0.1 accetta connessioni solo da quella macchina, che di solito è il valore predefinito corretto per lo sviluppo. Un server su 0.0.0.0 risponde su ogni interfaccia, adattatore VPN incluso, il che è più esposizione di quanto la maggior parte delle persone intenda. Quando l'indirizzo loopback letterale fallisce, controlla il bind prima di ogni altra cosa.

Guarda il socket in ascolto e annota l'indirizzo a cui è legato, non solo la porta. Se un altro dispositivo o un container deve raggiungere il servizio attraverso il tunnel, legalo all'interfaccia specifica che userà e consenti quella porta deliberatamente. Se serve solo alla tua macchina, mantieni il bind stretto e correggi il client invece di allargare il server. Un port forwarding o uno strato di tunnel può collegare i due, ma ognuno aggiunge un componente che avrà bisogno del proprio debug più avanti.

Dove uno strumento di debug si aspetta la LAN

Gli strumenti di debug portano con sé presupposti che un tunnel rompe in silenzio. Un bridge di debug per telefono perde il dispositivo quando la VPN cattura la sottorete del dispositivo, quindi riconnettersi tramite l'indirizzo LAN o un cavo evita il conflitto. Un hub di automazione del browser va in timeout quando l'hub è raggiungibile solo tramite il proxy, o quando un firewall locale scarta la sua porta di controllo. Un debugger remoto può richiedere elevazione e un indirizzo loopback dove il client ha riscritto la route.

Identifica la porta di controllo e la porta dati separatamente, perché spesso una sopravvive mentre l'altra no. Poi decidi se la correzione appartiene alla configurazione dello strumento, a una route per quella sottorete o a una regola di split tunneling. Modificare un file hosts su ogni macchina di sviluppo scala peggio e viene dimenticato per primo. Preferisci l'impostazione che vive con il profilo e che può essere rivista da chi possiede il tunnel.

Fermati alla prima fase che fallisce

Scendi lungo tre fasi: risolvi il nome, apri un socket verso l'indirizzo letterale, poi lascia che lo strumento faccia la propria connessione. Ogni fase elimina uno strato, quindi il primo guasto nomina lo strato da correggere e tutto ciò che segue resta non testato. Annota il risultato prima di cambiare qualcosa, perché una correzione applicata prima della misurazione non si distingue dalla fortuna. Se il primo tentativo fallisce e un nuovo tentativo funziona, il tunnel probabilmente non era pronto quando lo strumento è partito.

Sostituisci l'attesa fissa con un controllo di prontezza limitato che aspetta la route, e tieni la fase che fallisce nel log così la persona successiva vede dove si è fermata. Uno strumento che si riprende da solo non è corretto, è fortunato, e la fortuna finisce sulla macchina di qualcun altro. Cambia il tunnel per ultimo, e solo per la fase che ha davvero fallito. Quell'ordine è anche il percorso più breve verso una build funzionante, perché ti impedisce di ricostruire un componente che non era mai coinvolto.