TCP/IP-huella de proxy: verificación del SO en 5 minutos

Has configurado un navegador anti-detección en Windows y Chrome, has seleccionado una IP limpia, alineado la zona horaria y el idioma, pero el sitio aún muestra un captcha o corta la cuenta. Una causa común se encuentra por debajo del navegador, a nivel de TCP/IP. El servidor ve el primer paquete de conexión (SYN), y por sus campos se puede identificar qué sistema operativo envió ese paquete. Si es un proxy de Linux y el User-Agent indica Windows, el sistema anti-bot recibe una contradicción que no se puede corregir con encabezados.

El tema ha dejado de ser exótico. El 13 de octubre de 2026, según Proxyway, el proveedor británico Byteful habilitó en beta abierta la suplantación de huellas TCP/IP para proxies de centros de datos e ISP: pueden hacerse pasar por Windows, macOS, Linux, Android e iOS. La explicación de Proxyway es sencilla: los sistemas anti-bot están mirando cada vez más la huella TCP/IP. A continuación, analizaremos cómo funciona esta verificación, cómo comprobar tu proxy en cinco minutos y qué hacer en caso de discrepancia.

¿Qué es la huella TCP/IP y por qué la cambia el proxy?

Cada sistema operativo recopila el paquete SYN de manera diferente: su TTL inicial, tamaño de la ventana TCP, factor de escalado de la ventana, MSS y, lo más importante, el conjunto y orden de las opciones TCP. El fingerprinting pasivo (la clásica herramienta p0f, las variantes modernas se llaman Zardaxt y JA4T) lee estos campos y adivina el sistema operativo, sin enviar nada al cliente en respuesta.

Un punto clave para quienes trabajan a través de un proxy: el sitio ve la pila TCP de la máquina que abre la última conexión hacia él. Un proxy normal (HTTP CONNECT o SOCKS5) acepta tu conexión y abre una nueva hacia el sitio, a su nombre. Por lo tanto, el TTL y las opciones TCP en el paquete pertenecen al proxy, no a tu computadora. Se puede cambiar el User-Agent, la huella TLS o los encabezados, pero el SYN ya ha sido recopilado por el núcleo de la máquina a través de la cual te conectas.

Valores típicos por sistema operativo

Referencias de análisis de Scrapfly y documentación de pydoll (en versiones específicas del núcleo y redes, los valores pueden variar):

Windows 10/11: TTL inicial 128, ventana 64240–65535, orden de opciones MSS, NOP, WSCALE, NOP, NOP, SACK (sin timestamp por defecto).
Linux: TTL 64, ventana 29200 en núcleos 3.x+ (en algunos núcleos 5.x/6.x 64240), orden MSS, SACK, TIMESTAMP, NOP, WSCALE.
macOS e iOS: TTL 64, ventana 65535, orden MSS, NOP, WSCALE, NOP, NOP, TIMESTAMP, SACK, EOL.
Android: TTL 64, el orden de opciones es similar al de Linux, lo cual es lógico, ya que tiene un núcleo Linux.

De aquí surge la principal trampa: casi todos los proxies de centros de datos funcionan en Linux. El perfil "Windows + Chrome" sobre un proxy de este tipo lleva en el SYN signos de Linux, y esta contradicción es la que más destaca.

¿Qué tan precisos son los anti-bots al detectar discrepancias?

Los números provienen del proyecto abierto Zardaxt: son versiones reescritas de p0f y satori.py, que buscan específicamente retransmisores, es decir, proxies HTTP y SOCKS, detrás de los cuales el navegador se presenta como otra máquina. Según el README para la compilación del 21 de septiembre de 2026 (base de 1,453 huellas aproximadamente de 23,000 sesiones):

el modelo con un umbral de 0.8 captura 94.4% de las conexiones a través de proxies y marca erróneamente solo 0.1% de las conexiones directas;
si el navegador indica Windows, el proxy es detectado en el 96% de los casos, si es Mac, en el 99%;
el punto débil es Android y Linux: comparten una misma clase, por lo que tales retransmisores son detectados en el 74% de los casos;
los VPN de túnel son casi invisibles para el modelo (6.1%): a través del túnel con el sitio, se habla con la pila de tu propio dispositivo.

Lo que más revela el sistema operativo es el orden de las opciones TCP: en el análisis factorial del proyecto, este campo adivina el sistema operativo en el 99.1% de los casos. La bandera DF es casi inútil (0.362). Esta es una herramienta abierta de un investigador, los detalles de los anti-bots comerciales no se publican, pero el principio es el mismo: comparar el sistema operativo del SYN con el del User-Agent.

Cómo comprobar tu proxy: paso a paso

Toma un "estándar" sin proxy. Abre en un navegador normal browserleaks.com/tcp. Anota el TTL, MSS, orden de opciones, la suposición de p0f y las estimaciones de Zardaxt por sistema operativo. Esta es tu pila real.
Verifica el proxy desde la consola. Realiza una solicitud a través del proxy a un clasificador abierto:
curl -x http://LOGIN:PASS@HOST:PORT "https://tcpip.incolumitas.com/classify?by_ip=1"
En la respuesta habrá un campo avg_score_os_class con puntuaciones para Linux, Windows, Mac OS e iOS. El ganador aquí es el sistema operativo del nodo de salida del proxy, no el de tu computadora.
Repite en el perfil anti-detección. Abre browserleaks.com/tcp o proxydetect.live/tcpip.html ya en el perfil con el proxy. Ahora compara dos cosas: el sistema operativo de TCP/IP y el sistema operativo del User-Agent del perfil.
Mira el MSS. Una línea Ethernet limpia da un MSS de 1460. Valores como 1380 (WireGuard), 1360 (IPsec) o 1240 indican un túnel en el camino. Esto por sí solo no es un baneo, las redes móviles también suelen dar un MSS menor, pero en conjunto con otros signos añade sospechas.
Realiza de 5 a 10 mediciones en rotación. En proxies residenciales y móviles, cada nueva IP puede ser otro dispositivo con otro sistema operativo. Una sola medición no dice nada, observa la distribución.
Compila en una tabla: tipo de proxy → sistema operativo por TCP → sistema operativo del perfil → coincidencia sí/no. Esta es la respuesta sobre qué perfil ejecutar en qué proxy.

Un solo TTL como prueba no es suficiente: el valor visible disminuye en cada enrutador, y el sitio evalúa solo el inicial (64 o 128) según la potencia más cercana. La combinación de campos es lo que importa, principalmente el orden de las opciones.

Qué hacer en caso de discrepancia

1. Ajusta el perfil al proxy, no al revés

La forma más económica: elige el sistema operativo del perfil para que coincida con lo que muestra el nodo de salida. Si el proxy da Linux, es más honesto ejecutar un perfil de Linux que intentar convencer al sitio de que eres Windows. Para tareas donde el sistema operativo del perfil no es importante (raspado de páginas públicas, monitoreo de precios), esto resuelve el problema por completo.

2. Elige el tipo de proxy según el sistema operativo necesario

Proxies de centros de datos casi siempre muestran un servidor Linux de un ASN en la nube. Esto es normal para el raspado desde un cliente Linux (Python, Go, curl en el servidor): la pila y el User-Agent de tu script están en concordancia. Para perfiles de "usuario de Windows", este es un punto débil. Toma proxies de centros de datos donde la velocidad y el precio por gigabyte sean importantes, no la leyenda de "persona real".
Proxies residenciales se conectan a través de dispositivos y puertas de enlace domésticos reales, por lo que el sitio ve la pila del nodo de usuario real. El sistema operativo en una IP específica no está garantizado de antemano, pero es la pila de un dispositivo real, no de un servidor en la nube. Para multi-cuentas y anti-bots complejos, los proxies residenciales ofrecen la imagen más natural, si se verifica la distribución de sistemas operativos en rotación.
Proxies móviles muestran rutas que parecen Android o iOS. Para perfiles móviles (redes sociales, aplicaciones, versión móvil de sitios), esto es una coincidencia perfecta en todos los niveles. Para más detalles sobre cómo distinguir una IP celular real de una falsa, consulta nuestra guía para verificar proxies móviles. Para tales tareas, son adecuados proxies móviles 4G/5G.

3. No confundas la capa TCP con la capa TLS

Herramientas como curl-impersonate o curl_cffi falsifican el apretón de manos TLS y HTTP/2 como Chrome, pero no tocan la pila TCP: el SYN sigue siendo recopilado por el núcleo de la máquina desde donde se establece la conexión. Una buena huella TLS sobre un TCP contradictorio no salva la situación, se necesitan ambas capas. Cómo alinear la parte TLS se detalla en el artículo sobre la elusión de JA4 a través de curl_cffi.

4. Suplantación de sistema operativo del lado del proxy y túneles

Los proveedores están comenzando a vender la suplantación de huellas TCP/IP en sus servidores, como el ejemplo de Byteful mencionado anteriormente, pero esto sigue siendo raro y en beta. También existe el camino inverso: los VPN de túnel son casi invisibles para el modelo Zardaxt como retransmisor, porque el sitio ve tu propia pila. También se conocen las desventajas: un MSS reducido indica un túnel, y la IP del propio VPN a menudo aparece en bases de datos como un host de alojamiento.

Errores comunes

Verificar solo con verificadores de IP. Los servicios de reputación de IP observan la dirección y ASN, no el SYN. Una IP limpia con una pila de Linux bajo un perfil de Windows pasa el verificador y falla en el anti-bot.
Hacer conclusiones basadas en una sola medición en rotación. En un pool residencial, la siguiente IP puede ser de otro sistema operativo.
Corregir con encabezados. Ningún encabezado reescribe el SYN después de que el núcleo lo ha enviado.
Ignorar perfiles de Android en proxies de Linux. Para modelos abiertos, esta es una zona de incertidumbre (74% de captura), pero los anti-bots comerciales pueden añadir otras señales, como tiempos y ASN móviles. Un perfil móvil se ve más natural en una IP móvil.

Conclusión

La huella TCP/IP es una capa que no se puede corregir desde el navegador: la determina la máquina que abre la conexión hacia el sitio. La verificación toma cinco minutos: browserleaks.com/tcp sin proxy y con proxy, más curl a un clasificador abierto. Luego, la regla simple es: el sistema operativo del perfil debe coincidir con el del nodo de salida. El centro de datos es adecuado para scripts de Linux, los proxies residenciales para perfiles de escritorio "vivos", y los móviles para escenarios móviles. Selecciona el tipo de proxy según tu perfil, realiza de 5 a 10 mediciones en rotación, y el anti-bot perderá uno de sus indicadores más confiables.