Empreinte TCP/IP d'un proxy : comment vérifier que votre OS ne vous expose pas aux anti-bots

Vous avez configuré un navigateur anti-détection sous Windows et Chrome, choisi une IP propre, aligné le fuseau horaire et la langue, mais le site continue d'afficher un captcha ou de bloquer le compte. Une cause fréquente réside en dessous du navigateur, au niveau TCP/IP. Le serveur voit le premier paquet de connexion (SYN), et à partir de ses champs, il peut déterminer quel système d'exploitation a envoyé ce paquet. Si c'est un proxy Linux, et que le User-Agent déclare Windows, le système anti-bot reçoit une contradiction qui ne peut pas être corrigée par les en-têtes.

Le sujet a cessé d'être exotique. Le 13 octobre 2026, selon Proxyway, le fournisseur britannique Byteful a inclus dans sa bêta ouverte la substitution de l'empreinte TCP/IP pour les proxies de centres de données et ISP : ils peuvent se faire passer pour Windows, macOS, Linux, Android et iOS. L'explication de Proxyway est simple : les systèmes anti-bot regardent de plus en plus l'empreinte TCP/IP. Nous allons voir ci-dessous comment cette vérification est organisée, comment vérifier votre proxy en cinq minutes et que faire en cas de non-concordance.

Qu'est-ce que l'empreinte TCP/IP et pourquoi les proxies la changent

Chaque système d'exploitation collecte le paquet SYN à sa manière : son TTL initial, la taille de la fenêtre TCP, le facteur d'échelle de la fenêtre, MSS et, surtout, l'ensemble et l'ordre des options TCP. Le fingerprinting passif (la référence ici est l'outil p0f, les versions modernes s'appellent Zardaxt et JA4T) lit ces champs et devine le système d'exploitation sans rien envoyer en réponse au client.

Le point clé pour ceux qui travaillent via un proxy : le site voit la pile TCP de la machine qui ouvre la dernière connexion vers lui. Un proxy ordinaire (HTTP CONNECT ou SOCKS5) accepte votre connexion et en ouvre une nouvelle vers le site, en son propre nom. Par conséquent, le TTL et les options TCP dans le paquet appartiennent au proxy, et non à votre ordinateur. Changer le User-Agent, l'empreinte TLS ou les en-têtes est possible, mais le SYN a déjà été collecté par le noyau de la machine par laquelle vous vous connectez.

Valeurs typiques par système d'exploitation

Repères issus de l'analyse de Scrapfly et de la documentation pydoll (les valeurs peuvent varier selon les versions spécifiques du noyau et des réseaux) :

• Windows 10/11 : TTL initial 128, fenêtre 64240–65535, ordre des options MSS, NOP, WSCALE, NOP, NOP, SACK (sans timestamp par défaut).
• Linux : TTL 64, fenêtre 29200 sur les noyaux 3.x+ (sur certains noyaux 5.x/6.x 64240), ordre MSS, SACK, TIMESTAMP, NOP, WSCALE.
• macOS et iOS : TTL 64, fenêtre 65535, ordre MSS, NOP, WSCALE, NOP, NOP, TIMESTAMP, SACK, EOL.
• Android : TTL 64, l'ordre des options est proche de Linux, ce qui est logique, car il utilise un noyau Linux.

Voici donc le principal piège : presque tous les proxies de centres de données fonctionnent sous Linux. Le profil « Windows + Chrome » au-dessus d'un tel proxy porte dans le SYN des signes de Linux, et cette contradiction est la plus évidente.

À quel point les anti-bots détectent-ils la non-concordance

Des chiffres sont disponibles grâce au projet ouvert Zardaxt : ce sont des réécritures de p0f et satori.py, qui cherchent précisément les relais, c'est-à-dire les proxies HTTP et SOCKS, derrière lesquels le navigateur se fait passer pour une autre machine. Selon le README pour la compilation du 21 septembre 2026 (base de 1 453 empreintes provenant d'environ 23 000 sessions) :

• le modèle avec un seuil de 0,8 détecte 94,4% des connexions via un proxy et marque à tort seulement 0,1% des connexions directes ;
• si le navigateur déclare Windows, le proxy est détecté dans 96% des cas, si c'est Mac, alors dans 99% ;
• le point faible est Android et Linux : ils partagent une seule classe, donc ces relais sont détectés dans 74% des cas ;
• les VPN tunnelisés sont presque invisibles pour le modèle (6,1%) : à travers le tunnel avec le site, la pile de votre propre appareil est visible.

Ce qui trahit le plus le système d'exploitation, c'est l'ordre des options TCP : dans l'analyse factorielle du projet, ce champ devine le système d'exploitation dans 99,1% des cas. Le drapeau DF est presque inutile (0,362). C'est un outil ouvert d'un chercheur, pour les anti-bots commerciaux, les détails ne sont pas publiés, mais le principe est le même : comparer le système d'exploitation du SYN avec celui du User-Agent.

Comment vérifier votre proxy : étape par étape

1. Faites une « référence » sans proxy. Ouvrez dans un navigateur ordinaire browserleaks.com/tcp. Notez le TTL, MSS, l'ordre des options, la supposition de p0f et les évaluations de Zardaxt par rapport au système d'exploitation. C'est votre véritable pile.
2. Vérifiez le proxy depuis la console. Exécutez une requête via le proxy vers un classificateur ouvert :
   curl -x http://LOGIN:PASS@HOST:PORT "https://tcpip.incolumitas.com/classify?by_ip=1"
   Dans la réponse, il y aura un champ avg_score_os_class avec des scores pour Linux, Windows, Mac OS et iOS. Le gagnant ici est le système d'exploitation du nœud de sortie du proxy, et non celui de votre ordinateur.
3. Répétez dans le profil anti-détection. Ouvrez browserleaks.com/tcp ou proxydetect.live/tcpip.html déjà dans le profil avec le proxy. Comparez maintenant deux choses : le système d'exploitation du TCP/IP et le système d'exploitation du User-Agent du profil.
4. Regardez le MSS. Une ligne Ethernet propre donne un MSS de 1460. Des valeurs comme 1380 (WireGuard), 1360 (IPsec) ou 1240 indiquent un tunnel sur le chemin. Cela ne constitue pas un bannissement en soi, les réseaux mobiles donnent souvent un MSS plus faible, mais en combinaison avec d'autres signes, cela ajoute des soupçons.
5. Effectuez 5 à 10 mesures en rotation. Sur des proxies résidentiels et mobiles, chaque nouvelle IP peut être un autre appareil avec un autre système d'exploitation. Une seule mesure ne dit rien, regardez la distribution.
6. Consolidez dans un tableau : type de proxy → système d'exploitation par TCP → système d'exploitation du profil → concordance oui/non. C'est la réponse à la question de quel profil exécuter sur quel proxy.

Un seul TTL comme preuve ne suffit pas : la valeur visible diminue à chaque routeur, et le site n'évalue que le premier (64 ou 128) selon la puissance la plus proche. La combinaison des champs décide, avant tout l'ordre des options.

Que faire en cas de non-concordance

1. Ajustez le profil au proxy, et non l'inverse

Le moyen le moins cher : choisir le système d'exploitation du profil de manière à ce qu'il corresponde à celui affiché par le nœud de sortie. Si le proxy donne Linux, il est plus honnête de lancer un profil Linux plutôt que de prouver au site que vous êtes sous Windows. Pour les tâches où le système d'exploitation du profil n'est pas important (parsing de pages publiques, surveillance des prix), cela résout entièrement le problème.

2. Choisissez le type de proxy selon le système d'exploitation requis

• Les proxies de centres de données montrent presque toujours un serveur Linux d'un ASN cloud. C'est normal pour le scraping depuis un client Linux (Python, Go, curl sur le serveur) : la pile et le User-Agent de votre script sont en accord. Pour les profils « utilisateur Windows », c'est un point faible. Prenez des proxies de centres de données là où la vitesse et le prix par gigaoctet sont importants, et non la légende d'un « être humain vivant ».
• Les proxies résidentiels passent par de véritables appareils domestiques et passerelles, donc le site voit la pile du véritable nœud utilisateur. Le système d'exploitation sur une IP spécifique n'est pas garanti à l'avance, mais c'est la pile d'un appareil vivant, et non d'un serveur cloud. Pour le multi-comptes et les anti-bots complexes, les proxies résidentiels offrent l'image la plus naturelle, si l'on vérifie la distribution des systèmes d'exploitation en rotation.
• Les proxies mobiles montrent des chemins ressemblant à Android ou iOS. Pour les profils mobiles (réseaux sociaux, applications, version mobile des sites), c'est une correspondance parfaite à tous les niveaux. Pour en savoir plus sur la façon de distinguer une véritable IP mobile d'une contrefaçon, consultez notre guide de vérification des proxies mobiles. Pour ces tâches, les proxies mobiles 4G/5G sont appropriés.

3. Ne confondez pas la couche TCP avec la couche TLS

Des outils comme curl-impersonate ou curl_cffi falsifient la poignée de main TLS et HTTP/2 sous Chrome, mais ne touchent pas la pile TCP : le SYN est toujours collecté par le noyau de la machine d'où provient la connexion. Une bonne empreinte TLS au-dessus d'un TCP contradictoire ne sauve pas, les deux couches sont nécessaires. Comment aligner la partie TLS est expliqué dans l'article sur le contournement de JA4 via curl_cffi.

4. Substitution du système d'exploitation du côté du proxy et tunnels

Les fournisseurs commencent à vendre la substitution de l'empreinte TCP/IP sur leurs serveurs, comme l'exemple de Byteful ci-dessus, mais cela reste rare et en bêta. Il existe aussi une voie inverse : les VPN tunnelisés sont presque invisibles pour le modèle Zardaxt en tant que relais, car le site voit votre propre pile. Les inconvénients sont également connus : un MSS réduit indique un tunnel, et l'IP du VPN lui-même est souvent répertoriée dans des bases de données comme étant celle d'un hébergeur.

Erreurs fréquentes

• Vérifier uniquement avec des vérificateurs d'IP. Les services de réputation IP se basent sur l'adresse et l'ASN, et non sur le SYN. Une IP propre avec une pile Linux sous un profil Windows passe le vérificateur et échoue sur l'anti-bot.
• Tirer des conclusions à partir d'une seule mesure en rotation. Sur un pool résidentiel, la prochaine IP peut être un autre système d'exploitation.
• Essayer de corriger avec des en-têtes. Aucun en-tête ne réécrit le SYN après que le noyau l'ait envoyé.
• Ignorer les profils Android sur des proxies Linux. Pour les modèles ouverts, c'est une zone d'incertitude (74% de détection), mais les anti-bots commerciaux peuvent ajouter d'autres signaux, comme des timings et un ASN mobile. Un profil mobile semble plus naturel sur une IP mobile.

Conclusion

L'empreinte TCP/IP est une couche qui ne peut pas être corrigée depuis le navigateur : elle est déterminée par la machine qui ouvre la connexion vers le site. La vérification prend cinq minutes : browserleaks.com/tcp sans proxy et avec proxy, plus curl vers un classificateur ouvert. Ensuite, une règle simple : le système d'exploitation du profil doit correspondre à celui du nœud de sortie. Le centre de données convient pour les scripts Linux, les proxies résidentiels pour les profils de bureau « vivants », et les mobiles pour les scénarios mobiles. Choisissez le type de proxy en fonction de votre profil, effectuez 5 à 10 mesures en rotation, et l'anti-bot perdra l'un de ses indices les plus fiables.