TCP/IP e fingerprinting dei proxy: come verificare che il tuo sistema operativo non ti tradisce con l'antibot

Hai configurato un browser anti-detect per Windows e Chrome, hai selezionato un IP pulito, allineato il fuso orario e la lingua, eppure il sito continua a mostrare un captcha o a bloccare l'account. Una causa comune si trova sotto il browser, a livello di TCP/IP. Il server vede il primo pacchetto di connessione (SYN), e dai suoi campi si può capire quale sistema operativo ha inviato quel pacchetto. Se si tratta di un proxy server Linux, ma l'User-Agent dichiara Windows, il sistema anti-bot riceve una contraddizione che non può essere corretta con gli header.

Il tema ha smesso di essere esotico. Il 13 ottobre 2026, secondo Proxyway, il fornitore britannico Byteful ha attivato in beta aperta la sostituzione dell'impronta TCP/IP per i proxy di data center e ISP: possono spacciarsi per Windows, macOS, Linux, Android e iOS. La spiegazione di Proxyway è semplice: i sistemi anti-bot guardano sempre più all'impronta TCP/IP. Di seguito analizzeremo come funziona questo controllo, come verificare il proprio proxy in cinque minuti e cosa fare in caso di incongruenza.

Che cos'è l'impronta TCP/IP e perché il proxy la cambia

Ogni sistema operativo raccoglie il pacchetto SYN a modo suo: il proprio TTL iniziale, la dimensione della finestra TCP, il fattore di scaling della finestra, MSS e, soprattutto, il set e l'ordine delle opzioni TCP. Il fingerprinting passivo (classico è l'utilità p0f, le varianti moderne si chiamano Zardaxt e JA4T) legge questi campi e indovina il sistema operativo, senza inviare nulla al client in risposta.

Il punto chiave per chi lavora tramite proxy è: il sito vede lo stack TCP della macchina che apre l'ultima connessione verso di esso. Un proxy normale (HTTP CONNECT o SOCKS5) accetta la tua connessione e ne apre una nuova verso il sito, a nome proprio. Pertanto, il TTL e le opzioni TCP nel pacchetto appartengono al proxy, e non al tuo computer. Cambiare l'User-Agent, l'impronta TLS o gli header è possibile, ma il SYN è già stato raccolto dal kernel della macchina attraverso cui ti connetti.

Valori tipici per i sistemi operativi

Riferimenti da un'analisi di Scrapfly e dalla documentazione di pydoll (i valori possono variare a seconda delle versioni specifiche del kernel e delle reti):

• Windows 10/11: TTL iniziale 128, finestra 64240–65535, ordine delle opzioni MSS, NOP, WSCALE, NOP, NOP, SACK (senza timestamp di default).
• Linux: TTL 64, finestra 29200 su kernel 3.x+ (su alcuni kernel 5.x/6.x 64240), ordine MSS, SACK, TIMESTAMP, NOP, WSCALE.
• macOS e iOS: TTL 64, finestra 65535, ordine MSS, NOP, WSCALE, NOP, NOP, TIMESTAMP, SACK, EOL.
• Android: TTL 64, l'ordine delle opzioni è simile a Linux, il che ha senso, dato che utilizza un kernel Linux.

Da qui la principale trappola: quasi tutti i proxy di data center funzionano su Linux. Il profilo "Windows + Chrome" sopra un tale proxy porta nel SYN segni di Linux, e questa contraddizione risalta maggiormente.

Quanto sono precisi gli anti-bot nel rilevare incongruenze

I dati provengono dal progetto aperto Zardaxt: si tratta di versioni riscritte di p0f e satori.py, che cercano specificamente i relay, cioè i proxy HTTP e SOCKS, dietro cui il browser si presenta come un'altra macchina. Secondo il README per la build del 21 settembre 2026 (con una base di 1.453 impronte da circa 23.000 sessioni):

• il modello con soglia 0,8 cattura 94,4% delle connessioni tramite proxy e contrassegna erroneamente solo 0,1% delle connessioni dirette;
• se il browser dichiara Windows, il proxy viene rilevato nel 96% dei casi, se Mac, nel 99%;
• il punto debole è Android e Linux: condividono una classe, quindi tali relay vengono catturati nel 74% dei casi;
• i VPN tunnel il modello quasi non li rileva (6,1%): attraverso il tunnel con il sito si parla dello stack del tuo dispositivo.

La cosa che più di tutte rivela il sistema operativo è l'ordine delle opzioni TCP: nell'analisi fattoriale del progetto questo campo indovina il sistema operativo nel 99,1% dei casi. Il flag DF è quasi inutile (0,362). Questo è uno strumento aperto di un ricercatore, per i commerciali anti-bot non vengono pubblicati dettagli, ma il principio è lo stesso: confrontare il sistema operativo dal SYN con quello dall'User-Agent.

Come controllare il proprio proxy: passo dopo passo

1. Fai un "campione" senza proxy. Apri in un browser normale browserleaks.com/tcp. Annota TTL, MSS, ordine delle opzioni, indovinello di p0f e valutazioni di Zardaxt per il sistema operativo. Questo è il tuo stack reale.
2. Controlla il proxy dalla console. Esegui una richiesta tramite proxy a un classificatore aperto:
   curl -x http://LOGIN:PASS@HOST:PORT "https://tcpip.incolumitas.com/classify?by_ip=1"
   Nella risposta ci sarà un campo avg_score_os_class con punteggi per Linux, Windows, Mac OS e iOS. Il vincitore qui è il sistema operativo del nodo di uscita del proxy, non del tuo computer.
3. Ripeti nel profilo anti-detect. Apri browserleaks.com/tcp o proxydetect.live/tcpip.html già nel profilo con proxy. Ora confronta due cose: il sistema operativo da TCP/IP e il sistema operativo dall'User-Agent del profilo.
4. Guarda il MSS. Una linea Ethernet pulita dà un MSS di 1460. Valori come 1380 (WireGuard), 1360 (IPsec) o 1240 indicano un tunnel lungo il percorso. Di per sé non è un ban, le reti mobili spesso danno anche un MSS minore, ma insieme ad altri segni aggiunge sospetti.
5. Fai 5–10 misurazioni in rotazione. Su proxy residenziali e mobili ogni nuovo IP può essere un altro dispositivo con un altro sistema operativo. Una misurazione non dice nulla, guarda la distribuzione.
6. Riassumi in una tabella: tipo di proxy → sistema operativo da TCP → sistema operativo del profilo → corrispondenza sì/no. Questa è la risposta su quale profilo eseguire su quale proxy.

Un solo TTL come prova non è sufficiente: il valore visibile diminuisce su ogni router, e il sito valuta solo il valore iniziale (64 o 128) secondo la più vicina potenza. La combinazione dei campi decide, prima di tutto l'ordine delle opzioni.

Cosa fare in caso di incongruenza

1. Adatta il profilo al proxy, non viceversa

Il modo più economico: scegliere il sistema operativo del profilo in modo che corrisponda a quello che mostra il nodo di uscita. Se il proxy fornisce Linux, è più onesto avviare un profilo Linux piuttosto che dimostrare al sito che sei Windows. Per compiti in cui il sistema operativo del profilo non è importante (parsing di pagine pubbliche, monitoraggio dei prezzi), questo risolve completamente il problema.

2. Scegli il tipo di proxy in base al sistema operativo necessario

• I proxy di data center mostrano quasi sempre un server Linux da un ASN cloud. Questo è normale per lo scraping da un client Linux (Python, Go, curl su server): lo stack e l'User-Agent del tuo script coincidono. Per profili "utente Windows" questo è un punto debole. Prendi proxy di data center dove la velocità e il prezzo per gigabyte sono importanti, non la leggenda di una "persona reale".
• I proxy residenziali escono attraverso dispositivi domestici reali e gateway, quindi il sito vede lo stack del nodo utente reale. Il sistema operativo su un IP specifico non è garantito in anticipo, ma è lo stack di un dispositivo reale, non di un server cloud. Per multi-accounting e anti-bot complessi, i proxy residenziali offrono la rappresentazione più naturale, se si verifica la distribuzione dei sistemi operativi in rotazione.
• I proxy mobili mostrano percorsi simili a Android o iOS. Per profili mobili (social media, applicazioni, versione mobile dei siti) questa è una corrispondenza ideale su tutti i livelli. Per ulteriori dettagli su come distinguere un vero IP cellulare da una falsificazione, leggi la nostra guida per controllare i proxy mobili. Per tali compiti sono adatti proxy mobili 4G/5G.

3. Non confondere il livello TCP con il livello TLS

Strumenti come curl-impersonate o curl_cffi falsificano il handshake TLS e HTTP/2 sotto Chrome, ma non toccano lo stack TCP: il SYN viene ancora raccolto dal kernel della macchina da cui proviene la connessione. Una buona impronta TLS sopra un TCP contraddittorio non salva, sono necessari entrambi i livelli. Come allineare la parte TLS è trattato nell'articolo su come bypassare JA4 tramite curl_cffi.

4. Sostituzione del sistema operativo lato proxy e tunnel

I fornitori iniziano a vendere la sostituzione dell'impronta TCP/IP sui propri server, come nel caso di Byteful sopra, ma questo è ancora raro e in beta. C'è anche un percorso inverso: i VPN tunnel il modello Zardaxt quasi non li rileva come relay, perché il sito vede il tuo stack. Anche gli svantaggi sono noti: un MSS ridotto indica un tunnel, e l'IP del VPN stesso è spesso elencato nelle banche dati come hosting.

Errori comuni

• Controllare solo con i verificatori IP. I servizi di reputazione IP guardano l'indirizzo e l'ASN, non il SYN. Un IP pulito con uno stack Linux sotto un profilo Windows supera il controllore e fallisce nell'anti-bot.
• Fare conclusioni da una sola misurazione in rotazione. Su un pool residenziale, il prossimo IP potrebbe essere un altro sistema operativo.
• Correggere con gli header. Nessun header riscrive il SYN dopo che il kernel lo ha inviato.
• Ignorare i profili Android su proxy Linux. Per i modelli aperti questa è una zona di incertezza (74% di cattura), ma gli anti-bot commerciali possono aggiungere altri segnali, come tempistiche e ASN mobili. Un profilo mobile appare più naturale su un IP mobile.

Conclusione

L'impronta TCP/IP è uno strato che non può essere corretto dal browser: è determinato dalla macchina che apre la connessione verso il sito. Il controllo richiede cinque minuti: browserleaks.com/tcp senza proxy e con proxy, più curl verso un classificatore aperto. La regola semplice è: il sistema operativo del profilo deve corrispondere a quello del nodo di uscita. I data center si adattano a script Linux, i proxy residenziali a profili desktop "vivi", i mobili a scenari mobili. Scegli il tipo di proxy in base al tuo profilo, esegui 5–10 misurazioni in rotazione, e l'anti-bot perderà uno dei suoi punti di riferimento più affidabili.