MOMO0302-02 9a0099db2b fix: surface core startup and TUN failures instead of hiding them (#2127)
* fix: show the core's stderr when the config check produces no stdout

`checkProfileConfig` built the user-facing message only from the failing
core process' stdout. When the core never gets far enough to log anything
- a dynamic-link failure, a missing symbol, an architecture mismatch -
mihomo writes to stderr and exits, leaving stdout empty. Both branches
then produced `<profileCheckFailed>:` with nothing after the colon, so
the user saw an unexplained "config check failed" while the real reason
(`dyld: Symbol not found: _SecTrustCopyCertificateChain ... which was
built for Mac OS X 12.0`) was only visible in the app log, which is where
the reporters of #1404 / #1163 / #1132 had to dig it out of.

stderr is already read and logged two lines above; fall back to it when
stdout carries no usable line. Behaviour is unchanged whenever stdout has
content, so the existing `level=error` path is untouched.

(cherry picked from commit 0d02e9b5f536476f527d37b081a3eae376d83a56)

* fix: surface TUN startup failures instead of silently leaving the switch on

When the kernel fails to bring up the virtual adapter for any reason other
than missing privileges (wintun install corruption, adapter name in use,
Code 56 class-config damage, ...), it only prints

    Start TUN listening error: <cause>

and the deferred handler in listener.ReCreateTun sets tunConf.Enable = false.
The core keeps running happily, but the GUI still shows TUN as enabled and the
tray icon still reports TUN mode, so the user only sees "I turned it on and
nothing happens" with no error anywhere in the UI.

The stdout watcher only matched the privilege case
("configure tun interface: operation not permitted"), so every other failure
was swallowed. Match the generic error line as well: log it, mirror the
kernel's own decision by turning the TUN switch off, refresh the tray, and show
the kernel's raw message to the user.

The dialog is intentionally the async showMessageBox - a modal
showErrorBox/showMessageBoxSync inside the stdout 'data' handler blocks the
main process, which in turn stalls the core once its stdout pipe fills up.
Repeated lines from a single failure are collapsed into one prompt per 10s.

Closes #453

(cherry picked from commit dc3fd8be7008018826b92ffbabdea423b4ded473)

* fix: add the missing TUN permission error message for zh-CN/en-US/zh-TW

tun.error.tunPermissionDenied only existed in ru-RU and fa-IR. Because the
fallback language is en-US and en-US was missing it too, i18next returned the
key itself, so when the core failed with
"configure tun interface: operation not permitted" Chinese and English users
got a dialog whose body was literally "tun.error.tunPermissionDenied" - no
indication that the fix is to grant the core permissions.

Relates to #655

(cherry picked from commit 2076d504341c4df0b311b1efc4146f3c3c5532f1)

* fix: make sure the core is dead before the app exits on Linux (#1341)

On exit `stopCoreForExit()` sent SIGINT to the core and immediately tore
down the Linux watchdog, then `app.exit()` ran after a 1.2s budget. There
was no SIGKILL escalation on that path: `stopPidFileCore()` only does
anything in lightweight mode, because `core.pid` is written by
`keepCoreAlive()` alone. So a core that needs longer than the budget to
shut down (TUN teardown, for example) survived the GUI, and the watchdog
that would have reaped it had already been killed.

Keep the watchdog alive across the shutdown, reuse the existing
`ensureCoreProcessExited()` (SIGINT -> wait -> SIGKILL -> wait) to confirm
the core is gone, and only then stop the watchdog. If the core still can't
be confirmed dead, the watchdog is left running so its `kill -9` fires when
the main process exits. The watchdog is still stopped in the normal case,
so the PID-reuse guard from 196fdcb is preserved.

(cherry picked from commit 22a65693cf842e24c48c6480e9035fb5d0ed3b90)

---------

Co-authored-by: Claude <noreply@anthropic.com>
2026-09-18 10:55:25 +08:00
2026-07-01 08:46:41 +08:00
2026-04-01 08:18:15 +08:00
2026-04-01 08:18:15 +08:00
2024-08-07 09:48:27 +08:00
2026-07-01 08:46:41 +08:00
2024-08-07 09:48:27 +08:00
2024-08-07 09:48:59 +08:00
2026-09-09 12:17:51 +08:00
2024-08-07 09:48:27 +08:00
2026-07-01 08:46:41 +08:00
2026-07-01 08:46:41 +08:00

Another Mihomo GUI

本项目认证稳定机场推荐:“狗狗加速

狗狗加速 —— 技术流机场 Doggygo VPN
  • 高性能海外机场,稳定首选,海外团队,无跑路风险
  • Clash Party专属8折优惠码party仅有500份
  • Party专属链接注册送 3 天,每天 1G 流量 免费试用
  • 优惠套餐每月仅需 15.8 元160G 流量,年付 8 折
  • 全球首家支持Hysteria1/2 协议集群负载均衡设计高速专线基于最新UDP quic技术极低延迟无视晚高峰4K 秒开配合Clash Party食用更省心
  • 解锁流媒体及 ChatGPT
  • 官网:https://狗狗加速.com

特性

  • 一键 Smart Core 规则覆写,基于 AI 模型自动选择最优节点 详细介绍请看 这里
  • 开箱即用,无需服务模式的 Tun
  • 多种配色主题可选UI 焕然一新
  • 支持大部分 Mihomo(Clash Meta) 常用配置修改
  • 内置 Smart内核 与 Mihomo(Clash Meta) 内核
  • 通过 WebDAV 一键备份和恢复配置
  • 强大的覆写功能,任意修订配置文件
  • 深度集成 Sub-Store轻松管理订阅

安装/使用指南见 官方文档

Description
No description provided
Readme GPL-3.0 41 MiB
Languages
TypeScript 89.5%
JavaScript 8.9%
Shell 1.2%
CSS 0.2%
NSIS 0.1%