WhatsApp через IPv6 прокси: VoIP, групповые чаты и обход ограничений
Содержание
Как WhatsApp использует сеть
WhatsApp держит постоянное TCP-соединение к своим серверам. Порт 5222 для XMPP-подобного протокола, порт 443 для медиа и звонков. Соединение живое, пока клиент в сети. Разрыв — и сообщения копятся на сервере до 30 дней.
Мобильный клиент переключается между Wi-Fi и LTE десятки раз в день. Каждый раз — новый IP, новый сеанс. Серверы WhatsApp видят это как смену endpoint. Прокси в этой схеме — дополнительный слой, который может как помочь, так и всё сломать.
IPv6 здесь не экзотика. У операторов давно dual-stack, а в некоторых регионах — IPv6-only с NAT64. WhatsApp умеет работать поверх IPv6 с 2016 года, но не все прокси-решения это переваривают.
Что ломается при проксировании VoIP
Голосовой трафик WhatsApp идёт через SRTP поверх UDP. Пакеты маленькие, 60–120 байт полезной нагрузки, интервал 20 мс. Потеря одного пакета — щелчок в ухе. Потеря десяти подряд — обрыв фразы.
TCP-прокси для VoIP не годится. Голова пакета в TCP добавляет 20 байт, плюс подтверждения, плюс retransmit при потере. Задержка растёт с 40 мс до 200+. Разговор превращается в рацию.
SOCKS5 умеет UDP ASSOCIATE. Это единственный способ гнать VoIP через прокси без потери качества. HTTP CONNECT — только TCP, для звонков бесполезен.
IPv6-прокси добавляет свои грабли. MTU в IPv6 минимум 1280 байт, фрагментация делается отправителем, не роутером. Если прокси не пропускает ICMPv6 Packet Too Big — большие пакеты молча теряются. Голос проходит, видео на 720p — нет.
Настройка SOCKS5 с IPv6
Клиент WhatsApp на Android не имеет встроенной настройки прокси. На iOS — тоже. Вариантов два: системный VPN-туннель или прокси на уровне роутера.
Для теста подойдёт curl. Проверяем, что прокси видит IPv6 и пропускает UDP:
```bash
curl -6 -x socks5h://[2001:db8::1]:1080 https://web.whatsapp.com -v
```
Флаг `-6` заставляет резолвить хостнейм в AAAA-запись. `socks5h` — резолвинг на стороне прокси, иначе DNS-запрос утечёт мимо туннеля.
Python-скрипт для проверки UDP через SOCKS5:
```python
import socks
import socket
s = socks.socksocket(socket.AF_INET6, socket.SOCK_DGRAM)
s.set_proxy(socks.SOCKS5, "2001:db8::1", 1080)
s.connect(("2606:4700:4700::1111", 53))
s.send(b"\x00\x00\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x03www\x07example\x03com\x00\x00\x01\x00\x01")
print(s.recv(512).hex())
```
Если ответ приходит — UDP через прокси работает. Если таймаут — сервер режет UDP или не поддерживает ASSOCIATE.
Групповые чаты и медиа
Групповой чат — это не multicast. Сервер WhatsApp рассылает копии каждому участнику. С точки зрения клиента это те же TCP-соединения, только трафика больше.
Медиа в группах — отдельная история. Фото и видео загружаются на CDN WhatsApp (домены `mmg.whatsapp.net`, `media-*.cdn.whatsapp.net`). Это HTTPS, порт 443. Прокси должен пропускать SNI без подмены, иначе TLS-хендшейк падает.
Проблема с IPv6: CDN WhatsApp отдаёт разные AAAA-записи в зависимости от региона. Прокси в Европе получит европейский edge, клиент в Азии — азиатский. Если прокси и клиент в разных регионах, CDN может отдать контент с задержкой 300+ мс.
Решение — Anycast. У WhatsApp есть Anycast-адреса для медиа. `media.fra2-1.fna.whatsapp.net` резолвится в ближайший edge. Если прокси сидит в Франкфурте, а клиент в Новосибирске — медиа пойдёт через Франкфурт. Задержка вырастет на 60–80 мс.
Кейс: обрыв звонков на MTU 1280
Сервер на Debian 12, ядро 6.1, nginx 1.24 в режиме stream-прокси. IPv6-туннель через Hurricane Electric. Клиент — WhatsApp Desktop на Windows 11.
Симптом: голосовые звонки соединяются, первые 3–5 секунд слышно, потом тишина в обе стороны. Чат работает нормально. Видео не запускается.
Причина — MTU. HE-туннель даёт MTU 1480 на интерфейсе, но внутри IPv6-пакета ещё инкапсуляция. Реальный MTU для полезной нагрузки — 1420. WhatsApp шлёт SRTP-пакеты по 1200 байт, они проходят. Но при переходе на видео пакеты вырастают до 1400+. Роутер на пути не может фрагментировать IPv6 и должен отправить ICMPv6 Type 2 (Packet Too Big). Этот ICMP блокировался файрволом.
Решение: разрешить ICMPv6 в ip6tables и понизить MTU на туннеле до 1380.
```bash
ip link set he-ipv6 mtu 1380
ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
```
После этого звонки держатся часами. Видео 720p работает, 1080p подтормаживает — не хватает полосы.
Кейс: DNS-утечка и бан аккаунта
Клиент — WhatsApp на iPhone, прокси — SOCKS5 на IPv6-адресе в Нидерландах. Настройка через сторонний VPN-клиент.
Через два дня аккаунт заблокирован на 24 часа. Причина — WhatsApp видит смену IP каждые несколько минут. Прокси-клиент переподключался при потере сети, каждый раз получал новый IPv6-адрес из пула /64.
WhatsApp банит за резкие скачки геолокации. Если IP меняется с амстердамского на сингапурский за минуту — это выглядит как угон аккаунта.
Решение — статический IPv6-адрес или пул /128 с привязкой к сессии. Прокси должен держать один адрес минимум 24 часа. В настройках VPN-клиента нужно выключить «случайный IPv6».
Второй момент — DNS. Если клиент резолвит `web.whatsapp.com` через локальный DNS провайдера, а трафик идёт через прокси, — утечка. WhatsApp видит DNS-запрос из одной страны, TCP-соединение из другой. Подозрительно.
Правильно — DNS через прокси. В SOCKS5 это `socks5h`, в WireGuard — `DNS = 2001:db8::53` в конфиге peer.
Кейс: групповой чат на 500 человек
Компания использует WhatsApp Business для рассылок. Группа на 500 участников, 20–30 сообщений в час в пике. Прокси — IPv6-only, пул из 16 адресов.
Симптом: сообщения доставляются с задержкой 2–5 минут. Иногда «часики» висят бесконечно, потом сообщение уходит.
Причина — rate limit. WhatsApp ограничивает количество сообщений с одного IP. Для групп — примерно 100 сообщений в минуту с адреса. Пул из 16 адресов должен давать 1600/мин, но распределение было неравномерным: 14 адресов простаивали, 2 держали всю нагрузку.
Проблема в sticky-сессиях. Прокси-балансировщик привязывал клиента к одному exit-ноду по хешу от порта. Порт у клиента не менялся — весь трафик шёл через один адрес.
Решение — round-robin по каждому новому TCP-соединению, а не по сессии. WhatsApp переподключается каждые 5–10 минут, каждое переподключение — новый exit-IP.
```nginx
stream {
upstream whatsapp_backend {
least_conn;
server [2001:db8::1]:1080;
server [2001:db8::2]:1080;
server [2001:db8::3]:1080;
}
server {
listen [::]:1080;
proxy_pass whatsapp_backend;
proxy_timeout 600s;
}
}
```
После переключения на least_conn нагрузка распределилась, задержка упала до 3–8 секунд.
Сравнение протоколов для VoIP
| Протокол | UDP | Накладные расходы | Задержка (мс) | Годен для звонков |
|---|---|---|---|---|
| SOCKS5 | Да | 10 байт | 5–15 | Да |
| HTTP CONNECT | Нет | 0 | 20–40 | Нет |
| WireGuard | Да | 32 байта | 10–25 | Да |
| OpenVPN UDP | Да | 69 байт | 30–60 | С натяжкой |
| Shadowsocks | Да | 7–15 байт | 5–20 | Да |
Цифры — из тестов на канале 100 Мбит/с, RTT до прокси 15 мс. Реальные значения зависят от загрузки и качества маршрута.
WireGuard проигрывает SOCKS5 по накладным расходам, но выигрывает по стабильности. Туннель держит MTU и не зависит от приложения. Для мобильного клиента это важно — переключение Wi-Fi/LTE не рвёт сессию.
Что делать с IPv6-only
Если прокси только на IPv6, а WhatsApp-серверы имеют AAAA-записи — всё работает. Проблема в другом: некоторые CDN и корпоративные сети до сих пор IPv4-only.
Проверка:
```bash
dig AAAA web.whatsapp.com +short
dig AAAA mmg.whatsapp.net +short
```
Если AAAA есть — трафик пойдёт по IPv6. Если нет — нужен NAT64/DNS64. Прокси должен уметь трансформировать IPv6 в IPv4 на выходе.
На практике WhatsApp имеет полный dual-stack. Проблемы возникают только с медиа-CDN в отдельных регионах.
Итог
WhatsApp через IPv6-прокси работает. Но требует внимания к трём вещам: UDP для VoIP, стабильный IP для аккаунта, правильный MTU для медиа. SOCKS5 с поддержкой ASSOCIATE — минимально достаточное решение. WireGuard — если нужна надёжность и не жалко 32 байта на пакет.
Инфраструктура вроде lexic.ml даёт пул IPv6-адресов, что решает проблему rate limit и банов за смену геолокации. Главное — не гнать весь трафик через один exit-нод и не забывать про ICMPv6.
