VLESS работает в браузере, но не работает в программах: почему

Ситуация, когда VLESS работает в браузере, но не работает в программах, встречается довольно часто.

Например:

• Chrome открывает сайты;
• YouTube работает;
• внешний IP в браузере изменился;

но при этом:

• Discord не подключается;
• игра не видит сеть;
• launcher работает напрямую;
• Telegram использует обычное соединение;
• отдельная программа показывает timeout.

На первый взгляд кажется странным:

если VLESS подключён, почему через него работает не всё?

Чаще всего ответ простой:

браузер использует proxy, а остальные программы в этот proxy вообще не отправляют свой трафик.

Это не обязательно ошибка сервера или VLESS-ключа.

Нужно разобраться, чем отличаются:

Proxy Mode

и:

TUN/VPN Mode.

Самый короткий ответ

Если браузер работает через VLESS, а остальные программы нет, сначала проверьте, включён ли TUN.

Упрощённо:

Proxy Mode

Chrome → Proxy → Xray → VLESS
Discord → напрямую
Игра → напрямую

TUN Mode

Chrome ┐
Discord ├→ TUN → Xray → VLESS
Игра ───┘

Разница принципиальная.

Обычный proxy ждёт, что приложение само направит соединение на локальный proxy-порт.

TUN работает на сетевом уровне и позволяет перехватывать значительно более широкий набор трафика.

Официальная документация Xray описывает TUN как виртуальный интерфейс: трафик, отправленный в него системной таблицей маршрутизации, поступает на обработку в Xray.

Почему браузер вообще работает через proxy

Многие браузеры умеют использовать:

• системные proxy-настройки;
• HTTP proxy;
• SOCKS proxy;
• собственные proxy-настройки.

Если VLESS-клиент включил системный proxy, браузер начинает отправлять соединения примерно так:

браузер
↓
локальный proxy
↓
Xray
↓
VLESS
↓
сервер
↓
сайт

Для Xray это обычный inbound.

В официальном примере Project X SOCKS inbound слушает локальный адрес 127.0.0.1 и принимает трафик приложений, после чего routing передаёт его в VLESS outbound.

Но приложение должно действительно воспользоваться этим входом.

Если оно этого не делает, Xray его трафика просто не видит.

Почему программа может игнорировать системный proxy

Не все приложения работают одинаково.

Некоторые используют системные сетевые настройки.

Другие:

• имеют собственный network stack;
• поддерживают только определённые типы proxy;
• вообще не используют системный proxy;
• создают UDP-соединения;
• подключаются напрямую к IP;
• используют собственные DNS-механизмы.

Поэтому обычного включения:

System Proxy

может быть достаточно для браузера, но недостаточно для всего компьютера.

Это не особенность конкретно VLESS.

Так работает сама proxy-модель.

Что делает TUN

TUN создаёт виртуальный сетевой интерфейс.

Система направляет в него IP-трафик, после чего клиент может передать его в Xray.

Актуальная документация Project X прямо описывает:

traffic sent to this interface will be processed by Xray.

Также Xray умеет автоматически добавлять в системную routing table маршруты вроде:

0.0.0.0/0

для IPv4 и:

::/0

для IPv6.

Поэтому приложение уже не обязано само поддерживать proxy.

Для него сеть выглядит обычной.

Почему TUN больше похож на классический VPN

Классический пользователь ожидает:

включил VPN → весь нужный интернет пошёл через него.

Именно это проще реализовать через TUN.

Приложение видит обычное сетевое соединение.

Дальше система отправляет пакеты в виртуальный интерфейс, а VPN-клиент уже решает:

• VLESS;
• direct;
• block;
• другой outbound.

Поэтому связка:

HAPP + TUN + VLESS

для пользователя ощущается как обычный системный VPN.

Если браузер работает, сервер VLESS исправен?

Это хороший признак, но не абсолютное доказательство исправности всего.

Если через браузер реально:

• открываются сайты;
• меняется внешний IP;
• передаются данные,

значит уже работают:

• сам клиент;
• VLESS-профиль;
• сервер;
• основной transport;
• выход в интернет.

Поэтому переустанавливать сервер или менять UUID в такой ситуации обычно бессмысленно.

Но конкретная программа всё ещё может использовать:

• другой протокол;
• UDP;
• другой домен;
• другой routing rule.

Именно это нужно проверять дальше.

1. Включите TUN

Это первое действие для Windows/macOS/Linux, если клиент предлагает отдельные режимы:

• Proxy;
• TUN.

Если сейчас включён только Proxy Mode, попробуйте TUN.

После этого полностью перезапустите проблемное приложение.

Почему перезапустить?

Программа могла уже открыть существующие соединения напрямую.

После запуска TUN новое соединение должно быть создано уже через новую сетевую схему.

Как понять, что TUN действительно заработал

Проверьте несколько вещей.

Браузер

Открывается интернет?

Внешний IP

Изменился ли он через VPN?

Проблемное приложение

Заработало ли оно?

Локальные сайты

Работают ли они согласно вашей routing-конфигурации?

Если после включения TUN заработали и браузер, и приложение, причина найдена:

программа просто не использовала обычный proxy.

2. Если после включения TUN пропал весь интернет

Это уже другая проблема.

Сам VLESS может быть исправен, но TUN неправильно взаимодействует с:

• routing table;
• физическим интерфейсом;
• DNS;
• firewall.

Project X отдельно предупреждает о возможности traffic loop: если трафик самого Xray снова попадает в его же TUN, получается цикл. Для предотвращения этого предусмотрен autoOutboundsInterface, который привязывает outbound к реальному физическому интерфейсу.

Обычному пользователю HAPP вручную настраивать это обычно не требуется.

Но симптом:

Proxy работает, TUN полностью убивает интернет

явно указывает уже не на VLESS-сервер.

3. Перезапустите HAPP после смены режима

При переходе:

Proxy → TUN

или обратно полезно полностью переподключить клиент.

Лучше:

1. Disconnect.
2. Сменить режим.
3. Connect.
4. Перезапустить нужную программу.

Так старые соединения не будут мешать проверке.

4. Отключите другой VPN

Одна из самых частых причин проблем с TUN — несколько VPN-клиентов одновременно.

Например, на компьютере установлены:

• HAPP;
• WireGuard;
• WARP;
• OpenVPN;
• Outline;
• корпоративный VPN.

Каждый из них может создавать:

• виртуальный интерфейс;
• маршруты;
• DNS;
• сетевые службы.

В результате браузер через локальный proxy продолжает работать, а системная маршрутизация превращается в хаос.

Для контрольного теста закройте всё кроме HAPP.

Даже выключенный VPN иногда влияет на сеть

Некоторые программы оставляют после себя:

• network adapter;
• service;
• route;
• filter driver.

Поэтому если проблема появилась после установки другого VPN, полезно:

1. закрыть другие клиенты;
2. перезагрузить Windows;
3. запустить только HAPP.

Если после этого TUN заработал, VLESS здесь ни при чём.

5. Проверьте firewall

System Proxy и TUN взаимодействуют с системой по-разному.

Firewall может разрешать:

браузер → локальный proxy

но мешать:

TUN → системный трафик.

Особенно это актуально для:

• сторонних firewall;
• antivirus suites;
• корпоративных security tools.

Не нужно отключать firewall навсегда.

Достаточно временно проверить его влияние.

6. Антивирус тоже может вмешиваться

Современные security suites могут устанавливать:

• network filters;
• web protection;
• HTTPS inspection;
• собственные сетевые драйверы.

Если:

браузер через proxy работает

а:

TUN постоянно ломается,

и проблема началась после обновления антивируса, стоит проверить этот вариант.

7. Discord работает в браузере, но не в приложении

Это практически учебный пример.

В браузере Discord может идти через системный proxy.

Desktop-приложение при этом использует собственные сетевые соединения, включая real-time traffic.

Особенно отличается голос.

Discord voice чувствителен к:

• UDP;
• routing;
• packet loss;
• TUN.

Поэтому ситуация:

сайт Discord открывается, но приложение или voice нет

ещё не означает, что Discord целиком работает через VLESS.

Для desktop Discord лучше проверять именно TUN.

8. Текст работает, а Discord voice нет

Тогда proxy уже частично выполняет задачу.

Но голос использует другой тип трафика.

В этом случае проверьте:

• TUN;
• UDP;
• другую VLESS-локацию;
• firewall.

Не нужно переустанавливать браузер или менять VLESS UUID.

9. Игра не работает через VLESS, а браузер работает

Игры особенно часто показывают разницу между proxy и TUN.

У игры обычно нет настройки:

использовать системный HTTP proxy.

Она просто отправляет:

• TCP;
• UDP;

в обычный сетевой интерфейс.

Без TUN такой трафик может вообще пройти мимо Xray.

Поэтому для игр системный TUN обычно значительно логичнее proxy mode.

Почему игра может видеть ваш обычный IP

Если браузер проксируется, а игра идёт напрямую:

Chrome → VLESS IP
Игра → ISP IP

Это совершенно нормальная ситуация для split networking.

VPN-клиент не обязательно проксирует весь компьютер только потому, что браузер показывает новый адрес.

10. Launcher работает, а сама игра нет

Тоже возможно.

Launcher может использовать обычный HTTPS/TCP.

Игра после запуска:

• UDP;
• собственные порты;
• другой набор серверов.

Поэтому один компонент работает через proxy, другой нет.

TUN решает именно проблему охвата системного трафика.

11. Telegram работает в браузере, приложение нет

Сначала убедитесь, что в Telegram Desktop не остался собственный старый proxy.

Например:

• SOCKS5;
• MTProto.

Тогда получается:

Telegram → старый proxy

вместо ожидаемого:

Telegram → TUN → VLESS

Для диагностики лучше временно отключить встроенный Telegram Proxy и оставить одну сетевую схему.

12. Программа имеет собственные proxy-настройки

Некоторые приложения позволяют вручную выбрать:

• Direct;
• System Proxy;
• HTTP;
• SOCKS5.

Если выбрано:

Direct

программа может сознательно обходить системный proxy.

Если хотите использовать Proxy Mode, попробуйте:

System Proxy

или локальный SOCKS/HTTP proxy клиента.

Но если таких программ много, TUN обычно проще.

13. Не все proxy одинаковы

Есть:

• HTTP proxy;
• HTTPS proxy;
• SOCKS;
• transparent proxy;
• TUN.

Поддержка одного типа не означает поддержку другого.

Например, приложение может уметь:

HTTP proxy

но не уметь проксировать через него UDP.

SOCKS способен быть гибче, но приложение всё равно должно уметь им пользоваться.

TUN переносит эту задачу на уровень операционной системы и клиента.

14. Почему UDP особенно важен

Многие приложения используют UDP.

Например:

• игры;
• voice;
• видеосвязь;
• некоторые современные transport-протоколы.

Если трафик идёт через обычный browser-oriented proxy, UDP может вообще не попасть в него.

При корректной TUN/Xray-схеме клиент может обрабатывать и TCP, и UDP.

Routing Xray позволяет отдельно создавать правила для протоколов и направлять трафик в соответствующий outbound.

15. TUN включён, но программа всё равно работает напрямую

Тогда нужно проверить routing.

Тот факт, что пакет попал в Xray, ещё не означает:

обязательно отправить его через VLESS.

Xray имеет отдельный routing-модуль, который выбирает outbound для подходящего трафика. Официальная документация прямо описывает on-demand proxying: разные входящие соединения можно отправлять в разные outbound согласно правилам.

Например:

YouTube → VLESS
Discord → VLESS
.ru → direct
LAN → direct

Это нормальная схема.

16. Ошибка routing rule

Если правило слишком широкое или неправильное, приложение может случайно попадать в:

direct

вместо:

proxy.

Например, домен или IP ошибочно оказался среди исключений.

Тогда:

• TUN работает;
• браузер работает;
• конкретное приложение идёт напрямую.

Это уже проблема правил маршрутизации.

Почему routing вообще может различать приложения

Xray способен принимать решение по разным признакам.

В том числе:

• домен;
• IP;
• порт;
• network;
• inbound;
• protocol.

В актуальной документации TUN также упоминается возможность process-name routing, если требуется проксировать только определённые процессы.

То есть схема может быть значительно сложнее:

весь компьютер через VPN

или:

только несколько конкретных программ.

17. Проверьте DNS

Иногда программа через TUN вроде бы попадает в Xray, но не может разрешить свои домены.

Симптомы:

• приложение долго запускается;
• показывает offline;
• часть функций работает;
• браузер при этом полностью исправен.

Почему браузер может работать?

Потому что у него может быть собственный Secure DNS/DoH.

А программа использует системный DNS.

В итоге они фактически находятся в разных DNS-схемах.

Secure DNS браузера может скрыть проблему

Представим:

Chrome → DoH → домен разрешился → сайт работает.

При этом:

приложение → System DNS → ошибка.

Пользователь делает вывод:

VPN работает только в браузере.

Но реальная проблема:

системный DNS сломан.

Поэтому при таком симптоме DNS нужно обязательно иметь в виду.

18. Проверьте Private DNS / сторонний DNS

Если используются:

• AdGuard;
• NextDNS;
• Secure DNS;
• собственный DNS на роутере;

для теста стоит упростить схему.

Не нужно одновременно менять всё.

Оставьте стандартную конфигурацию HAPP/TUN и посмотрите, заработало ли приложение.

19. IPv4 и IPv6 тоже могут отличаться

Браузеры давно умеют довольно хорошо переключаться между IPv6 и IPv4.

Конкретное приложение может вести себя иначе.

Например:

• сайт доступен через IPv4;
• приложение сначала выбирает проблемный IPv6;
• соединение долго ждёт timeout.

При использовании TUN важно, чтобы маршрутизация охватывала нужные address families.

Xray TUN может автоматически добавлять маршруты как для:

0.0.0.0/0

так и для:

::/0.

Если IPv6 случайно остаётся вне TUN, часть трафика потенциально может идти другим путём.

Нужно ли отключать IPv6

Не первым делом.

Сначала проверьте:

• TUN;
• routing;
• DNS;
• другой сервер.

IPv6 — нормальная современная часть сети.

Отключать его всем пользователям ради одного приложения нет смысла.

Но при диагностике подозрительного dual-stack поведения временный тест допустим.

20. Программа использует IP напрямую

Routing по доменам особенно удобен, когда Xray видит:

discord.com

или:

example.com.

Но приложение может соединяться напрямую с IP.

Тогда доменное правило само по себе может не сработать так, как ожидается.

Для transparent proxy-сценариев Xray имеет sniffing: он может определить доменное имя из трафика и использовать его для routing. В документации Project X это прямо приводится как типичный сценарий transparent proxy.

Обычному пользователю HAPP вручную собирать sniffing-конфигурацию обычно не требуется.

Но этот механизм объясняет, почему routing — сложнее простого списка доменов.

21. ECH тоже усложняет доменную маршрутизацию

Современные браузеры могут использовать Encrypted Client Hello.

Project X отдельно предупреждает, что при ECH Xray может видеть только домен из Outer Client Hello, из-за чего иногда требуется другой подход к DNS/routing.

Для обычного пользователя это не повод отключать ECH вручную.

Но полезно понимать:

доменная маршрутизация — не магия и не всегда видит каждый конечный hostname одинаково.

22. Программа работает после запуска HAPP, но перестаёт после перезапуска

Это может указывать на:

• порядок запуска;
• старые routes;
• старые соединения;
• другой VPN;
• TUN adapter.

Попробуйте:

1. закрыть программу;
2. отключить HAPP;
3. подключить HAPP заново;
4. только потом запустить приложение.

Если проблема исчезла, приложение сохраняло старую сессию или маршрут.

23. HAPP запущен после программы

Иногда программа устанавливает соединение ещё до VPN.

Например:

Discord → direct connection

после чего пользователь включает HAPP.

Приложение может некоторое время продолжать использовать уже существующую сессию.

Поэтому для чистого теста лучше перезапустить программу после подключения VPN.

24. Проверьте приложение после полной перезагрузки Windows

Если:

• менялись VPN;
• устанавливались драйверы;
• включался/выключался TUN;

обычная перезагрузка иногда полезнее десятка случайных настроек.

Она очищает:

• старые процессы;
• многие временные маршруты;
• сетевые состояния.

После загрузки запустите только HAPP и проблемную программу.

25. Почему приложение может вообще не стартовать при включённом TUN

Иногда программа при запуске проверяет:

• DNS;
• API;
• authentication server;
• CDN.

Если хотя бы один из них ошибочно попал в:

• block;
• неудачный direct;
• неправильный DNS route,

приложение может выглядеть полностью неработающим.

При этом браузер по-прежнему работает.

Поэтому нужно смотреть именно домены/соединения этого приложения.

26. Игра работает, а авторизация launcher нет

Обратная ситуация тоже возможна.

Launcher и игра могут использовать совершенно разные инфраструктуры.

Например:

launcher → HTTPS API
игра → UDP game server

Routing, который подходит одному, может не подходить другому.

Поэтому фраза:

«игра через VLESS работает»

не всегда означает, что работает весь связанный набор сервисов.

27. VPN включён, но программа определяет реальную страну

Это не обязательно означает утечку.

Приложение может определять регион по:

• аккаунту;
• GPS;
• SIM;
• языку системы;
• сохранённым настройкам;
• платёжному профилю.

Но сначала всё равно стоит проверить внешний IP именно для трафика приложения, если это возможно.

Не каждая региональная настройка зависит только от VPN IP.

28. Split tunneling может быть включён намеренно

Некоторые VPN-клиенты позволяют исключать приложения из VPN.

Например:

Chrome → VPN
Steam → Direct

Если такой режим когда-то настраивался, программа может сознательно обходить VLESS.

Проверьте:

• исключения приложений;
• routing profile;
• per-app rules.

Это особенно важно после импорта готовых профилей маршрутизации.

29. Локальные приложения иногда должны идти напрямую

Не всегда нужно отправлять через VLESS вообще всё.

Например:

• локальный принтер;
• NAS;
• роутер;
• некоторые банковские или региональные сервисы.

Xray routing специально предназначен для разделения:

proxy / direct.

Project X приводит разделение domestic и foreign traffic как один из основных примеров использования routing.

Поэтому direct сам по себе не является ошибкой.

Ошибка — когда туда случайно попало приложение, которое вы хотели проксировать.

30. Проверка через IP-сервисы не всегда достаточна

Если Chrome показывает VPN IP, это доказывает только:

Chrome вышел через VPN.

Это не доказывает, что:

• Discord;
• Steam;
• игра;
• Telegram

используют тот же маршрут.

Для проверки всей системы нужен системный TUN либо отдельный тест внутри нужного приложения.

31. Нужно ли настраивать proxy внутри каждого приложения

Если используется TUN — обычно нет.

Именно в этом его главное удобство.

Без TUN можно вручную настроить SOCKS/HTTP proxy в программах, которые это поддерживают.

Но тогда придётся повторять настройку:

• браузера;
• Telegram;
• downloader;
• других приложений.

Для постоянного VPN системный TUN проще.

32. TUN или ручной SOCKS: что выбрать

Для одного приложения SOCKS вполне нормален.

Например:

нужно проксировать только Telegram.

Но если задача:

• Discord;
• браузер;
• игры;
• launcher;
• приложения Windows;

логичнее системный TUN.

Меньше отдельных конфигураций.

33. Почему TUN может немного влиять на производительность

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

Также разные реализации могут использовать:

• системный stack;
• userspace stack.

Для современных компьютеров эта разница обычно не является главным ограничением скорости.

Гораздо чаще bottleneck находится в:

• сервере;
• маршруте;
• Wi-Fi;
• провайдере.

Поэтому не стоит избегать TUN только из страха потерять несколько процентов производительности.

34. Что делать, если проблема только с одной программой

Если всё остальное через TUN работает, а одна программа нет, не нужно ломать всю VLESS-конфигурацию.

Проверьте:

1. собственный proxy приложения;
2. firewall;
3. DNS;
4. UDP;
5. routing;
6. встроенные network settings приложения.

Это уже локальная проблема конкретного software.

35. Что делать, если через TUN не работает вообще ничего кроме браузера

Тогда нужно проверить, действительно ли браузер ещё не использует старый system proxy.

Возможно:

• TUN сломан;
• Chrome продолжает ходить через отдельный proxy;
• остальные приложения идут через неработающий системный маршрут.

Для чистого теста временно отключите Proxy Mode и оставьте только TUN.

Если браузер тоже перестал работать, проблема действительно в TUN.

36. Не включайте два режима без понимания причины

Иногда можно одновременно получить:

• system proxy;
• TUN.

Это не всегда ошибка, но диагностировать становится сложнее.

Когда ищете проблему, полезнее иметь понятную схему:

Тест Proxy

Только Proxy Mode.

Тест TUN

Только TUN.

Так сразу видно, на каком уровне появляется неисправность.

37. Проверьте другой сервер

Даже если браузер работает.

Конкретное приложение может обращаться к инфраструктуре, маршрут до которой через текущий VLESS-сервер плохой.

Например:

сервер A

• сайты отлично;
• игра timeout.

сервер B

• сайты отлично;
• игра работает.

Значит TUN был исправен.

Отличался маршрут после VPN-сервера до конечного сервиса.

38. Проверьте без VLESS

Полезный контрольный вопрос:

программа вообще работает напрямую?

Если нет:

• проблема приложения;
• его сервера;
• локального firewall;
• аккаунта.

VPN не обязан быть причиной.

Особенно если ошибка появилась одновременно и с VPN, и без него.

39. Что посмотреть в логах

Если клиент позволяет посмотреть лог, интересует именно момент запуска проблемного приложения.

Полезно увидеть:

• появляется ли вообще соединение;
• какой destination;
• какой outbound выбран;
• есть ли timeout;
• DNS error;
• direct или proxy.

Если приложение запускается, а в логе Xray вообще ничего нового нет, это сильный признак:

его трафик не попадает в Xray.

Тогда проблема находится до VLESS:

• Proxy Mode;
• TUN;
• routing ОС.

Если Xray видит соединение

Тогда ищем дальше.

Например:

application → TUN → Xray → outbound

уже произошло.

Следующий вопрос:

какой outbound выбрал routing?

Если:

direct

— проверяем правила.

Если:

VLESS

— смотрим сервер, DNS и конечный маршрут.

Это значительно полезнее случайного редактирования профиля.

40. Не меняйте VLESS-параметры первым делом

Если браузер через этот же профиль уже работает, не начинайте с:

• UUID;
• public key;
• SNI;
• fingerprint;
• short ID;
• flow.

Они уже доказали, что способны установить рабочее VLESS-соединение.

Проблема почти наверняка находится выше:

охват трафика → TUN → routing → DNS → конкретное приложение.

Быстрая таблица диагностики

Самая быстрая диагностика

Если VLESS работает в браузере, но не работает в программах, действуйте так:

1. Проверьте режим клиента

Если сейчас Proxy — включите TUN.

2. Перезапустите проблемную программу

Она должна создать новое соединение.

3. Отключите другие VPN

Чтобы они не меняли routes.

4. Проверьте firewall

Особенно если TUN вообще не работает.

5. Проверьте DNS

Если приложения запускаются, но не могут соединиться.

6. Попробуйте другой VLESS-сервер

Для исключения плохого маршрута.

7. Посмотрите лог

Если доступен.

Эти действия обычно намного полезнее полной переустановки VPN.

Что написать поддержке

Не:

сайты работают, игры нет.

А лучше:

Windows 11, HAPP. В Proxy Mode Chrome работает через VLESS. Discord Desktop и игры идут напрямую. После включения TUN Discord заработал, но игра всё ещё timeout. Франция и Нидерланды ведут себя одинаково.

Или:

Proxy Mode работает. При включении TUN полностью пропадает интернет даже в браузере. Другие VPN закрыты. После перезагрузки Windows ситуация сохраняется.

Во втором случае уже очевидно:

проверять сервер VLESS почти бессмысленно.

Нужно смотреть TUN и системную маршрутизацию.

Когда проблема действительно может быть в VLESS-сервере

Если:

• TUN работает;
• другие приложения идут через VPN;
• только конкретное направление не открывается;
• смена VLESS-локации исправляет проблему,

тогда виноват уже не локальный proxy.

Разница находится после VLESS:

• маршрут;
• server outbound;
• конечный сервис.

Поэтому не нужно впадать в другую крайность и считать TUN причиной вообще всего.

Почему несколько локаций полезны

Один VLESS-сервер не может иметь идеальный маршрут до всех сервисов.

Например:

Нидерланды

лучше для игры,

а:

Франция

лучше для Discord.

Если подписка содержит несколько узлов, переключение занимает секунды.

Это значительно удобнее попыток вручную изменить transport рабочего профиля.

Если нужен VLESS для всех программ

Для такого сценария удобнее использовать полноценную клиентскую схему:

HAPP → TUN → Xray → routing → VLESS/direct.

Xray TUN принимает системный IP-трафик через виртуальный интерфейс, а routing определяет, какой outbound использовать дальше. Это как раз соответствует архитектуре, описанной официальной документацией Project X.

Для пользователя результат простой:

• зарубежные приложения можно отправить через VLESS;
• локальные ресурсы оставить напрямую;
• не настраивать proxy вручную в каждой программе.

Если нужен готовый VLESS

Если не хочется самостоятельно:

• поднимать Xray;
• настраивать сервер;
• собирать routing;
• следить за инфраструктурой,

можно использовать готовую подписку.

На VLESS.ART доступны VLESS-ключи и подписки для HAPP и совместимых клиентов с несколькими серверными локациями.

Посмотреть тарифы:
https://vless.art/#tarif

Если возникла проблема с конкретной программой или TUN:

Поддержка:
https://vless.art/#support

Итог

Если VLESS работает в браузере, но не работает в программах, это очень часто означает, что VLESS как таковой уже исправен.

Браузер использует локальный proxy:

Browser → SOCKS/HTTP inbound → Xray → VLESS

а другие приложения могут вообще не отправлять туда свой трафик.

Официальная архитектура Xray строится именно вокруг Inbound → Routing → Outbound: трафик сначала должен каким-либо способом попасть в Xray, только после этого routing сможет направить его через VLESS.

Для системного подключения предназначен TUN.

Он создаёт виртуальный сетевой интерфейс, а системная routing table направляет туда нужный IP-трафик. Xray затем обрабатывает его и выбирает outbound.

Поэтому главный порядок диагностики:

Proxy → TUN → routing → DNS → UDP → firewall → другой сервер.

Если после включения TUN программа заработала — причина была не в VLESS-сервере.

Если Proxy работает, а TUN полностью ломает интернет — проверяйте локальные routes, firewall и другие VPN.

Если TUN работает почти со всеми программами, кроме одной — смотрите настройки и сетевой трафик именно этого приложения.

И только если приложение действительно попадает в Xray и отправляется в VLESS outbound, но соединение всё равно не устанавливается, имеет смысл снова возвращаться к серверу и маршруту.

То есть браузер, который уже работает через VLESS, — не просто странный симптом.

Это довольно полезный диагностический факт: базовое VLESS-соединение уже существует, а искать проблему нужно в том, как остальной трафик компьютера попадает в него.