LinkedIn через IPv6 прокси: автоматизация приглашений без триггера антифрода

Почему LinkedIn вообще смотрит на IP

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

Когда вы отправляете приглашение, сервер получает кучу метаданных: IP, ASN, геолокацию, TLS-фингерпринт, заголовки, тайминги запросов между действиями. LinkedIn складывает это в скоринг. Если аккаунт новый, а IP принадлежит датацентру — привет, капча или теневой бан.

IPv6 в этой схеме интересен тем, что даёт огромный пул адресов. Один /64 префикс — это 2^64 адресов. Провайдеры обычно выдают клиентам /56 или /48. Это меняет правила игры: можно ротировать IP без покупки новых подсетей.

Чем IPv6 отличается от IPv4 в контексте прокси

В IPv4 прокси-пул — это набор конкретных адресов. Каждый адрес имеет репутацию, историю, ASN. Хостер даёт вам /29 — восемь адресов, и вы их крутите. Когда адрес попадает в бан-листы, приходится покупать новый.

IPv6 даёт другую модель. Вы получаете префикс /64 и генерируете адреса по своему усмотрению. Хостеры часто выдают /48 — это 65 536 подсетей, каждая по 18 квинтиллионов адресов. Технически можно каждый запрос делать с нового IP.

Но есть нюанс. Многие сайты до сих пор плохо работают с IPv6. LinkedIn поддерживает IPv6 на уровне CDN, но детект-системы могут помечать "слишком новый" адрес как подозрительный. Адрес, который никогда не встречался в логах, выглядит необычно.

Как LinkedIn палит автоматизацию

Антифрод LinkedIn работает на нескольких уровнях. Первый — network layer. Проверяется ASN, репутация диапазона, наличие в спам-базах. Второй — device fingerprint. Canvas, WebGL, шрифты, разрешение экрана. Третий — поведенческий: скорость действий, паттерны кликов, время между приглашениями.

С IPv6 есть специфика. Если вы генерируете адреса из одного /64, LinkedIn может увидеть, что все запросы идут из одной подсети. Это не блокировка, но флаг. Особенно если адреса меняются слишком часто — например, каждые 5 секунд.

Нормальное поведение пользователя: один IP на сессию, меняется раз в сутки или при переподключении. Если IP меняется на каждом запросе, это палево.

Ротация IPv6: как это устроено технически

Прокси-сервер на IPv6 получает префикс. Клиент подключается к прокси, а прокси выбирает исходящий адрес из пула. В простейшем случае — round-robin по списку адресов.

Вот пример на Python, который генерирует адреса из /64 и делает запросы через SOCKS5:

```python

import random

import socket

import socks

def random_ipv6_from_prefix(prefix):

prefix like "2001:db8:1234:5678"

suffix = ":".join(f"{random.randint(0, 0xffff):x}" for _ in range(4))

return f"{prefix}:{suffix}"

def request_via_proxy(url, proxy_host, proxy_port, prefix):

ip = random_ipv6_from_prefix(prefix)

s = socks.socksocket()

s.set_proxy(socks.SOCKS5, proxy_host, proxy_port)

s.bind((ip, 0))

s.connect(("www.linkedin.com", 443))

s.send(b"GET / HTTP/1.1\r\nHost: www.linkedin.com\r\n\r\n")

return s.recv(4096)

```

Ключевой момент — `bind`. SOCKS5 позволяет указать исходящий адрес. Прокси-сервер должен поддерживать это. Не все реализации умеют.

На стороне сервера (например, 3proxy или Dante) настраивается пул. В 3proxy это делается через `external` директиву:

```

external 2001:db8:1234:5678::1

external 2001:db8:1234:5678::2

external 2001:db8:1234:5678::3

```

Но вручную прописывать тысячи адресов — бред. Нужен скрипт или динамическая генерация.

Проблема "свежих" IPv6 адресов

IPv6-адрес, который никогда не использовался, выглядит для антифрода странно. В IPv4 все адреса давно распределены, у каждого есть история. В IPv6 огромное пространство, и большинство адресов просто не встречается в трафике.

LinkedIn (и другие сервисы) могут проверять: был ли этот адрес замечен в легитимном трафике? Если нет — флаг. Это не бан, но дополнительная проверка.

Решение — прогревать адреса. Использовать их для обычного браузинга, лайков, просмотров. Не для массовых действий. Через несколько дней адрес набирает "историю".

Тайминги и лимиты приглашений

LinkedIn не публикует точные лимиты, но эмпирически: 100-150 приглашений в неделю для обычного аккаунта. Для новых — 20-50. Превышение ведёт к ограничению.

Если вы делаете 50 приглашений за час с одного IP — это триггер. Даже если IP чистый. Нормальный человек не отправляет 50 приглашений за час. Он делает это в течение дня, с паузами.

С IPv6-ротацией возникает соблазн: менять IP на каждом приглашении. Это хуже, чем один стабильный IP. Потому что паттерн "новый IP на каждое действие" — явный признак бота.

Правильная стратегия: один IP на сессию. Сессия — 2-4 часа. Внутри сессии — 10-20 действий с рандомными паузами 30-180 секунд.

Практическая схема ротации

Вот рабочий подход. Есть пул /64 префиксов. Каждый префикс — отдельная "личность". Внутри префикса выбирается один адрес на сессию.

```bash

!/bin/bash

PREFIXES=(

"2001:db8:1::"

"2001:db8:2::"

"2001:db8:3::"

)

for p in "\${PREFIXES[@]}"; do

ip="\${p}\$(printf '%x' \$((RANDOM % 65536)))"

echo "Using \$ip"

curl -6 --interface "\$ip" -s -o /dev/null -w "%{http_code}\n" https://www.linkedin.com

sleep \$((RANDOM % 120 + 60))

done

```

Здесь `--interface` заставляет curl использовать конкретный IPv6-адрес. Это работает, если адрес уже назначен на интерфейс. Если нет — нужно добавлять через `ip -6 addr add`.

Кейс: 500 приглашений за неделю без бана

Пример: аккаунт LinkedIn, возраст 8 месяцев, 1200 контактов. Задача — отправить 500 приглашений за 7 дней.

Настройка: 10 /64 префиксов от хостера в Нидерландах. ASN — не датацентровый, а residential-провайдер. Это важно. Датацентровые ASN у LinkedIn в чёрном списке.

Каждый префикс использовался 2-3 дня. Внутри дня — 3-4 сессии по 2 часа. За сессию — 15-20 приглашений. Паузы рандомные, 45-240 секунд. Между сессиями — минимум 4 часа.

Результат: 500 приглашений, 0 капч, 0 блокировок. Acceptance rate — 22%. Это нормально для B2B.

Что было бы при использовании одного IP: скорее всего, бан на 3-й день. Или теневой бан — приглашения уходят, но не доставляются.

Кейс: почему датацентровый IPv6 не работает

Другой пример. Тот же аккаунт, но прокси на Hetzner. IPv6 /64, ротация каждые 30 минут.

Первый день: 40 приглашений, всё ок. Второй день: 30 приглашений, две капчи. Третий день: аккаунт ограничен, требуется верификация по документу.

Причина: Hetzner — датацентр. ASN 24940. LinkedIn знает, что с этого ASN идёт много автоматизации. Даже чистый IPv6-адрес из этого диапазона получает минус к репутации.

Вывод: ASN важнее, чем сам адрес. Residential IPv6 или small ISP — то, что нужно. Датацентры — нет.

Кейс: TLS-фингерпринт и IPv6

Третий пример. Всё настроено правильно: residential IPv6, ротация по сессиям, паузы. Но LinkedIn всё равно палит.

Причина оказалась в TLS. Python `requests` использует OpenSSL с определённым набором шифров. Этот набор отличается от того, что использует Chrome. LinkedIn (через Cloudflare) проверяет JA3-фингерпринт.

Решение: использовать `curl_cffi` или аналоги, которые имитируют TLS Chrome. После замены библиотеки — проблема ушла.

```python

from curl_cffi import requests

r = requests.get(

"https://www.linkedin.com/feed/",

impersonate="chrome120",

proxies={"https": "socks5://[2001:db8::1]:1080"}

)

```

Здесь `impersonate` подменяет TLS-фингерпринт. Прокси указывается с IPv6 в квадратных скобках.

Мониторинг и что смотреть

Без мониторинга вы не узнаете, что аккаунт в теневом бане. Приглашения уходят, но не доставляются. Или доставляются, но не показываются в поиске.

Что проверять:

- HTTP-коды ответов. 429 — rate limit. 403 — блок.

- Наличие капчи в ответе. Ищите `captcha` в HTML.

- Скорость ответа. Если сервер отвечает за 200 мс вместо 800 — возможно, вы уже на другом endpoint (заглушка).

- Acceptance rate. Если резко упал — аккаунт под фильтром.

Логировать всё. IP, время, действие, ответ. Потом анализировать.

Инфраструктура: где брать IPv6

Не каждый хостер даёт IPv6. И ещё меньше — residential IPv6. Варианты:

| Провайдер | Тип | IPv6 | ASN тип |

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

| Hetzner | VPS | /64 | Датацентр |

| OVH | VPS | /64 | Датацентр |

| Vultr | VPS | /64 | Датацентр |

| Residential proxies | Пул | /128 | Residential |

| Small ISP | VPS | /48 | ISP |

Датацентровые IPv6 дешёвые, но палевные. Residential — дорого, но работает. Компромисс — small ISP, которые не помечены как датацентр.

На практике для LinkedIn лучше residential. Датацентр — только если аккаунт старый и прогретый.

Итог

IPv6 даёт гибкость, которой нет в IPv4. Но гибкость — не панацея. LinkedIn смотрит на ASN, TLS, поведение, тайминги. IP — только один из факторов.

Схема, которая работает: residential IPv6, ротация по сессиям, паузы, имитация TLS браузера, мониторинг. Без любого из этих элементов — бан рано или поздно.

И да, не забывайте: LinkedIn обновляет детект постоянно. То, что работало полгода назад, сегодня может не работать. Тестируйте на мелких аккаунтах, прежде чем гнать объём.