Полных аналогов не существует. Тут все-таки конкретная ниша - управление чистым sing-box с чистым универсальным переносимым между различными устройствами конфигом. Все существующее - это клиенты с GUI, где конфиг частично накидывается "мышкой" (без полного понимания что именно в конце будет передано в ядро), что не покрывает 100% возможностей ядра.
Упомянутая вами программа - это результат вайб-кодинга, где часть просто не работает, потому что никто не проверял. Например, плавное завершение ядра в этой программе было заявлено с первой версии, но десятки строк кода просто не работали (LLM их написала, но они не работали, никто их не проверил). А спустя несколько месяцев автор (Leadaxe) создал issue в репозитории sing-box, что, оказывается, ядро плавно невозможно завершить (https://github.com/SagerNet/sing-box/issues/3806). Это само собой не так. Вариант плавного завершения в том числе описан в этой статье. Так что о singbox-launcher у меня мнение крайне негативное.
Хочется использовать чистое свежее ядро с оригинальным json-конфигом (который я использую на всех устройствах). Без угадывания, что в каком окошке на что влияет. Без зависимости от промежуточного звена в виде переусложненного клиента (со своими багами). Развернуто я об этом писал в предыдущей статье: https://habr.com/ru/articles/1018964/
Как раз про это меню написано в самом начале. Чтобы выключить (или потом включить) системный прокси в Nekobox (и его форке Throne) нужно кликнуть на значок, переместить курсор на "системный прокси", потом переместить курсор на "отключить", потом только клик. Вместо одного клика по значку. Да, решается хитрой раздельной маршрутизацией (чтобы переключать вообще было не нужно).
Мне не нравится то, как разрабатывается Throne. То одно ломается, то другое. А оригинальный Nekobox уже заброшен.
В конфигурации выше используется 2 DNS для разных доменов, но все внешние. Можете просто указать один local, или добавить какие-то особые правила. Конфигурация очень гибкая, добиться можно почти чего угодно.
Я против публичного обсуждения благотворительности, но на публичное "обвинение" отвечу. Начать хотя бы с того, что доступ дается за любой единоразовый платеж. Я подключил ежемесячные платежи на хорошую сумму. Я стараюсь продвигать sing-box статьями на хабре, что идет в плюс автору (даже скорее всего финансово). Я пофиксил несколько багов в коде (один из них описан тут), PR приняты. Плюс добавил новое правило package_name_regex, будет в релизе в версии 1.14. Так что мои отношения с sing-box строятся именно на любви к продукту, а не на получении благ за деньги. Но конечно можно назвать это эгоизмом, потому что я сам пользуюсь программой и хочу сделать её лучше.
Да, прошу прощения, не сделал на этом акцента. Показалось, что если мы говорим о настройке своего сервера, то покупка домена не сложнее (и не дороже) аренды сервера.
Да, прошу прощения, я не обозначил это в статье. Конфигурация из статьи подразумевает наличие своего домена. Но можно обойтись и без него, но тогда не будет защиты от активного сканирования. Вариант с self-signed сертификатом. Caddy нужно будет настроить иначе. И в клиентской конфигурации sing-box в секции tls указать `insecure: true`.
При связке, описанной в статье, UDP работает. Я отдельно упомянул параметр udp_over_tcp. С клиентами на базе sing-box тоже работает. И с популярным Shadowrocket работает.
По поводу скорости всё индивидуально, можно сделать замеры. ИИ так мог ответить из-за режима Splice в Vision Reality, но он скорее про нагрузку сервера, да и включается не всегда (зависит от условий). И наоборот, у Vision Reality есть принципиальная проблема (особенность) с отсутствием мультиплексирования и необходимостью на каждое новое подключение подключаться к удаленному серверу для получения сертификата, что создает существенные задержки на каждое устанавливаемое соединение (а если сайт-донор еще и тормозит или блокирует частые подключения, то становится совсем плохо).
А вот то, что переходить с VLESS на Naive нет смысла, если VLESS хорошо работает - это верно (я об этом тоже сказал в заключении статьи).
К сожалению, проблема TLS in TLS остается. Вот что автор пишет в своей документации:
Соединение TLS поверх TLS требует большего количества циклов обмена данными (round trips) при рукопожатии, чем необходимо для обычных HTTP/2 (h2) запросов; иными словами, ни одному h2-запросу не нужно такое количество двусторонних обменов при установке соединения. Простого способа избежать этого нет, кроме использования MITM-проксирования, что нарушает сквозное (E2E) шифрование.
Накладные расходы TLS поверх TLS приводят к заметному увеличению длины пакетов и отсутствию пакетов малого размера. Устранение этих издержек также требует MITM-проксирования.
Кроме того, из-за накладных расходов TLS поверх TLS размер пакетов постоянно превышает лимиты MTU, чего не должно происходить со стороны исходного пользовательского агента (клиента). Решение этой проблемы требует повторной сегментации (re-segmentation), что реализовать непросто.
По сути маскируется это только мультиплексированием множества конечных соединений внутри одного туннеля (поэтому автор и рекомендует insecure_concurrency = 1), что затрудняет анализ длины и отчасти скрывает TLS in TLS.
Это сложно сделать из-за того, что VLESS очень сильно отличается в зависимости от настроек и транспорта (Vision, XHTTP, gRPC, Reality и прочее). И даже Vision работает сильно по-разному в зависимости от трафика, который он прогоняет (где-то включается Splice, а где-то нет).
Основное же отличие Naive я постарался описать в разделах "ClientHello и uTLS" и "О NaïveProxy". А к чему реально будет в дальнейшем привязываться цензор (какая особенность того или иного протокола будет мешать или помогать) - неизвестно. Может вообще все закончится белыми списками, а не анализом протоколов.
Согласен. Опять же нужна иностранная карта для доната. Но поддержка Naive есть не только в sing-box. В очень популярном Shadowrocket она есть. В бесплатном Karing тоже есть (ядро sing-box).
Скорее всего у вас используется протокол, который не совместим с мультиплексированием (или мультиплексирование отключено). Мультиплексирование - это когда несколько ваших соединений помещаются в один туннель до прокси. Соответственно без этого подключений до прокси много, что детектируется и приводит к блокировке IP. Решение - использование протоколов с мультиплексированием. Например, VLESS + XHTTP или NaiveProxy. Свежая статья о NaiveProxy: https://habr.com/ru/articles/1024990/
Дочитайте, пожалуйста, подраздел до конца. Следующее предложение после процитированного вами:
Для маскировки оба проекта используют библиотеку uTLS, которая позволяет сделать ClientHello похожим на ClientHello реального браузера (Chrome, Firefox или др.).
Как раз uTLS (о котором подраздел) и обеспечивает похожий на браузерный ClientHello, если он включен через конфиг. Если не использовать uTLS, то будет стандартный ClientHello от Go (в случае программы, написанной на Go).
Я задонатил автору sing-box через github (благодарность за хорошую программу). За это дается доступ к приватному telegram-чату с доступом к свежей версии sing-box для iOS и macOS.
Вы можете все равно направлять все в tun, но дальше уже управлять гибкими правилами маршрутизации.
Вам нужно редактировать секцию route. Сначала поменять значение final на direct. Это через что все будет идти, если не будет совпадений по правилам. Правила из rules проверяются сверху вниз до первого действия с action route. Если хотите конкретные приложения в прокси, то указываете их список в package_name, а outbound меняете на proxy-select или на tag конкретного сервера.
Работает с UDP. Конфиг сервера из моего коммента выше. Конфиг клиента из статьи (с udp_over_tcp). На клиенте должен быть включен TUN, чтобы UDP шли в прокси.
Отправил автору sing-box issue с предложением по PR, переписываюсь с ним в tg-чате. Хочу, чтобы появилась возможность ловить правилом такие соединения, когда не удается распознать package name: https://github.com/SagerNet/sing-box/issues/4009
Проблема изначально, что из-за выбора интерфейса не работает поиск процесса getConnectionOwnerUid. Это API появилось, когда Google стал ограничивать доступ к /proc/net. И когда добавляли, то непривилегированные приложения еще не могли использовать SO_BINDTODEVICE. Так что скорее всего это пробел в дизайне API — его спроектировали под реалии, когда обычные приложения не могли привязывать сокеты к интерфейсам.
Упомянутая вами программа появилась позже моей.
Полных аналогов не существует. Тут все-таки конкретная ниша - управление чистым sing-box с чистым универсальным переносимым между различными устройствами конфигом. Все существующее - это клиенты с GUI, где конфиг частично накидывается "мышкой" (без полного понимания что именно в конце будет передано в ядро), что не покрывает 100% возможностей ядра.
Упомянутая вами программа - это результат вайб-кодинга, где часть просто не работает, потому что никто не проверял. Например, плавное завершение ядра в этой программе было заявлено с первой версии, но десятки строк кода просто не работали (LLM их написала, но они не работали, никто их не проверил). А спустя несколько месяцев автор (Leadaxe) создал issue в репозитории sing-box, что, оказывается, ядро плавно невозможно завершить (https://github.com/SagerNet/sing-box/issues/3806). Это само собой не так. Вариант плавного завершения в том числе описан в этой статье. Так что о singbox-launcher у меня мнение крайне негативное.
Спасибо за комментарий.
Хочется использовать чистое свежее ядро с оригинальным json-конфигом (который я использую на всех устройствах). Без угадывания, что в каком окошке на что влияет. Без зависимости от промежуточного звена в виде переусложненного клиента (со своими багами). Развернуто я об этом писал в предыдущей статье: https://habr.com/ru/articles/1018964/
Как раз про это меню написано в самом начале. Чтобы выключить (или потом включить) системный прокси в Nekobox (и его форке Throne) нужно кликнуть на значок, переместить курсор на "системный прокси", потом переместить курсор на "отключить", потом только клик. Вместо одного клика по значку. Да, решается хитрой раздельной маршрутизацией (чтобы переключать вообще было не нужно).
Мне не нравится то, как разрабатывается Throne. То одно ломается, то другое. А оригинальный Nekobox уже заброшен.
Без root нельзя. С root имя можно менять в том же sing-box прямо в интерфейсе программы.
В sing-box похожего можно добиться через правила маршрутизации с версии 1.14.0 https://sing-box.sagernet.org/configuration/route/rule/#package_name_regex
Правило сработает, если не удается распознать имя приложения (при SO_BINDTODEVICE).
В конфигурации выше используется 2 DNS для разных доменов, но все внешние. Можете просто указать один local, или добавить какие-то особые правила. Конфигурация очень гибкая, добиться можно почти чего угодно.
https://sing-box.sagernet.org/configuration/dns/server/local/
Я против публичного обсуждения благотворительности, но на публичное "обвинение" отвечу. Начать хотя бы с того, что доступ дается за любой единоразовый платеж. Я подключил ежемесячные платежи на хорошую сумму. Я стараюсь продвигать sing-box статьями на хабре, что идет в плюс автору (даже скорее всего финансово). Я пофиксил несколько багов в коде (один из них описан тут), PR приняты. Плюс добавил новое правило package_name_regex, будет в релизе в версии 1.14. Так что мои отношения с sing-box строятся именно на любви к продукту, а не на получении благ за деньги. Но конечно можно назвать это эгоизмом, потому что я сам пользуюсь программой и хочу сделать её лучше.
Да, прошу прощения, не сделал на этом акцента. Показалось, что если мы говорим о настройке своего сервера, то покупка домена не сложнее (и не дороже) аренды сервера.
Ответил выше на похожий комментарий: https://habr.com/ru/articles/1024990/comments/#comment_29851264
Я считаю, что нет никакого риска взять ru домен (по крайней мере на данный момент). Плюс можно использовать поддомены.
Да, прошу прощения, я не обозначил это в статье. Конфигурация из статьи подразумевает наличие своего домена. Но можно обойтись и без него, но тогда не будет защиты от активного сканирования. Вариант с self-signed сертификатом. Caddy нужно будет настроить иначе. И в клиентской конфигурации sing-box в секции tls указать `insecure: true`.
https://sing-box.sagernet.org/configuration/shared/tls/#insecure
При связке, описанной в статье, UDP работает. Я отдельно упомянул параметр
udp_over_tcp. С клиентами на базе sing-box тоже работает. И с популярным Shadowrocket работает.По поводу скорости всё индивидуально, можно сделать замеры. ИИ так мог ответить из-за режима Splice в Vision Reality, но он скорее про нагрузку сервера, да и включается не всегда (зависит от условий). И наоборот, у Vision Reality есть принципиальная проблема (особенность) с отсутствием мультиплексирования и необходимостью на каждое новое подключение подключаться к удаленному серверу для получения сертификата, что создает существенные задержки на каждое устанавливаемое соединение (а если сайт-донор еще и тормозит или блокирует частые подключения, то становится совсем плохо).
А вот то, что переходить с VLESS на Naive нет смысла, если VLESS хорошо работает - это верно (я об этом тоже сказал в заключении статьи).
К сожалению, проблема TLS in TLS остается. Вот что автор пишет в своей документации:
По сути маскируется это только мультиплексированием множества конечных соединений внутри одного туннеля (поэтому автор и рекомендует
insecure_concurrency = 1), что затрудняет анализ длины и отчасти скрывает TLS in TLS.Это сложно сделать из-за того, что VLESS очень сильно отличается в зависимости от настроек и транспорта (Vision, XHTTP, gRPC, Reality и прочее). И даже Vision работает сильно по-разному в зависимости от трафика, который он прогоняет (где-то включается Splice, а где-то нет).
Основное же отличие Naive я постарался описать в разделах "ClientHello и uTLS" и "О NaïveProxy". А к чему реально будет в дальнейшем привязываться цензор (какая особенность того или иного протокола будет мешать или помогать) - неизвестно. Может вообще все закончится белыми списками, а не анализом протоколов.
Согласен. Опять же нужна иностранная карта для доната. Но поддержка Naive есть не только в sing-box. В очень популярном Shadowrocket она есть. В бесплатном Karing тоже есть (ядро sing-box).
Скорее всего у вас используется протокол, который не совместим с мультиплексированием (или мультиплексирование отключено). Мультиплексирование - это когда несколько ваших соединений помещаются в один туннель до прокси. Соответственно без этого подключений до прокси много, что детектируется и приводит к блокировке IP. Решение - использование протоколов с мультиплексированием. Например, VLESS + XHTTP или NaiveProxy.
Свежая статья о NaiveProxy: https://habr.com/ru/articles/1024990/
Дочитайте, пожалуйста, подраздел до конца. Следующее предложение после процитированного вами:
Как раз uTLS (о котором подраздел) и обеспечивает похожий на браузерный ClientHello, если он включен через конфиг. Если не использовать uTLS, то будет стандартный ClientHello от Go (в случае программы, написанной на Go).
https://github.com/refraction-networking/utls
Я задонатил автору sing-box через github (благодарность за хорошую программу). За это дается доступ к приватному telegram-чату с доступом к свежей версии sing-box для iOS и macOS.
Опубликовал статью о настройке сервера с naive: https://habr.com/ru/articles/1024990/
Может в самом telegram настроен прокси (в настройках приложения)?
Вы можете все равно направлять все в tun, но дальше уже управлять гибкими правилами маршрутизации.
Вам нужно редактировать секцию route. Сначала поменять значение final на direct. Это через что все будет идти, если не будет совпадений по правилам. Правила из rules проверяются сверху вниз до первого действия с action route. Если хотите конкретные приложения в прокси, то указываете их список в package_name, а outbound меняете на proxy-select или на tag конкретного сервера.
Работает с UDP. Конфиг сервера из моего коммента выше. Конфиг клиента из статьи (с
udp_over_tcp). На клиенте должен быть включен TUN, чтобы UDP шли в прокси.Отправил автору sing-box issue с предложением по PR, переписываюсь с ним в tg-чате. Хочу, чтобы появилась возможность ловить правилом такие соединения, когда не удается распознать package name: https://github.com/SagerNet/sing-box/issues/4009
Проблема изначально, что из-за выбора интерфейса не работает поиск процесса getConnectionOwnerUid. Это API появилось, когда Google стал ограничивать доступ к /proc/net. И когда добавляли, то непривилегированные приложения еще не могли использовать SO_BINDTODEVICE. Так что скорее всего это пробел в дизайне API — его спроектировали под реалии, когда обычные приложения не могли привязывать сокеты к интерфейсам.