Linux: настройка VLESS через GUI, CLI и systemd

VLESS на Linux можно настроить двумя нормальными способами: через графический клиент или через сетевое ядро в командной строке. Первый вариант быстрее для ноутбука и desktop-сессии. Второй лучше для постоянного запуска, серверов, мини-ПК, роутеров и ситуаций, где нужно понимать каждый слой: inbound, outbound, DNS, routing, systemd и TUN.

Эта статья не про покупку доступа и не про настройку сервера. Предполагается, что у вас уже есть профиль: одиночная ссылка vless://..., QR-код, subscription URL, sing-box JSON или Xray JSON. Задача Linux-клиента — корректно прочитать эти параметры, поднять локальный proxy или TUN, отправить трафик через нужный outbound и дать логи, если что-то не работает.

#Что нужно заранее

• Профиль подключения. Это может быть VLESS-ссылка, подписка или готовый JSON. Не публикуйте полный профиль в чатах: UUID, Reality public key, shortId, домен и token подписки могут быть чувствительными.
• Понимание связки. Запишите хотя бы тип: VLESS + Reality + RAW/TCP + Vision, VLESS + TLS + WebSocket, VLESS + gRPC или другой вариант. Слово VLESS само по себе недостаточно для диагностики.
• Совместимый клиент или core. Старый Xray/sing-box может не понимать новые поля Reality, XHTTP, flow или формат подписки.
• Права администратора. Для установки пакетов, systemd-сервиса, TUN и маршрутов обычно нужны sudo или заранее выданные Linux capabilities.
• Один профиль для первого теста. Не начинайте с пяти подписок, сложного rule-set, TUN, custom DNS и автозапуска одновременно.

#GUI-клиент или CLI: как выбрать

GUI-клиент подходит, если Linux используется как обычная рабочая станция. В интерфейсе проще импортировать QR-код или subscription URL, выбрать узел, включить системный proxy или TUN и быстро увидеть статус. Для Linux сейчас чаще встречаются Hiddify, v2rayN, NekoRay/форки и похожие клиенты. Проверяйте не только название, но и источник, дату релиза, поддерживаемый core и формат профиля.

CLI нужен, когда машина работает без графики, подключение должно стартовать до входа пользователя, требуется понятный systemd unit или нужно точно контролировать DNS/routing. В таком сценарии обычно выбирают Xray-core или sing-box. Оба могут работать как клиентский процесс: локальный SOCKS/HTTP inbound принимает трафик от приложений, а VLESS outbound отправляет его на сервер.

#Установка и источники пакетов

На Linux опасно ставить первый найденный архив с названием «vless client». Клиент получает доступ к сетевому трафику, может менять маршруты и DNS, а в TUN-режиме часто требует повышенные права. Используйте официальные репозитории, GitHub Releases проекта, документацию разработчика или пакетный репозиторий, который явно указан upstream.

• Hiddify. Официальный проект описывает приложение как мультиплатформенный proxy-клиент для Android, iOS, Windows, macOS и Linux на базе sing-box, с remote profiles, TUN mode и поддержкой VLESS/Reality.
• v2rayN. Репозиторий 2dust/v2rayN описывает его как GUI-клиент для Windows, Linux и macOS с поддержкой Xray, sing-box и других ядер.
• Xray-core. Project X указывает официальные Linux-скрипты установки, Docker-образ и варианты пакетов; для запуска на Linux конфиг обычно лежит в /etc/xray/ или /usr/local/etc/xray/.
• sing-box. Официальная документация дает репозитории для APT/DNF и отмечает, что на systemd-системах пакет обычно уже включает сервис sing-box.
• AUR и сторонние пакеты. Удобны на Arch-подобных системах, но проверяйте PKGBUILD, maintainer, источник бинарника и свежесть версии.

Если используете AppImage, проверьте исполняемый бит: chmod +x имя-файла.AppImage. Если приложение не стартует на Wayland или в минимальной системе, проблема может быть не в VLESS, а в зависимостях GUI, sandbox, FUSE, tray-индикаторе или правах на создание сетевого интерфейса.

#Настройка через GUI-клиент

1. Установите клиент из проверенного источника. Сверьте GitHub-репозиторий, домен проекта, имя файла и архитектуру Linux: x86_64, arm64 или другой вариант.
2. Импортируйте профиль без ручного перепечатывания. Для одиночного узла используйте vless:// из буфера или QR; для списка узлов добавляйте subscription URL именно в раздел подписок/remote profiles.
3. Выберите один узел. Для первого теста отключите auto-select, сложные routing groups и экспериментальные режимы.
4. Проверьте обычный proxy-режим. Если клиент поднимает SOCKS/HTTP на 127.0.0.1, настройте браузер или системный proxy и откройте тестовый сайт.
5. Только затем включайте TUN. TUN требует больше прав и меняет маршруты для всей системы; при ошибке может пропасть интернет до остановки клиента.
6. Посмотрите логи клиента. Важны не только слова Connected/Disconnected, а строки про handshake, DNS, route, timeout, unsupported option и permission denied.

У GUI есть ограничение: он может скрывать сгенерированный JSON. Если статус зеленый, но сайты не открываются, ищите режим работы. Иногда включен только локальный proxy, а приложения не используют proxy-настройку. Иногда TUN включен, но DNS остался системным. Иногда подписка импортировалась как список узлов без правил маршрутизации, и клиент применил собственные defaults.

#CLI с Xray-core

Xray-core удобно использовать, когда у вас есть готовый Xray JSON или VLESS-ссылка, которую можно конвертировать в outbound. В официальной документации Project X для Linux указан типовой запуск: xray run -c /etc/xray/config.json, а конфиги обычно находятся в /etc/xray/ или /usr/local/etc/xray/. Если Xray установлен официальным install-скриптом, FHS-пути часто включают /usr/local/bin/xray, /usr/local/etc/xray/*.json и systemd unit.

Минимальная клиентская модель выглядит так: локальный inbound принимает трафик от программ, VLESS outbound идет к серверу, routing отправляет нужные соединения в нужный outbound, DNS отвечает за резолвинг. Не вставляйте серверный inbound в клиентский конфиг: клиенту обычно нужен локальный SOCKS/HTTP inbound и удаленный VLESS outbound.

• VLESS outbound. Проверьте address, port, id, encryption, flow, streamSettings.network и streamSettings.security.
• Reality. Сравните serverName/sni, fingerprint, public key, shortId и spiderX с исходным профилем.
• DNS. Xray DNS связан с routing: DNS-запросы встроенного сервера могут идти по маршрутам, а domainStrategy влияет на сопоставление доменов и IP.
• TUN. Xray TUN создает интерфейс на Linux, но не меняет системную таблицу маршрутизации автоматически. Маршруты нужно продумать отдельно, иначе интерфейс существует, а трафик в него не идет.

#CLI с sing-box

sing-box часто удобнее для Linux TUN-сценариев, потому что его конфигурация явно делит dns, route, inbounds и outbounds, а TUN inbound имеет много Linux-специфичных опций. В официальной установке через пакетный менеджер на systemd-системах обычно появляется сервис sing-box. Управление типовое: sudo systemctl start sing-box, sudo systemctl restart sing-box, sudo systemctl enable sing-box, логи через sudo journalctl -u sing-box --output cat -f.

Для ручного теста используйте команду вида sudo sing-box run -c /etc/sing-box/config.json, если именно там лежит ваш конфиг. Внутри JSON проверьте tags: inbounds[].tag, outbounds[].tag, route.final, DNS server tags и route rules. Ошибка в регистре тега, например proxy против Proxy, может сломать маршрутизацию без очевидного сообщения для пользователя.

• Proxy-режим. Начните с mixed, socks или http inbound на localhost. Это проще, чем сразу TUN.
• TUN-режим. Используйте tun inbound только после базовой проверки outbound. Для Linux важны auto_route, auto_redirect, strict_route и nftables.
• Loop prevention. Документация sing-box рекомендует предотвращать loopback через route.auto_detect_interface, route.default_interface или outbound.bind_interface.
• DNS. В TUN-сценариях проверьте DNS rules, final DNS server, FakeIP, hijack-dns и IPv4/IPv6 strategy.

#systemd и автозапуск

systemd нужен после того, как конфиг уже запускается вручную. Он не исправляет JSON, не выдает магически права на TUN и не обновляет подписку сам по себе. Зато systemd дает автозапуск, перезапуск после сбоя, единый журнал и понятный жизненный цикл процесса.

Если вы пишете собственный unit, не запускайте процесс от случайного desktop-пользователя только потому, что так заработало в терминале. Для TUN и маршрутов процессу могут понадобиться root-права или capabilities, например CAP_NET_ADMIN. В systemd это обычно оформляют через настройки вроде AmbientCapabilities=CAP_NET_ADMIN и CapabilityBoundingSet=CAP_NET_ADMIN, но конкретная схема зависит от дистрибутива, namespace, пути к бинарнику и политики безопасности.

#TUN-права и маршруты на Linux

TUN создает виртуальный сетевой интерфейс. В обычном proxy-режиме приложение работает только с программами, которые явно используют SOCKS/HTTP proxy. В TUN-режиме Linux-маршруты направляют трафик системы в виртуальный интерфейс, а Xray или sing-box обрабатывает его дальше. Поэтому TUN ломается не так, как обычный proxy: здесь участвуют /dev/net/tun, capabilities, route table, nftables/iptables, NetworkManager, Docker, firewalld/ufw и IPv6.

Для Xray важно помнить: официальный TUN inbound создает интерфейс на Linux, но Xray не меняет системную таблицу маршрутизации автоматически. Если вы создали xray0, но не добавили маршруты, трафик туда не попадет. Если добавили слишком широкий default route, исходящее соединение самого Xray может вернуться в Xray и получить routing loop. Документация предлагает избегать петли через привязку к реальному интерфейсу в sockopt.interface или через sendThrough.

Для sing-box Linux TUN чаще автоматизирован: auto_route может выставлять маршрут в TUN, а auto_redirect использует nftables для улучшения маршрутизации и производительности. Но автоматизация не отменяет проверки. Если включены Docker bridge networks, VPN другого клиента, корпоративный агент, локальный firewall или необычный routing policy, TUN может работать иначе, чем в чистой инструкции.

• Permission denied / operation not permitted. Проверьте, есть ли /dev/net/tun, запущен ли процесс с нужными правами и не режет ли systemd unit capabilities.
• Интернет пропал сразу после TUN. Остановите сервис, верните маршруты, затем проверьте auto_route, route final, default interface и исключения локальной сети.
• Не открывается локальная сеть. Добавьте direct-исключения для private IP, роутера, принтера, NAS, Docker/VM подсетей и корпоративных адресов.
• Петля подключений. Убедитесь, что исходящий трафик самого core не отправляется обратно в TUN: используйте auto_detect_interface/default_interface/bind_interface или Xray sockopt/sendThrough.
• ICMP/ping ведет себя иначе. Не все TUN-стэки одинаково обрабатывают ICMP; проверяйте TCP-сайт и DNS отдельно, а не только ping.

#DNS и routing

На Linux DNS часто становится причиной симптома «клиент подключен, но сайты не открываются». У системы может быть systemd-resolved, NetworkManager, статический /etc/resolv.conf, DNS от Wi-Fi, DNS от корпоративного клиента и DNS внутри Xray/sing-box. Если включить TUN, но оставить DNS снаружи, часть запросов может идти мимо ожидаемого маршрута. Если весь DNS загнать в proxy без исключений, может сломаться резолвинг самого proxy-сервера.

В Xray встроенный DNS используется вместе с routing: domainStrategy определяет, когда домен резолвится в IP для сопоставления правил, а DNS-запросы встроенного сервера могут следовать маршрутизации. В sing-box похожая логика выражена через dns.servers, dns.rules, dns.final, route.rules и route.final. В TUN-сценариях также встречается перехват DNS-запросов через hijack-dns.

1. Найдите маршрут по умолчанию. В sing-box это route.final; если он пустой, смотрите порядок outbounds. В Xray смотрите routing rules и первый outbound.
2. Проверьте DNS final. DNS по умолчанию не обязан совпадать с proxy-маршрутом, но выбор должен быть осознанным.
3. Проверьте IPv6. Если сеть плохо поддерживает IPv6, сайты могут зависать при попытке использовать AAAA-записи. Не отключайте IPv6 вслепую навсегда, но включите его в диагностику.
4. Оставьте локальные адреса direct. Роутер, локальный DNS, принтер, NAS, Docker, libvirt и приватные подсети часто должны обходить proxy.
5. Не смешивайте сразу FakeIP, DoH, TUN и rule-set. Добавляйте по одному, иначе невозможно понять, где появилась ошибка.

#Логи: где смотреть

На Linux логи — не вспомогательная деталь, а основной способ не гадать. Для packaged sing-box официальный маршрут — journalctl -u sing-box. Для Xray зависит от установки: при официальном install-скрипте есть пути под /var/log/xray/, но README отдельно предупреждает, что Xray не пишет в эти файлы по умолчанию без блока log в конфиге. Если service запускает процесс в stdout/stderr, смотрите systemd journal.

• После изменения конфига выполните restart и сразу откройте хвост журнала: sudo journalctl -u sing-box --output cat -f или sudo journalctl -u xray --output cat -f.
• Для короткой диагностики временно включайте более подробный log level. После теста верните обычный уровень, чтобы не хранить лишние адреса и домены.
• Перед отправкой логов удалите UUID, subscription URL, Reality public key/shortId, домены серверов, реальные IP и личные названия профилей.
• Если логов нет, проверьте, запускается ли именно тот unit, тот binary и тот config path, который вы редактируете.

#Troubleshooting

#Итоговый чеклист

1. Определите маршрут. Desktop и быстрый импорт — GUI; headless, автозапуск и прозрачная диагностика — CLI.
2. Проверьте источник клиента. Официальный сайт, GitHub Releases, upstream repository или понятный пакетный репозиторий.
3. Зафиксируйте тип профиля. VLESS + Reality/TLS + transport + flow, без публикации секретов.
4. Запустите без TUN. Сначала локальный SOCKS/HTTP proxy и один сайт, затем DNS/routing, затем TUN.
5. Запустите вручную. Только после успешного xray run -c или sing-box run -c переносите конфиг в systemd.
6. Проверьте systemd. status, restart, enable, journalctl -u ... -f.
7. Разберите TUN отдельно. /dev/net/tun, root или CAP_NET_ADMIN, auto_route/auto_redirect, nftables, default interface и исключения LAN.
8. Разберите DNS отдельно. systemd-resolved/NetworkManager, DNS final, route final, hijack-dns, IPv6 и утечки.
9. Меняйте одну вещь за раз. Иначе Linux-настройка VLESS превращается в набор случайных правок без воспроизводимой причины.

Надежная настройка VLESS на Linux строится слоями. Сначала доверенный клиент и корректный профиль. Затем ручной запуск и понятные логи. Потом systemd для постоянной работы. И только после этого TUN, DNS и сложные правила маршрутизации. Такой порядок не самый эффектный, зато он быстро показывает, где именно ломается цепочка: в профиле, ядре, правах Linux, маршрутах или DNS.