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

Почему Discord ломается именно на голосовых

Текстовые каналы Discord живут на HTTPS и WebSocket через 443 порт. Голос — совсем другая история. Он идёт по UDP, чаще всего на порты 50000–65535, плюс сигнализация через WebSocket. Провайдеры и корпоративные фильтры часто режут именно UDP-диапазон, оставляя TCP нетронутым. Текст работает, голос — тишина. Классическая картина.

Второй момент: Discord использует STUN/TURN для NAT traversal. Если UDP зарезан, клиент не пробьёт дырку в NAT и уйдёт в релей через TCP-фолбэк. Иногда он работает, иногда нет — зависит от региона и от того, как именно фильтруют.

IPv6 здесь выигрывает по одной причине: адресное пространство. У вас не один адрес, а /64 или /48. Можно раскидать голосовые сессии по разным адресам, и фильтр, заточенный под конкретные IP, просто не успевает за вами.

Что реально блокируют

Разберём по слоям. На DNS-уровне режут `discord.gg`, `discordapp.com`, `discord.media`. Лечится своим резолвером или DoH. На уровне IP — блокируют подсети Cloudflare и Discord. Лечится прокси. На уровне DPI — смотрят на SNI в TLS-хендшейке и на паттерны UDP-пакетов. Вот тут начинается веселье.

Голос Discord шифруется, но паттерн трафика узнаваем: регулярные UDP-пакеты фиксированного размера, ~20ms интервал для Opus-фреймов. DPI-системы типа российских ТСПУ это ловят по энтропии и таймингу. IPv6-адрес тут не спасает сам по себе — спасает то, что трафик уходит на прокси, и наружу идёт уже другой поток.

Ещё один слой — RTP-заголовки. Discord использует свой протокол поверх UDP с собственным заголовком. Если фильтр обучен на сигнатурах, он сработает независимо от IP-версии.

Как IPv6-прокси обходит это

Схема простая. Клиент Discord на вашей машине думает, что говорит напрямую с голосовым сервером. На деле весь UDP-трафик заворачивается на прокси-сервер, у которого есть IPv6-адрес. Прокси переупаковывает пакеты и отправляет их с другого адреса.

Ключевая фишка — ротация адресов. У вас /64, это 2^64 адресов. Каждая новая голосовая сессия может идти с нового IPv6. Фильтр видит поток с адреса A, блокирует — следующая сессия уже с адреса B. Пока оператор обновит правила, вы уже на C.

Плюс IPv6-туннелирование часто игнорируется фильтрами. Многие DPI-системы настроены на IPv4-диапазоны, а IPv6 идёт в обход. Это не баг, это недоделка инфраструктуры, и ей пользуются.

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

Возьмём типичный VPS с IPv6 /64. Ставим UDP-релей. Вот минимальный конфиг на Python для теста — не продакшн, но показывает механику.

```python

import socket

import select

import os

LISTEN = ("::", 50000)

TARGET = ("2001:db8::1", 50000)

sock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)

sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

sock.bind(LISTEN)

clients = {}

while True:

r, _, _ = select.select([sock], [], [], 1.0)

if not r:

continue

data, addr = sock.recvfrom(65535)

if addr not in clients:

out = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)

out.bind(("2001:db8:1::" + format(os.getpid() % 65536, "x"), 0))

clients[addr] = out

clients[addr].sendto(data, TARGET)

```

Здесь каждый клиент получает свой исходящий сокет с уникальным IPv6. Это упрощённо, без обработки обратного трафика, но идея ясна. В продакшне такое делают через `socat` или `udp2raw`, но с поддержкой source address selection.

Для TCP-части (сигнализация) хватит обычного прокси. Discord-клиент умеет SOCKS5, но IPv6 через SOCKS5 работает не везде. Проверяйте.

Клиентская сторона: что подкрутить

Discord не имеет встроенной настройки UDP-прокси. Вообще. Это боль. Варианты: прозрачный редирект через iptables/nftables, либо сторонние обёртки.

Вот правило nftables, которое заворачивает весь UDP Discord на локальный прокси:

```

table ip6 discord_proxy {

chain output {

type nat hook output priority -100; policy accept;

ip6 daddr { 2606:4700::/32, 2001:db8::/32 } udp dport 50000-65535 \

redirect to :50000

}

}

```

Диапазоны надо подставить актуальные подсети Discord. Они меняются, так что раз в пару недель проверяйте через `dig`.

Для Linux-клиента ещё нужен `ip6tables` с `MASQUERADE` на исходящем интерфейсе, чтобы обратный трафик вернулся. На Windows всё сложнее — там WFP-фильтры, и без стороннего софта вроде `proxifier` не обойтись.

Кейс: офис в Москве, 40 человек

Корпоративная сеть, провайдер режет UDP выше 49152. Голос Discord не работает ни у кого, текст летает. Поставили IPv6-релей на VPS в Нидерландах, /64 от провайдера. Завернули UDP 50000–65535 через nftables на шлюзе. Задержка выросла с 15ms до 48ms — терпимо для голоса, Opus жрёт до 100ms джиттера без деградации.

Через неделю провайдер начал резать по IPv6 тоже. Добавили ротацию: каждые 5 минут новый исходящий адрес из /64. Проблема ушла. Потом ещё раз вернулась — уже по сигнатурам пакетов. Тут помог только полный туннель через WireGuard с обфускацией. IPv6-прокси — не панацея, это один слой.

Кейс: геймер в Казахстане

Один пользователь, домашний интернет, блокировка Discord на уровне DPI. Текст через VPN, голос — нет, потому что VPN гонит всё через TCP и задержка 200ms+. Поставил UDP-релей на IPv6-адрес, оставил текст напрямую. Голос пошёл через релей, ping 60ms до Франкфурта. Работает.

Через месяц провайдер начал throttle-ить IPv6-туннели. Скорость упала до 2 Mbit/s, голос захлёбывался. Решение — сменил протокол туннеля на UDP-based с обфускацией, трафик стал похож на обычный QUIC. Проблема ушла.

Кейс: студенческий кампус

Университетский файрвол, всё через прокси-сервер с авторизацией. UDP вообще запрещён, только TCP 80/443. Discord-клиент падал в TCP-фолбэк и работал, но с задержкой 300ms+. Студенты жаловались.

Поставили IPv6-релей вне кампуса, завернули UDP через SSH-туннель с `-w` флагом (tun-интерфейс). Получили полноценный UDP поверх TCP. Задержка 120ms, приемлемо. Не идеально, но лучше, чем ничего. IPv6 тут не главное — главное, что релей был вне сети и адрес не попадал в чёрный список кампуса.

Метрики: что мерить

Задержку round-trip до голосового сервера. Discord показывает её в настройках голоса. Норма — до 100ms, комфорт — до 60ms. Выше 150ms начинаются обрывы.

Джиттер. Opus терпит до 100ms, дальше идут артефакты. Мерьте через `mtr` с UDP-флагом.

Потери пакетов. Даже 2% дают заметные щелчки. Проверяйте через `iperf3 -u -b 100K` — это примерная нагрузка голосового канала.

| Параметр | Норма | Терпимо | Плохо |

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

| RTT | <60ms | 60–150ms | >150ms |

| Джиттер | <30ms | 30–100ms | >100ms |

| Loss | <0.5% | 0.5–2% | >2% |

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

IPv4-адресов мало, ротация ограничена. Один VPS — один-два адреса. Фильтр быстро учится. IPv6 даёт /64 минимум, это 18 квинтиллионов адресов. Ротация становится тривиальной.

Плюс многие фильтры IPv6 просто не умеют. Инфраструктура DPI в большинстве стран строилась под IPv4, IPv6 добавили позже и часто криво. Это временное преимущество, но пока работает.

Минус: не везде есть IPv6. Мобильные операторы в некоторых регионах до сих пор IPv4-only. Тогда нужен dual-stack релей.

Чего IPv6-прокси не решает

Не поможет против фильтрации по SNI. Если DPI читает TLS-хендшейк и видит `discord.com`, никакой IPv6 не спасёт. Нужна обфускация или domain fronting.

Не поможет, если провайдер режет весь UDP без разбора. Тогда только TCP-туннель с имитацией легитимного трафика.

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

Что использовать в продакшне

`udp2raw` — оборачивает UDP в фейковый TCP, проходит через многие DPI. `WireGuard` с IPv6 — быстро, но узнаваем. `Shadowsocks-libev` с UDP relay — работает, но требует настройки. `sing-box` — современный вариант, умеет много протоколов, включая Hysteria2 на QUIC.

Для голоса критична задержка, так что QUIC-based решения (Hysteria2, TUIC) обычно выигрывают у TCP-туннелей. Они дают 20–40ms overhead против 100–200ms у TCP.

Прокси-сервис с IPv6-пулом вроде lexic.ml удобен тем, что не надо поднимать VPS и возиться с /64. Но если нужен полный контроль над ротацией и протоколами — свой сервер гибче.

Итог

Голос Discord через IPv6-прокси работает, но это не кнопка «включить». Нужен релей, ротация адресов, правильные nftables-правила на клиенте и понимание, что фильтры эволюционируют. То, что работало полгода назад, сегодня может не работать. Держите в запасе второй протокол и второй сервер. И мерьте задержку — без цифр вы не поймёте, стало лучше или просто по-другому плохо.