Почему резидентный IP помечен как прокси или хостинг: как проверить

Сервисы IP-аналитики никогда не видят устройство за адресом. Они размечают адрес по записям реестров, данным маршрутизации, DNS-именам и наблюдаемому поведению. «Резидентный» IP помечается как прокси или хостинг, когда один из этих слоёв указывает на дата-центр. Это может быть сеть, которая анонсирует адрес, конкретная /24, в которой он находится, организация в WHOIS или обратный DNS, расхождение между страной регистрации и страной геолокации или история ретрансляции прокси-трафика. Каждый из этих слоёв можно проверить самостоятельно бесплатными инструментами — примерно за десять минут на один IP. Ниже показано, как это сделать.

Наш разбор репутации IP и фрод-скоринга объясняет, как строится оценка вроде IPQualityScore и как её используют сайты. Эта статья — практическое дополнение к нему: какие сигналы классификации формируют вердикт, как их отдают четыре популярных сервиса и как провести воспроизводимый аудит одного IP или выборки выходных IP.

Почему IP помечается как прокси или хостинг

Большинство вердиктов «hosting» или «proxy» для якобы резидентных IP складываются из пяти сигналов. Первыми идут владение сетью и маршрутизация, затем имена, затем согласованность местоположения, затем наблюдаемое поведение. Сервисы комбинируют их по-разному, поэтому их выводы и расходятся.

1. Тип ASN: кто анонсирует адрес

Каждый маршрутизируемый IP анонсируется в BGP автономной системой (ASN). Сервисы классифицируют ASN по типу организации, которая за ней стоит. Поле type для ASN у IPinfo принимает одно из значений isp, hosting, business, education или government. В PeeringDB, где сети описывают себя сами, есть поле info_types. Его API возвращает ["Cable/DSL/ISP"] для Comcast (AS7922) и ["Content"] для Cloudflare (AS13335):

curl -s "https://www.peeringdb.com/api/net?asn=7922" | jq '.data[0] | {name, info_types}'

Если анонсирующая ASN принадлежит хостинг-компании, почти любой сервис назовёт IP хостинговым, на кого бы адрес ни был зарегистрирован. Это самый весомый сигнал, и оспорить его труднее всего.

2. Анонсируемый префикс, а не только ASN

Когда мы проверяли статические «резидентные» или ISP-адреса, полезной единицей анализа часто оказывался анонсируемый префикс, обычно /24, а не ASN. Одна /24 внутри в остальном чистой сети провайдера может читаться как хостинг, тогда как остальная часть ASN считается резидентной. Вероятная причина в том, что сервисы исправляют данные на уровне префиксов. Блок, который сдали в аренду, перемаршрутизировали или на котором замечали хостинговые серверы, переразмечается отдельно, а остальная ASN сохраняет свою метку. Кроме того, /24 — самый маленький блок IPv4, который как правило принимается в глобальной таблице маршрутизации, поэтому это естественная единица для аренды и повторного анонса. Так что, если помечен один IP, проверьте его соседей в той же /24, прежде чем винить всего провайдера прокси или всего ISP.

3. Организация в WHOIS и обратный DNS

Записи реестров и PTR-имена — дешёвые сигналы, и сервисы используют их, чтобы разрешать спорные случаи. Netname или org со словами вроде «hosting», «cloud», «server» или «VPS» либо PTR вида vps-123.example-host.net тянут в сторону хостинга. У резидентных диапазонов обычно провайдерские PTR, в которых закодирована технология доступа или есть слова «dynamic» или «pool». Отсутствие PTR ничего не доказывает ни в одну сторону: многие ISP не заполняют обратный DNS, а многие хостеры заполняют.

4. Страна в реестре и страна геолокации

Расхождение между страной регистрации IP (по данным регионального интернет-регистратора, RIR) и страной, в которую его помещают сервисы геолокации, — одна из самых частых причин вердикта «hosting» или «proxy» для статического IP, которые мы встречали. Настоящий домашний интернет редко путешествует: клиенты немецкого провайдера находятся в Германии. Арендованные и повторно анонсированные блоки путешествуют часто: регистрация остаётся за исходным владельцем, а адреса используются в другом месте. Операторы могут указать, где префикс используется на самом деле, через самостоятельно опубликованный geofeed (RFC 8805), который находится через WHOIS по RFC 9632. Геолокация от этого сдвигается, но расхождение с реестром остаётся видно любому, кто посмотрит.

Разберём реальный пример: 1.1.1.1. Whois-сервис Team Cymru для сопоставления IP и ASN (запрос от 2026-10-03) показывает в одной строке три разных факта:

$ whois -h whois.cymru.com " -v 1.1.1.1"
AS      | IP               | BGP Prefix          | CC | Registry | Allocated  | AS Name
13335   | 1.1.1.1          | 1.1.1.0/24          | AU | apnic    | 2011-08-11 | CLOUDFLARENET - Cloudflare, Inc., US

Блок зарегистрирован в Австралии через APNIC (он принадлежит APNIC Labs). Анонсируется он как /24 из ASN Cloudflare, зарегистрированной в США, а ip-api геолоцирует его в AU с hosting: true. Для резолвера, который совместно эксплуатируют APNIC и Cloudflare, всё это ожидаемо. Но для IP, проданного вам как «резидентный US», такое трёхстороннее расхождение объяснило бы любой вердикт «hosting».

5. Наблюдаемое поведение

Последний слой — то, что сервисы видели за IP: обращения к ханипотам, попадание в фиды злоупотреблений, работа VPN или прокси-софта, появление в роли выхода известной резидентной прокси-сети. Это единственный слой, который может пометить настоящий домашний IP у настоящего провайдера. Residential proxy API от IPinfo возвращает service, в котором IP был замечен, вместе с last_seen и percent_days_seen за 7-дневное окно. MaxMind определяет is_residential_proxy как IP, который «находится в предполагаемой анонимизирующей сети и принадлежит резидентному ISP», причём IP пиринговых (P2P) прокси явно исключены. Сервисы проводят эту границу в разных местах, но суть не меняется: чистая ASN не защищает IP, который реально используется как прокси.

Как четыре сервиса отдают вердикт

Каждый сервис отвечает на немного разный вопрос. Два «противоречащих» результата часто оба верны. Названия полей ниже взяты из актуальной документации каждого сервиса.

AbuseIPDB добавляет ещё одну метку, которую вы будете часто видеть: usageType со значениями вроде «Data Center/Web Hosting/Transit» (документация).

ISP-прокси: почему это серая зона

«ISP»-прокси, или «статические резидентные» прокси, — это адреса, зарегистрированные на интернет-провайдера, но направленные на серверы в дата-центре. Это серая зона, потому что слой реестра говорит «резидентный», а слои маршрутизации и поведения могут говорить другое. Пройдёт ли конкретный IP проверку, зависит от того, каким слоям сервис больше доверяет для данного префикса.

Хороший вариант — провайдер анонсирует собственный блок из собственной ASN, а серверы стоят в его сети. Тогда тип ASN, WHOIS и геолокация согласуются. Слабый вариант — блок, зарегистрированный на провайдера, анонсирует ASN хостинг-компании, часто после аренды. Реестр по-прежнему говорит «ISP», но анонсирующая ASN хостинговая, а это самый весомый сигнал, и страна в реестре может не совпадать с геолокацией. Сервисы догоняют такие блоки префикс за префиксом, поэтому одна /24 у провайдера может быть чистой, а соседняя — помеченной. Продуктовую сторону описывает наш разбор ISP-прокси. Аудит ниже помогает понять, какой вариант вам продали.

Как проверить IP самостоятельно, шаг за шагом

Прогоняйте одни и те же пять шагов для каждого IP: получите выходной IP, посмотрите регистрацию, посмотрите маршрутизацию, проверьте DNS, затем спросите два-три сервиса. Сравнивайте на уровне /24. Всё ниже работает на бесплатных эндпоинтах.

Шаг 1: получите реальный выходной IP

Убедитесь, какой адрес на самом деле видит целевой сайт. Не доверяйте дашборду. Для прокси:

curl -s -x "http://USERNAME:PASSWORD@gate.proxyhat.com:8080" https://api.ipify.org

Наш прокси-чекер делает то же самое в браузере, если не хочется писать скрипт.

Шаг 2: регистрация (RDAP, Team Cymru)

IP=1.1.1.1
# RDAP через редиректор rdap.org: зарегистрированный диапазон, владелец, страна в реестре
curl -sL "https://rdap.org/ip/$IP" | jq '{name, handle, country, type, startAddress, endAddress}'
# Сводка в одну строку: ASN, BGP-префикс, страна в реестре, реестр, имя AS
whois -h whois.cymru.com " -v $IP"

Запишите country и name владельца. Для 1.1.1.1 RDAP возвращает "name": "APNIC-LABS", "country": "AU".

Шаг 3: маршрутизация (RIPEstat, bgp.he.net)

RIPEstat Data API бесплатен, работает без ключа и покрывает адресное пространство всех RIR, а не только RIPE.

# Анонсирующая ASN и точный анонсируемый префикс
curl -s "https://stat.ripe.net/data/network-info/data.json?resource=$IP" | jq '.data'
# Кому принадлежит ASN и анонсируется ли префикс вообще
curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=$IP" | jq '.data | {resource, announced, asns}'
# Страна по статистике делегирования RIR
curl -s "https://stat.ripe.net/data/rir-stats-country/data.json?resource=$IP" | jq '.data.located_resources'
# Все префиксы, которые анонсирует ASN, — чтобы понять, не выбивается ли эта /24
curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS13335" | jq '.data.prefixes | length'

Для наглядности bgp.he.net показывает те же ASN и префикс вместе с аплинками и пирами. Маленькая ASN с одним-двумя транзитными провайдерами, которые сами являются хостинг-компаниями, говорит о многом.

Шаг 4: обратный DNS

dig +short -x $IP

Шаг 5: два-три сервиса, результаты рядом

# ip-api: бесплатно, без ключа, только HTTP
curl -s "http://ip-api.com/json/$IP?fields=status,countryCode,isp,org,as,reverse,mobile,proxy,hosting"
# IPinfo Lite: бесплатно с токеном, страна + ASN
curl -s "https://api.ipinfo.io/lite/$IP?token=$IPINFO_TOKEN"
# AbuseIPDB: бесплатный ключ, 1000 проверок в день
curl -sG https://api.abuseipdb.com/api/v2/check --data-urlencode "ipAddress=$IP" \
  -H "Key: $ABUSEIPDB_KEY" -H "Accept: application/json" | jq '.data | {usageType, isp, abuseConfidenceScore}'

Аудит выборки выходных IP по префиксам

Для пула, а не одного IP, группируйте результаты по анонсируемому префиксу. Этот скрипт читает файл с IP, использует batch-эндпоинт ip-api (до 100 IP в одном POST, 15 запросов в минуту на бесплатном тарифе) и RIPEstat и выводит по одной строке на префикс:

import json, sys, time, urllib.request
from collections import defaultdict

def get(url, data=None):
    req = urllib.request.Request(url, data=data, headers={
        "User-Agent": "ip-audit/1.0", "Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=20) as r:
        return json.load(r)

def ripestat(call, resource):
    return get(f"https://stat.ripe.net/data/{call}/data.json?resource={resource}")["data"]

ips = [l.strip() for l in open(sys.argv[1]) if l.strip()]

geo = {}
fields = "query,countryCode,isp,org,as,proxy,hosting,mobile"
for i in range(0, len(ips), 100):
    chunk = ips[i:i + 100]
    for row in get(f"http://ip-api.com/batch?fields={fields}", json.dumps(chunk).encode()):
        geo[row["query"]] = row
    time.sleep(4)  # не превышаем 15 batch-запросов в минуту

by_prefix = defaultdict(list)
for ip in ips:
    net = ripestat("network-info", ip)
    reg = ripestat("rir-stats-country", ip)["located_resources"]
    reg_cc = reg[0]["location"] if reg else "?"
    by_prefix[(net["prefix"], ",".join(net["asns"]))].append((ip, reg_cc, geo.get(ip, {})))

for (prefix, asns), rows in sorted(by_prefix.items()):
    hosting = sum(1 for _, _, g in rows if g.get("hosting"))
    proxy = sum(1 for _, _, g in rows if g.get("proxy"))
    mismatch = sum(1 for _, cc, g in rows if g.get("countryCode") and cc != g["countryCode"])
    print(f"{prefix:<20} AS{asns:<8} n={len(rows):<3} hosting={hosting} proxy={proxy} "
          f"reg!=geo={mismatch}  isp={rows[0][2].get('isp', '?')}")

Запуск: python3 audit.py exits.txt. Для большой выборки добавьте короткую паузу между вызовами RIPEstat. Вывод обычно сразу всё объясняет. Если помеченные IP сгруппированы в одном-двух префиксах, проблема в префиксе. Если они равномерно распределены по ASN, проблема в ASN. Если они разбросаны по множеству чистых префиксов, дело в поведении: эти IP известны как выходы прокси.

Как интерпретировать расхождения между сервисами

Когда сервисы расходятся, сначала разберитесь, какой слой читает каждый из них, и только потом решайте, кто «прав». Обычно один читает регистрацию, а другой — маршрутизацию или поведение.

• «ISP» у одного, «hosting» у другого. Реестр против маршрутизации. Проверьте анонсирующую ASN. Если это хостинг-компания, сайты будут ориентироваться именно на вердикт «hosting».
• Резидентный тип подключения плюс флаг прокси. Настоящий адрес провайдера с замеченной прокси-активностью. Никакие изменения маршрутизации это не исправят — это проблема истории.
• Везде чисто, кроме фрод-скора одного сервиса. Обычно это недавняя история злоупотреблений или настройки strictness. Посмотрите поля злоупотреблений у этого сервиса, прежде чем списывать IP.
• Разные страны. Сравните страну RIR, geofeed и геолокацию сервисов. Сервисы обновляются с разной скоростью, поэтому недавно переехавший блок какое-то время может давать разные результаты.

Значение имеет то, каким сервисом пользуется нужный вам сайт, а узнать это обычно нельзя. Поэтому «чисто» у одного сервиса — недостаточное доказательство.

Сигналы в одной таблице

Сервисы не публикуют свои веса. Колонка «вес» — наше прочтение их документации и того, как меняются вердикты во время аудитов. Считайте её ориентиром, а не спецификацией.

Статические, ротируемые резидентные или мобильные: что аудит значит для выбора

Какой продукт покупать, зависит от того, нужен ли вам один и тот же IP надолго, — и от этого же зависит, насколько важен аудит.

• Статические / ISP-адреса. Каждый IP остаётся у вас неделями, поэтому проверяйте до того, как берёте. Прогоните скрипт по префиксам на предложенных IP, отбракуйте помеченные /24 и расхождения реестра с геолокацией и спросите, какая ASN их анонсирует. Здесь аудит окупается сильнее всего.
• Ротируемые резидентные. Отдельные IP приходят и уходят, поэтому проверка одного выхода мало что даёт. Возьмите выборку из 100+ выходов и посмотрите распределение типов ASN и флагов hosting. «Резидентный» пул, в котором многие выходы анонсируются из хостинговых ASN, резидентным не является.
• Мобильные. ASN операторов и CGNAT делают такие адреса самыми трудными для пометки как хостинг, но история злоупотреблений общая со всеми реальными пользователями за тем же адресом. Компромиссы описаны в нашем руководстве по мобильным прокси, а сравнение трёх типов — в статье резидентные vs дата-центровые vs мобильные.

Чего этот аудит не покажет

Аудит объясняет, почему сервис размечает IP именно так. Он не предсказывает, заблокирует ли вас конкретный сайт. Сайты сочетают репутацию IP с отпечатками TLS, HTTP/2 и браузера, а также с поведением. Чистый резидентный IP за TLS-отпечатком, похожим на дата-центровый, всё равно получит челлендж. Кроме того, аудит не видит закрытых данных сервиса — только публичные слои, на которых эти данные строятся. Используйте его, чтобы отсеивать плохие IP и задавать провайдерам точные вопросы. Не воспринимайте чистый результат как гарантию.