Vai al contenuto principale
50% di sconto tutti i piani, tempo limitato. A partire da $2.48/mo
9 min left
Sicurezza e rete

Proxy SOCKS5 vs proxy residenziale vs VPN: perché la rete dell'IP conta più del protocollo

J Di Jonas 9 min di lettura
Tre percorsi a livelli a confronto: un portatile che raggiunge un server tramite un relay SOCKS5, traffico che esce da un'abitazione su una rete residenziale e un portatile che invia traffico in un tunnel VPN cifrato

Un'offerta di proxy recita «proxy residenziale SOCKS5». L'etichetta mette insieme entrambi i lati del confronto tra proxy SOCKS5 e proxy residenziale, e non dice per quale delle due parole stai pagando. Se tratti le due parole come due livelli dello stesso prodotto, rischi di comprare un server SOCKS5 su un VPS a noleggio e scoprire che il tuo script di scraping viene ancora segnalato.

Per lo stesso problema viene proposta una VPN, che cambia una terza cosa. I tre termini stanno a livelli diversi: un protocollo di relay, la rete dietro un indirizzo di uscita e l'ambito di un tunnel.

La versione breve

  • SOCKS5 (RFC 1928) non ha una cifratura propria, e i metodi senza autenticazione e con nome utente e password usati dalla maggior parte delle installazioni non ne aggiungono alcuna.
  • Un IP di uscita viene etichettato come residenziale, datacenter o mobile in base al tipo di rete da cui proviene: un ISP consumer, un provider di hosting o un operatore mobile.
  • I siti web vedono l'IP di uscita, non il protocollo usato per raggiungerlo. Un server SOCKS5 su un VPS a noleggio esce da un indirizzo di datacenter e viene classificato come traffico datacenter.
  • Una VPN cambia il percorso del traffico, non il tipo di fondo della sua rete di uscita. Un server VPN su una rete datacenter esce comunque da un IP di datacenter, e i servizi di IP intelligence possono anche segnalare quell'indirizzo come endpoint VPN noto.

Tre etichette che rispondono a tre domande diverse

Tre schede affiancate: un proxy SOCKS5 è un protocollo di relay per un'applicazione configurata, senza cifratura propria; un proxy residenziale è un IP di uscita su una rete consumer o di un ISP; una VPN è un tunnel su un collegamento di rete che può trasportare il traffico dell'intero dispositivo

SOCKS5 è un protocollo, pubblicato come RFC 1928 nel marzo 1996, che inoltra il traffico di un'applicazione attraverso un server. Definisce come viene negoziata quella connessione, non chi possiede l'indirizzo di uscita. Residenziale, datacenter e mobile descrivono la rete a cui è registrato un indirizzo di uscita. Una VPN crea un tunnel, cifra, o entrambe le cose, su un collegamento di rete.

ProprietàProxy SOCKS5Proxy residenzialeVPN
Cosa descrive il termineUn protocollo di relayLa rete a cui è registrato l'IP di uscitaUn tunnel su un collegamento di rete
Traffico copertoL'applicazione configurata per usarloDipende dal protocollo usato per raggiungerloIl collegamento di rete su cui è configurata
CrittografiaNessuna propria; dipende dal metodo di autenticazioneNon è una proprietà dell'etichettaTunnel e/o cifratura (CNSSI 4009)
Cosa vede la destinazioneL'IP di uscita del relayUn IP di uscita su una rete consumer o di un ISPL'IP di uscita del server VPN

Leggi «proxy residenziale SOCKS5» come due scelte separate. «SOCKS5» è il protocollo che il tuo client usa per raggiungere il relay. «Residenziale» è la rete a cui appartiene l'IP di uscita del relay. Ognuna delle due può cambiare senza l'altra. Un server SOCKS5 può stare altrettanto facilmente su un indirizzo di datacenter.

Acquistarli insieme è una scelta sensata, una volta capito quale metà fa quale lavoro.

Cosa definisce il protocollo SOCKS5 e cosa lascia fuori

SOCKS5 negozia un metodo di autenticazione e poi inoltra la connessione. RFC 1928 non definisce alcuna cifratura propria. I comuni metodi senza autenticazione e con nome utente e password non ne aggiungono, e RFC 1929 invia la password in chiaro. Il metodo GSS-API di RFC 1961 può aggiungere integrità e, opzionalmente, riservatezza, mentre un tunnel SSH, una VPN o un involucro TLS separati possono proteggere il trasporto tra client e proxy. HTTPS protegge il payload dell'applicazione end-to-end, ma non protegge lo scambio di autenticazione SOCKS5 in sé.

La negoziazione è breve. Il client elenca i metodi di autenticazione che supporta e il server ne sceglie uno. RFC 1928 elenca i codici dei metodi: nessuna autenticazione, GSSAPI, nome utente e password, e intervalli riservati a metodi assegnati e privati. Completata questa sotto-negoziazione, il client invia la richiesta di connessione e il server inoltra il traffico.

La specifica si descrive come uno «shim-layer» (strato intermedio) tra il livello applicazione e il livello di trasporto, e non definisce alcun cifrario. Se il metodo scelto prevede un incapsulamento per integrità o riservatezza, RFC 1928 vi incapsula il traffico: richieste, risposte e dati inoltrati.

RFC 1929, che specifica il metodo con nome utente e password, non definisce alcun incapsulamento e dichiara apertamente il suo punto debole:

Poiché la richiesta trasporta la password in chiaro, questa sotto-negoziazione è sconsigliata negli ambienti in cui lo «sniffing» (l'intercettazione del traffico) è possibile e praticabile.

Fonte: Il metodo con nome utente e password di RFC 1929

Il design ha una sua storia. La storia di SOCKS5 di NT Kernel spiega che i server SOCKS dell'epoca del 1996 giravano per lo più all'interno di reti «generalmente considerate fidate», e che la riservatezza doveva essere garantita altrove. Lo stesso resoconto nota che GSSAPI può aggiungere integrità e riservatezza, a seconda del livello di protezione negoziato, ma il suo supporto è rimasto molto meno diffuso, e la maggior parte delle installazioni reali usa ancora nome utente e password.

Niente di tutto questo rende HTTPS leggibile attraverso il proxy. TLS 1.3 è progettato per impedire le intercettazioni, le manomissioni e la falsificazione dei messaggi tra client e server, e un relay SOCKS5 si limita a inoltrare quei byte cifrati.

Cosa rende un indirizzo IP residenziale, datacenter o mobile

Un IP di uscita è residenziale, datacenter o mobile in base alla rete che lo detiene. Fraudlogix, un'azienda di rilevamento delle frodi, colloca gli IP datacenter in data center, strutture di hosting e provider cloud nel suo glossario degli IP datacenter. Peakhour, che vende servizi di gestione dei bot, associa le uscite residenziali a connettività consumer o di un ISP. Tratta il mobile a parte: gli operatori usano modelli diversi di condivisione degli indirizzi, tra cui il CGNAT (NAT di livello carrier).

Dal lato della rete, l'IP di uscita si trova già in un contesto di routing e di registrazione prima che un qualsiasi protocollo proxy lo tocchi. Un segnale importante è l'ASN (numero di sistema autonomo) che annuncia il prefisso dell'indirizzo, utile per identificare l'operatore di rete.

Le reti di proxy residenziali si formano in diversi modi, e non tutti coinvolgono un volontario. Peakhour elenca:

  • condivisione di banda volontaria o su contratto
  • VPN gratuite, app ed estensioni del browser che instradano traffico di terzi attraverso i dispositivi degli utenti
  • SDK integrati nelle app
  • dispositivi e router compromessi

La via degli SDK ha prove recenti a sostegno. Il report di Krebs on Security di luglio 2026 riferisce che la società di sicurezza Spur ha trovato SDK di proxy residenziali in oltre il 42 per cento delle app dello store webOS di LG. Più di un quarto delle app Samsung Tizen conteneva componenti simili. Secondo il report di Spur, Bright Data rappresentava la maggioranza di quegli SDK su entrambe le piattaforme, e LG ha dichiarato che sospenderà le app che mantengono l'opzione proxy.

Bright Data ha detto a Krebs che la sua rete si basa sul consenso e che ogni peer aderisce tramite una schermata dedicata. Secondo Spur, «una richiesta di consenso una tantum nascosta in un'app per TV non sostituisce una trasparenza reale, un controllo continuo e la supervisione della piattaforma». Nessuno di questi modelli di approvvigionamento dipende da SOCKS5.

Perché i siti classificano la rete di uscita, non il protocollo

Diagramma di flusso: l'app di un utente invia una richiesta tramite un relay proxy o VPN, il sito di destinazione vede solo l'IP di uscita, e un motore di classificazione usa segnali di rete, di storico e di sessione, come ASN, reputazione e impronta TLS, per etichettarlo come residenziale, datacenter o VPN/proxy

Un sito di destinazione vede l'IP di uscita del proxy, non il protocollo che il tuo client ha usato per raggiungere il proxy. La classificazione basata sull'IP parte dall'indirizzo di uscita e dal suo contesto: ASN, classificazione come hosting/ISP/operatore, reputazione e intervalli noti di VPN, Tor o proxy. Un server SOCKS5 su un VPS a noleggio viene quindi classificato come traffico datacenter.

La guida di Peakhour ai proxy residenziali afferma: «La destinazione vede l'IP di uscita del proxy, non la sorgente originale». L'handshake SOCKS5 avviene tra il tuo client e il relay. Il sito riceve una normale connessione dall'indirizzo del relay.

La pagina di Peakhour sul rilevamento dei proxy elenca da dove parte di solito la classificazione: reputazione, ASN, geolocalizzazione, classificazione come provider di hosting, uscite VPN e Tor note, e storico degli abusi. Nessuno di questi segnali viene dal protocollo. La stessa pagina afferma: «Gli intervalli datacenter sono di solito più facili da identificare dal contesto di IP e ASN».

I dati di Fraudlogix per il lookup IP classificano un indirizzo usando segnali come l'appartenenza a un datacenter, l'ASN, l'organizzazione, l'ISP e il tipo di connessione. Cambiare il protocollo, la porta o il metodo di autenticazione del proxy non cambia queste proprietà dell'IP di uscita.

Secondo la pagina di rilevamento di Peakhour, gli indirizzi residenziali e mobili sono più difficili da valutare dal solo IP, perché utenti legittimi e traffico proxy possono condividerli nello stesso momento. Vengono valutati comunque: la pagina descrive come il contesto IP venga combinato con indizi a livello di richiesta, come impronte TLS, coerenza del browser e comportamento. Un'uscita residenziale che invia richieste troppo in fretta può far scattare una verifica, un rallentamento, un blocco o una risposta di rate limit HTTP 429.

Un proxy SOCKS5 è la stessa cosa di una VPN?

No. Una VPN trasporta il traffico su un collegamento di rete tramite tunnel, cifratura, o entrambi. A seconda del client e della policy di routing, può coprire tutto il traffico del dispositivo o solo una parte. Un proxy SOCKS5 inoltra le applicazioni configurate per usarlo e non aggiunge una cifratura propria. Entrambi possono presentare alla destinazione un IP di uscita diverso, e quell'uscita ha comunque un tipo di rete di fondo.

Il glossario del NIST, che cita CNSSI 4009, definisce una VPN come una rete «costruita a partire dalle risorse di sistema di una rete fisica usando la cifratura e/o facendo passare in tunnel i collegamenti della rete virtuale attraverso la rete reale». Se configurata come tunnel di uscita predefinito del router, una VPN può coprire ogni dispositivo che c'è dietro.

La pagina di rilevamento di Peakhour include le uscite VPN tra le categorie classificate, accanto a provider di hosting, ISP residenziali e operatori mobili, quindi usare una VPN non rende di per sé un'uscita residenziale. È sempre la rete di uscita di fondo a determinare quell'etichetta. Un nodo di uscita per la privacy in self-hosting su un server a noleggio esce dall'indirizzo di datacenter di quel server.

Abbinare l'obiettivo all'etichetta che lo decide

Scegli l'etichetta in base all'obiettivo. Reindirizzare il traffico di un'applicazione è una questione di protocollo proxy. Mettere in tunnel e cifrare il traffico di un dispositivo è una questione di VPN. Avere bisogno di molti indirizzi su reti consumer è una questione di rete IP, e lì il protocollo usato per raggiungere il pool di indirizzi è un dettaglio secondario.

ObiettivoEtichetta che decideCosa quell'etichetta non decide
Instradare il traffico di un'applicazione tramite un relayIl protocollo proxySe l'uscita sembra residenziale
Mettere in tunnel e cifrare il traffico di un dispositivoLa VPNIl tipo di rete dell'uscita
Molti indirizzi su reti consumerLa rete IP (residenziale o mobile)La riservatezza del tuo traffico

Se ti interessa l'indirizzo in uscita di un solo script, un server SOCKS5 sul tuo VPS è sufficiente e ben collaudato, purché la destinazione accetti traffico datacenter.

Vedi piani Linux

Costruisci su un VPS Linux con accesso root, NVMe e la potenza di AMD EPYC.

Vedi piani Linux

Domande frequenti

Un proxy SOCKS5 nasconde il tuo indirizzo IP?

Dal lato della destinazione, sì: il sito vede l'IP di uscita del proxy al posto del tuo. L'operatore del proxy vede il tuo vero indirizzo IP e tutto il traffico che la tua applicazione non cifra da sé, quindi nascondere il tuo indirizzo ai siti significa fidarsi di chi gestisce il proxy.

Si possono usare un proxy SOCKS5 e una VPN contemporaneamente?

Sì, i due si possono sovrapporre. Quando un'applicazione raggiunge un proxy SOCKS5 attraverso un tunnel VPN, la VPN protegge il tratto dal tuo dispositivo al server VPN, e il proxy stabilisce l'IP di uscita che la destinazione vede per quell'applicazione. La VPN non copre il tratto tra il server VPN e il proxy.

Un proxy residenziale è più sicuro di un proxy datacenter?

Non nel senso di proteggere il tuo traffico. L'etichetta residenziale o datacenter cambia il modo in cui un sito classifica l'IP di uscita, e nessuna delle due aggiunge cifratura. Un'uscita residenziale può anche passare da un dispositivo o router domestico di cui di solito non puoi verificare né il consenso né la sicurezza del proprietario.

Condividi

Discussione

Commenti

Accedi per partecipare alla discussione.

Altro dal blog

Continua a leggere.

Diagram comparing a three-interface DMZ firewall with the same isolation pattern arranged inside a single server
Sicurezza e rete

Che cos'è una DMZ nelle reti?

Una DMZ è un segmento di rete che isola i servizi esposti al pubblico. Scopri il modello classico a tre interfacce e come avvicinarsi al suo obiettivo di sicurezza su un solo VPS.

Jonas 12 min di lettura

Pronto a distribuire? Da 2,48 $/mese.

Cloud indipendente, dal 2008. AMD EPYC, NVMe, 40 Gbps. Rimborso entro 14 giorni.