В sing-box добавлен протокол Snell

В sing-box добавлен Snell

В sing-box 1.14.0 добавлена поддержка прокси-протокола Snell.

Inbound: Snell - sing-box
Outbound: Snell - sing-box

Snell — это зашифрованный прокси-протокол от разработчиков Surge.

Зачем он нужен

Его сильные стороны:

  • зашифрованный трафик, похожий на случайный поток;
  • простая схема с PSK, как у Shadowsocks;
  • мультиплексирование соединений;
  • нормальная TCP-семантика, без грубого ломания поведения соединений;
  • multi-user режим на одном сервере;
  • в Snell v6 — traffic shaping, то есть изменение характеристик трафика, а не просто “рандомные байты”.

Главная идея Snell v6 — не притворяться HTTPS/TLS, а делать трафик менее одинаковым между разными установками. Профиль трафика зависит от ключа, поэтому разные серверы с разными PSK могут выглядеть по-разному.

Поддержка в sing-box

Для inbound доступны версии:

"version": 5

или

"version": 6

Важно: sing-box не поддерживает QUIC proxy mode из Snell v5, поэтому v5 фактически используется как v4 wire protocol.

Основные параметры

psk

Основной pre-shared key сервера.

Для Snell v6 ключ должен быть длиной от 12 до 255 байт.

"psk": "password"

users

Multi-user режим. Можно задать отдельных пользователей со своими ключами:

"users": [
  {
    "name": "user1",
    "userkey": "user-password"
  }
]

name нужен в основном для логов, userkey — ключ конкретного пользователя. Верхнеуровневый psk остаётся серверным ключом.

obfs_mode

Только для Snell v5.

"obfs_mode": "http"

Возможные значения:

none
http

По умолчанию используется none.

mode

Только для Snell v6. Отвечает за traffic shaping:

"mode": "default"

Возможные значения:

default
unshaped
unsafe-raw

Для обычного использования лучше оставлять:

"mode": "default"

Минимальный inbound v6

{
  "type": "snell",
  "tag": "snell-in",
  "listen": "::",
  "listen_port": 12345,
  "version": 6,
  "psk": "strong-password-123",
  "mode": "default"
}

Коротко

Snell в sing-box — это альтернатива Shadowsocks-подобным прокси. Он интересен не тем, что “маскируется под HTTPS”, а тем, что даёт зашифрованный прокси-трафик с мультиплексированием и, в версии 6, traffic shaping. Для новых конфигураций логичнее смотреть именно на Snell v6.

А какие клиенты его поддерживают?

Оригинальные клиенты sing-box плюс которые используют его в качестве движка

Звучит так, будто разработчики Sing-box в Shadowsocks нашли фатальный недостаток - его делали не они!

А в наших реалиях отсутствие маскировки под TLS делает только хуже - ТСПУ шейпит одиночные соединения, а при достаточной массовости весь сервер улетает в блок. Недавно блокировали такое, задев даже SSH.

Snell тоже делали не они. Изначально это проприетарный протокол от разработчиков Surge. Тут нет никакой подоплеки в плане конкуренции с SS, SS в sing-box тоже есть и остается. Да и отличия от SS существенные. Тут мультиплексирование именно на уровне протокола (плюс полная TCP-семантика). И тут есть маскировка трафика на основе ключа, то есть с разными ключами будут разные профили (framing, padding, размеры пакетов). Для РФ наверное протоколы с TLS лучше, но я бы не стал без тестов уверять, что Snell будет так же блокироваться сразу, как и SS.

По-моему, SS блокируется моментально по принципу “протокол не определен - бан”. С этим будет то же самое, разве что обфускация под http вдруг заработает на каких-то хостингах (если такие существуют)

такого нет, блокируется https через ss/vmess/…, скорее всего по размерам пакетов

На практике встречалось и обратное: tls/http замедлялись, а неизвестный мусор работал. Нормальный tcp протокол со встроенным мультиплексированием - этакий аналог AmneziaWG - не повредит.

Немного удручает бессмысленное раздувание функциональности sing-box с забиванием на проблемы и баги в реализациях прочих протоколов. Ведь всем очень нужны Claude code multiplexer, USB/IP и тому подобное. Надеюсь, автора рано или поздно отпустит.

Уж не знаю как на оригинальном Sing-Box, но в Sing-Box-Extended мультиплексирование из коробки в Snell не работает! Сегодня обновил, настроил, стал проверять. В логах простыня из соединений. Временно пришлось отказаться от использования. У кого оригинал проверьте так ли это.

на мегафоне голый snell палят.

у меня работает по такой схеме: снаружи shadow-tls затем на localhost забинден snell listener.

по клиентам: клеш мета на андроид, а на пк - v2rayN михомо ядро. конфиги написаны на yaml формате с pack-файлом, где указана маршрутизация.

Multiplex не проверял. Сравнивал без него. У меня на сегодня это самый быстрый протокол по пропускной способности и задержкам (на sing-box-extended). Второе место Mieru.
Вы не отписывались автору про multiplex?

Не отписывался пока. Вопрос, какому автору? В sing-box-exended была своя реализация snell, её я не проверял, но недавно обновился до 1.14.0 и там уже автор отказался от собственной реализации snell в пользу нативной upstream-реализации оригинального sing-box по понятным причинам. И вот именно в ней мультиплексирование не работает. То есть в оригинальном sing-box по идее тоже работать не должно.
Поэтому наверно писать имеет смысл сразу секаю, автору sing-box, а я ему писать точно не буду. Наверно ни для кого не секрет, что он, мягко говоря, не совсем адекватный товарищ и ранее были уже у меня с ним недопонимания.

Вы бы хотя бы примеры конфигов для повторение проблемы приложили.

Какие примеры? Конфиги предельно простые и совершенно обычные как указаны в документации.
Inbound Snell - sing-box
Outbound Snell - sing-box
Ничего сверх этого не дописывал. В outbound менял reuse true/false - значения не имеет. Всё равно куча отдельных соединений. Использовал V6.

Прочитай как устроено мультиплексирование в snell протоколе, там используется переиспользование уже открытых tcp соеденений для новых запросов, но если одновременно будет 10 запросов - будет открыто 10 новых, если в пуле нет свободных tcp соеденений для переиспользования, но будут переиспользоваться для других запросов при закрытии

Если что код протокола открыт, и ты можешь прочитатьь его

Действительно, если начать активно сёрфить, открывает сразу с десяток соединений. В дальнейшем они держатся плюс-минус в этом диапазоне. На сайтах типа ютюба открывает сразу 10-15 соединений.
Ну не знаю, есть ли смысл в таком мультиплексировании в нынешних реалиях. Как по мне 10+ это всё же много. Благо альтернатив хватает.
Спасибо за разъяснения.

Это нормально, это наверное золотая середина. Одно соединение – плохо, на каждый коннект новый коннект – плохо, а тут они выбрали что-то между.

И всё же видимо у меня с разработчиками совершенно разные понятия о мультиплексе. Я вот понаблюдал и мне так и остался не ясен смыл.
Вот так выглядят соединения проходящие с компа через роутер по протоколу snell

Спойлер

А вот так выглядят соединения VLESS Reality с XTLS-Vision, в котором мультиплекса нет вообще

Спойлер

Что называется, найдите 10 отличий…

А вот так в моём понимании (и в понимании разработчиков XHTTP видимо тоже) выглядит нормальный мультиплекс, здесь VLESS Reality XHTTP XMUX.

Спойлер

Можно наблюдать часами и ничего не изменится. Если очень активно юзать, то появится максимум ещё одно (лимит установлен в 3), но не при каких обстоятельствах больше не будет.

Так что реализация такого мультиплекса как в snell, если он там есть вообще, достаточно сомнительная, даже в Mieru это сделано более грамотно.