<b>Прокси, SSH-туннели и DNS: где ломается сетевой контур антидетекта</b>

<b>Прокси, SSH-туннели и DNS: где ломается сетевой контур антидетекта</b>

Сетевое окружение проверяют не по факту наличия прокси, а по согласованности слоев. Резидентский IP без совпадения ASN, гео и таймзоны — уже аномалия. Разберем энтропию данного параметра: у антифрод-системы нет задачи доказать, что вы бот; ей достаточно увидеть несостыковку между IP, DNS и TCP-отпечатком.

Базовый чек-лист:
— egress-IP должен совпадать с регионом профиля;
— DNS-запросы не должны уходить мимо туннеля;
— IPv6 либо полностью маршрутизируется, либо отключается;
— WebRTC не должен светить локальные адреса;
— у прокси и браузера должны совпадать язык, часовой пояс и accept-language.

Резидентский прокси дает правдоподобный внешний слой, но не решает проблему утечек. Если системный резолвер продолжает работать напрямую, детект на уровне сетевого стека видит разрыв маршрута. SSH-туннель полезен там, где нужен предсказуемый egress и контроль над маршрутизацией, но его тоже надо проверять через packet capture: часть приложений упрямо использует собственный DNS-кэш или QUIC, обходя ожидаемый путь.

Практика простая: сначала строится маршрут, потом под него подгоняется браузерный профиль. Если прокси, DNS, WebRTC и TLS Client Hello не складываются в один сетевой портрет, спуфинг через инъекцию JS-кода не спасет. Под капотом Chromium API важна не «магия антидетекта», а отсутствие противоречий на каждом узле цепочки.