Почему прокси на ASN хостинг-провайдеров палятся антифродом за 3 запроса: разбор по IP-диапазонам

Почему ASN хостинга — это красная тряпка

Антифрод-системы не смотрят на IP по одному. Они смотрят на принадлежность к автономной системе. Если запрос приходит из ASN, зарегистрированной как hosting, datacenter или cloud — счётчик подозрительности тикает сразу. Не через десять запросов. С первого.

Разница между residential ASN и hosting ASN — это не «немного подозрительно» и «очень подозрительно». Это два разных мира. Comcast (AS7922) обслуживает миллионы домашних абонентов. DigitalOcean (AS14061) — это стойки с виртуалками. Антифрод знает это по базе MaxMind, IP2Location, IPinfo. И реагирует соответственно.

Причём база ASN обновляется не раз в год. MaxMind GeoIP2 пересобирает данные ежедневно. IPinfo подтягивает изменения раз в несколько часов. Если провайдер переклассифицировал диапазон из residential в business — через сутки это уже в базах у Cloudflare, Sift, Forter, Arkose.

Что видит антифрод в первые 200 миллисекунд

Запрос ещё не дошёл до бэкенда, а система уже собрала досье. ASN, страна регистрации, тип сети (hosting/isp/business/education), репутация подсети, история abuse-жалоб. Всё это прилетает от провайдера IP-репутации за 20-50 мс.

Дальше — TLS-фингерпринт. JA3/JA4 хеш. Если это curl с дефолтными настройками — хеш один. Если это Python requests — другой. Если это headless Chrome — третий. Хостерский IP + curl-хеш = почти гарантированный флаг.

Потом — заголовки. Accept-Language, User-Agent, порядок заголовков, наличие sec-ch-ua. Хостерский IP, который притворяется браузером, но отправляет заголовки в алфавитном порядке — это подпись автоматизации. Реальный Chrome отправляет их в строго определённом порядке. И не тот, что у Python-скрипта.

Как выглядит ASN-скоринг на практике

Большинство антифрод-движков используют весовую модель. Не бинарное «хостинг/не хостинг». Вот примерная раскладка весов, которую применяют в индустрии:

| Фактор | Вес | Комментарий |

|---|---|---|

| ASN type = hosting | +40 | Базовый флаг, срабатывает мгновенно |

| ASN type = isp | +5 | Обычный residential, почти не влияет |

| ASN type = business | +15 | Корпоративные сети, умеренный риск |

| Datacenter IP range | +25 | Дополнительно к hosting-флагу |

| JA3 не совпадает с UA | +30 | curl под видом Chrome |

| Нет Accept-Language | +10 | Боты часто его не ставят |

| Прокси-заголовки (Via, X-Forwarded-For) | +20 | Утечка через заголовки |

| rDNS содержит "vps", "cloud", "host" | +15 | Обратная зона палит контору |

Порог блокировки обычно 60-70. Хостерский IP с curl-хешем набирает 40+30+10 = 80. Блок. Даже без единого поведенческого сигнала.

Residential IP с тем же curl-хешем набирает 5+30+10 = 45. Проходит. Пока не начнёт долбить форму логина 50 раз в минуту.

Реальные диапазоны, которые палятся первыми

Не все хостинговые ASN одинаково токсичны. Есть те, что годами ассоциируются со скрейпингом и abuse. Их диапазоны помечены в базах как high-risk.

Вот список ASN, которые антифрод режет почти без разбора:

- AS14061 (DigitalOcean) — тысячи abuse-репортов в месяц, база IPinfo помечает как hosting с 2016 года

- AS16509 (Amazon AWS) — весь диапазон EC2, но Lambda и API Gateway имеют отдельные ASN с другой репутацией

- AS24940 (Hetzner) — Германия, огромный объём сканирований портов

- AS16276 (OVH) — Франция, исторически много ботов

- AS9009 (M247) — VPN-провайдер, весь диапазон в чёрных списках

При этом есть хостинги с менее засвеченными диапазонами. Мелкие региональные провайдеры, чьи ASN ещё не попали в high-risk категорию. Но это временно — как только с них пойдёт трафик, репутация просядет за недели.

Почему 3 запроса — это уже много

Первый запрос: ASN-чек, TLS-фингерпринт, заголовки. Если всё чисто — пропуск. Если хостерский IP — уже флаг, но не блок. Система ставит на паузу, ждёт второй запрос.

Второй запрос: проверка cookie, fingerprint браузера через JS-челлендж, поведенческие метрики (движения мыши, тайминги). Хостерский IP, который прошёл JS-челлендж за 50 мс — это подозрительно. Реальный пользователь тратит 200-800 мс на загрузку и выполнение скрипта.

Третий запрос: если первые два дали флаги, третий почти гарантированно ловит блок или капчу. Антифрод не даёт «разогнаться». Три запроса — это стандартное окно для скоринга. Дальше либо доверие, либо отсечение.

Утечки, которые убивают даже хороший прокси

Даже если IP residential, есть способы его спалить. Заголовки, DNS-утечки, WebRTC, тайминги TCP. Прокси может быть чистым, но клиент под ним — кривой.

Вот типичный набор утечек, который антифрод ловит за один запрос:

```bash

curl -x http://user:pass@proxy.example.com:8080 \

-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \

-H "Accept-Language: en-US,en;q=0.9" \

--compressed \

https://httpbin.org/headers

```

Если прокси добавляет `Via: 1.1 proxy.example.com` или `X-Forwarded-For` — антифрод видит реальную цепочку. Если TLS-фингерпринт не совпадает с заявленным браузером — второй флаг. Если rDNS прокси содержит «vps» или «host» — третий.

Проверка утечек через Python:

```python

import requests

proxies = {

"http": "http://user:pass@proxy.example.com:8080",

"https": "http://user:pass@proxy.example.com:8080"

}

r = requests.get("https://httpbin.org/headers", proxies=proxies, timeout=10)

headers = r.json()["headers"]

leaks = []

for h in ["Via", "X-Forwarded-For", "Forwarded", "X-Real-IP"]:

if h in headers:

leaks.append(f"{h}: {headers[h]}")

if leaks:

print("Leaks detected:")

for l in leaks:

print(f" {l}")

else:

print("No proxy headers leaked")

```

Если хоть один из этих заголовков есть — прокси палится независимо от качества IP.

Кейс: парсинг маркетплейса с DigitalOcean

Задача: собирать цены с крупного маркетплейса. 50 000 запросов в сутки. Взяли 20 дроплетов DigitalOcean в разных регионах. Первые 200 запросов прошли. На 201-м — Cloudflare-челлендж. На 250-м — полная блокировка по ASN.

Причина: Cloudflare видит AS14061 и включает managed challenge для всего диапазона. Не важно, что User-Agent был реальный Chrome, что куки сохранялись, что задержки между запросами 2-5 секунд. ASN-флаг перебивает всё.

Цифры: 20 IP, 200 успешных запросов, 0 успешных после 250-го. Время до блокировки — 47 минут. Пропускная способность упала с 50 rps до нуля за один цикл челленджа.

Решение: перешли на residential-прокси с ротацией по 10 минут. Стоимость выросла в 8 раз, но success rate поднялся с 0% до 94%. ASN residential (AS7922, AS701, AS3320) не триггерит managed challenge.

Кейс: регистрация аккаунтов через Hetzner

Сервис требовал регистрации 500 аккаунтов в день. Использовали Hetzner Cloud (AS24940). Первые 3 аккаунта с одного IP — успех. Четвёртый — SMS-верификация. Пятый — бан по IP.

Причина: антифрод-система (в данном случае Sift) видит AS24940 и применяет правило «один аккаунт на IP за 24 часа для hosting-ASN». Для residential-ASN правило мягче — 3-5 аккаунтов на IP.

Технические детали: Sift получает ASN-данные от MaxMind, обновление раз в сутки. Hetzner помечен как hosting с 2018 года. Порог скоринга для регистрации — 55. Один только ASN-флаг даёт +40. Плюс отсутствие истории устройства +15. Плюс новый email-домен +10. Итого 65 — блок.

Решение: residential-прокси с привязкой к городу. Не просто «США», а конкретный город, чтобы ASN совпадал с billing-адресом карты. Success rate вырос с 8% до 71%.

Кейс: API-запросы через AWS Lambda

Сервис финансовых данных. Запросы шли через AWS Lambda. IP-адреса — из AS16509 (Amazon). Первые 50 запросов — норма. На 51-м — 403 с заголовком `x-amzn-waf-action: block`.

Причина: WAF целевого сервиса имел правило: «блокировать AS16509 для эндпоинтов /api/v1/*». Не весь AWS, а конкретные подсети, которые чаще всего использовались для скрейпинга. Lambda выходит через NAT Gateway, IP которого в базе помечен как «cloud provider, high abuse».

Цифры: 50 успешных запросов, 403 после 51-го. Задержка ответа выросла с 120 мс до 3400 мс (WAF добавляет latency на проверку). Rate limit на стороне WAF — 100 запросов в минуту с одного IP, но ASN-правило сработало раньше.

Решение: перешли на выделенные residential-прокси с фиксированной сессией. 4 IP, ротация раз в час. Success rate — 99.2%. Стоимость — \$15 за гигабайт трафика против \$0.09 у AWS.

Что делать: стратегии обхода ASN-фильтров

Первое — не использовать хостинговые ASN для задач, где нужна репутация. Вообще. Даже для «безобидных» запросов. Антифрод не разбирается, безобидный у вас запрос или нет. Он видит ASN и режет.

Второе — если нужен хостинг, брать ASN, которые ещё не в high-risk. Мелкие провайдеры, региональные хостеры, VPS-конторы в странах с низким abuse-рейтингом. Но это лотерея. Репутация меняется быстро.

Третье — residential-прокси с ротацией. Дорого, но работает. Ключевое — ротация по сессии, не по запросу. Антифрод не любит, когда IP меняется между запросами. Это поведенческий флаг.

Четвёртое — mobile-прокси. ASN мобильных операторов (AS21928 T-Mobile, AS3320 Deutsche Telekom) имеют наивысший trust score. Потому что за одним IP могут стоять тысячи реальных пользователей через CGNAT. Антифрод не может блокировать весь диапазон — слишком много ложных срабатываний.

Для ротации с сохранением сессии на стороне клиента:

```python

import requests

from requests.adapters import HTTPAdapter

from urllib3.util.retry import Retry

session = requests.Session()

retry = Retry(total=3, backoff_factor=0.5, status_forcelist=[429, 500, 502, 503])

session.mount("https://", HTTPAdapter(max_retries=retry))

session.proxies = {

"http": "http://user:pass@residential.proxy.example.com:8080",

"https": "http://user:pass@residential.proxy.example.com:8080"

}

session.headers.update({

"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",

"Accept-Language": "en-US,en;q=0.9",

"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",

"Accept-Encoding": "gzip, deflate, br",

"Connection": "keep-alive"

})

for i in range(10):

r = session.get("https://target.example.com/api/data", timeout=15)

print(f"Request {i}: {r.status_code}")

```

Сессия сохраняет cookie, HTTPAdapter ретраит на 429/5xx. Прокси-провайдер держит один IP на сессию — антифрод видит консистентность.

Почему IPv6 меняет расклад

IPv6-адресация ломает классический ASN-скоринг. У residential-провайдеров IPv6-префиксы часто выдаются /64 на абонента. Это 18 квинтиллионов адресов на одного клиента. Антифрод не может трекать репутацию по отдельным IPv6 — слишком много.

Но есть нюанс. Хостинговые провайдеры тоже выдают IPv6. И их /48 или /56 префиксы так же легко классифицируются по ASN. Плюс многие антифрод-базы ещё не имеют полноценных данных по IPv6-репутации. Это временное окно.

Прокси-провайдеры вроде lexic.ml работают с IPv6-диапазонами residential-ASN, где /64 выдаётся реальным абонентам. Антифрод видит residential ASN, но не может привязать конкретный IPv6 к истории abuse. Ротация внутри /64 даёт тысячи «чистых» адресов с одного префикса.

Таблица: скорость детекции по типам ASN

| Тип ASN | Пример | Запросов до флага | Запросов до блока |

|---|---|---|---|

| Cloud (AWS, GCP) | AS16509 | 1 | 3-5 |

| VPS (DO, Hetzner) | AS14061 | 1-2 | 5-10 |

| Business | AS8075 (Microsoft) | 5-10 | 50+ |

| Residential ISP | AS7922 (Comcast) | 20-50 | 200+ |

| Mobile (CGNAT) | AS21928 | 100+ | 1000+ |

Цифры приблизительные. Зависят от конкретного антифрода, целевого сервиса, поведения клиента. Но порядок величин стабилен: cloud-ASN палятся мгновенно, mobile держатся дольше всех.

Итог без воды

ASN — это первый и самый жёсткий фильтр. Раньше поведенческого анализа, раньше fingerprinting, раньше всего. Если IP принадлежит хостингу — вы уже под подозрением. Три запроса — это не много. Это стандартное окно, за которое антифрод принимает решение.

Residential и mobile ASN обходят этот фильтр. Не потому что они «лучше» технически, а потому что антифрод не может их блокировать без массовых ложных срабатываний. Экономика ложных блокировок защищает реальных пользователей — и тех, кто под них маскируется.

Хостинговые прокси работают только там, где антифрод слабый или отсутствует. Для всего остального — residential, mobile, IPv6-ротация внутри residential-префиксов. Дороже, медленнее, но проходит.