proxychains è ancora lì dopo aver rimosso il prefisso

Rimuovi proxychains da un comando, lo avvii di nuovo e vedi ancora il messaggio di avvio del wrapper. Controlla l'ambiente di avvio prima di cercare un'impostazione nell'applicazione.

Su Linux, LD_PRELOAD chiede al linker dinamico di caricare gli oggetti condivisi indicati prima delle librerie ordinarie. I wrapper proxy possono usare questo meccanismo per intercettare le chiamate di rete supportate. Se qualcuno ha esportato la variabile in una shell, i programmi figli successivi possono ereditarla anche quando le loro righe di comando non contengono alcun prefisso del wrapper.

Un primo controllo in sola lettura in quella shell è:

printf '%s\n' "$LD_PRELOAD"

Cerca una libreria del wrapper proxy, ma mantieni la possibilità che la variabile elenchi anche altre librerie caricate deliberatamente. Rimuovere ogni voce alla cieca può compromettere un altro strumento.

Cambia il lanciatore, poi riavvia il programma

Rimuovi il precaricamento proxy accidentale dall'ambiente che avvia il programma interessato. Se un file di avvio o un lanciatore lo esporta, correggi anche quella fonte. Negli avvii Bash, segui l'ordine dei file di avvio. Un figlio nuovo di una shell pulita è un caso diverso dal figlio di un vecchio terminale o IDE che conserva ancora la variabile.

Annullare una variabile d'ambiente non scarica una libreria da un processo già avviato con essa. Un'applicazione in esecuzione può quindi mantenere il wrapper finché non viene riavviata tramite il percorso di avvio corretto.

Se la variabile è assente, ispeziona altre fonti di precaricamento configurate come /etc/ld.so.preload e il lanciatore reale. Il meccanismo ha limiti: gli eseguibili statici, le chiamate di sistema dirette e le restrizioni di esecuzione sicura possono comportarsi diversamente. Con sudo, l'ordine del wrapper conta. Un precaricamento ereditato spiega un'intercettazione inattesa; non è prova che tutto il traffico di rete passi dal proxy.