Звонки Telegram не работают на VLESS+REALITY: как починить
Не проходят звонки в Telegram при VLESS+REALITY на 3X-UI? Проблема в UDP. Включаем UDP на inbound, настраиваем фаервол, split-tunnel для Telegram IP (149.154.160.0/20). Чеклист, tcpdump, логи Xray. Работает на aeza VPS.
Не работают звонки в Telegram при использовании VLESS+REALITY: что делать?
У меня есть сервер (провайдер aeza) с панелью 3X-UI (VLESS, XTLS Vision, REALITY). В целом всё работает нормально: трафик загружается, блокировки обходятся, но последние пару дней возникли проблемы с звонками в Telegram. Звонки зависают на стадии “Соединение…” и не проходят дальше.
Важная деталь: проблема возникает только когда оба устройства (телефоны/планшеты) подключены к моему VPN-серверу. Если звонить на компьютер, который также подключен к моему VPN, звонок проходит успешно. Если же один телефон подключить к другому VPN (в моем случае PaperVPN), то звонок тоже работает нормально.
Я уже пробовал следующие решения:
- Настроить SOCKS-прокси
- Изменить Transmission с TCP(RAW) на WebSocket и другие варианты
- Включить Sniffing
- Поменять Flow с xtls-rprx-vision на xtls-rprx-vision-udp443
- Изменить SNI на разные варианты, включая те, которые должны быть доступны при белых списках
- Включить Force TCP в настройках Telegram
Ни одно из этих действий не помогло решить проблему. Если кто-то сталкивался с подобной ситуацией, буду благодарен за советы по устранению этой неполадки.
Проблема почти наверняка связана с тем, что медиа в Telegram (голос/видео) идёт по UDP, а при VLESS+REALITY UDP либо не форвардится, либо блокируется/не обрабатывается панелью — в итоге telegram звонки зависают на «Соединение…». Быстрое исправление: в 3x-ui включить поддержку UDP на inbound (через Advanced: добавить network: tcp,udp или udp: true), открыть/форвардить UDP в фаерволе и/или сделать split‑tunnel (исключить Telegram IP 149.154.160.0/20 или домены) — подробный чеклист и команды ниже.
Содержание
- Почему telegram звонки не проходят при VLESS+REALITY (корень проблемы)
- VLESS+REALITY и 3x UI: как включить UDP на inbound и не потерять настройки панели
- Telegram звонки VPN: split-tunnel, белый список и обходы
- Проверки и отладка: tcpdump, логи Xray и тесты UDP
- Чеклист действий (приоритетные шаги)
- Ошибки, которых стоит избегать и финальные советы
- Источники
- Заключение
Почему telegram звонки не проходят при VLESS+REALITY (корень проблемы)
Коротко: голос/видео в Telegram используют UDP (P2P/STUN/hole punching). Когда оба телефона находятся за одним VPN-сервером, они пытаются установить P2P-соединение через UDP, но если сервер/панель и/или клиент не форвардит UDP — звонок зависает на «Соединение…». Причины обычно такие:
- inbound на сервере принимает только TCP (по умолчанию), UDP не включён или 3x-ui не выставляет соответствующую опцию; об этом есть обсуждение в GitHub у 3x-ui.
- фаервол/iptables/nftables не пропускают/не NAT‑ируют UDP-трафик между клиентами (hairpin NAT / NAT loopback).
- клиентское приложение не пересылает UDP (на мобильных клиентах есть переключатели UDP или ограничения платформы).
- попытки «заставить» всё работать только сменой flow (xtls-rprx-vision-udp443) или Force TCP в Telegram иногда не помогают, потому что это не подмена фактической передачи медиа по UDP.
Такое поведение уже обсуждалось: пользователи отмечали, что включение UDP в inbound и настройка domain‑sniffing/исключений для telegram.org решали проблему в ряде случаев — см. обсуждение Xray по VLESS+Reality и Telegram XTLS/Xray-core discussion и практические заметки на Habr Q&A Habr Q&A.
VLESS+REALITY и 3x UI: как включить UDP на inbound и не потерять настройки панели
Если вы управляете сервером через 3x-ui, редактировать raw config.json прямо не рекомендуется — панель перезапишет изменения. Делайте так:
- Войдите в 3x-ui → Inbounds (или нужный inbound) → Advanced / Ручная настройка.
- Добавьте опцию, позволяющую принимать UDP. В обсуждениях рекомендуют одну из форм:
- добавить
"network": "tcp,udp"в описание inbound, либо - добавить флаг
"udp": trueна уровне inbound.
В комментариях к 3x-ui это указано как рабочее решение: Issue #3283.
- Перезапустите Xray core через панель (Stop/Start или Restart). Изменения без перезапуска не подхватятся.
- Убедитесь, что используемая версия Xray поддерживает необходимые возможности UDP/Reality — при необходимости обновите Xray/3x-ui.
Пример (ориентировочно, правьте через Advanced, а не вручную в config.json):
{
"inbounds": [
{
"port": 443,
"protocol": "vless",
"settings": { /* клиенты */ },
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {}
},
"udp": true
}
]
}
Важно: в разных версиях поле и расположение могут отличаться — пользуйтесь именно интерфейсом 3x-ui, чтобы панель не перезаписала правки.
Telegram звонки VPN: split-tunnel, белый список и обходы
Если включить UDP на inbound не получается или вы хотите быстрый и стабильный обход: исключите трафик Telegram из туннеля (split‑tunnel). Это решает проблему, потому что звонки пойдут напрямую через мобильного оператора или публичные Telegram‑серверы.
- На стороне сервера/панели: добавьте правило белого списка/маршрутизации для доменов и IP Telegram — минимально: 149.154.160.0/20 (этот диапазон упоминается в обсуждениях как один из важных для Telegram) XTLS/Xray-core discussion.
- В 3x-ui есть возможности для роутинга/whitelist — добавьте telegram.org, t.me и нужные подсети.
- На мобильном устройстве: если клиент поддерживает split‑tunnel, настройте исключение Telegram или разрешите приложению обходить прокси.
- Дополнительно в самом Telegram (Settings → Privacy → Calls) можно проверить P2P‑опции: иногда полезно отключить P2P, чтобы заставить приложение использовать реле (репли): обзор возможных настроек — DTF.
Если один из участников остается в другом VPN и всё работает — это сильный признак именно проблемы с UDP/маршрутизацией между клиентами одного сервера.
Проверки и отладка: tcpdump, логи Xray и тесты UDP
Как понять, где «теряется» UDP? Быстрые тесты:
- На сервере включите захват пакетов и попытайтесь позвонить:
- sudo tcpdump -nn -i any udp and host <IP_клиента_A>
Или ловите STUN-пакеты (часто UDP 3478): - sudo tcpdump -nn -i any udp port 3478
Если при попытке звонка пакетов нет — сервер их не получает. Значит проблема на клиенте/сети до сервера или фаервол блокирует UDP.
- Проверка форвардинга/iptables:
- sudo iptables -L -n -v
- sudo iptables -t nat -L -n -v
Убедитесь, что INPUT и FORWARD позволяют UDP, а для исходящего NAT есть MASQUERADE: - sudo sysctl -w net.ipv4.ip_forward=1
- sudo iptables -t nat -A POSTROUTING -s <VPN_SUBNET> -o <PUBLIC_IF> -j MASQUERADE
(подставьте ваш VPN подсеть и интерфейс вместо плейсхолдеров).
- Логи Xray / 3x-ui:
- Проверьте логи через 3x-ui (Logs) или systemd: sudo journalctl -u xray -f
Ищите ошибки, связанные с udp, reality, vless или отказами при обработке пакетов.
- На клиенте:
- Убедитесь, что в приложении (V2RayNG, BifrostV, некспорт и т.д.) включен UDP relay/enable UDP. Некоторые клиенты по умолчанию не шлют UDP через прокси.
- Сценарии:
- Если сервер получает UDP от A, но не отправляет B — это пробел в NAT/маршрутизации (hairpin).
- Если сервер не получает UDP от A — клиент не отправляет или ISP/мобильная сеть блокирует UDP к вашему порту.
Полезный чек: одновременно запустите tcpdump и звоните; скопируйте небольшой дамп и приложите к issue на GitHub/форум — это сильно ускорит помощь.
Чеклист действий (приоритетные шаги)
- Обновите 3x-ui и Xray до последних стабильных версий.
- Через 3x-ui → Inbound → Advanced включите UDP: добавить
network: tcp,udpилиudp: true, затем перезапустить Xray (см. Issue #3283). - Проверьте, что мобильный клиент поддерживает UDP и что в нём включён UDP/Allow UDP.
- Откройте UDP в фаерволе/включите форвардинг:
- sudo sysctl -w net.ipv4.ip_forward=1
- sudo iptables -I INPUT -p udp -j ACCEPT
- sudo iptables -I FORWARD -p udp -j ACCEPT
- sudo iptables -t nat -A POSTROUTING -s <VPN_SUBNET> -o <PUBLIC_IF> -j MASQUERADE
- Включите Sniffing / domain routing для telegram.org в Xray/3x-ui (помогает правильной маршрутизации медиа) — обсуждается в Xray discussion.
- Если после включения UDP звонки всё ещё не проходят только когда оба в вашем VPN — реализуйте split‑tunnel (исключите Telegram: 149.154.160.0/20 и домены).
- Диагностика: захват tcpdump во время попытки звонка; соберите логи Xray и снимок iptables — приложите при обращении за помощью.
- Временный обход: один из участников может перейти на мобильные данные / другой VPN для звонков, пока правятся настройки сервера.
Ошибки, которых стоит избегать и финальные советы
- Не редактируйте config.json вручную, если вы управляете 3x-ui — изменения будут перезаписаны; используйте Advanced в панели.
- Не забывайте перезапустить Xray после правок.
- Менять только flow (xtls-rprx-vision → xtls-rprx-vision-udp443) часто бессмысленно без реального включения UDP/правил фаервола.
- Не пренебрегайте тестами tcpdump — они быстро покажут, доходят ли UDP-пакеты до сервера.
- Если нужно быстро вернуть голос — временно исключите Telegram из туннеля (split‑tunnel) — это надёжно работает как обходной путь.
- Для получения помощи прикладывайте: краткое описание сценария, вывод tcpdump (пару секунд), фрагмент логов xray и текущую конфигурацию inbound (через Advanced) — это сокращает время на разбор.
Источники
- Обсуждение проблемы UDP и 3x-ui: https://github.com/MHSanaei/3x-ui/issues/3283
- Решения и замечания по VLESS/Reality и Telegram (Xray‑core): https://github.com/XTLS/Xray-core/discussions/4020
- Практика: включение UDP на сервере/клиенте (Habr Q&A): https://qna.habr.com/q/1405008
- Статья о настройках звонков в Telegram (P2P/настройки): https://dtf.ru/software/4710304-problemy-so-zvonkami-v-telegram-kak-ikh-reshit-bystro-i-prosto
- Сообщения сообщества о различиях клиентов (reddit): https://www.reddit.com/r/VPN/comments/1g4vsn3/vless_reality_is_working_on_my_android_phone/
Заключение
Коротко: telegram звонки при VLESS+REALITY чаще всего ломаются из‑за отсутствия UDP‑форвардинга или из‑за проблем NAT, особенно когда оба клиента в одном VPN. Первое, что нужно сделать — в 3x-ui включить UDP на inbound и перезапустить Xray, затем проверить firewall/NAT и, при необходимости, настроить split‑tunnel (исключить Telegram IP 149.154.160.0/20). Если после этого останутся вопросы — соберите tcpdump и логи xray и приложите их при запросе помощи.