Один IP в 32 чёрных списках: почему дешёвый прокси обходится дороже

Вы настроили антидетект до последнего параметра. Уникальный canvas, честный WebGL, аккуратные шрифты, разведённые часовые пояса, чистые куки. Аккаунт всё равно ловит капчу на каждом шаге, а через день прилетает бан. Знакомая ситуация? Первым делом мы грешим на фингерпринт: перепроверяем набор энтропии, крутим версии браузера, меняем user-agent. Иногда это помогает. Но часто проблема лежит совсем в другой плоскости, и разбираться в ней стоит раньше, чем в тонкостях отпечатка.

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

В этой статье мы разберём, как устроены публичные блоклисты, почему дешёвые прокси попадают в них годами, чем принципиально отличается мобильный IP и как проверить свои адреса до того, как они начнут сжигать аккаунты. Пишем спокойно, с реальными цифрами и живым примером ответа API. Без обещаний обхода конкретных площадок и без превосходных степеней.

Почему бан приходит раньше, чем вы думаете

Типичный сценарий выглядит так. Вы поднимаете сессию, открываете целевую площадку, и вместо контента получаете 403 или бесконечную капчу. Логика подсказывает искать причину в свежих настройках браузера. Но давайте разложим последовательность событий по порядку.

Когда браузер устанавливает соединение, сервер получает IP-адрес источника ещё до того, как отдаст хоть один байт контента. На этом этапе антифрод-система может свериться с внутренними и внешними списками репутации. Многие из этих списков публичны и обновляются ежедневно. Если ваш адрес в них есть, сайт уже настроен к вам недоверчиво. Дальше события развиваются по одному из двух путей.

• Повышенное недоверие. Вам показывают капчу, ограничивают частоту действий, требуют подтверждение по телефону. Аккаунт живёт, но каждый шаг превращается в борьбу.
• Прямой отказ. 403 на входе, мгновенная блокировка регистрации, шадоубан свежесозданного профиля. Браузер до реального взаимодействия просто не допускают.

Ключевая мысль: фингерпринт проверяется позже. Сначала — сеть. И если вы годами вылизываете отпечаток, но берёте адреса из общего котла, вы оптимизируете второй этап, проваливая первый. Отсюда практический вывод, к которому мы будем возвращаться: репутацию IP нужно проверять до использования, а не после первого бана.

Как устроены публичные блоклисты

Существует целая экосистема открытых фидов — регулярно обновляемых списков IP-адресов, сгруппированных по типу угрозы. Изначально они создавались для сетевой безопасности: администраторы подключают их к файрволам, чтобы отсекать сканеры, спам-ботов и известные источники атак. Но раз списки публичны, ими пользуется кто угодно, включая антифрод целевых сайтов.

Внутри этой экосистемы есть отдельная группа фидов, которая каталогизирует именно открытые прокси, узлы анонимизации и подобные сервисы. Назовём конкретные файлы, чтобы разговор был предметным:

• firehol_proxies.netset — сводный набор адресов, замеченных как открытые прокси.
• socks_proxy.ipset — список SOCKS-прокси, доступный во временных срезах на 1, 7 и 30 дней.
• sslproxies.ipset — каталог SSL-прокси.
• tor_exits.ipset — выходные узлы сети анонимизации.

Обратите внимание на срезы 1/7/30 дней у socks_proxy. Это значит, что адрес фиксируется н�� разово, а с историей. Даже если прокси перестал отвечать сегодня, в недельном и месячном срезе он ещё числится. Для антифрода это удобно: свежая метка ловит активные адреса, а исторические срезы отсекают тех, кто пытается переждать.

Мы в проекте IPGuardian агрегируем эту экосистему целиком. Актуальные цифры на 2026 год: 162 источника блоклистов, 8 категорий, ежедневное обновление. Категория «анонимайзеры» собрана из 17 источников и содержит 4,88 млн адресов — это крупнейшая категория в базе. Для сравнения: категория abuse насчитывает около 1,6 млн адресов, attacks — порядка 497 тыс. Анонимайзеров больше, чем abuse и attacks вместе взятых.

Суммарно по всем категориям это 7,11 млн отдельных IP-адресов плюс 356 тыс. подсетей, что в пересчёте даёт свыше 2,1 млрд покрытых адресов. Надёжность обновления держится на уровне 94,4% успешных синхронизаций за месяц. Это не абстрактная витрина цифр, а тот объём данных, с которым сверяется любой, кто подключил открытые фиды к своему антифроду.

Демонстрация: берём адрес из бесплатного листа

Теория — это хорошо, но давайте посмотрим на реальный ответ. Возьмём адрес, который лежит в общедоступном прокси-листе, и прогоним его через проверку. Запрос предельно простой:

curl -X POST https://ipguardian.net/api/check -H "Content-Type: application/json" -d '"1.20.254.32"'

Ответ (в сокращённом виде):

• "found": true
• {"filename": "socks_proxy.ipset", "category": "anonymizers"}
• {"filename": "socks_proxy_7d.ipset", "category": "anonymizers"}
• {"filename": "firehol_proxies.netset", "category": "anonymizers"}
• {"filename": "stopforumspam.ipset", "category": "abuse"}

Разберём, что мы видим. Поле found: true сразу говорит: адрес известен. Дальше идёт список источников. Первые три строки ожидаемы — это метки анонимайзеров. Адрес числится как SOCKS-прокси в свежем и недельном срезе, а также в сводном наборе открытых прокси. Ничего удивительного: он и правда прокси из открытого листа.

А теперь посмотрите на последнюю строку. stopforumspam.ipset, категория abuse. Это уже не «прокси». Это метка источника спама. Адрес попал в базу площадки, которая собирает данные о спам-регистрациях и злоупотреблениях на форумах. То есть через этот IP кто-то не просто ходил анонимно, а совершал действия, которые получили ярлык abuse.

И вот здесь начинается самое важное различие, ради которого стоит читать дальше.

Два разных ярлыка, две разные судьбы аккаунта

Метки в блоклистах неравнозначны. С точки зрения антифрода есть большая разница между «это прокси» и «это источник злоупотреблений».

Ярлык «помечен как прокси»

Категория anonymizers говорит сайту: соединение идёт через промежуточный узел, реальное происхождение скрыто. Реакция обычно сдержанная — повышенное недоверие. Вам покажут капчу, попросят подтверждение, ограничат лимиты. Неприятно, но с этим ещё можно работать. Многие легитимные пользователи ходят через корпоративные шлюзы, и полностью резать такой трафик рискованно для самого сайта.

Ярлык «помечен как spam/abuse»

Категории abuse и spam — это другой разговор. Здесь сайт видит не просто скрытие, а историю вредоносных действий с конкретного адреса. Реакция жёстче: мгновенная блокировка, отказ в регистрации, бан на входе. Логика простая — с этого IP уже прилетало плохое, зачем рисковать снова.

Проблема дешёвых прокси в том, что они собирают оба ярлыка сразу. Через публичный или общий прокси годами ходят все подряд: кто-то парсит, кто-то спамит, кто-то регистрирует ботоферму, кто-то рассылает мусор по форумам. Каждое такое действие оставляет след, и адрес обрастает метками из разных категорий.

Худшие адреса в нашей базе числятся в 32 списках одновременно — сразу в категориях abuse, anonymizers, attacks и spam. Представьте, что вы взяли такой адрес для нового аккаунта. Сайт видит соединение, за миллисекунды сверяется со списками, обнаруживает целый букет проблемных меток и закрывает дверь ещё до того, как ваш идеально настроенный антидетект успел отрисовать первую страницу. Дешевизна прокси в этот момент оборачивается сожжённым аккаунтом, потраченным временем на прогрев и, в случае арбитража, слитым бюджетом.

Чем принципиально отличается мобильный IP

Теперь ключевой момент — почему мобильные адреса устроены иначе. Речь не о магии, а об архитектуре сотовых сетей.

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

Отсюда следует главное. Оператор не раздаёт свой адрес как открытый прокси. Его нет в socks_proxy.ipset, его нет в firehol_proxies.netset, его нет в каталогах анонимайзеров — просто потому, что он не является публичным прокси по своей природе. Сканеры, которые ищут открытые прокси-порты, такой адрес не находят и в списки не заносят.

Более того, у сайта есть сильный экономический стимул не блокировать такие адреса целиком. Заблокировать мобильный IP оператора означает отрезать разом сотни реальных клиентов, которые в этот момент делятся тем же адресом. Для площадки это прямая потеря живых пользователей и денег. Поэтому к мобильным адресам антифрод относится осторожнее по определению.

Именно поэтому мобильные прокси показывают другую динамику в работе с аккаунтами. Вы находитесь среди живого трафика, а не в общем котле анонимайзеров с историей злоупотреблений.

Важная оговорка: мобильный IP не броня

Здесь мы обязаны быть честными, и эта оговорка усиливает материал, а не ослабляет его. Мобильный IP тоже может попасть в spam или abuse-листы. Если кто-то из абонентов за тем же CGNAT-адресом набедокурил — рассылал спам, ломился в чужие аккаунты, запускал вредоносную активность — адрес получит метку abuse. Категория anonymizers его, скорее всего, обойдёт, а вот spam/abuse — вполне.

Из этого следует прямой практический вывод, а не благостное заключение «берите мобильные и спите спокойно». Нужны две вещи:

• Проверка перед использованием. Прежде чем пускать адрес в дело, сверьтесь со списками. Мобильный он или нет — если на нём висит abuse-метка, лучше узнать об этом до, а не после бана.
• Ротация. Возможность сменить адрес, если текущий оказался запачкан чужой активностью. Мобильные сети позволяют менять IP, и это встроенная страховка от чужих ошибок.

Никакой тип прокси не даёт стопроцентной гарантии. Разница в вероятностях и в том, есть ли у вас инструменты контроля. У мобильных адресов вероятность попасть в котёл анонимайзеров близка к нулю по архитектурным причинам, а риск abuse управляется проверкой и ротацией.

Практика: как проверить свои адреса

Перейдём к самому полезному — как встроить проверку репутации в свой рабочий процесс. Хорошая новость: для базовой проверки не нужны ни регистрация, ни API-ключ.

Одиночная проверка через curl

Самый простой сценарий — проверить один адрес перед запуском профиля:

1. Отправьте POST-запрос на эндпоинт /api/check.
2. В теле передайте IP-адрес строкой в формате JSON.
3. Прочитайте ответ: поле found, массив sources с именами файлов и категориями.

Команда:

curl -X POST https://ipguardian.net/api/check -H "Content-Type: application/json" -d '"ВАШ_IP"'

Если found равно false — адрес в известных списках не значится, это хороший знак. Если true — смотрите, в каких именно категориях. Метка anonymizers терпима для многих задач, метка abuse или spam — повод отложить адрес.

Пакетная проверка до 100 адресов

Когда у вас пул из десятков адресов, проверять по одному неудобно. Сервис принимает до 100 адресов за один запрос. Скорость ответа — 4–5 мс на адрес, то есть весь пул из сотни проверяется за считанные сотни миллисекунд. Это позволяет встроить проверку прямо в пайплайн, не превращая её в узкое место.

Типичный алгоритм пакетной проверки:

1. Соберите список адресов, которые собираетесь использовать (до 100 за запрос).
2. Отправьте их одним POST-запросом на эндпоинт проверки.
3. Разберите ответ: для каждого адреса будет found и список источников.
4. Отфильтруйте адреса с метками abuse и spam — их в работу не пускаем.
5. Адреса с чистым ответом или только с лёгкими метками отправляйте в ротацию.

Как читать ответ

Три поля, которые вам действительно нужны:

• found — булево значение. true означает, что адрес найден хотя бы в одном списке.
• category — тип угрозы. anonymizers, abuse, spam, attacks и другие. По категории вы понимаете тяжесть проблемы.
• filename — имя конкретного источника. Полезно, чтобы понять, насколько свежая метка. Например, socks_proxy.ipset против socks_proxy_7d.ipset говорит о разной актуальности.

Способы применения: пять рабочих сценариев

Разберём, как проверка репутации встраивается в конкретные задачи. Для каждого сценария — для кого, зачем и как.

Сценарий 1. Предзапусковая проверка в мультиаккаунтинге

Для кого: те, кто ведёт десятки и сотни профилей в антидетект-браузерах.

Зачем: отсеять запачканные адреса до создания аккаунта, чтобы не сжигать прогретые профили на плохой сети.

Как: перед привязкой прокси к профилю прогоняйте адрес через проверку. Если видите abuse или spam — не используйте этот адрес для важного аккаунта. Простое правило экономит часы на восстановлении банов. Лайфхак: держите короткий скрипт, который проверяет адрес в момент назначения профилю и подсвечивает проблемные метки.

Сценарий 2. Гигиена пула для парсинга

Для кого: специалисты по сбору данных.

Зачем: адреса с меткой anonymizers чаще ловят капчу, что рушит стабильность парсинга и раздувает расходы на её обработку.

Как: перед началом крупной сессии пакетно проверяйте весь пул. Разделите адреса на три группы: чистые (в приоритете), с лёгкими метками (в резерв), с abuse/spam (в отсев). Работайте преимущественно на чистой группе, держа скорость запросов в разумных пределах.

Сценарий 3. Отладка внезапного роста банов в арбитраже

Для кого: арбитражники трафика.

Зачем: когда связка внезапно перестаёт работать, важно быстро понять, дело в креативе, в аккаунте или в сети.

Как: при всплеске банов первым делом проверьте адреса. Если они обросли abuse-метками — причина найдена, дело не в креативах. Это экономит бюджет, который иначе ушёл бы на бесконечные тесты объявлений. Инсайдерский совет: фиксируйте историю проверок, чтобы видеть, когда именно адрес испортился.

Сценарий 4. Приёмка новых прокси у поставщика

Для кого: все, кто закупает прокси.

Зачем: проверить качество пула до оплаты или сразу после получения доступа.

Как: получив тестовый доступ, прогоните выданные адреса через пакетную проверку. Высокая доля меток anonymizers и abuse в пуле — сигнал, что вы платите за общий котёл. Это объективный критерий вместо обещаний продавца.

Сценарий 5. Автоматическая ротация по репутации

Для кого: специалисты по автоматизации.

Зачем: не просто менять адрес по таймеру, а менять его, когда репутация ухудшилась.

Как: встройте периодическую проверку текущего адреса в свой пайплайн. Как только на нём появляется метка abuse (например, чужой абонент за тем же CGNAT набедокурил) — инициируйте ротацию. Скорость 4–5 мс на адрес позволяет делать это без задержек в основном процессе.

Типичные ошибки и как их избежать

Собрали частые промахи, которые видим на практике.

• Проверять адрес только после бана. К этому моменту аккаунт уже потерян. Проверка должна быть предзапусковой, а не посмертной.
• Считать мобильный IP неуязвимым. Мы уже разобрали: abuse-метка возможна и на мобильном адресе. Проверяйте и мобильные пулы тоже.
• Игнорировать имя источника. Метка в недельном срезе и в свежем — разный уровень актуальности. Смотрите filename, а не только категорию.
• Гнаться за дешевизной пула. Экономия на прокси оборачивается расходами на восстановление банов и слитым тестовым бюджетом. Считайте полную стоимость.
• Не разделять категории меток. anonymizers и abuse требуют разной реакции. Первую иногда можно терпеть, вторую — почти никогда.

Комбинации с другими инструментами

Проверка репутации не заменяет остальную гигиену, а дополняет её. Как это стыкуется:

• Антидетект-браузер + проверка IP. Отпечаток закрывает поведенческий и технический уровень, проверка IP — сетевой. Вместе они закрывают обе стадии, на которых вас оценивает антифрод.
• Система управления профилями + пакетная проверка. Назначайте адреса профилям только после фильтрации по репутации. Проверка на 100 адресов за запрос легко встраивается в этот шаг.
• Парсер + ротация по репутации. Пусть парсер получает из пула только чистые адреса, а испортившиеся автоматически отправляются в отсев.

Сравнение подходов: дешёвый прокси против мобильного с проверкой

Сведём разницу в понятную картину, без упоминания конкретных конкурентов.

Общий или публичный прокси

• Часто присутствует в каталогах анонимайзеров (socks_proxy, firehol_proxies).
• Нередко несёт метки abuse и spam из-за истории использования всеми подряд.
• Худшие экземпляры — в 32 списках одновременно.
• Дешевле на входе, дороже по итогу из-за банов и капчи.

Мобильный IP с проверкой репутации

• Архитектурно отсутствует в каталогах открытых прокси.
• Находится среди живого абонентского трафика через CGNAT.
• Сайту невыгодно блокировать его целиком — за ним реальные клиенты.
• Риск abuse-метки остаётся, но управляется проверкой и ротацией.

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

FAQ

Нужна ли регистрация, чтобы проверить адрес?

Для базовой проверки через API регистрация и ключ не требуются. Отправляете POST-запрос и читаете ответ.

Сколько адресов можно проверить за один запрос?

До 100 адресов в одном запросе. Скорость обработки — 4–5 мс на адрес, весь пул проверяется за доли секунды.

Как часто обновляются списки?

Ежедневно. Надёжность синхронизации за месяц — 94,4% успешных обновлений. Всего в базе 162 источника и 8 категорий.

Что означает found: true?

Адрес найден хотя бы в одном из списков. Дальше смотрите массив sources — там указаны категории и имена файлов, чтобы понять тяжесть проблемы.

Метка anonymizers — это приговор?

Нет. Это сигнал повышенного недоверия: возможна капча и ограничения. Гораздо серьёзнее метки abuse и spam — они чаще ведут к прямому бану.

Могут ли мобильные IP попасть в блоклисты?

В каталоги открытых прокси — практически нет, это следует из архитектуры сотовых сетей. Но в spam/abuse-листы мобильный адрес попасть может, если кто-то из абонентов за тем же CGNAT злоупотреблял. Поэтому проверка и ротация нужны и здесь.

Почему дешёвый прокси в итоге дороже?

Через общие адреса годами ходят все подряд, они обрастают метками из разных категорий. Бан аккаунта, потерянный прогрев и слитый тестовый бюджет обходятся дороже разницы в цене на прокси.

Как встроить проверку в автоматизацию?

Отправляйте пакетный запрос на этапе назначения адресов профилям и периодически перепроверяйте активные адреса. При появлении метки abuse инициируйте ротацию.

Что важнее — фингерпринт или репутация IP?

Оба важны, но проверяются на разных этапах. Репутация IP оценивается раньше, до отрисовки браузера. Идеальный отпечаток не спасёт, если адрес уже в чёрных списках.

Сколько всего адресов покрыто базой?

7,11 млн отдельных IP плюс 356 тыс. подсетей, что в пересчёте даёт свыше 2,1 млрд покрытых адресов. Крупнейшая категория — анонимайзеры, 4,88 млн адресов.

Выводы: с чего начать

Соберём картину воедино. Бан аккаунта — это не всегда история про фингерпринт. Часто причина в репутации самого IP, известной сайту ещё до первого запроса. Публичные фиды каталогизируют открытые прокси и анонимайзеры, а история злоупотреблений добавляет к адресам метки abuse и spam. Дешёвые прокси собирают оба типа ярлыков, и худшие из них числятся в 32 списках сразу.

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

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

Как начать прямо сейчас:

1. Возьмите адреса, которые используете, и прогоните их через проверку API — без регистрации и ключа. Один адрес через curl или пакет до 100 адресов за запрос.
2. Отфильтруйте адреса с метками abuse и spam. Оцените, сколько из вашего пула на самом деле проблемные.
3. Постройте процесс так, чтобы в работу шли только проверенные адреса, а испортившиеся уходили в ротацию.

Если не хочется собирать связку из отдельных инструментов, проверка репутации уже встроена в mobileproxy.space. Вы получаете мобильные адреса и возможность сверять их со списками в рамках одного рабочего процесса — как готовое решение той самой задачи, с которой мы начали: узнать о проблеме до бана, а не после него.