¿El sitio solo te bloquea con la VPN activada? Esto es lo que ve
El bloqueo suele ser la dirección de salida, no una fuga. Revisa la red desde la que parece llegar tu tráfico, el resolutor que un sitio puede registrar y lo que sabe el código de la página.
La tienda carga bien en casa y muestra un muro de «tráfico inusual» en el momento en que el túnel se levanta. Un foro se niega a iniciar tu sesión, y una página de streaming insiste en que estás en un país que nunca has visitado. Nada de eso requiere software espía. Un sitio ve la dirección desde la que llegan tus paquetes, y con una VPN esa dirección pertenece a un centro de datos en lugar de a una línea doméstica. La mayor parte de lo que se llama detección de VPN empieza y termina en ese único hecho, y el resto es inferencia con una tasa de error previsible.
El bloqueo empieza por dónde parece que vienen tus paquetes
Cada solicitud lleva una dirección de origen, y el servidor que la recibe puede consultarla en datos públicos: qué red la anuncia, si esa red es un proveedor de alojamiento, si ha aparecido en listas de abuso y qué país le asigna el registro. Nada de eso te identifica, y todo junto basta para encasillarte.
Mira tu propio tráfico como lo haría un desconocido. Dos comandos cubren la mayor parte de la superficie, y el segundo es el que la gente olvida:
curl -sS https://ipinfo.io/json
dig +short TXT o-o.myaddr.l.google.com @ns1.google.com
El primero devuelve la dirección de salida, su organización y su país. El segundo devuelve la dirección del resolutor que llegó al servidor de nombres de Google, que a menudo es una red distinta de tu salida y es la dirección que ve un sitio si registra datos del lado del resolutor. Cuando esas dos pertenecen a países distintos, algunos sitios tratan la discrepancia como sospechosa aunque no haya nada malo en tu configuración.
Cuando el rechazo empieza solo después de que el túnel se levanta, sospecha de la dirección de salida antes que de nada más. Cambia de servidor y vuelve a intentarlo antes de tocar el navegador. Un bloqueo que te sigue por tres salidas del mismo proveedor tiene que ver con los rangos del proveedor; un bloqueo que desaparece en otro servidor tiene que ver con esa única dirección.
La zona horaria, el idioma y el reloj no concuerdan con la dirección
El código de la página puede leer tu zona horaria, tus preferencias de idioma y la configuración de pantalla sin ninguna petición de permiso. Un navegador que informa de la hora de Europa Central mientras la conexión llega de un centro de datos en Singapur es una señal más fuerte que la dirección sola, y es justo el tipo de discrepancia que la puntuación de fraude está hecha para notar.
Intl.DateTimeFormat().resolvedOptions().timeZone
navigator.language
Intl.DateTimeFormat().resolvedOptions().locale
Esas tres líneas en la consola de desarrollador te dicen qué ofrece voluntariamente tu navegador. Un cliente VPN puede cambiar tu ruta y nada más, así que el perfil que llevas se queda doméstico mientras que tu salida no lo es. La coherencia es lo que importa aquí: un portátil configurado en la misma región que la salida parece normal, y uno que se contradice a sí mismo no.
También es por eso que el fallo es intermitente. A muchos sitios no les importa, unos pocos lo puntúan, y un sitio de suscripción decide que eres un estafador. El cliente funciona correctamente en los tres casos, y por eso la respuesta habitual del soporte, «debe ser tu navegador», es a la vez molesta y en parte cierta.
Lo que el código de la página sabe realmente de tu máquina
JavaScript no tiene ninguna API que enumere interfaces de red. Una página no puede preguntar qué direcciones tiene tu portátil, así que la vieja afirmación de que un script lee tu dirección LAN es sobre todo un recuerdo de la época de los complementos, cuando los controles ActiveX, los applets de Java y otro código nativo podían hacer exactamente eso.
| Signal | What it reveals | Status today |
|---|---|---|
| Source address of the request | Exit network, country, hosting status | Always visible; the main signal |
| Time zone and language | Where the profile claims to be | Readable without permission |
| WebRTC candidates | Local addresses, historically | Host candidates are mDNS-obfuscated by default |
| Interface list | All local addresses | Not available to ordinary JavaScript |
WebRTC es la excepción honesta a «ninguna fuga de direcciones locales». Su recopilación de candidatos exponía antes direcciones locales a cualquier página que lo pidiera, y la solución fue sustituir los candidatos de host por nombres mDNS aleatorios. Ese valor predeterminado se mantiene en los navegadores actuales, pero es una decisión del navegador y no una garantía del protocolo, así que una versión anticuada o una configuración endurecida que vuelva a habilitar los candidatos locales todavía puede filtrar. Actualizar el navegador te ayuda aquí más que cualquier extensión.
Tu proveedor ve los nombres, no los contenidos
HTTPS protege el contenido de una página de extremo a extremo, y el operador del túnel que reenvía esos bytes no puede leerlos. El operador aún puede ver a qué dirección has contactado, y en la mayoría de despliegues el nombre del servidor en el handshake, porque el nombre tiene que ser legible para que la conexión se dirija al sitio correcto. Encrypted Client Hello existe precisamente para ocultar ese campo, y solo ayuda cuando tanto el cliente como el sitio lo admiten.
La resolución de nombres es la otra mitad. Si tu proveedor también proporciona el resolutor, ve cada nombre que consultas antes de que exista cualquier conexión. Si tu dispositivo usa un resolutor público por HTTPS, el proveedor ve una conexión a ese resolutor y nada más, mientras que el resolutor mismo ve la lista.
Una solicitud HTTP sin cifrar es legible para el operador por la misma razón por la que es legible para la red del hotel: nada en su interior está cifrado. Un túnel nunca ha afirmado lo contrario, y no arregla la elección de la aplicación.
Separa «esto es una VPN» de «este soy yo»
La detección es barata, probabilística y a menudo errónea. Las direcciones de salida compartidas se marcan porque alguien más abusó de ellas, los rangos corporativos se clasifican como alojamiento, y los operadores móviles producen resultados geográficos que sorprenden a todos. La identificación es un problema distinto: necesita un vínculo persistente como una cuenta con la que has iniciado sesión, una cookie, un dato de pago o dos observadores que comparan notas.
Decide contra cuál de los dos luchas realmente. Si el objetivo es leer una página, HTTPS ya hace ese trabajo y el túnel cambia poco. Si el objetivo es evitar que el sitio sepa en qué ciudad estás, la salida y el resolutor son lo que importa. Si el objetivo es romper el vínculo con tu identidad real, la cuenta es el punto débil, y cambiar de servidor no hace nada por el inicio de sesión que acabas de usar.
Una salida nueva no te desconecta de nada, y no puede borrar lo que un sitio ya ha guardado sobre la cuenta que usaste. La secuencia práctica es, pues, poco espectacular: elige una salida cuya red parezca normal, mantén el perfil del navegador coherente con ella, actualiza el navegador para que las funciones propensas a fugas usen sus valores predeterminados modernos, y acepta que un pequeño número de sitios seguirá equivocándose contigo.