github Leadaxe/singbox-launcher v1.6.3
release v1.6.3

3 hours ago

Release v1.6.3

Downloads

macOS (Universal) - Supports both Apple Silicon and Intel

Option 1: Installation Script (Recommended)

Install with a single command (version v1.6.3):

curl -fsSL https://raw.githubusercontent.com/Leadaxe/singbox-launcher/develop/scripts/install-macos.sh | bash -s -- v1.6.3

The script will:

  • Download the release archive
  • Extract and install to /Applications/
  • Fix macOS quarantine attributes and permissions
  • Launch the application automatically

Option 2: Manual Installation

  1. Download: singbox-launcher-v1.6.3-macos.zip
  2. Extract the ZIP file
  3. Remove quarantine attribute (required):
    xattr -cr "singbox-launcher.app" && chmod +x "singbox-launcher.app/Contents/MacOS/singbox-launcher"
  4. Double-click singbox-launcher.app to run
    • If macOS blocks the app, go to System Settings → Privacy & Security and click "Open Anyway"
    • Alternatively, right-click the app and select "Open" (first time only)

Windows (amd64)

  1. Download: singbox-launcher-v1.6.3-win64.zip
    • or singbox-launcher-v1.6.3-win64-full.zipfull bundle: sing-box.exe, wintun.dll, the config template and Mesa3D (mesa3d/, used only when no hardware OpenGL — RDP, VMs) are already inside, nothing is downloaded on first launch
  2. Extract the ZIP file to a folder, for example: C:\Program Files\singbox-launcher\
  3. Run singbox-launcher.exe from that folder
    • You may need administrator rights to install to Program Files
    • The regular archive downloads sing-box and wintun.dll on first launch

Windows 7 (x86, legacy)

  1. Download: singbox-launcher-v1.6.3-win7-32.zip
  2. Extract the ZIP file to a folder and run singbox-launcher-win7-32.exe
    • For Windows 7 / 32-bit or legacy compatibility only

Linux Support

⚠️ Linux build temporarily unavailable - мы ищем тестировщика для ручного тестирования перед включением автоматической сборки.

Checksums

See checksums.txt for SHA256 checksums of all files.

Release notes — v1.6.3

EN

Fixes

  • Importing sing-box JSON no longer drops TLS fields. An import of a sing-box outbound array, a whole config or a subscription in that format ran through an inline emitter that knew only seven TLS keys: tls.certificate was lost on naive nodes, and alpn, certificate_public_key_sha256 (pins), min_version/max_version, cipher_suites, the client_* keys and fragment were lost on every scheme — a naive node with an inline certificate came out unusable, and elsewhere the node connected with weaker settings than the config asked for. The emitter now carries the core's full TLS field list, and values that arrive from JSON as arrays no longer fall through a wrong type assertion. Nodes added as a single JSON object by hand were never affected. See LxBox #140.

  • A naive node no longer takes down the whole config with a foreign TLS key. The naive core accepts exactly four TLS keys — enabled, server_name, certificate, certificate_path — and fails the entire config on any other one, so a single such node kept the core from starting. The emitter now writes only those four for naive.

Technical / Internal

  • REALITY links accept key_share=hybrid|classical on vless:// and anytls://, next to pbk/sid. classical is what REALITY servers on Xray older than v26.9.8 need — they drop a hybrid ClientHello, and until now such a server could only be set up by hand-editing the node's JSON body. The value is read only on a real REALITY node (valid pbk); anything outside the two values drops the field, not the node.
  • Core pinned to sing-box-lx 1.14.1-lx.4. Two core-side changes reach users: tls.reality.key_share in a node's JSON body is now passed through to the core (hybrid / classical; empty = whatever the uTLS fingerprint carries), and the template's TLS fragmentation flags (tls_fragment / tls_record_fragment) now actually apply to REALITY nodes — older cores silently ignored them there, so a REALITY node with fragmentation enabled behaves differently on the wire.

RU

Исправления

  • Импорт sing-box JSON больше не теряет поля TLS. Импорт массива outbound'ов sing-box, целого конфига или подписки в этом формате шёл через встроенный эмиттер, знавший всего семь ключей TLS: у узлов naive терялся tls.certificate, а у любых схем — alpn, certificate_public_key_sha256 (пины), min_version/max_version, cipher_suites, ключи client_* и fragment. Узел naive со встроенным сертификатом получался нерабочим, а в остальных случаях узел подключался на более слабых настройках, чем просил конфиг. Теперь эмиттер держит полный список полей TLS ядра, а значения, приходящие из JSON массивом, больше не проваливаются на неверной проверке типа. Узлы, добавленные руками одним объектом JSON, эта потеря не задевала. См. LxBox #140.

  • Узел naive с чужим ключом TLS больше не роняет весь конфиг. Ядро naive принимает ровно четыре ключа TLS — enabled, server_name, certificate, certificate_path — и на любом другом валит конфиг целиком, так что один такой узел не давал ядру стартовать. Теперь эмиттер пишет у naive только эти четыре.

Техническое / Внутреннее

  • В ссылках REALITY читается key_share=hybrid|classical — у vless:// и anytls://, рядом с pbk/sid. classical нужен REALITY-серверам Xray старше v26.9.8: они рвут соединение на гибридном ClientHello, и раньше такой сервер заводился только правкой JSON-тела узла. Значение читается только у настоящего REALITY-узла (валидный pbk); всё, кроме этих двух значений, снимает поле, а не узел.
  • Ядро запинено на sing-box-lx 1.14.1-lx.4. Две правки ядра видны пользователю: tls.reality.key_share из JSON-тела узла доезжает до ядра (hybrid / classical; пусто = как несёт uTLS-отпечаток), и флаги фрагментации TLS из шаблона (tls_fragment / tls_record_fragment) теперь реально применяются к REALITY-узлам — прежние ядра их там молча игнорировали, так что у REALITY-узла с включённой фрагментацией меняется поведение на проводе.

Don't miss a new singbox-launcher release

NewReleases is sending notifications on new releases.