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

Discord блокирует голосовые каналы и стримы для российских IP с 2024 года. Текстовые чаты работают, а вот WebRTC-соединения режутся на уровне провайдера. Проблема в том, что голосовой трафик идёт через UDP, и обычные HTTP-прокси тут бесполезны. Нужен либо SOCKS5 с поддержкой UDP, либо полноценный IPv6-туннель.

Почему голос Discord ломается именно на UDP

Discord использует WebRTC для голоса и видео. Транспорт — SRTP поверх UDP, порты 50000–65535. Плюс STUN/TURN для NAT traversal. Когда провайдер блокирует диапазон UDP-портов или режет пакеты по сигнатурам, клиент не может установить медиа-сессию. Текстовый чат живёт на WebSocket (TCP 443) и продолжает работать.

Ключевая деталь: Discord определяет регион голосового сервера по IP. Российские IP попадают на серверы в EU (обычно Франкфурт или Амстердам), но сам медиапоток всё равно блокируется на стороне провайдера. Если пакеты не проходят, клиент падает обратно на TCP-режим через порт 443 — но это работает только когда Discord сам разрешает fallback, а с 2024 года он часто просто отказывает.

IPv6 здесь выигрывает по одной причине: провайдеры режут IPv4 UDP выборочно, а IPv6-маршруты часто идут в обход DPI-оборудования. Плюс адресное пространство IPv6 огромное — заблокировать диапазон сложнее, чем один IPv4.

SOCKS5 vs HTTP-прокси vs IPv6-туннель

Не каждый прокси пропустит голос. Вот реальное сравнение по типам:

| Тип прокси | UDP | WebRTC | Discord Voice | Стрим 1080p60 |

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

| HTTP CONNECT | Нет | Нет | Не работает | Не работает |

| SOCKS5 TCP-only | Нет | Частично | Падает на TCP fallback | Лаги 300+ мс |

| SOCKS5 UDP ASSOCIATE | Да | Да | Работает | 720p стабильно |

| IPv6-туннель (wireguard) | Да | Да | Работает | 1080p60 ок |

| IPv6-прокси с UDP relay | Да | Да | Работает | 1080p60 ок |

Разница принципиальная. HTTP-прокси умеет только CONNECT по TCP. SOCKS5 с флагом UDP ASSOCIATE создаёт отдельный UDP-сокет на стороне прокси, и клиент шлёт пакеты туда. IPv6-туннель заворачивает весь трафик, включая UDP, в инкапсуляцию.

Discord-клиент уважает системный SOCKS5, но есть нюанс: он не всегда использует UDP ASSOCIATE, даже если прокси его поддерживает. Приходится либо патчить клиент, либо использовать прокси на уровне ОС (TUN-режим).

Настройка SOCKS5 с UDP relay

Классический подход — поднять локальный SOCKS5 с поддержкой UDP. Например, через `sing-box` или `v2ray`. Вот минимальный конфиг sing-box для клиента:

```json

{

"inbounds": [

{

"type": "tun",

"interface_name": "tun0",

"inet4_address": "172.19.0.1/30",

"inet6_address": "fdfe:dcba:9876::1/126",

"auto_route": true,

"strict_route": true,

"stack": "system"

}

],

"outbounds": [

{

"type": "socks",

"tag": "proxy",

"server": "2001:db8::1234",

"server_port": 1080,

"version": "5",

"udp_over_tcp": false

}

]

}

```

Ключевой момент — `auto_route: true` и `stack: system`. Это заворачивает весь UDP в туннель, включая WebRTC. Discord видит исходящий IP как IPv6-адрес прокси и открывает голосовой регион, привязанный к нему.

Проверить, что UDP реально идёт через прокси, можно так:

```bash

curl -6 --socks5-hostname 2001:db8::1234:1080 https://ifconfig.co

должен вернуть IPv6 прокси, не локальный

python3 -c "

import socket

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

s.settimeout(3)

s.sendto(b'ping', ('2001:4860:4860::8888', 53))

print(s.recvfrom(512))

"

```

Если второй скрипт виснет — UDP не проходит. Если возвращает ответ — всё ок, голос пойдёт.

Как Discord выбирает голосовой регион

Discord делает запрос к `https://discord.com/api/v9/voice/regions` через свой клиент. Регион выбирается по задержке (RTT) и по геолокации IP. С российским IPv4 клиент видит регион `russia` — а он либо отсутствует, либо заблокирован. С IPv6-адресом европейского прокси клиент видит `europe` и подключается к серверам во Франкфурте или Стокгольме.

Задержка критична. Discord требует RTT < 200 мс до голосового сервера, иначе переключает на другой. Если прокси в Нидерландах, из Москвы RTT будет 40–60 мс. Из Новосибирска — 90–120 мс. Всё ещё в пределах нормы.

Вот как выглядит реальный запрос к API:

```bash

curl -6 -x socks5h://[2001:db8::1234]:1080 \

-H "Authorization: YOUR_TOKEN" \

https://discord.com/api/v9/voice/regions

```

Ответ покажет список доступных регионов и их latency. Если видите `russia` — прокси не работает, Discord всё ещё видит ваш реальный IP.

Стримы: почему они тяжелее голоса

Голос — это 32–128 kbps SRTP. Стрим 1080p60 — 6–8 Mbps, плюс отдельный поток для звука. Пропускная способность прокси становится узким местом. SOCKS5 с UDP relay на слабом VPS даст потери пакетов и артефакты.

Тут вступает в игру MTU. IPv6-туннель добавляет 40 байт заголовка IPv6 + 8 байт UDP + overhead инкапсуляции. Стандартный MTU 1500 превращается в 1420 или даже 1380. Если не выставить MSS clamping, крупные пакеты фрагментируются, и стрим рассыпается на квадраты.

Настройка MTU на TUN-интерфейсе:

```bash

ip link set dev tun0 mtu 1380

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \

-j TCPMSS --clamp-mss-to-pmtu

```

Для IPv6:

```bash

ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \

-j TCPMSS --clamp-mss-to-pmtu

```

Без этого Discord-стрим будет работать первые 10–15 секунд, а потом уйдёт в реконнект. Классическая грабля.

Что показывает диагностика

Discord имеет встроенную диагностику: Settings → Voice & Video → Debug. Там видно RTT, jitter, packet loss. Норма — RTT < 100 мс, jitter < 30 мс, loss < 1%. Если loss выше 5% — стрим не пойдёт.

Типичные цифры для IPv6-прокси из Москвы в Амстердам:

| Метрика | Значение | Комментарий |

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

| RTT голос | 45–70 мс | ок |

| RTT стрим | 55–85 мс | ок |

| Jitter | 8–15 мс | ок |

| Packet loss | 0.1–0.5% | ок |

| Throughput | 12–18 Mbps | хватает на 1080p60 |

Если throughput меньше 8 Mbps — стрим уйдёт в 720p или 480p автоматически. Discord адаптивный.

Кейс: провайдер режет UDP 50000–60000

Пример: клиент на Ростелекоме, Москва. Голос Discord не работает, текстовый чат работает. Диагностика показывает, что все UDP-пакеты на порты 50000–60000 дропаются на стороне провайдера. TCP 443 проходит.

Причина — провайдер блокирует диапазон UDP по сигнатурам WebRTC. Решение: IPv6-прокси с UDP relay. После настройки sing-box с TUN-режимом голос заработал с RTT 52 мс. Стрим 1080p60 — стабильно 15 Mbps throughput, loss 0.3%.

Важный момент: пришлось отключить `udp_over_tcp` в конфиге. Если включить — UDP заворачивается в TCP, и Discord видит это как TCP-соединение, переключаясь на fallback-режим с худшим качеством. Прямой UDP через IPv6 работает лучше.

Кейс: Discord видит IPv6, но голос не идёт

Пример: сервер на Ubuntu 22.04, nginx 1.24 как reverse proxy, sing-box как SOCKS5-сервер с UDP relay. Клиент подключается, Discord видит европейский IP, но голосовой канал не устанавливается. В логах sing-box — `UDP ASSOCIATE failed`.

Причина: nginx не пропускает UDP. HTTP reverse proxy работает только с TCP. SOCKS5 UDP relay требует прямого доступа к порту, минуя nginx. Решение — вынести sing-box на отдельный порт (1080) и открыть его напрямую, не проксируя через nginx.

Конфиг nginx для TCP-части (если нужен):

```nginx

stream {

upstream socks_backend {

server 127.0.0.1:1080;

}

server {

listen 443;

proxy_pass socks_backend;

proxy_timeout 300s;

}

}

```

Но UDP-часть всё равно идёт напрямую. nginx тут не помощник.

Кейс: стрим рассыпается через 30 секунд

Пример: клиент в Новосибирске, IPv6-прокси во Франкфурте. Голос работает, стрим 1080p60 запускается и через 25–35 секунд падает с ошибкой `Stream ended unexpectedly`. Packet loss в диагностике — 8–12%.

Причина: MTU mismatch. TUN-интерфейс имел MTU 1500, но IPv6-туннель добавляет overhead. Крупные пакеты фрагментировались, фрагменты терялись. Решение: выставить MTU 1380 на TUN и включить MSS clamping. После этого loss упал до 0.4%, стрим работает часами.

Дополнительно помогло увеличение буфера UDP на сервере:

```bash

sysctl -w net.core.rmem_max=26214400

sysctl -w net.core.wmem_max=26214400

sysctl -w net.ipv4.udp_mem="65536 131072 262144"

```

Без этого при пиковой нагрузке буфер переполнялся и пакеты дропались.

Почему IPv6, а не IPv4-прокси

IPv4-прокси тоже работает, но есть нюансы. Во-первых, IPv4-адреса прокси часто уже в бан-листах Discord (особенно дешёвые VPS из известных дата-центров). Во-вторых, провайдеры режут IPv4 UDP агрессивнее, чем IPv6. В-третьих, IPv6-адрес можно менять в пределах /64 префикса — это даёт ротацию без переезда на новый VPS.

Для Discord критично, чтобы IP не был в чёрных списках. IPv6-адреса из свежих /48-префиксов реже попадают в бан. Плюс провайдеры часто не имеют DPI для IPv6 на том же уровне, что для IPv4.

Сервисы вроде lexic.ml дают IPv6-прокси с UDP relay из коробки — это снимает головную боль с настройкой sing-box и MTU. Но если хочется контролировать всё самому, VPS за 3–5 евро в месяц с /64 префиксом решает задачу.

Что проверить перед покупкой прокси

Чек-лист:

1. Поддержка UDP ASSOCIATE в SOCKS5. Спросите у провайдера или проверьте через `socat`.

2. Наличие IPv6 /64 или /48 префикса. Один адрес — мало, нужна ротация.

3. Пропускная способность минимум 20 Mbps на клиента для стримов.

4. RTT до европейских голосовых серверов Discord < 150 мс.

5. Отсутствие бана IP в Discord. Проверяется через API регионов.

Проверка UDP ASSOCIATE:

```bash

python3 -c "

import socks

s = socks.socksocket()

s.set_proxy(socks.SOCKS5, '2001:db8::1234', 1080)

s.bind(('0.0.0.0', 0))

print('UDP relay OK:', s.getsockname())

"

```

Если скрипт падает с ошибкой — UDP не поддерживается, голос не пойдёт.

Итоговая архитектура

Рабочая схема выглядит так: локальный TUN-интерфейс с MTU 1380, sing-box в режиме TUN с auto_route, SOCKS5-сервер на IPv6-адресе с UDP relay, MSS clamping на обоих концах. Discord видит европейский IPv6, открывает голосовой регион EU, медиапоток идёт через UDP напрямую.

Задержка 50–90 мс в зависимости от географии. Стрим 1080p60 — 12–18 Mbps throughput. Packet loss < 1% при правильном MTU. Голос работает стабильно, текстовые чаты — как обычно.

Главное — не пытаться пропустить UDP через TCP-прокси. Это работает, но качество падает в разы. Discord переключается на fallback-кодек Opus в режиме низкой задержки, звук становится металлическим, стрим — слайд-шоу. Прямой UDP через IPv6 — единственный способ получить нормальное качество.