Коротко — да, v2rayNG поддерживает VLESS поверх WebSocket. Если на том же сервере и с теми же параметрами всё работает в v2rayN / Happy на ПК, то скорее всего проблема в настройке клиента (несоответствие параметров) или в нюансах TLS/WS/Host‑заголовка, а не в блокировках. Ниже — список наиболее вероятных причин и конкретные шаги для диагностики и исправления.
Возможные причины и что проверить
1. Протокол выбран неверно
- Убедитесь, что в конфиге клиента выбран именно VLESS, а не VMess.
2. Неправильные параметры WebSocket (path / Host)
- Путь (path) должен совпадать точно (включая или исключая начальный слеш — проверьте, как указан на сервере).
- В заголовках WS обязательно укажите Host (обычно домен, на который выдали сертификат). Многие сервера/CDN проверяют Host, и если он пустой/неправильный — соединение отклоняется.
- Сравните значения path и Host в v2rayNG с рабочим конфигом из v2rayN/Happ.
3. TLS / SNI / проверка сертификата
- Если сервер использует TLS, в клиенте должно быть включено TLS и указан SNI (обычно тот же домен).
- Убедитесь, что сервер отдает полный цепочку сертификатов. На Android старые/неполные цепочки могут приводить к ошибке.
- Для проверки: openssl s_client -connect domain:port -servername domain — посмотрите цепочку и CN/SAN.
- Для теста временно включите в клиенте опцию "Skip certificate verify" (только для диагностики).
4. Несоответствие порта / TLS / plaintext
- Частая ошибка — порт с TLS, а в клиенте TLS выключен (или наоборот). Проверьте, какой порт слушает сервер (plain WS или WSS).
5. Host/Cloudflare/кэш/CDN
- Если перед сервером CDN (Cloudflare, CDN с фронтом), убедитесь, что конфиг CDN поддерживает WebSocket и что Host/path не переписываются.
- Иногда на сервере настроены правила, которые разрешают только определённые Host заголовки.
6. Особенности VLESS (flow/xtls)
- Если сервер настроен на XTLS (xtls-rprx, tcp+xtls), то это другое транспортное решение и v2rayNG может не поддерживать/нужно настроить иначе. Убедитесь, что сервер действительно использует VLESS+WS, а не VLESS+XTLS.
7. Баги клиента / версия
- В редких случаях в конкретной сборке v2rayNG может быть баг. Попробуйте:
- Обновить до самой новой версии v2rayNG (если есть).
- Временно использовать другой Android‑клиент (v2rayNG fork / Kitsunebi / BifrostV / V2RayNG from GitHub) чтобы проверить, воспроизводится ли проблема.
8. Логи
- Включите логирование в v2rayNG (уровень debug) и посмотрите ошибку — это самый быстрый способ понять причину.
- Посмотрите логи сервера (v2ray-core/xray) — они обычно показывают, почему соединение отвергнуто (неверный uuid, TLS handshake failed, invalid path и т. п.).
Пошаговая процедура для диагностики (рекомендуемая)
1. Экспортируйте/сравните конфиг, который работает (v2rayN/Happ) и конфиг в v2rayNG — проверьте все поля: протокол, адрес, порт, id/UUID, flow, network=ws, path, headers Host, TLS, SNI.
2. Включите в v2rayNG debug‑лог и попробуйте подключиться — сохраните лог.
3. Посмотрите логи сервера параллельно (обычно /var/log или systemd journal) в момент попытки — что пишет сервер?
4. Проверьте TLS цепочку через openssl s_client.
5. Если в логах клиента видно, что WebSocket handshake возвращает 400/404/401 или TLS handshake fails — это указывает на Host/path или сертификат соответственно.
6. Попробуйте временно включить в клиенте "Skip cert verify" и/или поменять Host на тот, который используется рабочим клиентом.
Если хотите, помогу точнее — пришлите (без приватных ключей, но с конфигурацией клиента/серверными полями, замаскировав UUID/пароли) вывод логов v2rayNG (debug) и строки из server log в момент попытки подключения; по ним можно определить причину в >90% случаев.