Как проверить, является ли IP-адрес proxy: пошаговая инструкция

В чем сложность обнаружения proxy

Понять, что входящее соединение пришло через proxy, часто нужно в самых разных задачах: при расследовании злоупотреблений, защите точек входа, анализе странного сетевого трафика или борьбе с мошенничеством. Под словом proxy при этом скрываются разные сущности: открытые HTTP/SOCKS-прокси, коммерческие VPN-серверы, дата-центровые узлы для скрейпинга, выходные узлы Tor и residential proxy-сети.

Проблема в том, что все эти схемы по-разному выглядят на уровне маршрутизации IP и транспортных протоколов. Поэтому одной «волшебной» команды, которая даст окончательный ответ да/нет, не существует. Надежная проверка строится на нескольких независимых сетевых сигналах. Ниже — практический разбор: как вручную проверить IP и что делать, если такие проверки нужны в потоке, а не разово.

Шаг 1: проверьте Reverse DNS (rDNS) и PTR-записи

Reverse DNS позволяет сопоставить IP-адрес с настроенным для него доменным именем. Хостинг-провайдеры, домашние интернет-провайдеры и мобильные операторы часто используют характерные шаблоны в PTR-записях — по ним можно понять, в каком контексте обычно живет этот IP.

PTR-запись можно запросить через dig:

bash dig -x 198.51.100.42 +short

Что дает этот сигнал

• Домашний или broadband ISP: Имена хостов с фрагментами вроде pool, cable, fiber, dhcp либо динамическими форматами октетов, например 198-51-100-42.dyn.exampleisp.net, обычно указывают на обычные пользовательские подключения.
• Дата-центр или VPS: Шаблоны вроде vps, server, compute, hosted-by, linode, ovh или типичные облачные имена, например ec2-198-51-100-42.compute-1.amazonaws.com, говорят о дата-центровой инфраструктуре. Обычные пользователи редко приходят в браузере напрямую с VPS — разве что используют собственный VPN или proxy.
• Нет PTR или запись слишком общая: Многие операторы proxy поднимают узлы на дешевых VPS и не настраивают forward-confirmed reverse DNS (FCrDNS).

Ограничения

Residential proxy-сети могут направлять трафик через арендованные или скомпрометированные пользовательские устройства. В таком случае PTR-запись будет выглядеть как обычный домашний провайдер, и проверка rDNS ничего подозрительного не покажет.

Шаг 2: посмотрите ASN и данные маршрутизации

Каждый IP-адрес относится к автономной системе — Autonomous System (AS). Регистрация AS показывает, какая организация владеет IP-блоком и анонсирует его через BGP. Обычные домашние пользователи получают адреса в ASN телеком-операторов, тогда как коммерческие proxy и VPN почти всегда размещаются в ASN хостингов, облаков или colocation-провайдеров.

Данные ASN можно запросить через DNS- или WHOIS-сервисы Team Cymru:

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

Либо напрямую обратиться к региональным интернет-регистраторам — ARIN, RIPE, APNIC:

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

Как оценивать ASN-сигналы

• Если IP принадлежит DigitalOcean, Hetzner, OVH, AWS или M247, а пользователь выглядит как обычный интерактивный посетитель сайта, почти наверняка трафик идет через посредника: VPN, коммерческий forwarder или автоматизированный скрипт.
• Посмотрите на NetType и тип назначения блока. Перераспределенные или portable-блоки, связанные с proxy-агрегаторами, нередко раскрывают название компании, отличное от базового телеком-оператора.

Ограничения

Проверка на уровне ASN не поймает residential proxy, если за ним остается реальный оператор доступа — AT&T, Comcast или международный мобильный провайдер.

Шаг 3: проверьте известные выходные узлы Tor и threat lists

Сеть Tor публикует авторитетный и регулярно обновляемый список активных выходных IP-узлов. Поскольку Tor exit relays публичны, совпадение с этим списком дает высокую уверенность.

Активный список выходных узлов можно получить напрямую:

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

Также можно выполнить DNS-проверку через Tor Project DNSBL:

bash # Разверните октеты целевого IP и запросите зону dnsel dig 42.100.51.198.ip-port.exitlist.torproject.org A +short

Если запрос вернул 127.0.0.2, IP является активным выходным узлом Tor.

Ограничения

Tor — лишь один из видов инструментов анонимизации. Публичные blocklists для открытых proxy в целом очень нестабильны: они собирают адреса, которые могут исчезать уже через несколько минут. Из-за этого при перераспределении IP-диапазонов легко получить много ложных срабатываний.

Шаг 4: пассивный и активный анализ портов

Proxy-сервисы часто слушают стандартные или дополнительные proxy-порты. Массово сканировать порты каждого клиента — навязчиво, медленно и нередко юридически рискованно. Но при ручном разборе инцидента проверка типовых портов может быть оправданной.

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

• Порт 1080: стандартный порт SOCKS proxy.
• Порт 3128: порт по умолчанию для Squid HTTP proxy.
• Порты 8080, 8888: популярные альтернативные HTTP forwarders.

Если подключение к этим портам возвращает HTTP-заголовок вроде Proxy-Agent, Via: 1.1 squid или обрывает неожиданный SOCKS-handshake, перед вами proxy-сервер.

Ограничения

Коммерческие VPN, production-grade reverse proxy и residential proxy-демоны обычно не слушают публично на клиентских интерфейсах. Они поднимают исходящие reverse tunnels к управляющему узлу, поэтому открытых входящих портов может не быть вовсе.

Ручные проверки и реальность

| Метод | Основной сигнал | Главная слепая зона | | :--- | :--- | :--- | | Reverse DNS | Дата-центровые hostnames, отсутствующий PTR | Residential proxy выглядят как обычные ISP | | ASN Lookup | Классификация хостинга или облачного провайдера | Не видит трафик, перенаправленный через residential-подсети | | Tor Exit Lists | Точный список активных Tor exits | Не покрывает VPN, SOCKS и коммерческие proxy | | Port Probing | Открытые proxy-демоны: Squid, SOCKS | Современные туннели используют исходящие reverse-соединения |

Шаг 5: автоматизированный IP intelligence в реальном времени

Ручной анализ хорош для постфактум-разбора инцидентов, но интерактивным приложениям нужны проверки за доли секунды — во время логина, оплаты или регистрации. На этом уровне главная проблема — обнаружение residential proxy: нужно понять, что IP из настоящей сети потребительского ISP на самом деле участвует в backconnect proxy-туннеле.

Для этого приходится объединять BGP-анонсы, телеметрию активных проверок, honeypots и поведенческие признаки соединений в один lookup. IP intelligence-сервис вроде guarda.net сводит эти сигналы в единый JSON-ответ:

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

Типичный ответ содержит отдельные булевы классификации и общий risk score:

{ "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 }

Структурированные поля позволяют firewall или коду приложения применять точные политики: например, отклонять дата-центровые IP при регистрации, но разрешать корпоративные VPN; либо усиливать аутентификацию только тогда, когда is_proxy равно true или общий risk_score превышает заданный порог.

Если нужно быстро проверить IP без настройки скриптов, бесплатную проверку можно запустить прямо на главной странице guarda.net. Сервис уже обработал более 594,400 запросов.