# Cómo comprobar si un proxy filtra IP, DNS o WebRTC con ToDetect Source: https://ipvolt.com/es/blog/proxy-leak-check-todetect Markdown: https://ipvolt.com/es/blog/proxy-leak-check-todetect.md Language: es [Inicio de ipvolt](https://ipvolt.com/es.md) / [Blog](https://ipvolt.com/es/blog.md) / Comprobar fugas de IP, DNS y WebRTC de un proxy con ToDetect Análisis Publicado: 2026-10-23 Actualizado: 2026-10-23 Por ipvolt 10 min de lectura Comprueba si un proxy de navegador filtra IP, DNS, WebRTC o zona horaria con las herramientas gratuitas de ToDetect, con resultados medidos en una línea móvil 4G. 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](/es/guides/germany-proxies) 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](/downloads/proxy-leak-check-todetect/results.json), 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](https://www.todetect.net/ip/) 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](https://www.todetect.net/dns-leak/) 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](https://www.todetect.net/ip/). 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 del proxy móvil: Berlin, D2VODAFONE, tipo de IP Mobile, IP Quality Score 94%](/media/blog/proxy-leak-check-todetect/leak-ip.png) *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ó: | Conexión | Tipo de IP | Puntuación | Deducciones mostradas | | --- | --- | ---: | --- | | Conexión propia de la máquina (VPN, Estonia) | Datacenter | 68% | IP Usage Frequency -3%, VPS/IDC Provider -25%, Occasional ASN Organization Change -4% | | Proxy móvil 4G (Vodafone Germany) | Mobile | 94% | IP Usage Frequency -3%, Regional ISP -3% | 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](https://www.todetect.net/dns-leak/) 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. ![DNS Leak Test de ToDetect a través del proxy: dos resolvedores de Vodafone Germany](/media/blog/proxy-leak-check-todetect/leak-dns-leak.png) *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](/es/blog/socks5-vs-socks5h) trata ese caso. ## 4. Comprueba WebRTC Abre el [WebRTC Leak Test](https://www.todetect.net/webrtc/). 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é. ![WebRTC Leak Test de ToDetect con la configuración predeterminada de Chromium: WebRTC IP Exposure Detected](/media/blog/proxy-leak-check-todetect/leak-webrtc.png) *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 | Navegador y ajuste | Servidores STUN con la dirección propia de la máquina | Resultado | | --- | ---: | --- | | Chromium, predeterminado | 13 de 17 (tres ejecuciones) | Fuga | | Chromium headless, `--force-webrtc-ip-handling-policy=disable_non_proxied_udp` | 0 de 17 (una ejecución) | Correcto | | Chromium en ventana normal, mismo flag | 13 de 17 (dos ejecuciones) | Fuga | | Chromium en ventana normal, preferencia de perfil `webrtc.ip_handling_policy` = `disable_non_proxied_udp` | 0 de 17 (dos ejecuciones) | Correcto | | Firefox, predeterminado | 10 de 17 (una ejecución) | Fuga | | Firefox, `media.peerconnection.ice.proxy_only` = true | 0 de 17 (una ejecución) | Correcto | *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: ```js 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](/es/guides/playwright-proxy-setup) 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](https://chromeenterprise.google/policies/#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](https://chromewebstore.google.com/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia). 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. ![WebRTC Leak Test de ToDetect después de la corrección: todos los servidores STUN muestran Not detected](/media/blog/proxy-leak-check-todetect/fixed-webrtc.png) *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](https://www.todetect.net/timezone/). 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. ![Timezone Detection de ToDetect: Europe/Berlin según la IP frente a Europe/Vilnius en el navegador](/media/blog/proxy-leak-check-todetect/leak-timezone.png) *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. ![Timezone Detection de ToDetect después del cambio: ambas zonas Europe/Berlin, configuración regional de-DE](/media/blog/proxy-leak-check-todetect/fixed-timezone.png) *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](https://www.todetect.net/) 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](https://www.todetect.net/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](https://www.todetect.net/ip/) muestra la ubicación, el ISP y el tipo de IP del proxy, no los tuyos. 3. Confirma que el [DNS Leak Test](https://www.todetect.net/dns-leak/) solo muestra resolvedores de la red del proxy o los que elegiste. 4. Ejecuta el [WebRTC Leak Test](https://www.todetect.net/webrtc/). 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](https://www.todetect.net/timezone/). 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](https://ipvolt.com/#waitlist-closing). Un correo cuando se abra el acceso. Nada más. ## Fuentes - [Chromium: compatibilidad con proxies en Chrome (net/docs/proxy.md)](https://chromium.googlesource.com/chromium/src/+/main/net/docs/proxy.md) - [RFC 8828: WebRTC IP Address Handling Requirements](https://www.rfc-editor.org/rfc/rfc8828) - [Política de Chrome Enterprise: WebRtcIPHandling](https://chromeenterprise.google/policies/#WebRtcIPHandling) - [Definición de la política en Chromium: WebRtcIPHandling.yaml](https://chromium.googlesource.com/chromium/src/+/main/components/policy/resources/templates/policy_definitions/WebRtc/WebRtcIPHandling.yaml) - [API de extensiones de Chrome: chrome.privacy (webRTCIPHandlingPolicy)](https://developer.chrome.com/docs/extensions/reference/api/privacy) - [Chrome Web Store: WebRTC Network Limiter](https://chromewebstore.google.com/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia) - [Código fuente de Chromium: content_switches.cc (force-webrtc-ip-handling-policy)](https://chromium.googlesource.com/chromium/src/+/main/content/public/common/content_switches.cc) - [Código fuente de Chromium: headless_web_contents_impl.cc](https://chromium.googlesource.com/chromium/src/+/main/headless/lib/browser/headless_web_contents_impl.cc) - [Código fuente de Chromium: renderer_preferences_util.cc](https://chromium.googlesource.com/chromium/src/+/main/chrome/browser/renderer_preferences_util.cc) - [Código fuente de Firefox: modules/libpref/init/all.js (preferencias media.peerconnection)](https://github.com/mozilla-firefox/firefox/blob/main/modules/libpref/init/all.js) - [Código fuente de Firefox: StaticPrefList.yaml](https://github.com/mozilla-firefox/firefox/blob/main/modules/libpref/init/StaticPrefList.yaml) - [ToDetect: IP Quality Check](https://www.todetect.net/ip/) - [ToDetect: DNS Leak Test](https://www.todetect.net/dns-leak/) - [ToDetect: WebRTC Leak Test](https://www.todetect.net/webrtc/) - [ToDetect: Timezone Detection](https://www.todetect.net/timezone/) - [ToDetect: Browser Fingerprint Checker](https://www.todetect.net/) - [ToDetect: Bot Detection](https://www.todetect.net/bot-detection/) ## Entérate cuando se abra el acceso a ipvolt. Ya que estás aquí ipvolt está en desarrollo. Deja tu correo y te avisaremos una sola vez cuando se abra el acceso. Un correo cuando se abra el acceso. Nada más. [Solicitar acceso anticipado](https://ipvolt.com/es/blog/proxy-leak-check-todetect#waitlist-blog-end) [Privacidad](https://ipvolt.com/privacy) ## Artículos relacionados - [Python 3.15 para web scraping: qué se instala y qué falla](https://ipvolt.com/es/blog/python-3-15-web-scraping.md) (Análisis, 16 oct 2026, 9 min de lectura): pip install scrapy falla en Python 3.15 sin compilador de C porque brotli no tiene wheel cp315. Instalamos 19 paquetes de scraping con pip y uv para ver el resto. - [Parsear precios japoneses: yenes, ancho completo y etiquetas fiscales](https://ipvolt.com/es/blog/japanese-price-parsing.md) (Análisis, 6 oct 2026, 7 min de lectura): Parsea precios japoneses sin perder la divisa ni la base fiscal, con un fixture de Python probado: yen de ancho completo, precios mixtos y casos de revisión deliberados. - [SOCKS5 vs SOCKS5h: diferencias y qué envían 6 clientes (probado)](https://ipvolt.com/es/blog/socks5-vs-socks5h.md) (Comparativa, 4 oct 2026, 8 min de lectura): socks5:// no significa DNS local en todos los clientes. Registramos qué envían curl, Requests, HTTPX, aiohttp, Playwright y Node a un proxy SOCKS5 con cada esquema. ## Guías relacionadas - [Configurar un proxy en Playwright](https://ipvolt.com/es/guides/playwright-proxy-setup.md): Configura un proxy HTTP autenticado en un contexto de navegador de Playwright, aísla el estado de la prueba y diagnostica la navegación por separado de los subrecursos. - [Proxies de Alemania: redes, ciudades y pruebas regionales](https://ipvolt.com/es/guides/germany-proxies.md): Evalúa proxies de Alemania con contexto actual de operadores y roaming, límites de la ubicación por ciudad, control del idioma del navegador y una lista de aceptación. - [Proxies HTTP vs SOCKS5: elige según la conexión](https://ipvolt.com/es/guides/http-vs-socks5-proxies.md): Compara HTTP CONNECT y SOCKS5, entiende dónde se resuelve el DNS y los límites de TLS, y elige un protocolo que tu cliente y tu proveedor realmente soporten. ## Sobre ipvolt Análisis técnico del equipo de ipvolt. El acceso a ipvolt aún no está abierto. [Leer el original en inglés](https://ipvolt.com/blog/proxy-leak-check-todetect.md)