Почему IPv6-прокси «палятся» в TikTok: анализ TLS-отпечатков и поведения аккаунта

Антифрод TikTok не смотрит на IP в первую очередь. Он смотрит на то, как твой клиент устанавливает соединение. IPv6 тут вторичен — но именно с ним связана половина проблем, потому что большинство прокси-провайдеров отдают голый адрес без нормальной поддержки IPv6-стека на клиенте. Разбираем, где рвётся.

Что реально видит TikTok на входе

Первое касание — TCP-хендшейк и TLS ClientHello. До того как ты отправишь логин, сервер уже знает: версию TLS, набор шифров, порядок расширений, ALPN, поддерживаемые группы, длину ключа, наличие GREASE, JA3/JA4-хэш. Это отпечаток стека, а не аккаунта. И он у тебя один на все профили, если ты гоняешь их через один и тот же curl или requests.

IPv6-адрес добавляется сверху. TikTok видит префикс /64, ASN провайдера, наличие rDNS, возраст аллокации. Если прокси из датацентра Hetzner с префиксом 2a01:4f8::/29 — это один сигнал. Если из residential-пула — другой. Но TLS-отпечаток важнее адреса: с правильным JA4 и «плохим» IPv6 ты проживёшь дольше, чем наоборот.

Проверить свой отпечаток можно так:

```bash

curl -6 -s https://tls.browserleaks.com/json | jq '{ja3_hash, ja4, akamai_hash}'

```

Если ja4 показывает `t13d1516h2_8daaf6152771_...` — это дефолт Python requests или Go. Такой отпечаток в TikTok-мобильном трафике не встречается никогда.

JA3, JA4 и почему одного недостаточно

JA3 — это MD5 от конкатенации версии TLS, списка шифров, расширений, эллиптических кривых и форматов точек. Простой, но ломается при любом изменении порядка. JA4 — следующее поколение, уже с префиксами: `t` (TCP), версия TLS, SNI-флаг, число шифров, ALPN. Стабильнее и точнее.

TikTok-мобильный клиент на Android 13 с последней версией приложения выдаёт конкретный JA4, и он меняется от версии к версии. Если ты эмулируешь «мобильный трафик» через requests с TLS 1.3 и стандартным набором — тебя отличат от реального клиента за один пакет. Не потому что IP плохой, а потому что ClientHello не тот.

Проблема IPv6-прокси: часть провайдеров делает transparent proxy на уровне TCP, и TLS-сессия терминируется на их стороне. Тогда JA3/JA4 у всех клиентов одинаковый — серверный. Это мгновенный флаг.

```python

import ssl, socket

ctx = ssl.create_default_context()

ctx.set_alpn_protocols(["h2", "http/1.1"])

ctx.minimum_version = ssl.TLSVersion.TLSv1_3

with socket.create_connection(("api16-normal-c-useast1a.tiktokv.com", 443), timeout=10) as sock:

with ctx.wrap_socket(sock, server_hostname="api16-normal-c-useast1a.tiktokv.com") as ssock:

print(ssock.version(), ssock.cipher(), ssock.selected_alpn_protocol())

```

Этот скрипт покажет, что реально уходит в сеть. Если версия TLS 1.2 и ALPN http/1.1 — ты уже не похож на мобильный клиент, который всегда идёт по h2 и TLS 1.3.

Поведение аккаунта: тайминги и последовательности

Отпечаток — входной билет. Дальше решает поведение. TikTok логирует интервалы между запросами, порядок эндпоинтов, размеры батчей. Мобильный клиент при старте делает серию из 8-12 запросов за 400-900 мс: конфиг, регион, фича-флаги, авторизация. Если ты дёргаешь API вручную с паузами по 2-3 секунды — это не мобильное приложение.

IPv6 тут добавляет ещё один слой: путь до сервера. Residential IPv6 из Европы даёт RTT 20-40 мс до европейского ЦОД TikTok. Датацентровый IPv6 из того же региона — 10-15 мс. Слишком быстро — тоже сигнал. Твой клиент физически не может отвечать за 8 мс, если он «с мобильного интернета».

Типичный паттерн палева: аккаунт зарегистрирован с одного IPv6 /64, логин идёт с другого /64 того же провайдера, а активность — с третьего. TikTok связывает это по ASN и по совпадению префикса выше /48. Один провайдер, разные подсети, одинаковый TLS — связка готова.

Как IPv6-префикс выдаёт пул

Ключевая деталь: IPv6-адреса не покупают по одному. Провайдер выдаёт /64 или /48. TikTok видит префикс и группирует аккаунты по нему. Если с /64 за сутки зашло 200 разных аккаунтов — префикс помечается. Дальше любой новый аккаунт с этого /64 получает повышенный скор риска ещё до первого действия.

Датацентровые префиксы известны. Residential-провайдеры — нет, но у них другая беда: адреса ротируются, и один и тот же /64 может достаться разным людям в разное время. TikTok это знает и относится к residential-IPv6 мягче, но требует стабильности: аккаунт должен сидеть на одном префиксе хотя бы несколько дней.

Таблица реальных сигналов, которые собирает антифрод:

| Сигнал | Датацентр IPv6 | Residential IPv6 | Мобильный IPv6 |

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

| ASN | 24940, 16276, 14061 | 12389, 3216 | 8359, 31213 |

| RTT до EU-ЦОД | 8-15 мс | 20-40 мс | 40-120 мс |

| Стабильность /64 | высокая | средняя | низкая |

| rDNS | обычно есть | часто есть | почти всегда |

| JA4 совпадает с мобильным клиентом | редко | редко | часто |

Если твой прокси-провайдер отдаёт адреса из 2a01:4f8::/29 (Hetzner) — это гарантированный датацентр. Никакой TLS-отпечаток это не перекроет.

Терминация TLS на стороне прокси

Самая частая причина палева — прокси терминирует TLS. Ты думаешь, что твой curl идёт напрямую, а на деле соединение разрывается на прокси и пересобирается с серверным стеком. В логах TikTok — один JA4 на сотни «разных» клиентов.

Проверить просто: сравни JA4 через прокси и напрямую.

```bash

curl -6 --proxy "http://[2001:db8::1]:3128" -s https://tls.browserleaks.com/json | jq .ja4

curl -6 -s https://tls.browserleaks.com/json | jq .ja4

```

Если хэши разные — прокси вмешивается. Если одинаковые — идёт pass-through, всё честно. Для SOCKS5 это правило работает так же, но там терминируют реже.

Нормальный IPv6-прокси для TikTok — это SOCKS5 без инспекции, с сохранением клиентского ClientHello. HTTP CONNECT тоже годится, но многие провайдеры вешают на него MITM ради «аналитики». От таких бежать.

Кейс: аккаунты с одного /64 на residential-прокси

Пример: клиент взял residential IPv6-пул, 500 адресов в одном /64, гонял 40 аккаунтов TikTok через ротацию по запросу. Через 6 дней — бан 28 из 40. Разбор показал: все 40 аккаунтов логинились с префикса 2a02:xxxx:xxxx::/48, JA4 у всех одинаковый (Python requests 2.31, TLS 1.3, стандартный набор), интервалы между запросами ровные — 1500 мс ровно, как по таймеру.

Причина связки: префикс + идентичный JA4 + роботизированные тайминги. TikTok не разбирался, кто есть кто — снёс всю группу. Решение: развести аккаунты по разным /48, поднять реалистичный TLS-стек (curl-impersonate или tls-client), добавить джиттер в тайминги 300-2000 мс с неровным распределением. Выживаемость выросла до 34 из 40 за тот же период.

Кейс: MITM на HTTP CONNECT

Другой пример: прокси-провайдер на HTTP CONNECT с «оптимизацией трафика». Клиент не проверял. JA4 через прокси — `t13d1516h2_..._server_side`, у всех клиентов одинаковый, включая тех, кто работал с разных устройств. TikTok пометил 12 аккаунтов за 48 часов. Причина — серверный TLS-стек, который не совпадал ни с одним реальным клиентом.

Проверка заняла 30 секунд: `curl --proxy` и сравнение с прямым запросом. Хэши не совпали. Переезд на SOCKS5 без инспекции — и новые аккаунты перестали падать на входе. Старые не восстановились, но это уже вопрос репутации префикса, а не отпечатка.

Кейс: слишком быстрый IPv6

Третий: клиент сидел на датацентровом IPv6 во Франкфурте, target — европейский ЦОД TikTok. RTT 9 мс стабильно. Аккаунты жили по 2-3 дня. Проблема оказалась не в отпечатке — TLS был настроен нормально через curl-impersonate. Проблема в физике: мобильный клиент из Германии не может иметь RTT 9 мс до TikTok, у него минимум 25-30 через оператора.

Антифрод это видит по TCP-таймингам: SYN-ACK, RTT, jitter. Решение — residential-прокси с реальным RTT 30-60 мс. Аккаунты стали жить по 2-3 недели. Отпечаток тот же, изменился только сетевой профиль.

Что делать с TLS на клиенте

Если работаешь с TikTok через IPv6 — забудь про requests и голый curl. Нужен стек, который повторяет ClientHello реального клиента. Варианты: curl-impersonate (патченный curl с профилями Chrome/Firefox), tls-client на Go, или специализированные библиотеки под мобильные профили.

Для мобильного профиля Android 13 + TikTok 34.x нужен конкретный набор: TLS 1.3, GREASE, определённый порядок расширений, ALPN h2, SNI без ECH. Готовых пресетов под TikTok мало, чаще собирают вручную по дампу трафика с реального устройства.

```python

from tls_client import Session

s = Session(client_identifier="chrome_120")

s.proxies = {"https": "socks5h://[2001:db8::1]:1080"}

r = s.get("https://api16-normal-c-useast1a.tiktokv.com/aweme/v1/feed/")

print(r.status_code, r.headers.get("x-tt-logid"))

```

`x-tt-logid` в ответе — это трейс-ID на стороне TikTok. По нему видно, попал ли запрос в «подозрительные» — если логид приходит с префиксом, характерным для фрод-пула, ответ будет 200, но с пустым телом и флагом в заголовках.

Ротация и стабильность: где баланс

Аккаунт не должен прыгать по /64 каждые 5 минут. TikTok строит поведенческую модель: устройство, регион, префикс, тайминги. Резкая смена префикса в середине сессии — сигнал. Стабильный /64 на аккаунт на 3-7 дней — норма. Ротация — только при смене аккаунта или по расписанию, не по запросу.

При этом один /64 не должен держать больше 5-10 аккаунтов одновременно. Больше — префикс получает вес. Residential-провайдеры это понимают, датацентровые — нет, у них /64 один на весь пул.

Чек-лист перед запуском

Проверь три вещи до первого логина. Первое: JA4 через прокси совпадает с прямым запросом — значит, нет MITM. Второе: RTT до целевого ЦОД в диапазоне 25-80 мс — значит, не датацентр. Третье: префикс /48 не пересекается с другими твоими аккаунтами — значит, нет связки.

Если все три прошли — IPv6-прокси не спалит тебя сам по себе. Палят отпечаток, тайминги и жадность при ротации. Сам адрес — последнее, на что смотрит антифрод, но первое, что выдаёт пул, когда остальное уже настроено.