ЧЕК ЛИСТ: ПРОКСИ и ФИНГЕРЫ [апрель 2026]
Как можно быстро спалиться с прокси:
- Сетевой уровень (IP и диапазоны)
Массовые запросы с одного диапазона.
Если с одной подсети льется подозрительно много запросов → блокируется весь диапазон. Подозрительные ASN (автономные системы). У Яндекса базы, где видно, что IP арендован у дата-центра, а не у мобильного оператора → повышенный риск бана. Информацию об активности абонента может передавать сам провайдер: Нет перемещений абонента, используется одна и та же базовая станция. Нет звонков, только поисковый трафик с Яндекса и тп. По сравнению с резидентными прокси, мобильные прокси и их сети могут выглядеть крайне подозрительно для детекта. Точно мы не знаем, что именно может передавать провайдер, но что есть такая возможность, уже настораживает.
Яндекс может очень внимательно следить за данными ТСПу. Резкое увеличение запросов.
Всплески (десятки тысяч запросов в минуту) → триггер защиты. Признак, что анти-DDoS Яндекса режет IP по лимиту.
- Технический уровень (признаки прокси)
Отсутствие “человеческого” поведения в TCP/HTTP. Повторяющиеся User-Agent, однотипные заголовки.
WebRTC / DNS-leak
Даже через прокси браузер может «проболтаться», что реальный IP другой.
Fingerprints
Canvas, AudioContext, WebGL, TimeZone → одинаковые у сотен сессий.
TLS Fingerprint
Отличается от реальных браузеров: одинаковый порядок шифров → палится как бот.
- Системный уровень (интеграции внутри Яндекса)
NOC и базы злоупотреблений
У Яндекса централизованный мониторинг IP: жалобы, абузы, сигналы → попадаешь в чёрный список.
Кросс-сервисы
Блок может идти не только в Поиске, но и в Маркете, Директе, Картах, если IP «засветился».
Метки «серые» и «черные» IP
Если твой пул уже использовался для накрутки → новый проект будет гореть с первых запросов.
🔥 Технический ЧЕК-ЛИСТ для антидетекта нПФ
1) IP / СЕТЬ / TLS
Что должно быть:
Резидентные провайдерские прокси – самые эффективные
Мобильные прокси (разные провайдеры, разные сети/подсети)
ASN — обычный провайдер, а не AWS / GCP / Hetzner / OVH (здесь наименьше шанс спалиться, для инфо)
Geo по IP совпадает с timezone, языком и поведением (здесь наименьше шанс спалиться, для инфо)
Идеальная частота смены IP (1 IP = 1 профиль/сессия), max 2 смены за сессию.
Корректный TLS-профиль (как у реального Chrome/Яндекс.Браузер).
❌ Что считается подозрительным
Большенство дипазонов подсетей мобильный ip Яндекс знает, кто использует сервисы по аренде
Частая ротация IP (за сессию более 2-3 скачков ip).
JA3/TLS, который не совпадает с реальным браузером.
🛠 Как проверить
WebRTC leaks: browserleaks.com/webrtc
TLS/JA3: ja3er.com, fingerprintjs.io/demos
2) БРАУЗЕРНЫЙ ОТПЕЧАТОК (FINGERPRINT)
WebGL renderer/vendor соответствуют устройству и OS.
Canvas fingerprint реалистичный, не пустой и не статичный.
AudioContext fingerprint не дефолтный
navigator.* параметры согласованы: hardwareConcurrency, languages, platform, deviceMemory.
Шрифты → не 5 штук, а нормальный набор
touchscreen параметры соответствуют профилю (desktop ≠ android).
❌ Подозрительные признаки
Canvas всегда одинаковый меж сессиями или
AudioContext fingerprint → “0” или одинаковый в разных устройствах.
Шрифтов мало (палевно когда выставляют 5–6).
Touch parameters включены на десктопе.
Уровень батареи = 1 или необычные значения (Battery API плохо подменён).
navigator.plugins.length = 0
3) ПОВЕДЕНЧЕСКИЕ СИГНАЛЫ (наименьший шанс спалиться, для инфо)
Плавные движения мыши (реальная кривая, не «линейка»).
Нормальные задержки между действиями: 200–600 мс для кликов, 1–3 сек паузы.
Скорость прокрутки естественная, не скачками.
Набор текста с микрозадержками (не «вставка за 0,01 сек»).
Нормальная длина сессии (5–120 секунд минимум).
КРОСС-ПРОВЕРКИ И НЕСООТВЕТСТВИЯ
IP-гео совпадает с timezone в браузере (наименьший шанс спалиться, для инфо)
Locale соответствует языку UI и устройства (наименьший шанс спалиться, для инфо)
Устройство+OS+GPU не конфликтуют.
Версия браузера = версия WebGL/Canvas сигнатур.
Про туннелирования прокси
Что такое туннелирование прокси — простыми словами
Туннелирование — это способ “обернуть” весь трафик через специальный канал, чтобы:
скрыть реальный IP,
скрыть реальное устройство/приложение,
скрыть “шумные” признаки бота,
показать сайту трафик, похожий на настоящий браузерный трафик.
Проще: Это когда твой трафик не выглядит как «бот через прокси», а выглядит как «обычный чел из обычного дома через обычный интернет».
Почему обычный прокси стал палиться:
Обычные HTTP/SOCKS прокси не маскируют:
сетевые отпечатки (TLS/JA3),
HTTP-заголовки,
fingerprint TCP-соединения,
структуру запросов браузера,
характеристики клиента (кто инициировал запрос),
параметры соединения (TTL, window size, cipher suite).
Туннелирование делает всё иначе
- Прячет твоё реальное сетевое поведение
Обычный бот → отправляет клиентское соединение сам.
Туннелирование → передаёт твоё соединение через другой “контейнер”, и сайт видит сетевой профиль уже туннеля, а не твой.
Это значит:
JA3 совпадает с реальными устройствами,
cipher suites как у обычных пользователей,
HTTP-запросы выглядят естественно.
- Делает так, будто твой трафик идёт от реального устройства
Хорошие туннели (например, резидентское туннелирование) используют реальные роутеры пользователей.
Выглядит так, будто:
ты сидишь дома за своим Wi-Fi,
у тебя нормальный провайдер,
соединение как у живого пользователя.
Это резко снижает шанс детекта в Яндексе.
- Маскирует автоматизацию
Антифрод ловит отклонения в поведении самого TCP/IP, даже без JS и без браузера.
Туннелирование прячем:
TCP window size
TTL
особенности пакетов
число retransmissions
порядок отправки SYN/ACK
То есть даже low-level сетевой отпечаток становится человеческим.
- Маскирует головную боль с WebRTC и DNS
Туннелирование:
блокирует утечки реального IP через WebRTC,
перенаправляет DNS-запросы,
работает по принципу “всё через канал” без дыр.
⭐️ В итоге, что получает Яндекс?
Если без туннеля — примерно такую картину:
❌ JA3: нестандартный, ботский
❌ подозрительные заголовки прокси
❌ WebRTC утечки
❌ TCP fingerprint → бот
Яндекс любит сетевые признаки, он анализирует:
прокси-пулы
TLS fingerprint
JA3
качество соединения
задержки пакетов
ротацию IP
WebRTC/DNS конфликты
