github Leadaxe/singbox-launcher v0.9.4
release v0.9.4
on GitHub

latest release: v0.9.5
4 hours ago

Release v0.9.4

Downloads

macOS (Universal) - Supports both Apple Silicon and Intel

Option 1: Installation Script (Recommended)

Install with a single command (version v0.9.4): 

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

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-v0.9.4-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-v0.9.4-win64.zip
  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 launcher will automatically download sing-box and wintun.dll on first launch

Windows 7 (x86, legacy)

  1. Download: singbox-launcher-v0.9.4-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.

Highlights (EN)

Two fixes addressing real user reports:

  • route.final from Configurator now actually applies — previously the «Final outbound» dropdown selection was silently ignored, all unmatched traffic went via template default (proxy-out) regardless of user choice.
  • TLS root certificate store is now exposed in Configurator → Settings as a dropdown (System / Mozilla CA bundle / Chrome Root Store), giving users a one-click escape from broken Windows cert stores that produce x509: certificate signed by unknown authority errors.

Fixed

  • route.final selection respects the user's choice. Reported by Michael M: setting Configurator → Rules → Final outbound to direct-out had no effect — the generated config.json still had "final": "proxy-out", so all unmatched traffic kept going through the proxy. Two parallel half-finished mechanisms collided: presenter wrote the choice to state.config_params["route.final"] on Save, but the build pipeline's routeConfigForUpdate had a TODO for reading it («template default is fine for now»), and the template hardcoded "final": "proxy-out" instead of using the @varname substitution channel. Both fixed in one go: template now uses "final": "@route_final" (consistent with dns_final, auto_detect_interface, etc.), presenter persists the value into state.vars["route_final"], build pipeline relies entirely on substitution. Existing state.json files heal silently — legacy config_params value is read on first load and rewritten to vars on next Save. Closes the regression in Configurator → Rules → Final outbound.

Added

  • TLS root certificate store dropdown (Configurator → Settings → «TLS root certificate store»). New template var cert_store (enum: system / mozilla / chrome, default system). Maps to sing-box's certificate.store (docs). Use case: Windows installations where the OS root certificate pool is broken (Microsoft auto-update root pool stale, antivirus tampered with the trust store, etc.) and TLS fails everywhere with x509: certificate signed by unknown authority. Switching to mozilla or chrome uses the built-in CA bundle instead of the OS store, bypassing the issue. Default system keeps current behavior — no migration impact.

Technical / Internal

  • New template var pattern: wizard_ui: "hidden" for vars whose UI surface lives outside Settings tab (in our case Configurator → Rules → Final outbound dropdown — values depend on dynamic outbound list, can't be a static dropdown in Settings).
  • extractConfigParams reduced to no-op stub. Field state.config_params[] retained in schema for read-only legacy migration and possible future params.
  • Substitution verified for both new vars (@cert_store x 3 values, @route_final x 4 values) via direct BuildConfig probes.

Migration notes

  • No manual action required. Existing v0.9.3 installs that had route.final set in Configurator (which was silently ignored anyway) will pick the value up correctly on first Save in v0.9.4 — eager-migrated from config_params to vars. After that the legacy entry in config_params is no longer written.

Основное (RU)

Два фикса по реальным репортам пользователей:

  • route.final из конфигуратора теперь действительно применяется — раньше выбор «Final outbound» молча игнорировался, весь не-матченный трафик шёл через template-default (proxy-out) независимо от выбора пользователя.
  • TLS root certificate store теперь доступен в Configurator → Settings как dropdown (System / Mozilla CA bundle / Chrome Root Store) — однокликовый escape от сломанного Windows cert store, дающего ошибки x509: certificate signed by unknown authority.

Исправлено

  • Выбор route.final теперь работает. Сообщил Michael M: установка Configurator → Rules → Final outbound в direct-out не давала эффекта — сгенерированный config.json всё равно содержал "final": "proxy-out", весь не-матченный трафик продолжал идти через прокси. Столкнулись два параллельных полу-доделанных механизма: presenter писал выбор в state.config_params["route.final"] при Save, но build pipeline в routeConfigForUpdate имел TODO про чтение этого («template default fine for now»), а template хардкодил "final": "proxy-out" вместо использования канала substitution через @varname. Оба починены: template теперь "final": "@route_final" (унифицировано с dns_final, auto_detect_interface и др.), presenter пишет в state.vars["route_final"], build pipeline полностью полагается на substitution. Существующие state.json лечатся автоматически — legacy config_params читается при первой загрузке и переписывается в vars при следующем Save.

Добавлено

  • Dropdown TLS root certificate store (Configurator → Settings → «TLS root certificate store»). Новая template var cert_store (enum: system / mozilla / chrome, default system). Маппится на sing-box certificate.store (docs). Use case: Windows установки где сломан системный pool корневых сертификатов (просрочен Microsoft auto-update, антивирус подменил trust store и т.п.) — TLS везде валится с x509: certificate signed by unknown authority. Переключение на mozilla / chrome использует встроенный CA-bundle вместо системного, обходит проблему. Default system сохраняет текущее поведение — миграция не требуется.

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

  • Новый template-var паттерн: wizard_ui: "hidden" для var'ов, чей UI surface живёт вне Settings tab (в нашем случае Configurator → Rules → Final outbound dropdown — значения зависят от динамического outbound list, нельзя сделать статическим dropdown'ом в Settings).
  • extractConfigParams сведена к no-op stub. Поле state.config_params[] остаётся в schema только для read-only legacy миграции и возможных будущих параметров.
  • Substitution проверена для обеих новых var'ов (@cert_store × 3 значения, @route_final × 4 значения) прямыми BuildConfig пробами.

Миграция

  • Ручных действий не требуется. Существующие v0.9.3 инсталляции, у которых route.final был выставлен в конфигураторе (но молча игнорировался), при первом Save в v0.9.4 подхватят значение корректно — eager-мигрировано из config_params в vars. После этого legacy запись в config_params больше не пишется.
Check out latest releases or
releases around Leadaxe/singbox-launcher v0.9.4

Don't miss a new singbox-launcher release

NewReleases is sending notifications on new releases.

Get notifications