Кратко — проблема скорее всего связана с UDP/QUIC (который YouTube на мобильных клиентах активно использует) или с особенностями транспорта/MTU/NAT на пути от мобильного клиента до сервера. Ниже — пошаговый план проверки и исправлений: от быстрых тестов до глубокой диагностики. Делайте шаги по порядку и присылайте логи/выводы, если нужно — помогу интерпретировать.
1) Быстрые пробные выгрузки (чтобы понять, это точно QUIC/UDP)
- Подключитесь с телефона и:
- Отключите QUIC/HTTP3 в мобильном браузере (в Chrome: chrome://flags → disable QUIC) и/или попробуйте смотреть видео в Safari (iOS) или другом плеере — если после отключения QUIC видео начинает работать, причина почти наверняка в UDP/QUIC.
- В клиенте VLESS временно смените transport на tcp/ws (или добавьте отдельный порт tcp/ws) и подключитесь — если после этого YouTube работает нормально, проблема в UDP/QUIC/XTLS-UDP/сете.
2) Соберите логи (сервера и клиента)
- На сервере (Xray/v2ray/3x-ui) включите уровень логов info или debug и посмотрите:
- tail -n 200 /var/log/xray/access.log
- tail -n 200 /var/log/xray/error.log
- или логи 3x-ui в месте, где они хранятся
Ищите: ошибки QUIC/UDP, время ожидания (timeout), RST, failed to read/write и т.п.
- На телефоне включите лог клиента (many clients имеют debug-лог) и посмотрите ошибки при попытке воспроизвести видео.
3) Захват пакетов (важно для подтверждения проблем с UDP)
- На сервере запустите tcpdump/tshark и повторите попытку воспроизведения:
- tcpdump -i any -w quic.pcap 'host <IP_клиента> or host <youtube_ip>'
- или фильтр: tcpdump -i any -w dump.pcap 'udp and port 443'
Затем откройте pcap в Wireshark и ищите QUIC (udp/443), сильные потери, повторные передачи, RST.
- На телефоне используйте (Android) app Packet Capture или включите USB-tether и делайте tcpdump на ПК.
4) Проверка UDP/потерь/черных дыр (MTU/NAT)
- Проверьте потерю пакетов/latency UDP между клиентом и сервером:
- iperf3 можно использовать (сервер: iperf3 -s, клиент: iperf3 -c <сервер> -u) — если UDP теряется, видно сразу.
- Возможна PMTU blackhole: большие UDP-пакеты теряются. Попробуйте уменьшить MTU на клиенте/сервере или применить MSS-clamping:
- iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
- либо для входящего/исходящего трафика на сервере:
iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
- Попробуйте уменьшить MTU интерфейса сервера (временно):
- ip link set dev eth0 mtu 1400
Если после уменьшения MTU видео заработало — проблема с фрагментацией/MTU.
5) Проверка NAT/файрвола/провайдера
- Убедитесь, что на сервере/хостинге разрешён UDP порт 443 (и нет rate-limit или udp inspection):
- iptables -L -n -v и iptables -t nat -L -n -v
- Если провайдер или дата-центр DPI/ACL может блокировать QUIC/UDP — попробуйте подключиться через другой VPS/провайдера или через мобильный интернет (если тест раньше велся по Wi‑Fi).
- Проверьте значения conntrack (если много коротких UDP потоков, таблица может быть переполнена):
- sysctl net.netfilter.nf_conntrack_max
- dmesg | grep conntrack
При необходимости увеличить nf_conntrack_max.
6) Эксперименты с транспортом и версиями XTLS/Xray
- xtls-rprx-vision-udp443 — это экспериментальная опция для UDP relay; она может быть нестабильна. Попробуйте:
- Вернуть стабильный xtls (xtls-rprx-vision) или использовать tls+ws / tcp+ws / grpc на 443.
- Создайте дополнительный inbound с tcp/ws на 443 и протестируйте с телефона.
- Убедитесь, что используете актуальную и стабильную версию xray-core (иногда баги в реализации QUIC/XTLS влияют на мобильные клиенты).
7) DNS и sniffing
- Вы уже пробовали fakedns/sniffing — проверьте, не вмешивается ли это в доставку пакетов:
- Попробуйте полностью отключить fakedns/sniffing; используйте нативный DoH/DoT или DNS-over-HTTPS на клиенте и сервере.
- Проверьте, как разрешаются домены YouTube на телефоне: dig/host для r{X}.googlevideo.com. Неправильный IP может направлять на серверы, где UDP недоступен.
8) Диагностика QUIC/HTTP3 специально
- На сервере/ПК можно тестировать QUIC к YouTube или к другим HTTP3-совместимым ресурсам (curl с --http3) чтобы понять, QUIC вообще проходит:
- curl --http3 -I https://www.youtube.com/ (может не дать полного результата из-за сложной маршрутизации, но тест полезен)
- В логах xray ищите строки, связанные с “quic” или “udp: read/write failed”.
9) Параметры ядра и таймауты UDP
- Увеличьте таймауты/пороговые значения для UDP в conntrack (если подозреваете, что NAT режет короткие UDP-потоки):
- sysctl -w net.netfilter.nf_conntrack_udp_timeout=30
- sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=180
(подберите значения осторожно)
10) Как собрать полезную информацию для помощи
Если хотите, пришлите (фрагменты, не полные конфиденциальные данные):
- Серверный лог xray (debug) за время попытки воспроизведения;
- tcpdump pcap (или его часть) с пометкой времени;
- конфигурацию inbound (streamSettings) из 3x-ui для порта 443 (замаскируйте секреты/пароли);
- укажите: телефон на Wi‑Fi или мобильная сеть? ПК подключён к тому же Wi‑Fi?
Резюме быстрых действий для проверки (в порядке приоритета)
1. Отключить QUIC в браузере/принудительно переключить VLESS на TCP/WS — если заработало, виноват UDP/QUIC.
2. Включить debug-логи xray и собрать клиентские логи.
3. Захватить трафик (tcpdump) и посмотреть потери/повторные передачи QUIC (udp/443).
4. Попробовать MSS-clamp / уменьшить MTU.
5. Попробовать альтернативный transport (ws/grpc) или другой VPS/провайдера.
Если хотите, начнём с самого простого: скажите, пожалуйста, на какой сети находятся ваши телефоны (Wi‑Fi того же роутера, что и ПК? мобильный оператор?), и пришлите 2–3 строки из server error.log в момент попытки воспроизведения — помогу интерпретировать и предложу точечные правки конфигурации.