Netflix через IPv6 прокси: обход геоблокировок и выбор региона

Netflix определяет регион по IP-адресу клиента. Точка. Если вы выходите с российского адреса — получите каталог РФ, где половины сериалов нет. Если с американского — полный набор, но с ограничениями по аккаунту. IPv6 тут интересен тем, что пул адресов огромен, а многие провайдеры и CDN-прослойки относятся к нему менее строго, чем к IPv4. Но не всё так радужно, как обещают продавцы «вечных прокси».

Разберём, как это работает на уровне протокола, где Netflix палит подмену, и как выбрать регион так, чтобы не словить блок через неделю.

Как Netflix вообще определяет регион

Netflix использует несколько слоёв геолокации. Первый — IP-адрес клиента, по нему строится первичная привязка к стране. Второй — DNS-резолвинг: если запросы уходят на публичный DNS (8.8.8.8, 1.1.1.1), Netflix видит, откуда пришёл запрос к его CDN, и сверяет с IP. Третий — данные аккаунта: страна регистрации, история платежей, язык интерфейса.

IPv6 добавляет нюанс. Многие CDN (в том числе Open Connect, собственная сеть Netflix) поддерживают IPv6-доставку контента. Когда клиент подключается по IPv6, Netflix видит префикс /64 или /48 и определяет регион по базе RIR (ARIN, RIPE, APNIC). Если префикс принадлежит европейскому провайдеру — вы «в Европе», независимо от того, где физически стоит сервер.

Проблема в том, что базы геолокации IPv6 обновляются медленнее, чем IPv4. Свежевыделенный блок может числиться в стране регистрации RIR, а не там, где реально используется. Это иногда играет на руку, иногда бьёт по рукам.

Почему IPv6, а не IPv4

IPv4-адреса дорогие и «выжженные». Большинство датацентровых диапазонов давно в чёрных списках стримингов. IPv6-блоки дешевле, их больше, и они менее засвечены. Провайдер может выдать вам /64 — это 18 квинтиллионов адресов, из которых вы используете десяток.

Второй плюс — маршрутизация. IPv6 идёт напрямую, без NAT, без CGNAT-прослоек, которые часто ломают геолокацию. Пакет от клиента до сервера проходит меньше хопов, меньше шансов, что промежуточный узел подменит заголовки или сломает TLS-сессию.

Минус — не все клиенты поддерживают IPv6. Если ваш роутер или провайдер дома не умеет в IPv6, придётся строить туннель (6to4, Teredo, или просто IPv4-прокси до IPv6-выхода). Это добавляет задержку и точки отказа. Замерял: туннель через HE.net добавляет 15-40 мс в зависимости от маршрута.

Схема работы: клиент → прокси → Netflix

Классическая схема: ваш браузер или Smart TV отправляет запрос на прокси-сервер, тот подставляет свой IPv6-адрес и форвардит трафик к Netflix. Обратно — та же дорога. Netflix видит только адрес прокси.

Важно, чтобы прокси не просто форвардил TCP, а корректно обрабатывал TLS SNI и заголовки. Netflix использует HTTPS с жёсткой проверкой сертификатов, MITM не пройдёт. Прокси должен работать на уровне L4 (TCP-проксирование) или L7 с прозрачным пробросом.

Вот минимальный рабочий пример на Python с использованием `asyncio` и `socks` — TCP-форвардер, который слушает на IPv4 и выходит через IPv6:

```python

import asyncio

async def pipe(reader, writer):

try:

while data := await reader.read(65536):

writer.write(data)

await writer.drain()

except Exception:

pass

finally:

writer.close()

async def handle(local_reader, local_writer):

remote_reader, remote_writer = await asyncio.open_connection(

host="2606:4700:4700::1111",

port=443,

family=2 # AF_INET6

)

await asyncio.gather(

pipe(local_reader, remote_writer),

pipe(remote_reader, local_writer)

)

async def main():

server = await asyncio.start_server(handle, "0.0.0.0", 8080)

async with server:

await server.serve_forever()

asyncio.run(main())

```

Это скелет. В реальности нужен SNI-роутинг, чтобы разные домены Netflix шли через разные выходные адреса. Иначе получите ситуацию, когда `www.netflix.com` резолвится в один регион, а `ipv4-c001-ams001-ix.1.oca.nflxvideo.net` — в другой, и плеер падает с ошибкой M7111.

Выбор региона: что реально работает

Не все регионы одинаково полезны. США — самый большой каталог, но и самая агрессивная антифрод-система. Европа (UK, DE, NL) — компромисс: каталог приличный, проверки мягче. Япония и Корея — уникальный контент, но почти все датацентровые IPv6-блоки там в чёрных списках.

| Регион | Размер каталога (тайтлов) | Строгость проверки | Доступность IPv6-прокси |

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

| США | ~6000 | Высокая | Средняя |

| Великобритания | ~4000 | Средняя | Высокая |

| Германия | ~3800 | Средняя | Высокая |

| Нидерланды | ~3700 | Низкая | Высокая |

| Япония | ~5000 | Высокая | Низкая |

Цифры приблизительные, каталог меняется каждую неделю. Но соотношение «размер/строгость» стабильно: чем больше каталог, тем пристальнее следят.

Практический совет: не гонитесь за США сразу. Начните с Нидерландов или Германии — там проще пройти первичную проверку, а потом, если аккаунт «прижился», можно пробовать переключаться. Резкая смена региона с US на JP за один день — почти гарантированный флаг.

Как Netflix палит прокси

Первое — ASN. Если ваш IPv6-адрес принадлежит хостинг-провайдеру (Hetzner, DigitalOcean, OVH), Netflix это видит. Датацентровые ASN в приоритетных чёрных списках. Второе — поведение: одновременные запросы из разных регионов, нетипичное время активности, отсутствие истории просмотров.

Третье — DNS-утечки. Если клиент резолвит домены Netflix через локальный DNS провайдера, а трафик идёт через прокси — несовпадение. Netflix сверяет IP-адрес DNS-резолвера с IP клиента. Расхождение = флаг.

Четвёртое — WebRTC. Браузер может слить реальный IP через WebRTC-запросы, даже если весь HTTP-трафик идёт через прокси. На Smart TV этой проблемы нет, на десктопе — есть. Отключайте WebRTC или используйте браузер, который его не поддерживает.

Проверка прокси перед подключением

Прежде чем совать адрес в Netflix, проверьте его. Простой curl-запрос покажет, какой IP видит внешний мир и как он геолоцируется:

```bash

curl -6 --proxy "http://[2001:db8::1]:8080" \

-s https://ipinfo.io/json | jq '{ip, city, country, org}'

```

Ответ должен показать IPv6-адрес, страну, совпадающую с желаемым регионом, и организацию, которая не выглядит как «Hetzner Online GmbH». Если видите хостинг — прокси, скорее всего, уже в чёрном списке.

Второй тест — проверка DNS-резолвинга через тот же прокси:

```bash

curl -6 --proxy "http://[2001:db8::1]:8080" \

-s "https://1.1.1.1/dns-query?name=www.netflix.com&type=A" \

-H "accept: application/dns-json" | jq '.Answer'

```

Если DNS-запрос уходит через прокси и возвращает IP из нужного региона — хорошо. Если резолв идёт напрямую с вашего адреса — Netflix увидит расхождение.

Кейс: нидерландский /64 и ошибка M7111

Сервер на Debian 12, провайдер выдал /64 из блока, зарегистрированного на RIPE как NL. Прокси настроен на выход через `2001:db8:abcd::1`. Netflix открывается, каталог нидерландский, но при запуске любого тайтла — ошибка M7111 «проблема с подключением к потоковому серверу».

Причина: `www.netflix.com` резолвился в европейский CDN, а `nflxvideo.net` — в американский, потому что DNS-запросы уходили через локальный резолвер провайдера, а не через прокси. Плеер получал манифест с одного континента, а видео-сегменты — с другого. Таймаут 8 секунд, соединение рвалось.

Решение: настроить DNS-over-HTTPS через тот же прокси, принудительно указать резолвер Cloudflare с EDNS Client Subnet, отключённым для запросов Netflix. После этого оба домена резолвились в один регион, ошибка ушла. Задержка выросла на 12 мс, но стабильность важнее.

Кейс: ротация адресов внутри /64

Аккаунт работал через `2001:db8:abcd::1` три недели. Потом Netflix начал показывать заглушку «This title is not available in your region» на части контента. Не полный бан, но половина каталога пропала.

Причина: Netflix помечает не отдельный адрес, а префикс /64. Если кто-то ещё из этого блока использовал адреса для обхода — весь /64 попал под подозрение. Проверка показала: соседний адрес `2001:db8:abcd::42` фигурировал в публичных списках «Netflix proxy» на GitHub.

Решение: переехать на другой /64 из того же /48. Адрес `2001:db8:abce::1` — чистый, каталог вернулся. Вывод: не используйте первый адрес из блока, если блок свежий и может быть засвечен. Берите адрес с середины диапазона, например `::a1b2`, чтобы снизить шанс пересечения с чужими настройками.

Кейс: Smart TV и отсутствие IPv6

Телевизор LG C2, приложение Netflix. Роутер раздаёт IPv4 через NAT, IPv6 не настроен. Прокси на IPv6-адресе недоступен напрямую. Пришлось строить мост: локальный прокси на Raspberry Pi, который принимает IPv4-трафик от телевизора и форвардит через IPv6-туннель.

Настройка через `socat`:

```bash

socat TCP4-LISTEN:8080,fork,reuseaddr \

TCP6:[2001:db8:abce::a1b2]:8080

```

Задержка выросла: базовый RTT до прокси 28 мс, через мост — 41 мс. Netflix это стерпел, буферизация не появлялась при битрейте 15 Мбит/с. Но при 4K (25 Мбит/с) начались подгрузки. Пришлось поднять MTU на туннеле до 1480, чтобы избежать фрагментации. По умолчанию было 1280 — мало для 4K-потока.

Регион и язык интерфейса

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

Субтитры и аудиодорожки зависят от тайтла, не от региона. Американский каталог может содержать тайтл с русскими субтитрами, если они есть в глобальной базе. Но не все — часть контента локализована только для конкретных рынков.

Проверить доступные дорожки можно через API, но проще открыть тайтл и посмотреть в настройках плеера. Если нужной дорожки нет — значит, она не лицензирована для этого региона, и никакой прокси не поможет.

Ограничения и риски

Netflix активно борется с обходом. Каждые несколько месяцев обновляются чёрные списки, меняются алгоритмы детекции. То, что работало в январе, может отвалиться в марте. Прокси-провайдеры обновляют пулы, но гонка не прекращается.

Аккаунт могут заблокировать за нарушение ToS. Netflix формально запрещает использование VPN и прокси для доступа к контенту других регионов. На практике баны редки, но случаются — особенно при агрессивной смене регионов или использовании явно «палённых» адресов.

IPv6-прокси от lexic.ml работают с 2015 года, и за это время пулы неоднократно чистились от засвеченных блоков. Это не гарантия вечной работы, но снижает шанс попасть на адрес, который уже спалили до вас. Главное — не гнаться за халявой и проверять адрес перед использованием.

Что в итоге

IPv6-прокси для Netflix — рабочий инструмент, но не волшебная кнопка. Нужно понимать, как Netflix определяет регион, проверять ASN и DNS-резолвинг, не светить реальный IP через WebRTC, аккуратно менять регионы. Ошибки вроде M7111 почти всегда связаны с рассинхроном DNS, а не с блокировкой прокси.

Начните с европейских регионов, проверьте адрес через `ipinfo.io`, настройте DNS-over-HTTPS через тот же прокси, и только потом лезьте в США. И держите запасной /64 — пригодится, когда текущий засветится.