Cómo comprobar si una dirección IP es un proxy (paso a paso)

Entender el problema de la detección de proxies

Identificar si una conexión entrante procede de un proxy es una tarea habitual al investigar abusos, proteger puntos de autenticación o depurar tráfico de red anómalo. Los proxies pueden adoptar muchas formas: forwarders HTTP/SOCKS abiertos, servidores VPN comerciales, relays de scraping en centros de datos, nodos de salida de Tor y redes de proxies residenciales.

Como cada arquitectura de proxy interactúa de forma distinta con la capa de enrutamiento IP y con los protocolos de transporte, no existe un único comando manual que ofrezca una respuesta definitiva de sí o no. La detección exige evaluar varias señales de red independientes. En esta guía repasamos los pasos prácticos para inspeccionar una IP manualmente y cómo abordar la detección a escala.

Paso 1: Inspeccionar el DNS inverso (rDNS) y los registros PTR

Las consultas de DNS inverso vinculan una dirección IP con el nombre de dominio configurado para ella. Muchos proveedores de hosting, ISP de banda ancha y operadores móviles siguen convenciones de nombres estructuradas en sus registros PTR, lo que permite inferir el contexto operativo de la IP.

Puedes consultar el registro PTR con dig:

bash dig -x 198.51.100.42 +short

Qué te indica esta señal

• ISP residencial o de banda ancha: Los nombres de host que contienen cadenas como pool, cable, fiber, dhcp o formatos con octetos dinámicos (por ejemplo, 198-51-100-42.dyn.exampleisp.net) suelen corresponder a conexiones de usuarios domésticos.
• Centro de datos o VPS: Los nombres que siguen patrones como vps, server, compute, hosted-by, linode, ovh o nombres de cloud sin personalizar (por ejemplo, ec2-198-51-100-42.compute-1.amazonaws.com) apuntan a infraestructura de centro de datos. Es poco habitual que un usuario legítimo navegue directamente desde un VPS, salvo que esté usando una VPN o un proxy autoalojado.
• PTR ausente o genérico: Muchos operadores de proxies trabajan sobre instancias VPS baratas sin configurar DNS inverso confirmado hacia delante (FCrDNS).

Limitaciones

Los atacantes que usan redes de proxies residenciales enrutan el tráfico a través de equipos domésticos comprometidos o alquilados. El registro PTR mostrará un ISP residencial normal, por lo que las comprobaciones rDNS quedarán completamente esquivadas.

Paso 2: Consultar el número de sistema autónomo (ASN) y los datos de enrutamiento

Cada dirección IP pertenece a un sistema autónomo (AS). El registro del AS indica qué entidad posee el bloque IP y lo anuncia mediante BGP. Los usuarios residenciales suelen recibir IPs bajo ASN de operadores de telecomunicaciones de consumo, mientras que los proxies comerciales y los servidores VPN residen casi siempre en ASN de hosting, cloud o colocación.

Puedes consultar los detalles del ASN con los servicios DNS o WHOIS de Team Cymru:

bash whois -h whois.cymru.com " -v 198.51.100.42"

También puedes consultar directamente los registros regionales de Internet (ARIN, RIPE, APNIC):

bash whois 198.51.100.42 | grep -iE "origin|org-name|descr|nettype"

Cómo evaluar las señales ASN

• Si la IP pertenece a DigitalOcean, Hetzner, OVH, AWS o M247, y el usuario dice ser un visitante web interactivo, está enrutando el tráfico a través de un intermediario: una VPN, un forwarder comercial o un script automatizado.
• Revisa el campo NetType o la asignación del registro. Los bloques reasignados o portables asociados a agregadores de proxies suelen revelar nombres de empresa distintos del operador de telecomunicaciones subyacente.

Limitaciones

Las comprobaciones a nivel de ASN no detectan proxies residenciales cuando el operador subyacente sigue siendo AT&T, Comcast o un proveedor móvil internacional.

Paso 3: Comprobar nodos de salida de Tor conocidos y listas de amenazas

La red Tor publica una lista autoritativa y dinámica de direcciones IP de nodos de salida activos. Como los relays de salida de Tor son públicos, contrastar una IP con esta lista ofrece una señal de alta confianza.

Puedes descargar directamente la lista de salidas activas:

bash curl -s https://check.torproject.org/torbulkexitlist | grep -x "198.51.100.42"

También puedes ejecutar una comprobación basada en DNS contra la DNSBL del Tor Project:

bash # Invierte los octetos de la IP objetivo y consulta la zona dnsel dig 42.100.51.198.ip-port.exitlist.torproject.org A +short

Si esta consulta devuelve 127.0.0.2, la IP es un nodo de salida de Tor activo.

Limitaciones

Tor es solo una subcategoría dentro de las herramientas de anonimización. Las blocklists públicas de proxies abiertos generales son especialmente volátiles: recopilan proxies que a menudo dejan de estar disponibles en cuestión de minutos, lo que genera altas tasas de falsos positivos cuando los rangos IP se reasignan.

Paso 4: Análisis pasivo y activo de puertos

Los proxies suelen ejecutar software a la escucha en puertos estándar o auxiliares. Aunque lanzar un escaneo de puertos invasivo contra cada conexión de cliente resulta intrusivo, lento y a menudo problemático desde el punto de vista legal, una investigación manual de un incidente puede justificar la revisión de puertos habituales.

bash nc -zv -w 2 198.51.100.42 8080 3128 1080 8888 80

• Puerto 1080: Puerto estándar para proxy SOCKS.
• Puerto 3128: Puerto por defecto de Squid como proxy HTTP.
• Puertos 8080, 8888: Alternativas frecuentes para forwarders HTTP.

Si al conectar con estos puertos aparece una cabecera HTTP como Proxy-Agent, Via: 1.1 squid, o se cierra un handshake SOCKS inesperado, el host actúa como servidor proxy.

Limitaciones

Las VPN comerciales en producción, los proxies inversos y los daemons de proxies residenciales no escuchan públicamente en interfaces expuestas al cliente. Establecen túneles inversos salientes hacia un nodo de orquestación, sin dejar puertos entrantes abiertos.

Comprobaciones manuales frente a la realidad

| Técnica | Señal principal | Punto ciego principal | | :--- | :--- | :--- | | DNS inverso | Nombres de host de centro de datos, PTR ausente | Los proxies residenciales se camuflan como ISP de consumo | | Consulta ASN | Clasificación de proveedor hosting/cloud | No detecta tráfico reenviado por subredes residenciales | | Listas de salidas de Tor | Lista determinista de salidas Tor activas | Ciega ante VPN, SOCKS y proxies comerciales | | Sondeo de puertos | Daemons de proxy expuestos (Squid, SOCKS) | Los túneles modernos usan conexiones inversas salientes |

Paso 5: Inteligencia IP automatizada en tiempo de ejecución

La inspección manual funciona para el análisis posterior a un incidente, pero las aplicaciones interactivas necesitan comprobaciones en menos de un segundo durante procesos de autenticación, pago o registro. En este nivel, el principal reto es detectar proxies residenciales: identificar cuándo una IP perteneciente a un ISP de consumo legítimo está ejecutando un túnel de proxy backconnect.

Resolverlo exige agregar anuncios BGP, telemetría de sondeos activos, honeypots y patrones de comportamiento de conexión en una única consulta. Un servicio de inteligencia IP como Guarda (guarda.net) consolida estas señales en una respuesta JSON unificada:

bash curl -s "https://api.guarda.net/v1/ip/198.51.100.42" \ -H "Authorization: Bearer YOUR_API_KEY"

Una respuesta típica devuelve clasificaciones booleanas diferenciadas junto con una puntuación de riesgo compuesta:

{ "ip": "198.51.100.42", "is_proxy": true, "is_vpn": false, "is_tor": false, "is_datacenter": true, "asn": { "number": 16276, "org": "OVH SAS" }, "risk_score": 88 }

El uso de campos estructurados permite que tu firewall o el código de tu aplicación apliquen políticas precisas: por ejemplo, rechazar IPs de centro de datos durante el registro y permitir VPN corporativas, o elevar el nivel de autenticación solo cuando is_proxy sea true o cuando el risk_score global supere un umbral definido.

Si quieres evaluar una IP al momento sin configurar scripts, puedes hacer una comprobación IP gratuita directamente desde la página principal de guarda.net, que ya ha procesado más de 594,400 consultas.