TCP OS Fingerprint и прокси — как на самом деле работает детект

Клиенты часто спрашивают про «TCP отпечаток» и обвиняют провайдеров: «у вас плохой отпечаток прокси». Давайте разберёмся, что это такое на самом деле, почему большинство прокси-сервисов делают это неправильно — и как это решено в ProxyGrow на уровне ядра.

Что такое TCP OS fingerprint?

Когда устройство подключается к любому сайту, оно устанавливает TCP-соединение. В процессе хендшейка передаётся не только IP, но и набор низкоуровневых параметров из заголовков TCP-пакетов:

• Window Size — размер буфера приёма, заявленный операционкой
• TTL — начальное время жизни, разное у разных ОС
• MSS — максимальный размер сегмента, согласованный при handshake
• Порядок и набор TCP-опций — SACK, Timestamps, NOP, ECN, Window Scale
• Поведение TCP-стека — паттерны ретрансмиссий, обработка потерь, таймауты

Совокупность этих значений уникальна для каждой операционной системы. Windows 10, Android, iOS и Linux выглядят по-разному на сетевом уровне — это заложено в дизайн. Это и есть TCP OS fingerprint — пассивно считываемый сетевой слепок устройства. Его не нужно «запрашивать» — он передаётся автоматически с каждым SYN-пакетом.

Что происходит, когда ты используешь прокси?

Без прокси: устройство строит TCP-соединение напрямую с сайтом. Сайт видит твой IP и твой fingerprint.

С прокси: устройство строит TCP-соединение с прокси-сервером, а прокси открывает отдельное TCP-соединение с целевым сайтом. Это два разных соединения. Сайт видит параметры прокси-сервера, а не твоего устройства.

Если прокси-сервер работает на Linux (а большинство так и работает) — сайт видит Linux fingerprint. Если при этом браузер передаёт User-Agent: Windows 10, возникает несоответствие между L4 (транспортный уровень) и L7 (прикладной уровень) — и это рассогласование детектируется автоматически.

Как сайты это обнаруживают?

Стандартный инструмент пассивной детекции — p0f. Он анализирует входящие TCP SYN-пакеты и определяет ОС удалённого хоста без единого активного запроса. Никаких probe-пакетов, никаких алертов от IDS.

Сайт сопоставляет три сигнала:

1. L4 TCP fingerprint vs L7 User-Agent

Если TCP-стек говорит «Linux», а браузер — «Windows 10»: красный флаг. Это прямое указание на прокси или VPN.

2. RTT на L4 vs RTT на L7

Сайт видит задержку TCP-соединения от прокси до себя (например, 40 мс). Браузер клиента передаёт общий RTT 70 мс (клиент → прокси → сайт). Разница в этих значениях — явный индикатор промежуточного сервера.

3. Внутренняя несогласованность TCP-параметров

Если кто-то попытался «подделать» fingerprint — например, подменил Window Size под Windows, но оставил Linux-специфичный порядок TCP-опций — это хуже, чем честный Linux fingerprint. Несогласованные поля детектируются надёжнее, чем отсутствие спуфинга.

Что меняется в TCP при использовании прокси

Про мобильных операторов

Важный момент: CGNAT операторов сотовой связи сам по себе может изменять TCP fingerprint. Оборудование оператора способно выдавать Linux или FreeBSD fingerprint — даже при прямом подключении модема без какого-либо прокси. Поэтому «Linux в fingerprint» автоматически не означает детект или бан. Это один из множества сигналов, а не приговор.

Именно поэтому у мобильных прокси изначально структурное преимущество перед датацентровыми — ещё до любых ухищрений с fingerprint.

Где реально опасность?

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

1. Некачественный частичный спуфинг

Прокси-сервис меняет только Window Size или TTL, оставляя остальные параметры несовместимыми с заявленной ОС. Такой «гибрид» детектируется лучше, чем честный Linux fingerprint без спуфинга вообще.

2. Разница RTT L4 / L7

Чем больше разница между задержкой на сетевом уровне и задержкой браузера — тем очевиднее наличие промежуточного сервера.

3. DNS-утечки

Один общий DNS-резолвер на все модемы фермы — классическая ошибка. Сайт видит DNS-запросы из одного источника при разных IP. Каждый модем должен использовать DNS своего оператора.

Что важнее: L4 или L7?

L7 анализируется глубже. Canvas fingerprint, WebGL, TLS fingerprint (JA3/JA4), настройки HTTP/2, порядок заголовков браузера — всё это передаёт больше информации, чем TCP-стек. Но критична именно консистентность между L4 и L7: если они противоречат друг другу — ни один из уровней не спасёт.

Как это решено в ProxyGrow

Большинство прокси-сервисов либо вообще не работают с TCP fingerprint, либо делают частичный спуфинг — и получают результат хуже, чем без него.

В ProxyGrow реализован собственный сетевой стек на базе Linux kernel 6.12 — TCP Fingerprint Reality:

Полная имитация TCP-стека выбранной ОС Не замена отдельных полей, а воспроизведение всей логики поведения TCP: Window Size, TTL, MSS, порядок и набор опций, SACK/ECN-поведение, timestamp-паттерны — всё соответствует выбранной ОС целиком и внутренне согласовано.

Прозрачное клонирование fingerprint клиента на лету Система считывает TCP-параметры из входящего SYN-пакета клиента и проксирует их дальше к целевому сайту. Сайт видит fingerprint реального устройства клиента, а не прокси-сервера.

Применение fingerprint на разных доступах Считанный fingerprint клиента применяется консистентно на все его соединения, независимо от типа протокола.

Компенсация RTT: L4 RTT = L7 RTT Ключевое отличие. Система компенсирует задержку в TCP-стеке так, что разница между RTT на сетевом уровне (L4) и RTT браузера (L7) сводится к минимуму. Детект по дельте RTT устранён.

Работает на всех типах подключений SOCKS5, HTTP-прокси, OpenVPN, IKEv2, VLESS — fingerprint reality применяется на транспортном уровне, прозрачно для протокола верхнего уровня.

Минимальное влияние на производительность Вся обработка происходит на уровне ядра. Скорость и стабильность, характерные для ProxyGrow, сохраняются.

Сводная таблица

Ни один из описанных методов детекции — p0f, RTT-анализ, User-Agent vs TCP mismatch — не даёт сигнала, если fingerprint клиента передаётся корректно, а задержки скомпенсированы.

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