Primero confirma quién dio el aviso de VPN
Cuando una página muestra “proxy o VPN detectados”, primero distingue de qué capa proviene el mensaje. La primera categoría común son las etiquetas de clasificación de proveedores de inteligencia IP: el sitio web llama a su API para consultar si la dirección de conexión actual aparece en listas de hosting, proxy o redes anónimas, y luego muestra directamente la advertencia de riesgo. La segunda son reglas de rechazo que el propio sitio mantiene, como permitir solo direcciones de ciertos países o ASN específicos, o poner en lista negra rangos CIDR completos con abuso reciente. La tercera es la detección del entorno del navegador, que mediante JavaScript lee candidatos WebRTC, resultados de resolución DNS o características como zona horaria e idioma, y alerta si no coinciden con la conexión principal de la página.
La base y fiabilidad de estos tres tipos de juicio son completamente diferentes. Las etiquetas de proveedores de datos suelen provenir de observaciones históricas y envíos de terceros, con tiempos de actualización variables y posibles entradas obsoletas; las reglas personalizadas de un sitio a menudo solo se enfocan en su propia experiencia y no son una conclusión universal; la detección del navegador mezcla configuración del dispositivo y entorno de red, y no necesariamente indica una VPN real. Muchas plataformas solo dan un aviso genérico sin mostrar evidencia concreta al usuario; si se toma directamente como “confirmado que usas VPN”, se omite el proceso real de investigación.
La mayoría de los sitios web juzgan en base a solicitudes visibles, bases de datos de direcciones y sus propias reglas; no pueden observar directamente el túnel cifrado completo entre el dispositivo del usuario y la puerta de enlace VPN remota. Por lo tanto, el aviso de la página no es prueba de que se haya capturado el protocolo VPN del usuario. Primero verifica las etiquetas y su origen en Detección de VPN y proxy, luego combina con la investigación de proxy del sistema, túneles corporativos y salida del operador para decidir si es un problema de configuración, un registro antiguo o una política del sitio de destino.
¿Qué diferencia hay entre etiquetas de VPN, proxy, Tor y hosting?
VPN establece una conexión de red virtual; las VPN de acceso remoto comunes usan túneles cifrados, pero no todas las redes llamadas VPN se definen por el cifrado. Un proxy suele reenviar solicitudes para ciertas aplicaciones o protocolos, y su cifrado depende de la implementación específica. El nodo de salida de Tor representa el circuito que conecta con el servicio de Internet de destino; un relay ordinario no tiene necesariamente función de salida. La etiqueta de hosting es una pista de clasificación de proveedores de datos sobre centros de datos o infraestructura en la nube; estos conceptos pueden superponerse pero no son intercambiables.
No se puede equiparar hosting con VPN, ni VPN con malicia. Que una empresa use VPN para que los empleados accedan de forma remota a sistemas internos es una práctica de seguridad común, y el uso personal de VPN comerciales también es una opción legítima de privacidad. Muchos sitios rechazan directamente direcciones de hosting porque gran parte del tráfico automatizado y los ataques provienen de centros de datos, no porque esa dirección ejecute necesariamente un servicio VPN. Por el contrario, una dirección de banda ancha doméstica también puede usarse temporalmente como salida; la clasificación de datos debe considerar el tiempo y la fuente de observación.
Las listas de Tor deben leerse teniendo en cuenta fuente, tiempo de actualización y rol del nodo: una coincidencia con la lista actual de salidas solo significa que esa fuente registró esa IP como salida en el momento correspondiente; que no coincida no prueba que no se use Tor. Los relays ordinarios, puentes y nodos de salida tienen funciones diferentes, y no se puede tratar a todos los nodos por igual como origen del acceso al sitio web de destino. Una salida dada de baja también puede seguir en algunas bases de datos por retraso en la actualización; conviene revisar la entrada específica en lugar de leer solo una etiqueta.
¿De dónde proviene la evidencia de clasificación IP?
Las principales vías por las que un sitio web o sistema antifraude obtiene antecedentes de una IP incluyen: registros públicos de asignación de direcciones de los Registros Regionales de Internet, bases de clasificación de proveedores comerciales, listas de rangos publicadas por proveedores de nube y observaciones acumuladas de su propio tráfico de ataques o inicios de sesión. Los prefijos públicos oficiales solo indican a quién se asignó un CIDR, por ejemplo a un proveedor de nube o un ISP, no la ubicación física de la conexión actual ni si se usa un túnel. Las fuentes de datos autorizadas pueden ofrecer etiquetas de proxy o Tor, pero su frecuencia de actualización y reglas de decisión suelen ser opacas.
RDAP proporciona la organización registrante, el rango, eventos y contactos de un recurso de dirección; el ASN identifica el sistema autónomo. BGP muestra los anuncios de ruta observados; la validación de origen RPKI comprueba si el prefijo coincide con el ASN de origen según una autorización válida, pero no valida la ruta completa ni el comportamiento del usuario. Que la organización registrante sea un proveedor de nube es una pista de contexto, no puede probar por sí sola que el dispositivo actual use VPN, ni se puede usar RPKI Valid como evidencia de buena reputación de la dirección.
Sobre cómo usar la información de RDAP y ASN para el juicio, consulta RDAP, ASN, BGP y RPKI: cómo interpretar una consulta de IP. No concluyas basándote únicamente en una etiqueta. Las observaciones de tráfico real pueden tener sesgos; por ejemplo, una dirección compartida abusada por pocos usuarios hace que toda la IP entre en listas negras. La clasificación de proveedores de datos puede mezclar segmentos de hosting con VPN u omitir nuevos servicios anónimos. Cuanto más específica sea la evidencia, más fiable: tiempo, fuente, dirección y lista actualizada valen más que una simple conclusión de “alto riesgo”.
Orden de investigación cuando la banda ancha normal está marcada
Cuando una dirección de banda ancha doméstica o punto de acceso móvil se marca como proxy, primero revisa la configuración local. El sistema operativo o el navegador pueden tener un proxy manual configurado, y ciertas extensiones también cambian la salida; un equipo corporativo puede tener una VPN obligatoria o túnel de seguridad instalado. Luego revisa el entorno de red actual: la puerta de enlace empresarial puede enrutar todo el tráfico hacia un centro de datos, y el operador puede usar CGNAT para que varios usuarios compartan una IPv4 pública. Compartir significa que la misma dirección puede ser usada por otros usuarios al mismo tiempo, heredando así sus etiquetas de riesgo.
La asignación dinámica, transferencia de direcciones o cambio de uso pueden hacer que etiquetas antiguas no correspondan al entorno actual, pero primero confirma el registro real de asignación; no asumas que toda dirección de banda ancha dinámica se usó antes en un VPS. Una consulta RDAP pública suele ofrecer el registro actual y algunos campos de eventos, sin garantizar un historial completo. Puedes verificar con el operador el momento de asignación de la dirección y compararlo con la entrada de la lista y su fecha de actualización; al revisar IPv4 e IPv6 por separado, confirma también que ambas consultas se refieran realmente a la misma ruta de servicio.
Este tipo de investigación requiere combinar las ideas de Cómo saber tu IP pública y comprobar si tienes CGNAT: confirma si ves una dirección pública o una dirección interna del operador. Si es CGNAT, la salida visible hacia el exterior difiere de tu dirección local, y las etiquetas de riesgo pueden provenir de otros usuarios en el mismo pool. No concluyas de inmediato que la base de datos está equivocada; es posible que tu entorno realmente tenga un túnel empresarial o un proxy de punto de acceso. Registra la hora, el tipo de red y la dirección en ese momento, y compáralos con la hora de juicio indicada por el sitio web para localizar la causa del falso positivo.
Caso ilustrativo: red corporativa y punto de acceso móvil
Supón que un empleado usa la computadora de la oficina para acceder a un servicio con restricciones geográficas y la página muestra "VPN detectada". Al mismo tiempo, el empleado conecta el punto de acceso del teléfono al mismo servicio y el aviso desaparece. Este caso es completamente ilustrativo y no representa ninguna prueba real. La posible razón es que la salida de la red corporativa pasa por una VPN o puerta de enlace de seguridad empresarial, y la dirección de salida cae en un rango de centro de datos, marcado por los proveedores de datos como alojamiento o proxy. El punto de acceso móvil usa una dirección del operador, que pertenece a un tipo de red residencial o móvil, y no activa la misma regla.
En este escenario hipotético, es necesario registrar por separado el tipo de red, la hora de acceso, la IP de salida respectiva y si existe un túnel empresarial para la computadora corporativa y el punto de acceso móvil. La computadora corporativa puede tener configurada una VPN o proxy global, y la resolución DNS y la salida de conexión coinciden; el punto de acceso móvil no tiene estas configuraciones. Aunque las IP de salida difieran, no se puede atribuir directamente el problema a un empleado específico, porque la salida empresarial suele ser compartida y muchos empleados pueden usar la misma dirección al mismo tiempo.
Para investigar más, puedes revisar la tabla de enrutamiento o la configuración de proxy del sistema en la computadora corporativa para confirmar si se fuerza el túnel; consulta la información RDAP de la IP de salida, y si pertenece a un proveedor de nube o segmento de alojamiento, coincide con las reglas de riesgo del sitio web. El registro del punto de acceso móvil sirve como grupo de control, mostrando que la misma cuenta y el mismo dispositivo (si el teléfono abre el punto de acceso pero aún se usa el navegador de la computadora) dan resultados diferentes en redes distintas. Esta ilustración muestra que el aviso de la página puede provenir del entorno de red y no de una VPN activada por el usuario, y que bajo una salida compartida no se puede atribuir a un individuo.
¿Cómo comparar cuando los resultados de varios sitios de detección entran en conflicto?
Es común que diferentes sitios web den etiquetas distintas a la misma IP. Al comparar, primero mira la definición de "proxy" o "VPN" de cada fuente: algunos cuentan los segmentos de alojamiento como proxy, otros solo identifican salidas de VPN comerciales; algunos incluyen salidas de Tor, otros las excluyen. Luego mira el momento de actualización: una lista pudo actualizarse hace dos días y otra acaba de escanear, por lo que los resultados difieren naturalmente. La dirección consultada también influye: ves la dirección IPv4 de la conexión principal de la página, pero WebRTC puede haber filtrado otra dirección IPv6, y el sitio web puede juzgar basándose en direcciones diferentes.
Las diferencias de cobertura también son importantes. Algunos proveedores de datos solo cubren segmentos de proveedores de nube populares y no pueden identificar VPS pequeños o proxies emergentes; otros pueden marcar un país entero o un segmento de operador como de alto riesgo. La asignación y gestión de IPv4 e IPv6 son independientes, y el mismo proveedor puede dar resultados diferentes para ambos protocolos. Prioriza la consulta de registros originales, como la información de asignación devuelta por RDAP, instantáneas de rutas BGP o la hora y razón específicas de las entradas en listas negras, en lugar de solo mirar la puntuación mostrada por el sitio web.
No hagas una votación simple de los resultados de varios sitios web; que la mayoría diga "sí" no significa que sea un hecho; tampoco tomes la confianza más alta de un proveedor como una probabilidad. La confianza es una puntuación interna del proveedor de datos, que puede verse afectada por abuso histórico o salidas compartidas, sin calibración pública. El enfoque seguro es registrar la definición de cada fuente, la hora de actualización, la dirección consultada y la evidencia original, y luego juzgar en conjunto con tu propio entorno de red. Desconocido no equivale a seguro; no encontrar una coincidencia puede ser simplemente una omisión de la lista; clasificación no equivale a malicia; que un segmento de alojamiento esté marcado no indica que el usuario haya actuado mal.
Cómo mostrar sin coincidencia y desconocido para no inducir a error
Los resultados de consulta deben distinguir cuatro casos: lista vacía, tiempo de espera del servicio, fuente caducada, consulta exitosa pero sin coincidencia; no se deben mostrar todos como verde seguro. Lista vacía puede significar que la fuente de datos actual aún no ha incluido registros relevantes, o que la inicialización del sistema está incompleta; tiempo de espera del servicio significa que la interfaz ascendente no respondió dentro del tiempo acordado, y no equivale a ausencia de riesgo; fuente caducada indica que la marca de tiempo de la caché local es anterior a la ventana de verificación y el resultado puede no reflejar el estado actual; solo cuando la consulta es exitosa y devuelve explícitamente sin coincidencia se puede indicar que no hay entradas coincidentes bajo las reglas actuales de esa fuente de datos. Sin coincidencia no es una garantía de seguridad, porque la cobertura de la fuente de datos es limitada y ninguna lista puede agotar todos los proxies, VPN o salidas abusivas.
La geolocalización IP, ASN, BGP y RPKI describen estimaciones de ubicación, contexto de registro y estado de enrutamiento, no evidencia de comportamiento malicioso. Que un ASN anuncie un prefijo no significa que cada dirección del segmento tenga el mismo uso; que RDAP registre un proveedor de nube no indica que la IP actual ejecute un proxy. La página debe aclarar si la etiqueta describe infraestructura, comportamiento histórico o eventos en tiempo real, para que el lector sepa a qué objeto y momento se aplica la conclusión.
La capa de presentación debe expresar los diferentes estados con distintos niveles visuales y aclarar en el texto que "sin registro" no equivale a "aprobado". Por ejemplo, el método de manejo mencionado en Reputación IP: cómo interpretar riesgos y listas negras sugiere ofrecer una opción de reintento para datos de tiempo de espera y caducados, y para sin coincidencia indicar "no encontrado en la fuente actual, pero puede haber riesgos no cubiertos". Si el usuario ve un icono verde, al menos debe saber a qué condiciones específicas corresponde el verde. El operador también puede registrar la versión de la fuente de datos y la marca de tiempo de cada consulta para facilitar la revisión posterior. Esto evita malas interpretaciones y deja una cadena de evidencia para apelaciones.
La tasa de falsos positivos no es la exactitud
Supón una prueba con una muestra de 1000 direcciones independientes, de las cuales 25 son proxies reales y 975 no son proxies. El clasificador marca 30 como proxy, de las cuales 20 aciertan correctamente a proxies reales y 10 son falsos positivos; marca 970 como no proxy, de las cuales 5 son proxies reales no detectados y 965 son exclusiones correctas. En este caso, la precisión precision = 20/30 ≈ 0.667, la exhaustividad recall = 20/25 = 0.8, y la tasa de falsos positivos FPR = 10/975 ≈ 0.0103. Esta matriz de confusión es ilustrativa, no una medición real de este sitio, porque se necesitan datos supervisados con etiquetas reales para calcularla.
La exactitud (accuracy) es la proporción de predicciones correctas sobre el total: en este ejemplo, (20+965)/1000 = 0.985. Parece alta, pero la mayoría de las direcciones de la muestra no son proxies. Los numerosos verdaderos negativos pueden elevar la exactitud global y ocultar los falsos positivos entre las direcciones marcadas. Por eso también hay que evaluar el FPR y la precisión (precision). Si la etiqueta de proxy provoca un bloqueo directo, 10 de las 30 direcciones marcadas quedarían bloqueadas sin ser proxies. El número de direcciones no permite deducir cuántos usuarios se ven afectados. Cuanto mayor sea el tráfico legítimo, más solicitudes pueden sufrir bloqueos erróneos. La proporción de proxies, la coincidencia con listas negras históricas y la distribución de la población evaluada también pueden cambiar estas métricas.
Por lo tanto, no se puede equiparar simplemente la exactitud con la tasa de falsos positivos que percibe el usuario. Para mostrar la calidad de la detección, se deben informar simultáneamente el tamaño de la muestra, la definición de casos positivos, la ventana temporal y la distribución de las fuentes. De lo contrario, una cifra alta de exactitud puede ocultar numerosos daños colaterales. Para el usuario común, al encontrarse con una etiqueta de "proxy", debe saber de qué fuente proviene, a qué entrada concreta coincide y cuándo se actualizó por última vez. Si no se puede proporcionar este contexto, la etiqueta misma resulta sospechosa. El personal de operaciones tampoco debe dictar bloqueos basándose solo en una etiqueta única.
Las pruebas de fugas del navegador son otro asunto
WebRTC, DNS y la reputación de IP responden preguntas diferentes. WebRTC puede recopilar candidatos host, srflx o relay, y el alcance de la exposición depende de las políticas de privacidad del navegador y de la configuración de red; las solicitudes HTTP se transmiten según sus reglas de proxy y enrutamiento; lo que ve la prueba de DNS suele ser el origen de la consulta que el resolvedor recursivo hace al servidor autoritativo de la prueba. Que las direcciones sean diferentes puede ser perfectamente acorde al diseño; solo comparando con la ruta esperada se puede juzgar si hay información expuesta no deseada.
Las características del navegador como la zona horaria, el idioma o el Canvas no pueden demostrar de forma independiente el uso de VPN o fraude. Que el resolvedor de DNS y la salida HTTP no estén en la misma región tampoco es necesariamente anómalo; los servicios de resolución públicos y Anycast afectan a la geolocalización. Se pueden registrar los resultados por separado en Comprobación del entorno del navegador y luego, según Fugas de WebRTC, DNS e IPv6: cómo comprobarlas, verificar el alcance del proxy, la elección del resolvedor y los tipos de candidatos WebRTC. Primero confirma qué tipo de exposición no esperada es, y luego ajusta la configuración correspondiente.
Por lo tanto, cuando un sitio web indique "proxy detectado", no se debe atribuir de entrada a fugas del navegador o errores de WebRTC. Hay que verificar por separado los resultados de fugas del navegador y las etiquetas de reputación de IP. Si la prueba de fugas muestra una dirección local, pero la detección externa marca la IP de salida como hosting, puede ser simplemente el enrutamiento del operador o una salida compartida. Si ambos son anómalos, entonces hay que considerar el dispositivo del usuario o la configuración de red. Los operadores pueden combinar ambas señales, pero deben saber que provienen de capas diferentes y que los mecanismos de error son distintos.
Cómo enviar una revisión eficaz al responsable
Al enviar una revisión, proporciona la dirección pública en ese momento, la hora y la zona horaria, la etiqueta concreta, el servicio afectado y la fuente de datos. La prueba de asignación de dirección puede provenir de los registros del operador a los que tengas derecho; RDAP es una consulta de registro de recursos de Internet, no una función del propio enrutador, y no sustituye al contrato de banda ancha personal. En general, no es necesario enviar registros completos de navegación ni detalles del mapeo CGNAT. El alcance de lo que el responsable puede corregir depende de si gestiona una base de datos de clasificación, entradas de listas o reglas propias del sitio web.
La explicación de tráfico anómalo de Google puede ayudar a distinguir redes compartidas, solicitudes automáticas y problemas del navegador. Si encuentras un bucle de desafíos de Cloudflare, consulta su documento de solución de problemas de desafíos para comprobar si el navegador está soportado, si scripts o extensiones interfieren y si la red es estable; si se necesita que el sitio investigue, conserva el Ray ID y la hora del incidente. Estos documentos explican las vías de solución de cada producto, no prometen un desbloqueo general de IP.
Los requisitos de revisión varían según el proveedor de datos; algunos aceptan comentarios de usuarios finales, otros exigen que el administrador del rango demuestre el control, y se debe proceder según el canal de corrección específico. Redacta la solicitud como un problema verificable, por ejemplo: "Esta entrada es anterior a la asignación actual de la dirección, ¿pueden verificar el uso?", y adjunta las pruebas necesarias. Si quien realmente implementa el bloqueo es el sitio web de destino, también debes preguntar qué reglas y fuentes de datos utiliza; modificar una base pública no garantiza que todos los sitios se actualicen de inmediato.
Cómo los operadores de sitios web pueden reducir los daños colaterales
Los operadores no deben convertir la clasificación de IP en un interruptor binario. Asigna pesos separados a señales como hosting, VPN, salida de Tor, relay, etc., y combínalas con el comportamiento de inicio de sesión, la huella del dispositivo, el historial de sesiones y la frecuencia anómala para tomar decisiones integrales. Las operaciones sensibles como cambiar contraseña o retirar fondos pueden tener un umbral más alto, y la navegación normal puede ser más permisiva. Así, aunque una IP sea incluida erróneamente en un grupo de proxies, no se bloqueará la cuenta de inmediato. La clasificación en sí no es maliciosa; los falsos positivos suelen provenir de fuentes de datos obsoletas o salidas compartidas, como CGNAT que mapea muchos usuarios domésticos a una sola IPv4.
Los operadores pueden registrar en los logs las reglas, la versión de la fuente de datos, la hora de coincidencia y el resultado de la revisión de apelaciones. Tras confirmar un falso positivo, deben corregir la regla errónea o eliminar la entrada de bloqueo correspondiente; si se adopta una regla de permiso temporal, debe limitarse su alcance y fijar una fecha de revisión, sin confundir "eliminar de la lista blanca" con levantar el bloqueo. La Reputación de una subred /24: cobertura y riesgos ayuda a entender los registros de direcciones vecinas, pero la cantidad de etiquetas en sí no confirma si un segmento de red es compartido, pertenece al mismo inquilino o tiene comportamiento malicioso común.
No ocultes las consecuencias del bloqueo de todo un rango detrás de una etiqueta de IP única. Si por el historial de proxy de unas pocas direcciones en un /24 se bloquea todo el prefijo, debes explicarlo al usuario. Es mejor activar un captcha o una segunda verificación solo para acciones de alto riesgo, en lugar de denegar el servicio. Las métricas de monitoreo deben incluir la tasa de falsos positivos por ASN, por fuente de datos y por período, no la exactitud promedio. Así, cuando una fuente de datos marque repentinamente en masa las direcciones de un ISP como hosting, se podrá revertir rápidamente y reducir la presión de los tickets de soporte.
Preguntas frecuentes y límites de aceptación
El tipo de acceso residencial no garantiza que la dirección no se haya usado como salida de proxy; a la inversa, que un terminal ejecute un cliente VPN no significa que la dirección residencial local esté prestando servicio de proxy a otros. Al cerrar la VPN, las nuevas solicitudes web pueden cambiar inmediatamente a otra salida, pero el registro de la dirección anterior en la base de datos no necesariamente desaparece; la actualización depende de la fuente y de la política de retención. Al revisar, se debe precisar si se compara el cambio de etiqueta de la misma IP o el resultado de consulta de otra dirección tras cambiar de salida.
Que no haya etiqueta no garantiza poder iniciar sesión. Muchos sitios tienen reglas propias de control de riesgos, como exigir que el ASN de la IP pertenezca al país de destino, no permitir accesos desde centros de datos o deshabilitar túneles IPv6. Incluso si ninguna fuente de datos de terceros coincide, el sitio puede rechazar por cookies anómalas, inconsistencia de la huella del navegador o frecuencia de solicitudes. Al ver un aviso de "detección de proxy", primero separa la verificación del entorno de los datos de reputación de IP y registra qué página y qué solicitud activó el desafío. Si RDAP muestra que la IP actual pertenece a una línea corporativa o a un servidor en la nube, aunque no hayas activado una VPN, es fácil que se marque como hosting.
La conclusión solo puede limitarse a las pruebas actuales y al sitio web concreto. La misma IP puede estar marcada como proxy en el sitio A y funcionar con normalidad en el sitio B, porque las fuentes y los umbrales de cada sitio son diferentes. Si encuentras un problema irresoluble, puedes seguir el proceso de IP en una lista negra o CAPTCHA constante: qué hacer, centrándote en recopilar la hora, la IP, la captura de pantalla del aviso y la acción que lo desencadenó, y distinguir si se trata de un bloqueo a nivel de red o de un captcha a nivel de aplicación. No cambies de IP con frecuencia ni modifiques la huella del navegador para eludirlo, porque eso oculta la causa real y viola los términos de algunas plataformas.
