Netflix через IPv6 прокси: обход геоблокировок и выбор региона
Содержание
Почему Netflix и IPv6 — это отдельная история
Netflix определяет регион по IP-адресу. Логика простая: зашёл с российского IP — получил российскую библиотеку, зашёл с американского — американскую. IPv6 здесь не исключение, но есть нюансы. Многие прокси-сервисы исторически работали только через IPv4, а IPv6 либо не поддерживали, либо отдавали через туннель, который Netflix палит за секунды.
С IPv6 всё интереснее. Адресное пространство огромное — 2^128 против 2^32. Провайдеры выдают /64 или /56 префиксы, и внутри одного префикса можно гонять тысячи адресов. Netflix это знает и внимательно смотрит на ASN, на диапазон, на поведение. Если с одного /64 прилетает 500 запросов в минуту с разных адресов — это красный флаг.
Прокси на IPv6 работает иначе, чем IPv4-прокси. Тут нет NAT в привычном смысле. Каждый клиент может получить свой уникальный адрес из пула. Это и плюс, и минус одновременно.
Как Netflix детектит прокси
Netflix не дурак. У них своя система антифрода, плюс они покупают данные у MaxMind, IP2Location и подобных. Основные сигналы:
Первый — репутация ASN. Если IP принадлежит хостинг-провайдеру (DigitalOcean, Hetzner, OVH), а не residential-оператору, это уже подозрительно. Netflix знает диапазоны всех крупных хостеров.
Второй — поведенческий анализ. Сколько устройств сидит на одном IP, как часто меняется геолокация, какие заголовки приходят. Если с одного адреса одновременно смотрят из Токио и из Берлина — бан.
Третий — DNS и WebRTC утечки. Браузер может слить реальный IP через WebRTC, даже если трафик идёт через прокси. Netflix это использует.
Четвёртый — TLS fingerprint. JA3-хеш клиента. Если у вас Python-скрипт с requests, а заявляетесь как Chrome — несоответствие.
IPv6-прокси: чем отличается от IPv4
Главное отличие — размер пула. У IPv4-прокси обычно 10-100 адресов на сервер. У IPv6 — тысячи. Это позволяет ротировать адреса агрессивнее, но и палиться легче, если ротация тупая.
Второе — геолокация. IPv6-адреса хуже покрыты в базах геолокации. Иногда Netflix видит IPv6-адрес и не может определить страну точно — тогда он падает на IPv4 или на дефолт. Это можно использовать.
Третье — маршрутизация. IPv6 часто идёт через другие точки обмена, latency может быть выше или ниже. Зависит от провайдера.
Вот пример проверки, какой регион видит Netflix через конкретный IPv6:
```bash
curl -6 -s --interface 2001:db8::1 \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
https://www.netflix.com/title/80057281 \
-o /dev/null -w "%{http_code} %{redirect_url}\n"
```
Если редирект ведёт на `/ru/` — вы в российской библиотеке. Если на `/title/` без редиректа — контент доступен.
Выбор региона: что реально работает
Не все регионы одинаково полезны. Японская библиотека — аниме, которой нет больше нигде. Американская — самый большой каталог, около 6000 тайтлов. Британская — своя специфика, BBC-контент. Турецкая — дешёвая подписка, но каталог маленький.
Для IPv6-прокси лучше всего работают регионы с хорошим IPv6-покрытием: США, Германия, Нидерланды, Япония. Хуже — страны, где IPv6 внедрён частично: Индия, Бразилия, часть Юго-Восточной Азии.
Ключевой момент — Netflix сравнивает IPv4 и IPv6. Если вы зашли по IPv6 из США, а IPv4 у вас российский, будет несоответствие. Нужно, чтобы оба стека указывали на один регион. Или отключать IPv4 полностью через `Happy Eyeballs` timeout.
Настройка прокси на IPv6
Классическая схема — SOCKS5 или HTTP-прокси с IPv6-адресом. Но есть нюансы с DNS. Если резолвить `netflix.com` через локальный DNS, Netflix увидит запрос с вашего реального IP.
Вот рабочий конфиг для `dante-server` (SOCKS5 с IPv6):
```
logoutput: syslog
internal: 2001:db8::1 port = 1080
external: 2001:db8::1
socksmethod: username
user.privileged: root
user.notprivileged: nobody
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: error
}
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: connect
protocol: tcp udp
}
```
Важно: `internal` и `external` — оба IPv6. Если поставить IPv4 internal, часть трафика пойдёт напрямую.
Для проверки, что всё работает, используем Python:
```python
import socket
import socks
import requests
socks.set_default_proxy(socks.SOCKS5, "2001:db8::1", 1080,
username="user", password="pass")
socket.socket = socks.socksocket
r = requests.get("https://www.netflix.com/title/80057281",
headers={"User-Agent": "Mozilla/5.0"})
print(r.status_code, r.url)
```
Если `r.url` содержит `/ru-ru/` — прокси не работает или регион не тот.
Ротация адресов и что ломается
Ротация IPv6-адресов — палка о двух концах. Netflix запоминает сессию. Если в середине просмотра фильма IP меняется, сессия рвётся. Плеер выдаёт ошибку `M7111-1331` или просто зависает на 25%.
Правильная ротация — только между сессиями, не внутри. И не чаще, чем раз в несколько часов. Netflix считает аномалией, если один аккаунт за час сменил 10 регионов.
Второй момент — cookie и fingerprint. Netflix ставит `NetflixId` и `SecureNetflixId` куки. Они привязаны к региону. Если вы переключились с US на JP, куки надо чистить, иначе редирект будет странным.
Вот как выглядит проверка консистентности:
```bash
for i in 1 2 3; do
curl -6 -s --interface 2001:db8::\$i \
-c /tmp/nf_\$i.txt -b /tmp/nf_\$i.txt \
-H "Accept-Language: en-US,en;q=0.9" \
https://www.netflix.com/browse \
-o /dev/null -w "IP \$i: %{http_code} %{time_total}s\n"
done
```
Если коды разные — ротация ломает сессию.
Реальные грабли
Пример: сервер на Hetzner с /64 префиксом, 200 IPv6-адресов, SOCKS5 на dante. Netflix отдавал US-каталог первые 2 дня. На третий — начал показывать `Not available in your region` для половины тайтлов. Причина: Hetzner ASN попал в расширенный бан-лист после массовых регистраций. Решение — переезд на residential IPv6 через туннель, latency выросла с 12 мс до 45 мс, но каталог вернулся.
Второй пример: клиент использовал IPv6-прокси в Нидерландах, но DNS-резолвинг шёл через Google DNS (8.8.8.8) по IPv4. Netflix видел запросы к `nflxvideo.net` с российского IPv4 и блокировал CDN. Решение — форсировать DNS через прокси, использовать `dnsmasq` с `server=` на IPv6-резолвер провайдера.
Третий: TLS fingerprint. Python `requests` даёт JA3-хеш, который Netflix отличает от браузерного. Даже с идеальным IPv6 — бан через 5 минут. Решение — `curl_cffi` с импersonation Chrome 120.
Сравнение подходов
| Метод | Скорость | Детект | Стоимость |
|-------|----------|--------|-----------|
| Residential IPv4 | 20-40 мс | Низкий | \$3-15/GB |
| Datacenter IPv4 | 5-15 мс | Высокий | \$0.5-2/IP |
| Datacenter IPv6 | 5-20 мс | Средний | \$0.1-0.5/IP |
| Residential IPv6 | 30-60 мс | Низкий | \$1-5/GB |
| Мобильные IPv6 | 40-100 мс | Очень низкий | \$5-20/GB |
Цифры приблизительные, зависят от провайдера. Но тренд понятен: IPv6 дешевле, но детектится легче, если это datacenter.
Что делать с DNS
DNS — половина успеха. Netflix использует свои CDN (`nflxvideo.net`, `nflxso.net`). Если DNS-запрос уходит не через прокси, CDN отдаёт контент для вашего реального региона, и видео не играет.
Решение — `dnsmasq` с форвардом всех запросов через IPv6-резолвер:
```
no-resolv
server=2001:4860:4860::8888
server=2001:4860:4860::8844
cache-size=1000
```
Или через `unbound` с `forward-zone`. Главное — не использовать системный резолвер, который может уйти по IPv4.
Второй момент — EDNS Client Subnet. Некоторые резолверы передают ваш реальный подсеть в CDN. Это палево. Отключается флагом `edns-client-subnet: no` в unbound.
Автоматизация проверки
Держать прокси вручную — боль. Нужен скрипт, который проверяет каждый адрес раз в час. Вот минимальный вариант на Python:
```python
import asyncio
import aiohttp
async def check(ip):
connector = aiohttp.TCPConnector(local_addr=(ip, 0))
async with aiohttp.ClientSession(connector=connector) as s:
try:
async with s.get("https://www.netflix.com/title/80057281",
timeout=10,
allow_redirects=False) as r:
loc = r.headers.get("Location", "")
return ip, r.status, loc
except Exception as e:
return ip, 0, str(e)
async def main():
ips = [f"2001:db8::{i}" for i in range(1, 51)]
results = await asyncio.gather(*[check(ip) for ip in ips])
for ip, status, loc in results:
print(f"{ip}: {status} {loc}")
asyncio.run(main())
```
Скрипт покажет, какие адреса ещё в US-каталоге, а какие уже словили бан. Запускать по крону, банить мёртвые адреса.
Итог
IPv6-прокси для Netflix — рабочая схема, но требует внимания к деталям. Главное: консистентность IPv4/IPv6, правильный DNS, ротация между сессиями, а не внутри. Datacenter IPv6 дешевле, но детектится быстрее. Residential — дороже, но живёт дольше.
Сервисы вроде lexic.ml дают пул IPv6-адресов с ротацией, но даже с ними нужно следить за ASN и поведением. Netflix обновляет детект регулярно, так что разовая настройка не работает — нужен мониторинг и адаптация.
