Sing-box и Xray на практике

Cовместимость клиентов и особенности реализации. Работоспособность с разными популярными VPN-клиентами

8 мин чтенияРедакция GatedNet

sing-box и Xray-core решают примерно одну задачу, но заметно отличаются в деталях реализации и в экосистеме вокруг себя.

Оба ядра поддерживают VLESS, REALITY и другие современные прокси-протоколы. Если смотреть только на список возможностей, разница кажется небольшой. Она становится заметнее при использовании разных клиентских приложений: одинаковый профиль может вести себя по-разному в зависимости от того, какое ядро находится внутри клиента.

Особенно хорошо это видно на VLESS + REALITY.

Один протокол — разные реализации

VLESS и REALITY поддерживаются обоими проектами, но общей реализации у sing-box и Xray нет.

У каждого свой код, собственный сетевой стек и свой цикл обновлений. Поэтому одинаковые flow, SNI, public key, short ID и остальные параметры ещё не гарантируют абсолютно одинаковое поведение.

Разница становится заметнее, если посмотреть на популярные клиентские приложения.

Клиент Основное ядро
Hiddify sing-box
Happ Xray-core
v2RayTun Xray-core
INCY Xray-core

Hiddify находится в экосистеме sing-box, тогда как Happ, v2RayTun и INCY используют Xray-core.

На уровне интерфейса это почти незаметно. Пользователь импортирует одну и ту же vless:// ссылку, видит REALITY, SNI, fingerprint и остальные знакомые параметры.

Но после импорта профиль превращается во внутреннюю конфигурацию конкретного ядра. И здесь поведение уже может отличаться.

Совместимость с популярными клиентами

Для сравнения использовалась обычная конфигурация VLESS + REALITY без CDN и промежуточного reverse proxy.

Связка sing-box + Hiddify работала стабильно. Порт существенной роли не играл:

sing-box → Hiddify → 443   OK
sing-box → Hiddify → 8443  OK
sing-box → Hiddify → 9443  OK

С Happ, v2RayTun и INCY поведение оказалось другим.

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

После замены sing-box на Xray-core при аналогичной VLESS + REALITY конфигурации профиль заработал во всех проверенных приложениях:

Xray → Hiddify     OK
Xray → Happ        OK
Xray → v2RayTun    OK
Xray → INCY        OK

Это не универсальное правило совместимости. Xray-клиенты могут работать с sing-box, а sing-box-клиенты — с Xray.

Но на практике одинаковая заявленная поддержка VLESS + REALITY ещё не означает полностью одинаковое поведение разных реализаций.

Почему клиент показывает ping, но соединение не работает

Проверка задержки и полноценная передача трафика — не одно и то же.

Соединение проходит несколько этапов:

доступность IP
     ↓
TCP-соединение
     ↓
REALITY / TLS
     ↓
VLESS
     ↓
transport / flow
     ↓
routing / TUN
     ↓
пользовательский трафик

Конкретная реализация проверки зависит от клиента, поэтому успешный ping может подтверждать только часть этой цепочки.

Отсюда вполне возможна ситуация:

Latency: 42 ms
Status: connected

Браузер: соединения нет

Сам сервер при этом доступен, но проблема возникает уже на одном из следующих уровней.

Причиной может оказаться обработка flow, параметры REALITY, fingerprint, transport, TUN или преобразование исходной ссылки во внутреннюю конфигурацию приложения.

У subscription-ссылки вообще довольно длинный путь:

vless://
   ↓
парсер клиента
   ↓
внутренняя модель конфигурации
   ↓
sing-box или Xray
   ↓
TUN / сетевой стек ОС

Поэтому две программы могут импортировать одну ссылку без ошибок, но в результате сформировать немного отличающиеся конфигурации.

443, 8443 или 9443

VLESS и REALITY не становятся другими протоколами при смене порта.

Если нужный TCP-порт доступен и по отношению к нему нет отдельной фильтрации, с точки зрения самого протокола особой разницы между:

443
8443
9443

нет.

Это хорошо видно на связке sing-box + Hiddify, которая в тестах одинаково работала на всех трёх портах.

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

Если один и тот же профиль работает через Hiddify на 443, 8443 и 9443, но не передаёт трафик через другой клиент, причина с большей вероятностью находится выше TCP-уровня.

Почему sing-box + Hiddify ведёт себя предсказуемее

Hiddify использует sing-box в основе своего сетевого ядра. В результате с обеих сторон оказывается одна экосистема:

sing-box
    ↓
VLESS / REALITY
    ↓
Hiddify
    ↓
sing-box based core

При использовании Xray-клиента появляются две независимые реализации протокола:

sing-box
    ↓
VLESS / REALITY
    ↓
Xray-core
    ↓
клиент

Это нормальная ситуация: протокол как раз и нужен для взаимодействия независимых реализаций.

Но различия в версиях, TLS-стеке, обработке REALITY или отдельных параметров могут проявляться именно на этой границе.

С Xray ситуация немного другая. Значительная часть популярных VLESS-клиентов уже использует Xray-core, поэтому связка получается однородной:

Xray → Happ
Xray → v2RayTun
Xray → INCY

При этом Hiddify также умеет работать с VLESS + REALITY профилями Xray.

На практике это даёт Xray довольно широкую совместимость с существующей клиентской экосистемой.

Как выглядит один и тот же inbound

На уровне базовой конфигурации оба ядра описывают практически одну и ту же конструкцию.

sing-box

{
  "inbounds": [
    {
      "type": "vless",
      "listen": "::",
      "listen_port": 443,
      "users": [
        {
          "uuid": "USER_UUID",
          "flow": "xtls-rprx-vision"
        }
      ],
      "tls": {
        "enabled": true,
        "reality": {
          "enabled": true,
          "handshake": {
            "server": "example.com",
            "server_port": 443
          },
          "private_key": "PRIVATE_KEY",
          "short_id": [
            "SHORT_ID"
          ]
        }
      }
    }
  ]
}

Xray

{
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "USER_UUID",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": {
          "target": "example.com:443",
          "privateKey": "PRIVATE_KEY",
          "shortIds": [
            "SHORT_ID"
          ]
        }
      }
    }
  ]
}

Структура отличается довольно заметно.

В Xray сетевые параметры в основном собраны вокруг streamSettings. У sing-box TLS и REALITY находятся непосредственно внутри соответствующих объектов inbound.

На простом VLESS-конфиге это скорее вопрос привычки. На более сложных конфигурациях различия в архитектуре становятся заметнее.

API тоже устроены по-разному

У Xray есть gRPC API и HandlerService, позволяющий изменять пользователей работающего inbound без пересборки всей конфигурации.

У sing-box собственного аналога HandlerService сейчас нет. Его V2Ray API в первую очередь используется для статистики, а управление пользователями обычно приходится строить отдельно.

Если требуется динамически добавлять и удалять пользователей, вокруг sing-box, скорее всего, понадобится собственный небольшой сервис или другой механизм управления конфигурацией.

На этом различия API для обычного сравнения, пожалуй, можно закончить: это скорее архитектурная особенность двух проектов, чем преимущество одного протокола над другим.

В чём sing-box заметно отличается

sing-box выходит далеко за рамки VLESS.

В одном ядре собраны:

VLESS
Hysteria2
TUIC
Shadowsocks
Trojan
TUN
DNS
rule sets
маршрутизация

Особенно хорошо это заметно на клиентской стороне.

Для приложения, которому нужно поднять системный TUN, обработать DNS, выбрать маршрут для конкретного домена и одновременно поддерживать несколько совершенно разных прокси-протоколов, такая архитектура удобна.

Hiddify — хороший пример подобного подхода.

В чём отличается Xray

Xray сильнее связан с экосистемой V2Ray/XTLS.

Здесь особенно много внимания уделяется VLESS, REALITY, Vision и связанным транспортам. Одновременно вокруг Xray сформировалась большая экосистема клиентских приложений.

Именно поэтому один и тот же VLESS-профиль довольно часто оказывается хорошо совместим сразу с несколькими популярными клиентами.

Есть и уже упомянутый HandlerService, которого нет в sing-box.

В итоге различие скорее выглядит так:

sing-box — более универсальный сетевой движок с большим количеством протоколов, сильным TUN и развитой маршрутизацией.

Xray — более специализированная экосистема вокруг VLESS/XTLS с широкой представленностью в существующих клиентах и более развитым runtime API.

Таблица тестов

Чтобы сравнение не оставалось только субъективным впечатлением, проще всего прогнать одинаковую конфигурацию по одной матрице.

Core Client 443 8443 9443 Ping Трафик
sing-box Hiddify ✅ ✅ ✅ ✅ ✅
sing-box Happ — — — ✅ ❌
sing-box v2RayTun — — — ✅ ❌
sing-box INCY — — — ✅ ❌
Xray Hiddify ✅ ✅ ✅ ✅ ✅
Xray Happ ✅ ✅ ✅ ✅ ✅
Xray v2RayTun ✅ ✅ ✅ ✅ ✅
Xray INCY ✅ ✅ ✅ ✅ ✅

Для чистого теста стоит использовать одинаковые:

  • версии протокола;
  • flow;
  • SNI;
  • fingerprint;
  • REALITY destination;
  • public/short ID;
  • сетевые условия.

А затем проверить не только встроенный ping, но и обычный HTTP/HTTPS-трафик.

Итого

Если смотреть на документацию, sing-box и Xray во многом пересекаются.

Оба умеют VLESS, REALITY, TUN и множество других необходимых вещей. Но одинаковые названия протоколов скрывают две независимые реализации и две довольно разные экосистемы.

В тестах наиболее предсказуемой связкой для sing-box оказался Hiddify — клиент, который сам построен вокруг sing-box.

Xray показал более ровную совместимость с набором популярных VLESS-клиентов: Happ, v2RayTun, INCY и Hiddify.

У sing-box при этом заметно шире набор возможностей универсального сетевого ядра, особенно если речь идёт о TUN, DNS, маршрутизации и работе сразу с несколькими протоколами.

У Xray есть другая практическая особенность — большая клиентская экосистема и HandlerService для runtime-управления пользователями.

Поэтому выбирать между ними только по списку поддерживаемых протоколов не очень полезно. Гораздо показательнее посмотреть, с какими клиентами будет использоваться конфигурация и какие возможности самого core действительно нужны.

О публикации

Материал подготовлен редакцией GatedNet. Мы отделяем факты от мнений и обновляем публикации, когда появляется новая важная информация.

Наверх