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

Как LinkedIn детектит автоматизацию

LinkedIn не блокирует за «прокси». Он блокирует за поведение. Прокси — лишь один из сигналов в общей картине. Если ты шлёшь 200 приглашений в час с одного /64, тебя спалят независимо от того, IPv6 это или IPv4. Логика простая: живые люди не работают как бот.

Система anti-abuse LinkedIn (внутреннее название не публикуется, но механика известна по утечкам и патентам) собирает десятки метрик. Скорость действий. Время между кликами. Паттерны навигации. Соотношение просмотров профиля к отправленным инвайтам. Device fingerprint. TLS fingerprint. И да — IP-адрес с его репутацией.

IPv6 тут даёт одно ключевое преимущество: огромное адресное пространство. Один провайдер может выдать тебе /64 — это 18 квинтиллионов адресов. Но не спеши радоваться. LinkedIn не идиоты.

Почему IPv6-пулы работают иначе

У IPv4-прокси пул ограничен. 256 адресов в /24, 65 536 в /16. Провайдеры IPv4-прокси перепродают одни и те же адреса, и они быстро попадают в бан-листы. Репутация IP в IPv4-мире — товар. Чистый /24 стоит денег.

IPv6 устроен иначе. Дата-центры получают /48 или /64 от региональных интернет-регистраторов (RIPE, ARIN, APNIC). Внутри /64 можно генерировать миллиарды адресов. Формально каждый адрес уникален. На практике — subnet reputation. LinkedIn (и Cloudflare, который стоит перед ним) оценивает не только конкретный /128, но и весь /64 или /48.

Вот тут начинается самое интересное. Если ты крутишь 500 сессий с одного /64, Cloudflare видит 500 разных IP, но с одинаковым префиксом. Это подозрительно. Грамотный пул разбивает адреса по множеству /64 из разных /48.

```bash

Генерация адресов из /64 подсети

Допустим, провайдер выдал 2001:db8:abcd::/64

python3 -c "

import ipaddress

net = ipaddress.ip_network('2001:db8:abcd::/64')

for i, addr in enumerate(net.hosts()):

if i >= 10: break

print(addr)

"

```

Этот код выдаст первые 10 адресов. Для реальной работы нужен пул из сотен /64, а не из одной подсети.

Настройка прокси-сервера на IPv6

Squid и 3proxy — два рабочих варианта. Squid тяжелее, но стабильнее под нагрузкой. 3proxy легче, проще в конфиге. Для LinkedIn-автоматизации хватит 3proxy.

Конфиг 3proxy с IPv6-аутентификацией:

```

daemon

maxconn 200

nserver 2001:4860:4860::8888

nserver 2001:4860:4860::8844

nscache 65536

timeouts 1 5 30 60 180 1800 15 60

auth strong

users user1:CL:password1

allow user1

proxy -6 -n -a -p3128 -i2001:db8:abcd::1 -e2001:db8:abcd::1

flush

```

Флаг `-6` включает IPv6. `-i` — внутренний адрес, `-e` — внешний. Каждый пользователь привязывается к своему /128. Порт 3128 — стандартный для SOCKS5.

Проверка:

```bash

curl -x socks5h://user1:password1@[2001:db8:abcd::1]:3128 \

-s https://api.ipify.org?format=json

```

Ответ должен показать именно тот IPv6, который ты прописал. Если видишь IPv4 — значит, трафик утекает через основной интерфейс. Проверь `ip -6 route` и убедись, что маршрут по умолчанию идёт через нужный шлюз.

Ротация адресов и привязка к сессиям

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

Схема такая: один аккаунт = один IPv6 = одна cookie-сессия. Пока аккаунт жив, адрес не меняется. Если адрес сгорел (LinkedIn начал показывать капчу), меняешь и адрес, и сессию, и fingerprint браузера.

Привязка в Python через requests:

```python

import requests

PROXY = "socks5h://user1:password1@[2001:db8:abcd::1]:3128"

HEADERS = {

"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "

"AppleWebKit/537.36 (KHTML, like Gecko) "

"Chrome/120.0.0.0 Safari/537.36",

"Accept-Language": "en-US,en;q=0.9",

"Accept-Encoding": "gzip, deflate, br",

}

session = requests.Session()

session.proxies = {"http": PROXY, "https": PROXY}

session.headers.update(HEADERS)

r = session.get("https://www.linkedin.com/feed/", timeout=30)

print(r.status_code, len(r.text))

```

Обрати внимание на `socks5h` — буква `h` означает, что DNS-резолвинг идёт через прокси. Без неё запросы к DNS уходят с твоего реального IP. Утечка.

Лимиты, которые нельзя превышать

LinkedIn официально не публикует лимиты. Но эмпирически (данные собраны сообществом автоматизаторов за 2022–2024) картина такая:

| Действие | Безопасный лимит/день | Опасная зона |

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

| Приглашения | 20–30 | 80+ |

| Просмотры профилей | 80–100 | 300+ |

| Сообщения | 30–50 | 150+ |

| Посты/комментарии | 5–10 | 30+ |

Новые аккаунты (младше 30 дней) — лимиты в 3–5 раз ниже. Прогрев обязателен. Первую неделю — только просмотры и лайки. Вторую — добавление в контакты по 5–10 в день. Третью — 15–20. И только потом выходишь на рабочий режим.

Задержки между действиями — рандомные. Не 30 секунд ровно, а 18–47. Не 5 минут, а 3–11. Детерминированные интервалы палятся моментально.

```python

import random, time

def human_delay(base=25, spread=20):

delay = base + random.uniform(-spread, spread)

time.sleep(max(3, delay))

for _ in range(5):

... действие ...

human_delay(base=40, spread=25)

```

TLS fingerprint и почему одного IPv6 мало

Cloudflare (стоит перед LinkedIn) смотрит на JA3/JA4 fingerprint. Это хеш от параметров TLS ClientHello: версии, cipher suites, extensions, elliptic curves. У Python requests — один fingerprint. У Chrome 120 — другой. У curl — третий.

Если ты шлёшь запросы с IPv6-прокси, но с TLS-отпечатком Python requests — тебя вычислят. Потому что живой пользователь LinkedIn сидит в браузере, а не в скрипте.

Решение — либо использовать реальный браузер через Playwright/Selenium, либо подделывать TLS через curl_cffi или tls-client.

```python

from curl_cffi import requests as curl_requests

session = curl_requests.Session(impersonate="chrome120")

session.proxies = {

"https": "socks5h://user1:password1@[2001:db8:abcd::1]:3128"

}

r = session.get("https://www.linkedin.com/feed/")

print(r.status_code)

```

`impersonate="chrome120"` подставляет TLS-отпечаток реального Chrome 120. Вместе с IPv6-прокси это даёт связку, которую Cloudflare пропускает без капчи в большинстве случаев.

Прогрев IPv6-подсетей

Свежая /64 от хостера не имеет репутации. Cloudflare ставит таким подсетям нейтральный или слегка негативный скор. Если сразу начать долбить LinkedIn — капча с первого запроса.

Прогрев: пускаешь трафик на нейтральные сайты. Google, Wikipedia, GitHub, Stack Overflow. 50–100 запросов в день с каждого адреса в течение недели. Это создаёт историю. Не гарантия, но снижает шанс мгновенного бана.

Хостеры вроде Hetzner, OVH, DigitalOcean имеют разные диапазоны. Hetzner — один из самых засвеченных (много абьюза), его /16 часто в чёрных списках. Мелкие хостеры и региональные LIR — чище, но дороже и сложнее в получении.

Что делать, когда аккаунт ловит капчу

Капча — не бан. Это предупреждение. Первое появление — стоп на 48 часов. Никаких действий с аккаунта. Меняешь IP (новый /64), чистишь cookies, меняешь User-Agent на другую версию. Через двое суток — пробный заход: один просмотр профиля, проверка ленты. Если капчи нет — ещё день паузы. Потом медленный возврат к активности с половиной лимитов.

Если капча повторяется три раза подряд — аккаунт, скорее всего, под усиленным наблюдением. Дальнейшая работа с него бессмысленна. Либо забрасываешь на месяц, либо списываешь.

Restricted (ограничение) — хуже. Это уже бан с возможностью апелляции. Обычно прилетает за массовые приглашения без ответов. LinkedIn считает acceptance rate. Если из 100 инвайтов приняли 2 — это плохой сигнал. Норма — 20–40% для целевой аудитории.

Инфраструктура: сколько это стоит

Один IPv6-прокси на VPS с /64 от нормального хостера — \$5–15/мес. Пул из 10 /64 с разных /48 — \$50–150/мес. Плюс прокси-менеджер (если свой — бесплатно, если готовый — \$30–100/мес). Плюс антидетект-браузер, если работаешь через него — \$50–200/мес за 10–50 профилей.

Сервис lexic.ml даёт IPv6-прокси с 2015 года — за это время они накопили пулы подсетей с разной репутацией. Для LinkedIn-задач важна не столько цена, сколько разнообразие /48-префиксов. Один /48 с 65 536 /64 внутри — это уже серьёзный пул для ротации.

Считай экономику. 10 аккаунтов LinkedIn, каждый шлёт 25 инвайтов в день = 250 приглашений. При конверсии 25% — 62 новых контакта ежедневно. Если это B2B-продажи со средним чеком \$500 — математика сходится быстро. Но только если аккаунты живут месяцами, а не сгорают за неделю.

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

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

- IPv6-адрес не из засвеченного /48 (проверь через ipqualityscore или аналоги)

- DNS-резолвинг идёт через прокси (`socks5h`, не `socks5`)

- TLS-отпечаток совпадает с заявленным User-Agent

- Часовой пояс браузера совпадает с геолокацией IP

- Cookies и localStorage чистые для нового аккаунта

- Лимиты не превышены (см. таблицу выше)

- Задержки рандомизированы

- Прогрев подсети проведён (минимум 5–7 дней)

Автоматизация LinkedIn через IPv6 — рабочая схема. Но это не «включил прокси и погнал». Это дисциплина, мониторинг и готовность терять аккаунты. Кто обещает 100% выживаемость — врёт. Реальная цифра при аккуратной работе — 70–85% аккаунтов живут больше трёх месяцев.