Cómo comprobar si un proxy filtra IP, DNS o WebRTC con ToDetect

Un proxy en el navegador cambia el origen de las peticiones de la página. Las consultas DNS, las conexiones WebRTC y la zona horaria del navegador pueden seguir apuntando a la red propia de la máquina. Esta guía muestra cómo comprobar cada una con las herramientas gratuitas de ToDetect, qué aspecto tiene un resultado correcto y uno fallido, y qué correcciones funcionaron en nuestra prueba.

El ejemplo es una prueba real que hizo ipvolt:

• Cuándo: 23 de octubre de 2026, de 16:45 a 16:57 UTC.
• Máquina: un Mac con macOS 15.7.4.
• Navegadores: Chromium 153 y Firefox, controlados con Playwright 1.63.0, en modo headless y en ventanas normales.
• Proxy: un proxy móvil 4G en la red de Vodafone Germany que usamos para pruebas previas al lanzamiento, configurado como proxy HTTP con usuario y contraseña. Proxies de Alemania explica el contexto de las redes móviles alemanas.
• Conexión propia de la máquina: una salida de VPN comercial en Tallin (Estonia), que es una dirección de centro de datos.
• Enmascarado: las direcciones IP están ocultas en las capturas y eliminadas del archivo de resultados, que recoge los recuentos y las puntuaciones de cada ejecución.

1. Obtén una referencia sin el proxy

Ejecuta cada prueba una vez con el proxy desactivado para saber cómo se ve tu propia conexión. Nuestra referencia en IP Quality Check de ToDetect fue: ubicación Tallin, tipo de IP Datacenter, organización ASN con la etiqueta HOSTING y una IP Quality Score del 68%. El DNS Leak Test mostró un solo resolvedor, el de la VPN, en Estonia.

2. Comprueba la IP que ve el sitio web

Activa el proxy y vuelve a cargar la página IP Quality Check. Compara cuatro campos con lo que esperas del proxy: ubicación, ISP y ASN, tipo de IP y zona horaria.

A través del proxy móvil, la página mostró Berlin, ISP D2VODAFONE, ASN 3209 (Vodafone GmbH), tipo de IP Mobile, IP Abuse «No», zona horaria Europe/Berlin e idioma German.

IP Quality Check de ToDetect a través de la línea 4G de prueba, 23 de octubre de 2026. Dirección IP y prefijo ocultos.

La puntuación se calcula a partir de deducciones que aparecen en la página, y puedes abrirlas para ver por qué cambió:

La mayor parte de la diferencia es la deducción VPS/IDC Provider. Un resultado correcto significa que la ubicación, el ISP y el tipo de IP coinciden con el proxy que configuraste; el paso 5 compara la zona horaria con el navegador. Si sigues viendo tu propio ISP o tu ciudad, el navegador no está usando el proxy, y las demás pruebas no dirán mucho hasta que lo corrijas. La puntuación refleja las bases de datos propias de ToDetect; tómala solo como una señal entre otras.

3. Comprueba dónde se resuelve el DNS

Ejecuta el DNS Leak Test con el proxy activado. Muestra los resolvedores DNS que respondieron a las consultas de tu navegador. Un resultado correcto es una lista de resolvedores que pertenecen a la red del proxy o un resolvedor que elegiste a propósito. Un fallo es el resolvedor de tu ISP o de tu propia red.

A través del proxy, los resolvedores fueron 139.7.74.9 y 139.7.74.10, ambos «Vodafone Germany, Germany». El resolvedor estonio de la referencia había desaparecido.

Ambos resolvedores pertenecen a Vodafone Germany. La IP del cliente, arriba, está oculta.

Es lo esperado con un proxy HTTP en Chromium, cuya documentación dice que «name resolution is always deferred to the proxy» (la resolución de nombres siempre se delega en el proxy): el nombre de host viaja en la petición CONNECT. Puede haber fugas de DNS con SOCKS4, o con clientes SOCKS5 que resuelven los nombres localmente antes de conectar, como curl con socks5:// en lugar de socks5h://. SOCKS5 vs SOCKS5h trata ese caso.

4. Comprueba WebRTC

Abre el WebRTC Leak Test. Pregunta a 17 servidores STUN desde qué dirección pública parece llegar tu navegador. Un resultado correcto es «Not detected» o la dirección del proxy en todos los servidores. Un fallo es el aviso rojo «WebRTC IP Exposure Detected» y tu propia dirección en los campos Public IP.

Con la configuración predeterminada, los dos navegadores fallaron:

• Chromium, predeterminado: 13 de 17 servidores STUN devolvieron la dirección propia de la máquina (11 o 12 como IPv4, 1 o 2 como IPv6, en tres ejecuciones). Los otros 4 mostraron «Not detected».
• Firefox, predeterminado: 10 de 17 devolvieron la dirección IPv4 propia de la máquina y 4 mostraron «Not detected». Los otros 3 mostraron 0.0.0.0, que no revelaba ninguna IP; no averiguamos por qué.

La página sitúa la conexión en Berlín, por la IP del proxy, pero los servidores STUN devolvieron la dirección propia de la máquina (oculta): 13 de 17 en esta ejecución. El recorte muestra tres.

La causa es el transporte. WebRTC envía las peticiones STUN por UDP. Un proxy HTTP estándar solo retransmite conexiones TCP, así que por defecto esas peticiones salen por la conexión propia de la máquina y el servidor STUN ve esa IP pública. El RFC 8828 describe este caso: si se permite el acceso directo a Internet, «WebRTC's STUN checks will bypass the proxy and reveal the public IP address of the client» (las comprobaciones STUN de WebRTC esquivarán el proxy y revelarán la dirección IP pública del cliente).

Correcciones que probamos

Los recuentos incluyen direcciones IPv4 e IPv6.

El flag de línea de comandos corrigió Chromium headless, pero no una ventana normal. El código fuente de Chromium lee ese switch en el shell headless, mientras que Chrome normal lee la preferencia de perfil webrtc.ip_handling_policy. No encontramos documentación que diga que el flag se ignora en una ventana normal, así que tómalo como un resultado medido, no como una regla documentada.

La corrección de Chromium que medimos escribe la preferencia en el archivo Default/Preferences del perfil antes del arranque. En Playwright eso requiere un contexto persistente:

import { chromium } from 'playwright';
import { mkdtempSync, mkdirSync, writeFileSync } from 'node:fs';
import { tmpdir } from 'node:os';
import { join } from 'node:path';

const dir = mkdtempSync(join(tmpdir(), 'leak-check-'));
mkdirSync(join(dir, 'Default'));
writeFileSync(
  join(dir, 'Default', 'Preferences'),
  JSON.stringify({ webrtc: { ip_handling_policy: 'disable_non_proxied_udp' } }),
);

const context = await chromium.launchPersistentContext(dir, {
  headless: false,
  proxy: {
    server: process.env.PROXY_SERVER,
    username: process.env.PROXY_USERNAME,
    password: process.env.PROXY_PASSWORD,
  },
});

PROXY_SERVER contiene la URL del proxy, con el esquema y el puerto. Configurar un proxy en Playwright explica el resto de la configuración del cliente.

Otras dos formas de fijar la misma preferencia en Chrome, que no probamos:

• Configura la política empresarial WebRtcIPHandling con disable_non_proxied_udp. Chrome usa entonces UDP solo si el proxy configurado lo admite y, si no, usa TCP a través del proxy. La página de la política indica la ubicación en el registro de Windows y el nombre de la preferencia en macOS y Linux.
• Instala la extensión de Google WebRTC Network Limiter. Su ficha en la tienda dice que la opción que desactiva el UDP que no pasa por el proxy está desactivada por defecto y se activa desde la página Options.

Según la definición de la política en Chromium y la documentación de chrome.privacy, ambas controlan la preferencia que nosotros fijamos. Repite la prueba de WebRTC después de aplicar cualquiera de ellas.

En Firefox, abre about:config y pon media.peerconnection.ice.proxy_only en true, para que el tráfico WebRTC pase solo por el proxy configurado. En Playwright, pásala como firefoxUserPrefs: { 'media.peerconnection.ice.proxy_only': true } a firefox.launch(). Poner media.peerconnection.enabled en false desactiva WebRTC por completo. Solo probamos el primer ajuste, sin las opciones de zona horaria del paso 5.

Chromium en ventana normal con la preferencia de perfil: sin aviso de exposición, los 17 servidores en «Not detected» (se ven tres).

5. Comprueba la zona horaria

Abre Timezone Detection. Compara la zona horaria deducida de tu IP con el identificador de zona horaria del propio navegador. Si estás comprobando cómo se comporta un sitio para visitantes de la ubicación del proxy, como páginas localizadas o ubicaciones de anuncios, ambas deberían coincidir.

Con el proxy activado y el navegador con la configuración de la máquina, la zona según la IP era Europe/Berlin y el identificador de zona horaria IANA del navegador era Europe/Vilnius. Es una discrepancia en el identificador de zona horaria. El proxy cambia la ruta de red, no la zona horaria configurada en el navegador. En nuestra ejecución, ToDetect mostró el mismo desfase UTC para ambas; solo difería el identificador de zona.

La zona según la IP sigue al proxy. El identificador de zona del navegador se queda en la configuración de la máquina.

En Chromium añadimos después timezoneId: 'Europe/Berlin' y locale: 'de-DE' a las opciones de launchPersistentContext() del paso 4. Esta configuración combinada es la de las capturas de «después». Ambas zonas pasaron a ser Europe/Berlin.

Después del cambio: el identificador de zona horaria IANA del navegador es Europe/Berlin y la configuración regional es de-DE.

En un navegador normal sin automatización, la zona horaria viene del sistema operativo: cambia la zona horaria del sistema y elige el idioma en los ajustes del navegador. No probamos esta vía, así que vuelve a comprobar la página después.

6. Lee el resumen de la huella al final

La página principal de ToDetect reúne las comprobaciones anteriores en una puntuación «Browser Fingerprint Consistency» que, según ToDetect, «does not represent a definitive pass or fail result» (no representa un resultado definitivo de aprobado o suspenso). En una ventana normal de Chromium con perfil persistente, mostró un 65% con la configuración predeterminada y un 87% tras los cambios de WebRTC y zona horaria (valores tal como aparecían en pantalla). Las deducciones Timezone Anomaly y WebRTC Alert desaparecieron. Las deducciones WebDriver y ClientRect que quedaron se deben al navegador de prueba automatizado; también quedó una Language Anomaly, y no determinamos qué la provocó.

La página Bot Detection marcó anomalías WebDriver y Dev Tool en todas las ejecuciones, y una anomalía Headless Chrome en las ejecuciones headless, algo esperable con automatización. Los contextos de tipo privado y el modo headless añadieron sus propias deducciones a la huella, así que para QA, verificación de anuncios o comprobaciones geográficas, prueba en el perfil de navegador que vayas a usar para el trabajo real.

Lo que no probamos

No probamos SOCKS5 en el navegador (Chromium no admite la autenticación con usuario y contraseña en proxies SOCKS5), Safari, Edge, navegadores móviles ni la rotación de IP durante una sesión. Estos resultados describen una línea, una máquina y un día.

Lista de comprobación

1. Registra una referencia con el proxy desactivado: IP, ISP, tipo de IP y resolvedores DNS.
2. Con el proxy activado, confirma que la comprobación de IP muestra la ubicación, el ISP y el tipo de IP del proxy, no los tuyos.
3. Confirma que el DNS Leak Test solo muestra resolvedores de la red del proxy o los que elegiste.
4. Ejecuta el WebRTC Leak Test. Si aparece tu propia dirección, pon la preferencia webrtc.ip_handling_policy de Chrome en disable_non_proxied_udp o la preferencia media.peerconnection.ice.proxy_only de Firefox en true, y repítelo. No confíes en el flag de línea de comandos en una ventana normal.
5. Si tu prueba depende de la ubicación del proxy, ajusta la zona horaria y la configuración regional del navegador a ella (opciones de Playwright, o la zona horaria del sistema y el idioma del navegador en un navegador normal) y vuelve a comprobar Timezone Detection.
6. Lee las deducciones de la huella y separa las causadas por el proxy de las causadas por tu entorno de prueba.
7. Repite todas las pruebas después de cualquier cambio, en la configuración de navegador que vayas a usar de verdad.

ipvolt hizo estas comprobaciones para sus propias pruebas previas al lanzamiento. El servicio está en desarrollo y el acceso se abre a principios de noviembre. Si quieres saber cuándo, únete a la lista de acceso anticipado. Un correo cuando se abra el acceso. Nada más.

Etiquetas:ProxiesTroubleshooting