L'applicazione ignora il proxy: come incanalare il traffico

Hai configurato un proxy nelle impostazioni di Windows, hai riavviato il programma, ma continua a utilizzare l'IP domestico. Oppure, al contrario: il browser ha correttamente utilizzato il proxy, mentre il client desktop accanto a lui continua a mostrare l'indirizzo reale. Non si tratta di un bug del proxy né di credenziali errate. È una proprietà fondamentale di come i sistemi operativi gestiscono il "proxy di sistema": non costringe, ma offre solo un'opzione.

Di seguito sono riportati quattro modi funzionanti per costringere un'applicazione specifica a utilizzare SOCKS5, con le limitazioni di ciascun metodo e le insidie in cui più spesso si verifica la configurazione.

Perché il proxy di sistema non funziona: una breve verità tecnica

In Windows non esiste un unico "proxy di sistema". Ci sono almeno due set di impostazioni indipendenti. Il primo è WinINET: quello che modifichi in "Impostazioni → Rete e Internet → Server proxy". Viene letto da Internet Explorer/Edge, da alcune applicazioni su .NET e da tutto ciò che utilizza lo stack HTTP standard dell'utente. Il secondo è WinHTTP, utilizzato dai servizi di sistema e dai processi in background. Ecco il punto chiave: WinHTTP non utilizza le impostazioni di WinINET, a meno che non le importi esplicitamente. Questo si fa con il comando netsh winhttp import proxy source=ie, e — un dettaglio importante dalla documentazione Microsoft — il comando prende un istantanea delle impostazioni correnti. Hai cambiato il proxy nelle impostazioni in seguito? L'istantanea non si aggiorna automaticamente, il comando deve essere eseguito di nuovo.

Tuttavia, anche l'importazione non salva dalla principale categoria di problemi. Un numero enorme di programmi non chiede affatto al sistema: utilizzano il proprio stack di rete e aprono socket TCP direttamente. È così che funzionano molti client desktop di social media e messaggistica, launcher di giochi, torrent, alcune applicazioni Electron con configurazioni incorporate, utilità compilate in Go e Rust. Per loro, la voce "proxy" nelle impostazioni di sistema semplicemente non esiste come concetto.

Da qui la regola: se un'applicazione non ha il proprio campo per il proxy, l'unico modo affidabile è intercettare il suo traffico sotto il livello dell'applicazione. Ci sono esattamente quattro classi di metodi, e sono fondamentalmente diversi per prezzo, affidabilità e diritti richiesti.

Passo 0: assicurati che il problema sia proprio questo

Avvia l'applicazione e controlla quale IP mostra (profilo dell'account, pagina di servizio, qualsiasi indicatore incorporato).
Apri contemporaneamente il browser attraverso lo stesso proxy e verifica l'indirizzo. IP diversi = l'applicazione ignora l'impostazione di sistema.
Controlla se il programma ha le proprie impostazioni proxy: spesso sono nascoste in "Rete", "Connessione" o in un file di configurazione. Il supporto nativo è sempre migliore dell'intercettazione esterna: meno strati, meno guasti.
Controlla separatamente il DNS. Se l'applicazione risolve i nomi localmente, mentre il traffico passa attraverso il proxy, il tuo vero provider vede comunque dove stai andando.

Metodo 1. Proxifier — standard commerciale per Windows e macOS

Proxifier intercetta le connessioni delle applicazioni e le reindirizza al proxy specificato secondo le regole: puoi impostare "questo exe — attraverso il proxy A, quello — attraverso il proxy B, il resto — direttamente", separare per porte e indirizzi di destinazione, costruire una catena di più proxy.

Le versioni attuali al momento della scrittura: 4.14 per Windows (rilascio 23 aprile 2025) e 3.15 per macOS (18 settembre 2025). Licenza — $39.95 per copia, acquisto una tantum, a vita, con aggiornamenti minori gratuiti; c'è una prova completa di 31 giorni, sconti per acquisti all'ingrosso da due copie e rimborso entro 30 giorni.

Pratica di configurazione:

Proxy Servers → Add: specifica l'indirizzo, la porta, il protocollo SOCKS5 e le credenziali. Clicca su Check — il test deve passare prima di creare le regole, altrimenti dovrai risolvere due problemi contemporaneamente.
Proxification Rules → Add: in Applications seleziona il file eseguibile specifico, in Action — il tuo proxy.
Lascia la regola Default su Direct, se non vuoi reindirizzare l'intera macchina. Questo è l'errore più comune dei principianti: Default → Proxy reindirizza anche l'updater di sistema, l'antivirus e il traffico extra, per il quale paghi a gigabyte.
Guarda la scheda Connections in tempo reale: lì puoi vedere quale connessione è passata attraverso il proxy e quale direttamente.

Punti di forza — maturità, regole stabili e diagnostica chiara. Debolezze — costo e il fatto che, in presenza di sistemi anti-cheat aggressivi, l'intercettazione a livello driver può essere notata.

Metodo 2. ProxiFyre — alternativa gratuita per Windows con supporto UDP

Se il budget è zero e la piattaforma è Windows, c'è il progetto open source ProxiFyre (licenza AGPL-3.0). È costruito su NDISAPI/Windows Packet Filter — cioè funziona a livello di driver di filtraggio dei pacchetti e sa fare ciò che spesso manca: incapsulare in modo trasparente non solo TCP, ma anche UDP per ogni applicazione separatamente. Questo è fondamentale per tutto ciò che vive su UDP e QUIC — canali vocali, client di gioco, parte delle moderne connessioni browser.

Tra le novità nelle versioni recenti: il supporto per IPv6 è apparso in v2.3.0, SOCKS5-over-TLS — in v2.4.0, ci sono regole di esclusione per le applicazioni e catch-all per tutte le altre. Requisiti: Windows Packet Filter installato, librerie runtime di Visual Studio e diritti di amministratore.

La configurazione avviene tramite un file di configurazione con un elenco di applicazioni e i rispettivi endpoint SOCKS5. La barriera d'ingresso è più alta rispetto a Proxifier, ma non paghi e ottieni UDP.

Metodo 3. proxychains-ng — opzione veloce per Linux, con avvertenze

Classico per i sistemi Unix: proxychains4 curl https://example.com. Il meccanismo — LD_PRELOAD: la libreria sostituisce le chiamate ai socket nel programma collegato dinamicamente e le reindirizza a SOCKS.

Limitazioni da conoscere prima di costruire un flusso di lavoro su questo:

Solo TCP. UDP e ICMP non vengono incapsulati affatto — il ping attraverso proxychains non verifica nulla di significativo.
Solo binari collegati dinamicamente. Le utilità compilate staticamente (situazione tipica per Go) ignorano silenziosamente LD_PRELOAD — il traffico andrà direttamente, e non te ne accorgerai.
Su macOS si scontra con SIP. System Integrity Protection blocca il caricamento della libreria nei binari di sistema: proxychains4 ssh user@host non funzionerà. Una soluzione alternativa è copiare il binario nella tua cartella (cp /usr/bin/ssh ~/.local/bin/) e avviare la copia. Non consiglio di disattivare SIP per comodità: stai indebolendo la protezione dell'intero sistema per un'unica utilità.

Per compiti specifici (curl, script python, utilità da console) proxychains rimane il modo più veloce — si installa con un comando e non richiede root.

Metodo 4. Modalità TUN: intercettazione a livello di interfaccia virtuale

La classe di soluzioni più universale. Viene creata un'interfaccia di rete virtuale, i percorsi di sistema vengono reindirizzati in essa, e lo stack TCP/IP dell'utente analizza i pacchetti e li emette all'esterno tramite SOCKS5. Così funzionano tun2socks (utilizza lo stack gVisor, gestisce TCP e UDP, disponibile per tutte le piattaforme) e sing-box in modalità TUN.

Il principale vantaggio rispetto a LD_PRELOAD: viene intercettato tutto, compresi i binari statici e le applicazioni con il proprio stack. Sing-box ha anche il routing per processi — i campi process_name, process_path e process_path_regex, che forniscono vere regole per app; secondo la documentazione, questo è supportato su Linux, Windows e macOS (sulle piattaforme mobili le regole vengono impostate in base al nome del pacchetto o all'ID del bundle).

Due trappole su cui inciampano praticamente tutti:

Loop di routing. Se tutto il traffico va in TUN, anche la connessione al server SOCKS5 tenterà di andare in TUN — il tunnel inizia a reindirizzare se stesso. Si risolve con un percorso di esclusione esplicito verso l'IP del proxy attraverso l'interfaccia fisica. Questo è un problema noto e ricorrente nelle configurazioni di sing-box.
Diritti. La creazione di un'interfaccia TUN e la modifica della tabella di routing richiedono root/amministratore. Su una macchina aziendale con politiche potrebbe non essere disponibile.

Su Linux ci sono anche due approcci affini: redsocks — intercettazione tramite regole iptables con reindirizzamento a una porta locale (solo Linux, richiede root), e sshuttle, che solleva un routing simile a una VPN sopra l'accesso SSH normale, aggirando il classico problema "TCP sopra TCP".

Cosa si rompe più spesso

Perdita di DNS. Anche con un SOCKS5 configurato correttamente, l'applicazione può risolvere i domini localmente. Controlla che la risoluzione vada al proxy, e non al tuo provider.
È stato scelto SOCKS4 invece di SOCKS5. SOCKS4 non supporta UDP in linea di principio e non è in grado di trasmettere il nome di dominio in alcune implementazioni. Per intercettare traffico casuale, utilizza solo SOCKS5 — il perché è spiegato dettagliatamente nel materiale sui principi di funzionamento di SOCKS5.
Proxy HTTP invece di SOCKS. Il proxy HTTP può proxyizzare HTTP e tramite CONNECT — connessioni TLS. Non incapsula il traffico TCP casuale di un client di gioco o di messaggistica.
Regola Default per tutto il traffico. Reindirizzando l'intera macchina, bruci il traffico del pool residenziale per aggiornamenti e telemetria.
Mancanza di verifica dopo la configurazione. Controlla sempre l'IP di uscita effettivo dall'applicazione stessa, non dal browser accanto.

Quale tipo di proxy scegliere per l'intercettazione

Tecnicamente, l'intercettazione funziona con qualsiasi endpoint SOCKS5, ma la scelta del tipo determina se il tuo scenario arriverà a buon fine.

Residenziali — quando l'applicazione lavora con un servizio che valuta la reputazione dell'IP: social media, marketplace, pannelli pubblicitari, moduli di pagamento. Gli indirizzi dei data center vengono riconosciuti quasi immediatamente. Sono adatti proxy residenziali con supporto SOCKS5 e sessioni sticky — quest'ultima è critica, perché cambiare IP a metà sessione attiva appare peggio per l'antifrode rispetto a un IP "estraneo" inizialmente.
Data center — per compiti tecnici senza un severo antifrode: accesso API, servizi interni, banchi di prova, tutto dove la velocità e la stabilità del canale sono importanti, non l'aspetto "residenziale" dell'indirizzo. Qui, i proxy dei data center offrono il miglior ping e prevedibilità.
Mobile — quando l'applicazione è mobile per natura (emulatore, client di social media) e richiede la massima fiducia della piattaforma.

Separatamente: l'intercettazione a livello di applicazione non è una VPN, e non vale la pena sostituire l'uno con l'altro. Se hai bisogno di un solo canale protetto per l'intera macchina, e non di diversi IP per diverse applicazioni, il confronto degli approcci è presente nell'analisi WireGuard contro proxy.

Come scegliere un metodo in un minuto

L'applicazione ha le proprie impostazioni proxy → utilizza quelle, non intercettare nulla.
Windows, hai bisogno di risultati oggi, hai un budget → Proxifier.
Windows, hai bisogno di UDP e gratuitamente → ProxiFyre.
Linux, compito una tantum con un'utilità da console → proxychains-ng.
Devi intercettare un binario statico, un gioco o tutto insieme con regole per app → modalità TUN (sing-box, tun2socks), non dimenticando il percorso di esclusione verso il proxy.

La conclusione principale è semplice: "il proxy non funziona" in nove casi su dieci significa "il proxy non è configurato al livello giusto". La configurazione di sistema è una richiesta educata all'applicazione, mentre l'intercettazione a livello driver, LD_PRELOAD o interfaccia TUN è coercitiva. Scegli il livello giusto, controlla l'IP di uscita effettivo dall'applicazione stessa e non dimenticare il DNS — e il problema si risolve una volta per tutte, invece di riemergere dopo ogni aggiornamento del programma.