Prueba avanzada de fugas de IP y DNS: Verifique su seguridad

Muchos usuarios creen que comprar un "proxy residencial" les permite camuflarse por completo como usuarios domésticos comunes. Sin embargo, los sistemas modernos de control de riesgo van mucho más allá de las etiquetas estáticas en bases de datos GeoIP (como IP2Location o MaxMind). Aunque la IP de salida figure como residencial/ISP, la pasarela proxy que reenvía el tráfico casi siempre se ejecuta en un servidor Linux en la nube, lo que genera contradicciones evidentes entre capas: Primero, la firma de la pila TCP: el servidor de salida transmite la secuencia de opciones típica de Linux (MSS, SACK_PERM, TS, NOP, WS) durante el saludo inicial SYN en lugar del orden propio de Windows o Apple. Segundo, la discrepancia en la MTU: las conexiones domésticas PPPoE suelen tener una MTU de 1492 (las redes móviles entre 1400 y 1430), mientras que Ethernet en centros de datos es estándar 1500 (MSS=1460). Al detectar una IP residencial con MTU de centro de datos y pila Linux, el sistema clasifica la conexión como proxy automatizado.

💡 Compruebe su conexión con la Prueba de anonimato de proxy para ver dónde finaliza su enlace TCP.

No existe una vinculación física fija entre una dirección IP y una ubicación geográfica real. Los resultados mostrados dependen de la base de datos comercial GeoIP utilizada por cada sitio y de su ciclo de actualización: Primero, las fuentes de datos y algoritmos varían: proveedores como MaxMind, IP2Location o DB-IP analizan anuncios BGP, registros whois y latencias de red con diferentes ponderaciones e intervalos que van desde días hasta meses. Segundo, el enrutamiento Anycast y las redes CDN: plataformas como Cloudflare anuncian el mismo rango de IP en cientos de centros de datos de todo el mundo, redirigiendo su solicitud al nodo perimetral más cercano. Tercero, reasignaciones de IP entre países: cuando un proveedor reasigna rangos registrados en un país a servidores en otro, las bases de datos desactualizadas muestran la ubicación histórica. Nuestra herramienta combina múltiples bases de datos con triangulación por tiempo de ida y vuelta (RTT) a la velocidad de la luz para validar regiones físicas reales.

La puntuación de fraude de IP (o Risk Score) es un índice numérico (generalmente de 0 a 100) utilizado por sistemas antifraude para cuantificar la probabilidad de que una conexión provenga de actividades maliciosas o automatizadas. Sus factores clave incluyen: Primero, reputación histórica y listas de abuso: si la IP ha participado recientemente en ataques de relleno de credenciales, raspado de datos (scraping), spam o escaneos. Segundo, tipo de ASN e infraestructura: las redes de centros de datos (hosting) y proxys públicos conllevan un riesgo base significativamente mayor que las conexiones residenciales o móviles. Tercero, coherencia multipunto y de protocolos: si en una misma sesión se observa separación de salidas en doble pila IPv4/IPv6, desvío geográfico del servidor DNS o exposición de IP local por WebRTC.

💡 Utilice la Prueba de túnel dividido para identificar anomalías de enrutamiento que eleven su puntuación de riesgo.

Incluso con una VPN o proxy activo, su identidad real puede filtrarse a través de canales secundarios: Primero, fugas de DNS: cuando el navegador resuelve un dominio, si el cliente proxy no intercepta las solicitudes a nivel de sistema operativo, las consultas se envían en texto plano al servidor DNS de su proveedor local de Internet (ISP), revelando los sitios visitados y su ubicación. Segundo, fugas de WebRTC: WebRTC es una tecnología integrada en navegadores para comunicación en tiempo real que, al establecer conexiones punto a punto (P2P), elude los proxys HTTP/SOCKS y envía paquetes STUN por UDP directamente, dejando al descubierto su IP local y pública real. Nuestra página principal analiza sus salidas DNS y el estado de WebRTC en tiempo real.

💡 Para evaluar fugas a nivel de hardware, visite la Prueba de huella digital del navegador.

El panel de pila de red de la página de inicio ejecuta tres sondas relacionadas en paralelo: una dirigida a un dominio con únicamente registros A (iptestv4.myipdns.com), otra dirigida a un dominio con únicamente registros AAAA (iptestv6.myipdns.com) y una tercera hacia un dominio de doble pila con ambas familias de registros. Las dos primeras son obligatorias: cada nombre resuelve únicamente en una familia de direcciones, sin dejar elección a su sistema, lo que permite registrar sus salidas reales en IPv4 e IPv6 de manera independiente. La tercera sonda no es forzada; por el contrario, observa qué familia de direcciones seleccionó su propio sistema, lo cual se muestra en la columna «Protocolo preferido»: este resultado lo determinan las directivas de selección de direcciones del sistema operativo y del navegador (Happy Eyeballs, RFC 8305: cuando ambas pilas están disponibles, se prueba IPv6 primero, recurriendo a IPv4 solo ante un fallo), no nosotros. Comparar las tres juntas es fundamental porque muchos clientes proxy y VPN solo canalizan IPv4: si su salida IPv4 se encuentra en el ASN del proxy mientras que su salida IPv6 permanece en su operador de banda ancha, y el protocolo preferido indica IPv6, al visitar sitios web con doble pila la mayor parte de su tráfico no circula en absoluto por el túnel; este es el caso más común de «VPN activada pero identidad real expuesta», y no genera ningún mensaje de error.

⚠ Únicamente podemos indicarle si sus salidas de ambas familias pertenecen a redes distintas; no podemos determinar cómo debe configurarse su software de proxy. A la inversa ocurre lo mismo: que IPv6 figure como no disponible no equivale a seguridad; puede indicar simplemente que su red carece de IPv6 o que el proxy desactivó IPv6 por completo, siendo esto último a menudo la práctica correcta.

No leemos la configuración de su sistema local: los navegadores no pueden acceder a ella en absoluto, y cualquier sitio web que afirme conocer su configuración DNS local simplemente está haciendo conjeturas. El método real consiste en realizar la prueba a la inversa: este sitio opera su propio servidor DNS autoritativo y genera para cada comprobación un subdominio aleatorio temporal (del tipo k3f9x2ab.leakv4.myipdns.com) para que su navegador lo resuelva. Este nombre aparece solo una vez en el mundo y nunca existirá en ninguna caché, por lo que su cadena de resolución recursiva debe consultar obligatoriamente a nuestro servidor autoritativo; nosotros registramos quién realizó la consulta y devolvemos esa dirección a la página. Por consiguiente, la columna «Salida DNS» muestra la dirección de red de salida real de su servidor de resolución recursivo, no la dirección introducida en los ajustes de su sistema: si usted configura 8.8.8.8, quien nos consultará será una máquina emisora concreta de dicho clúster, la cual bien puede hallarse en otro país; los grandes servicios públicos emplean Anycast y clústeres, por lo que resulta totalmente normal que aparezcan varias direcciones diferentes en una misma prueba. El criterio verdadero no es la coincidencia de direcciones, sino: si esta salida se ubica en la red de su propio proveedor de Internet mientras que su IP de navegación sale por el proxy, significa que el tráfico DNS no siguió el túnel.

⚠ Este método únicamente observa quién consultó a nuestro propio servidor autoritativo; no podemos ver ni tenemos forma de conocer otros dominios consultados. Presenta además una limitación conocida: si su proxy también gestiona las consultas DNS, observaremos el servidor de resolución del proveedor proxy, lo que confirma que no hay fugas hacia su operador local, pero sus registros de consulta permanecen visibles para el proveedor proxy; esa es una cuestión independiente que esta herramienta no puede evaluar.

A través de WebRTC se envían sondeos individuales a múltiples servidores STUN para recopilar los candidatos srflx devueltos, es decir, la dirección IP pública y el puerto observados por el extremo remoto tras la traducción NAT. Existe un único criterio decisivo: los candidatos se agrupan por la IP pública asignada; si bajo la misma IP aparecen dos o más puertos distintos, se clasifica como NAT simétrico (asigna un nuevo puerto externo para cada nuevo destino); de lo contrario, se clasifica como NAT cónico (asigna invariablemente el mismo puerto público al mismo puerto interno). Agrupar antes de comparar puertos es un paso deliberado: en entornos con túnel dividido, distintos servidores STUN pueden tomar salidas diferentes, lo que provoca discrepancias en los puertos; sin embargo, esto se debe a diferencias de ruta y no al comportamiento de la NAT; de no agrupar, todos estos casos se diagnosticarían erróneamente como simétricos. Mostrar «Desconocido» obedece a dos causas: primero, no recibir ningún candidato srflx dentro del tiempo límite de 4 segundos (WebRTC deshabilitado en el navegador, bloqueado por extensiones o UDP saliente filtrado); segundo, recibir un único candidato cuya IP pública no coincide con la IP de acceso a este sitio, resultando imposible discernir entre deduplicación del navegador o división de tráfico, por lo que preferimos mostrar desconocido.

⚠ Aclaración honesta: nosotros solo diferenciamos entre NAT cónico y simétrico, sin subclasificar en cónico completo, restringido o restringido por puerto. El modelo de cuatro categorías del RFC 3489 requiere controlar combinaciones de puertos de origen y destinos mediante sondeos iterativos, y WebRTC en navegadores no proporciona dicho control; las herramientas web que informan una de esas cuatro clases en su mayoría solo están reetiquetando estos dos resultados.

Una sola comprobación en la página principal emite seis sondas en paralelo dirigidas a distintos dominios: una exclusivamente IPv4, una exclusivamente IPv6, dos destinadas a capturar huellas de pila de red sobre IPv4 e IPv6 respectivamente, una hacia un dominio de doble pila para observar la familia preferida de su sistema y una forzada expresamente mediante HTTP/1.1. No constituyen peticiones duplicadas; cada una recopila datos completamente diferentes. Su envío por separado es indispensable porque nuestro diagnóstico se fundamenta en la comparación entre capas: un mismo dispositivo expone características de pila diferentes en IPv4 frente a IPv6 y en HTTP/1.1 frente a HTTP/2 (y HTTP/3 cuando está disponible), las cuales solo pueden contrastarse tras obtenerse individualmente. Por otra parte, la ejecución en paralelo no busca velocidad: si se realizaran secuencialmente, un cambio de red, reconexión de proxy o restablecimiento del túnel combinaría registros pertenecientes a una máquina híbrida inexistente; la ejecución paralela garantiza que las seis sondas analicen el mismo enlace en el mismo instante. Entre ellas, la sonda HTTP/1.1 emite a propósito una sola solicitud: HTTP/1.1 carece de tabla dinámica HPACK, por lo que peticiones adicionales no aportan entropía extra, mientras que una sola llamada asegura que las cabeceras se asocien estrictamente al mismo registro.

⚠ La contrapartida es que la carga inicial conecta con múltiples subdominios, lo que bloqueadores de anuncios o extensiones estrictas de privacidad pueden interceptar. En tales circunstancias, la columna correspondiente mostrará un punto gris en estado desconocido; bajo ningún concepto utilizaremos datos de otras sondas para simular un valor aparentemente completo.