[Bug] DNS disable 不还原系统 DNS（DhcpEmpty 路径下网络被卡在 127.0.0.1）

[flyhigher139]

现象

用户操作：Settings → Enable DNS Mode（成功，TCC 弹窗确认）→ Disable DNS Mode（UI 立即显示 "DNS Mode: Off"）→ 浏览器/系统任何域名都解析失败，必须手动到 System Settings → Network → Wi-Fi → DNS 把 127.0.0.1 删掉才能恢复上网。

复现路径：用户原始系统 DNS 是 DHCP-empty（即 networksetup -getdnsservers Wi-Fi 输出 There aren't any DNS Servers set on Wi-Fi）。这是绝大多数家用 Wi-Fi 用户的默认状态。

期望

Disable DNS Mode 后系统 DNS 应该回到 Disable 之前的状态。DhcpEmpty 的情况下应该回到 networksetup -getdnsservers Wi-Fi 输出为空（DHCP 自动获取）。

实际

Disable 返回 Ok(()) 后，networksetup -getdnsservers Wi-Fi 仍然输出 127.0.0.1。系统级 DNS 解析全部失败，浏览器无法访问任何域名。

根因分析（基于 fix/dns-cancel-149 当前代码 + 现场日志）

PR #148 (fix(#148), commit 5a0ebd3) + PR #149 (feat(#149), commit d06822c) 的 disable 路径在 DhcpEmpty 场景下漏了兜底。

platform.rs::disable_dns_mode() (~line 863-1006) 的分支

match is_expected_proxy_alive() {
    true => {
        // 等 proxy 自我清理（最多 5s），NO fallback
        for _ in 0..50 { ... } // wait loop
        return Ok(());
    }
    false => {
        if interactive {
            osascript_restore(original).await?;  // 只有这条会调 networksetup
        }
    }
}

proxy 自我清理走的是 proxy.rs::restore_dns_and_exit()（~line 188-263），它会调 networksetup -setdnsservers Wi-Fi Empty（line 240-241）来还原 DhcpEmpty 状态。

但用户的现场日志显示：

• proxy 收到 shutdown signal（server.rs:230 打了 "DNS server received shutdown signal"）
• 但 restore_dns_and_exit 没执行到 networksetup 那行
• platform.rs::disable_dns_mode 返回 Ok(()) 之前也没走 osascript_restore 分支

也就是说 proxy 在收到 shutdown signal 后没能完成 restore_dns_and_exit，但 is_expected_proxy_alive() 在 5s 等待后返回了 false（proxy 确实死了），可 disable 还是返回 Ok(()) —— 因为 false 分支要么走 interactive=true 的 osascript 兜底（现场没打 osascript log），要么什么都不做（interactive=false）。两条分支都没成功还原 DNS。

链路 1: Proxy 还原失败 + interactive=false → 系统 DNS 泄漏

即使 is_expected_proxy_alive() 检测到 proxy 死掉，如果 interactive=false（disable IPC 默认值，从前端调用过来时），根本不会调 osascript 兜底。proxy 死了，restore 没完成，系统 DNS 卡在 127.0.0.1。

链路 2: Proxy 还原 "成功" 但 on-disk original 被污染

更隐蔽的是，即使 proxy 的 networksetup 调用成功了，下次 enable 也会失败：

1. 第一次 enable：DhcpEmpty，enable 不写 original.txt
2. disable：proxy 死了，restore 没跑
3. 系统 DNS = 127.0.0.1（脏）
4. 第二次 enable：capture_dns_state() 读到 Manual(["127.0.0.1"]) ← BUG
5. enable 把 127.0.0.1 当作 original 写到 manifest + original.txt
6. 下次 disable 时 proxy 调 networksetup -setdnsservers Wi-Fi 127.0.0.1
7. 等于 "还原" = "不变"，但实际真正的原始 DHCP 状态已经永久丢失

capture_dns_state 必须过滤掉 127.0.0.1（这是 mHost 自己注入的，不是用户的 original）。

复现步骤

# 0. 准备：网络 DNS 是 DHCP-empty（绝大多数家用 Wi-Fi 默认状态）
networksetup -getdnsservers Wi-Fi
# 期望：There aren't any DNS Servers set on Wi-Fi

# 1. 启动
MHOST_AUTO_DNS=1 pnpm tauri dev
# （我自己加了 temp trigger：enable → wait → disable → wait → enable，
#  方便在没有 UI 自动化下复现。TRIGGER 在 src-tauri/src/lib.rs setup() 里，
#  提交前必须移除。）

# 2. 等 ~10s 让 3 个阶段都跑完

# 3. 验证（应该看到 Empty，但实际看到 127.0.0.1）
networksetup -getdnsservers Wi-Fi
# 实际：127.0.0.1
# 期望：There aren't any DNS Servers set on Wi-Fi

# 4. 验证 on-disk original 也被污染
cat "$HOME/Library/Application Support/mHost/.runtime/mhost-dns-original.txt"
# 实际：127.0.0.1
# 期望：空文件

提议修复（TBD — 等 issue 跟踪后决定方向）

最小修复（blocker）：disable_dns_mode 在 is_expected_proxy_alive() == false 时永远走 osascript 兜底（不再受 interactive 限制），保证系统 DNS 一定被还原。

推荐修复：

1. disable_dns_mode 总在 proxy 死后做 networksetup -setdnsservers <iface> Empty 自检（不需要 sudo，因为 networksetup 不需要 root）。
2. capture_dns_state 过滤掉 127.0.0.1（这是 mHost 自身注入的 sentinel，永远不应该被当成用户 original）。
3. 加 eprintln 到 proxy.rs::restore_dns_and_exit 的所有分支，确认它到底执行到哪一步（exit_reason）—— 这是定位「为什么 proxy 收到 signal 但 restore 没跑」的关键。

相关 issue / PR

• fix(dns): enable_dns_mode must kill orphan proxy via sudo + add AppleScript trap #148 (fix: enable_dns_mode must kill orphan proxy via sudo + add AppleScript trap) — 修了 enable 的 orphan 问题，但 disable 的还原路径还有 DhcpEmpty gap
• feat(dns): Settings cancel button + IPC-level abort signal for DNS enable/disable #149 (feat: Settings cancel button + IPC-level abort signal for DNS enable/disable) — 加了 cancel，没动 disable 还原逻辑
• fix: DNS mode enable leaves orphan mhost-dns-proxy when osascript is cancelled — UI/backend state desync (#148) #147 (fix: DNS mode enable leaves orphan mhost-dns-proxy when osascript is cancelled) — 同源问题
• regression(#141): enable DNS mode hangs, no authorization dialog appears #142 (regression: enable DNS mode hangs, no authorization dialog appears) — 已 close 的同类问题（enable 端）
• fix: ship mhost-dns-proxy sidecar in .app + kill orphan proxy on enable + robust Ctrl+C exit #146 (PR) — 删了 enable 的 60s timeout（理由：timeout can't interrupt blocking thread），但 disable 路径在某些情况下没补上相应恢复

环境

• macOS（具体版本需要用户确认）
• mHost v0.3.3 (commit 576bb03) 之前是好的，之后 PR fix: ship mhost-dns-proxy sidecar in .app + kill orphan proxy on enable + robust Ctrl+C exit #146 改了 disable 路径
• 复现版本：fix/dns-cancel-149 @ d06822c（HEAD）

[flyhigher139]

v0.3.3 (576bb03) → HEAD (d06822c) DNS regression diff

把每个 DNS 关键文件的 git diff --stat 576bb03..d06822c 跑了一遍，按行为变化分组。

改动体量（commit 总数 = 5 个 PR/fix）

src-tauri/crates/mhost-dns/Cargo.toml      |    1 +
src-tauri/crates/mhost-dns/src/platform.rs |  940 ++++++++++++++++++++-
src-tauri/crates/mhost-dns/src/proxy.rs    |   61 +-
src-tauri/crates/mhost-dns/src/server.rs   |  260 +++++-
src-tauri/src/commands/dns.rs              | 1216 ++++++++++++++++++++++++++--
5 files changed, 2382 insertions(+), 96 deletions(-)

commands/dns.rs 翻倍（+1216/-96），platform.rs 翻三倍（+940）。体积爆炸。

顺序与时间线

576bb03 chore(release): bump version to 0.3.3   ← 用户确认这是好的
fe7fdef fix(#142): ship mhost-dns-proxy sidecar in build + add 60s osascript timeout (#143)
961c4cf fix(#140): DNS mode enable waits for proxy bind before changing system DNS (#141)
a2fe6e4 fix: ship mhost-dns-proxy sidecar in .app + kill orphan proxy on enable + robust Ctrl+C exit (#146)
5a0ebd3 fix(#148): DNS mode enable trap-kills proxy + sudo-level orphan cleanup (#150)
d06822c feat(#149): Settings cancel button + IPC-level abort signal for DNS enable/disable

A. 没变 / 等价（v0.3.3 和 HEAD 行为一致的部分）

函数	文件	行为等价
DnsProxy::new()	proxy.rs:115	✓
restore_dns_and_exit()	proxy.rs:188	✓
check_shutdown_signal()	proxy.rs:165	✓
shutdown_poll 1Hz 轮询	proxy.rs:326	✓
server::start()	server.rs:138	✓（结构同，加了 cancel 信号日志）
server::stop()	server.rs:275	✓
capture_dns_state()	platform.rs:326	✓（两版都不过滤 127.0.0.1）
networksetup_get_dns()	platform.rs:489	✓
OriginalDns::restore_argv()	同	✓
set_dns_mode_disable() 主体流程	commands/dns.rs:430	✓（签名多了 cancel）

这意味着：proxy 自我恢复 DNS 的核心机制在两个版本里完全一样。如果 v0.3.3 正常工作，那是因为 signal-file 协议 + proxy 自己 root 调 networksetup 在 v0.3.3 走得通；HEAD 同样走这套，恢复逻辑不应该失效。

B. v0.3.3 没有、HEAD 新增的代码（潜在回归源）

新增项	HEAD 位置	来源 PR	影响
is_expected_proxy_alive()	platform.rs:1063	#148	disable_dns_mode 入口处用它区分 alive vs dead，dead 分支依赖 osascript_restore 兜底
sudo_kill_orphan_dns_proxies()	platform.rs（PR #148 内）	#148	disable 路径独立调一次 sudo
cancel_dns_mode IPC + CancellationToken	commands/dns.rs:42, 102	#149	disable_dns_mode 多 cancel: Option<&CancellationToken> 形参
build_enable_script_body() 独立函数 + trap + inline pgrep	platform.rs:677	#148	osascript 脚本从 5 行 → 90 行；加 trap cleanup EXIT INT TERM + proxy_should_keep_running handoff flag
proxy_ready_file 轮询	platform.rs:602-603, 752-759	#140	5s 内 ready 才继续，否则 kill proxy + exit 1
FD redirect </dev/null >/dev/null 2>&1 &	platform.rs:745	#149 / PR1 fix	修 #142 root cause；v0.3.3 没有，proxy 继承 osascript pipe — 这个反而是 #142 hang 的真因
disable_recovery_marker_file() + write_recovery_marker()	platform.rs:82, 1013	#140+#148	写 marker，下一次启动 try_recover_dns 兜底

C. 与 issue #152 现象直接相关的差异

C1. v0.3.3 与 HEAD 的 disable_dns_mode() 分支逻辑

两版的 disable_dns_mode 主干流程完全一致：

1. 写 recovery marker
2. 读 pid_file → alive → 等 5s proxy self-cleanup → 清理
3. 5s 超时 + interactive=true → osascript_restore(original) 兜底
4. PID 文件存在但进程死了 → 清 PID 文件 → 落到分支 5
5. proxy 不在 + interactive=true → osascript_restore(original) 兜底
6. proxy 不在 + interactive=false → 直接返回 Err，依赖 try_recover_dns 下次启动兜底

差异：HEAD 在分支 3 多了一个 cancel.is_cancelled() check（line 929-937），cancel 时直接 return Ok(())，不调用 osascript_restore，不清 marker。这是 cancel 的设计意图。

C2. v0.3.3 vs HEAD 的 disable 调用方式

	v0.3.3	HEAD
set_dns_mode() IPC 形参	enabled: bool	enabled: bool + 内部 spin up fresh CancellationToken
set_dns_mode_disable() 调用 platform	disable_dns_mode(&original, true)	disable_dns_mode(&original, true, Some(&cancel))
cleanup_dns_on_exit	disable_dns_mode(&original, false)	disable_dns_mode(&original, false, None)

interactive 的语义两版相同：true = 用户在场（UI 路径，可弹 sudo）；false = exit/cleanup 路径（不弹 sudo，靠 marker + 下次启动）。

C3. v0.3.3 与 HEAD 的 enable_dns_mode 脚本对比

	v0.3.3 (576bb03)	HEAD (d06822c)
脚本长度	5 行	90+ 行
trap	无	trap cleanup EXIT INT TERM
orphan-kill 前置	无	inline pgrep -x mhost-dns-proxy 循环
ready file wait	无	5s 轮询 [ -f "$ready_file" ]
FD redirect	无	</dev/null >/dev/null 2>&1 &
handoff flag	无	proxy_should_keep_running=0/1
失败路径 proxy 清理	写文件失败时不清	trap + cleanup() + handoff flag 保证任何失败路径 kill proxy

v0.3.3 的脚本没 FD redirect —— 这是 PR #146+#149 才加的。所以 v0.3.3 在用户机上也应该有 #142 hang 问题（enable osascript 永不返回）。但用户报告 v0.3.3 enable 正常。这意味着用户机器上 v0.3.3 没复现 #142（可能 mhost-dns-proxy 是另一个路径起的，不继承 pipe，或者用户每次都是手动启 / TCC 已授权）—— 用户给的 v0.3.3 "正常" 信号是关于功能稳定，不一定是关于"enable 不 hang"。

D. 关键观察

D1. capture_dns_state 两版都不过滤 127.0.0.1

v0.3.3: platform.rs:210-222 → capture_dns_state 只看 networksetup 返回，不剔除 127.0.0.1
HEAD:   platform.rs:326-339  → 同

所以两版都有 issue #152 链路 2 描述的 bug：disable 后系统 DNS 漏在 127.0.0.1，第二次 enable capture_dns_state 读到 Manual(["127.0.0.1"]) 并写入 manifest + original.txt。

但 v0.3.3 不暴露这个 bug 的原因是：v0.3.3 的 proxy.rs::restore_dns_and_exit 每次 disable 都成功还原系统 DNS（v0.3.3 简化版脚本，proxy 一定能跑通 shutdown 协议）。HEAD 的 trap/ready/cleanup 三层逻辑理论上同样能跑通，但任何一层失败都导致 proxy 死 / 系统 DNS 不还原。

D2. v0.3.3 没有"cancel"概念

v0.3.3 没 cancel，用户 disable 时必须等 5s + 等 proxy 自然退出。在干净的 v0.3.3 上：

• 用户点 Disable → set_dns_mode_disable → disable_dns_mode → 写 signal="shutdown"
• proxy 1Hz poll 检测到 → restore_dns_and_exit 走 networksetup → 还原成功 → 退出
• mhost 端 kill(pid, 0) != 0 检测到 proxy 死 → 清文件 → 返回 Ok

HEAD 在 v0.3.3 的基础上多了一个 cancel path，cancel 直接跳出等待但不调用 osascript_restore。这意味着任何 cancel 路径都依赖 proxy 后续 self-cleanup + 下次启动 recovery marker 兜底。如果 cancel 在某些情况下与 proxy self-cleanup race 不赢，proxy 死后没还原系统 DNS，就 leak 到 127.0.0.1。

D3. 三个 candidate root cause

按"v0.3.3 → HEAD 改动让 disable 不再 100% 还原"的可能性排序：

1. proxy_should_keep_running handoff flag race（最可能）
   脚本成功路径在 networksetup -setdnsservers 之后设 proxy_should_keep_running=1。如果 set 之前 trap 触发了（osascript cancel / SIGPIPE / 等），trap 会把 proxy 当孤儿 kill + 清 pid_file。Disable 后续读 pid_file 是 None → 落到 "proxy 不在 + interactive=true" 分支 → 走 osascript_restore。但此时 original 是 in-memory OriginalDns，不是 on-disk original.txt——所以 restore_argv 是 enable 时记录的 Empty（DhcpEmpty）或 Manual 列表。这条路径在 v0.3.3 同样存在（v0.3.3 也写 in-memory original），所以不太可能是 [Bug] DNS disable 不还原系统 DNS（DhcpEmpty 路径下网络被卡在 127.0.0.1） #152 的新增原因。

2. trap + inline pgrep 把"刚要 self-cleanup"的 proxy 杀了
   第二次 enable 的脚本顶部的 inline pgrep -x mhost-dns-proxy 会扫到刚 disable 的 proxy（它还没走完 shutdown signal poll），TERM 杀掉，proxy 永远不会触发 restore_dns_and_exit。这是 HEAD 新增行为，v0.3.3 没有。这条是真正的回归。

3. write_signal_file 原子重写导致 check_shutdown_signal 看不到 signal
   v0.3.3 line 466 + HEAD line 485：signal 文件用 write_atomic_0600（tmp + rename）。proxy 的 check_shutdown_signal 读 std::fs::read_to_string 拿 content。atomic rename 让 reader 看到旧或新 inode，不会看到空。如果 osascript 第一次写时 mhost 先写了 "running"，下次 disable 再写 "shutdown"，proxy 看到的要么是 "running"（第一次启动后的状态）要么是 "shutdown"（disable 写的）。两版逻辑等价，不是回归。

E. 待实验验证

最有价值的实验（不写代码，先跑测试）：

# 在 fix/dns-cancel-149 分支（已含 #148 + #149）手动跑一次：
MHOST_AUTO_DNS=1 pnpm tauri dev &
# 等 PHASE 1 (enable) PHASE 2 (disable) 跑完，立刻：
networksetup -getdnsservers Wi-Fi
# 期望：There aren't any DNS Servers set on Wi-Fi
# 实际（issue #152 报告）：127.0.0.1
# 现场日志对照（grep mhost_dns::proxy / mhost_dns::server）：
grep -E 'mhost-dns-proxy|received shutdown signal|restoring system DNS|networksetup failed|cleanup_signal_files' /tmp/mhost-repro.log
# 期望看到：[mhost-dns-proxy] restoring system DNS on Wi-Fi to Empty (DHCP default)
#           [mhost-dns-proxy] system DNS restored
# 实际（issue #152 现场）："received shutdown signal" 有，但 restore 那行没有

如果现场日志确认"proxy 收到 signal 但没走到 restore_dns_and_exit 末尾"——指向 D2-2（trap/cleanup 把 proxy 杀了）。

F. 建议修复方向（基于 D 的回归）

按用户感知优先级：

1. 修复 capture_dns_state 过滤 127.0.0.1 —— 单独可改，单点 fix，两版都受益。直接避免 [Bug] DNS disable 不还原系统 DNS（DhcpEmpty 路径下网络被卡在 127.0.0.1） #152 链路 2 的连锁污染。这是最便宜的修复。
2. 修复 disable 兜底路径 —— disable_dns_mode 在 is_expected_proxy_alive() == false 时总是调 osascript_restore（不再受 interactive 限制）或加 networksetup（不需要 sudo）的快速 check。这条 HEAD 已经在做（分支 5），但需要保证 in-memory OriginalDns 是正确的。
3. 如果是 trap 杀了正在 self-cleanup 的 proxy —— 改 proxy_should_keep_running 触发时机（先写 1 再 networksetup），或 inline pgrep 加 --older <时间>，或 inline pgrep 不杀有 ready file 的进程。

这三条不互斥。1 + 2 是稳健兜底（即使 proxy 完全坏掉），3 是避免不必要的兜底。

---

G. 给维护者的简短清单

grep-friendly anchors (HEAD):
  platform.rs:677   build_enable_script_body (90+ line script with trap)
  platform.rs:745   "</dev/null >/dev/null 2>&1 &"  ← FD redirect (PR #146/#149)
  platform.rs:1063  is_expected_proxy_alive (PR #148)
  proxy.rs:188      restore_dns_and_exit (两版等价)
  commands/dns.rs:42 set_dns_mode (新增 cancel token)
  commands/dns.rs:477 set_dns_mode_disable calls platform::disable_dns_mode
  commands/dns.rs:430 set_dns_mode_disable signature

v0.3.3 anchors:
  platform.rs:572   pub fn disable_dns_mode(original, interactive)  (无 cancel)
  platform.rs:466   write_signal_file (atomic)
  proxy.rs:215+     async fn restore_dns_and_exit

[flyhigher139]

Follow-up hardening landed (commit 0191132)

The previous fix 3873345 closed the marker-path and capture-filter root causes. This follow-up commit hardens the remaining risks identified in the analysis above (defense layer + D3-2 race + post-restore verification).

What changed

Step 1 — OriginalDns defense layer (mhost-core::models + mhost-dns::platform)

• OriginalDns::restore_argv filters loopback before passing to networksetup; falls back to ["Empty"] if filter empties the list (never silently write 127.0.0.1)
• Legacy Vec<String> deserializer filters loopback before the is_empty() / "Empty" decision so pre-fix manifests migrate cleanly
• enable_dns_mode original.txt writer does a final filter before write_atomic_0600

Step 2 — D3-2 pgrep race fix (build_enable_script_body top-of-script inline block)

• Replaced bare pgrep -x mhost-dns-proxy with PID-targeted kill: read pid_file → verify ps -p <pid> -o comm= basename matches the recorded binary path → TERM
• Broad pgrep sweep kept as fallback, gated behind stat -f %m pid_file freshness check (>30s old or missing)
• Mirrors the existing cleanup_stale_proxy safety pattern at platform.rs:1198 (防 PID 重用误杀)
• Trap- cleanup() still uses broad pgrep (different lifecycle — post-enable-failure path)

Step 3 — Post-restore verification fallback (disable_dns_mode success branch)

• New verify_dns_restored_against_loopback helper + pure any_local_resolver
• After kill(pid,0) != 0 succeeds, verify current networksetup -getdnsservers doesn't contain loopback. If it does (proxy's networksetup call failed silently — configd hiccup, Wi-Fi handoff), escalate to osascript_restore and preserve recovery marker for next-launch retry
• Mirrors the existing 5s-timeout escalation shape at platform.rs:965

Tests

Replaced source-grep tests with behavioral coverage:

• test_networksetup_get_dns_filter_pipeline (real behavior on the wrapper)
• test_post_restore_verify_helper_detects_loopback (any_local_resolver pure function)
• test_disable_recovery_marker_file_path_is_canonical (real behavior — verifies helper self-consistency)
• test_enable_script_inline_orphan_kill_uses_pid_file + negative pin test_enable_script_inline_orphan_kill_does_not_blind_pgrep
• 3 new tests in mhost-core covering restore_argv loopback filter + legacy deserializer + tagged deserializer

Verification

• cargo fmt --all -- --check: clean
• cargo clippy --all-targets --all-features -- -D warnings: clean
• cargo test --all-features -- --nocapture: 137 mhost + 117 mhost-dns + 48 mhost-core + others all green
• pnpm test: 313 frontend tests pass
• pnpm build: clean

E2E recipe

doc/tech/dns-mode-e2e-recipe.md documents 4 manual macOS scenarios:

1. Happy path DhcpEmpty (sanity)
2. Quick re-enable cycle (D3-2 regression scenario)
3. Mid-restore kill -9 (force-restore fallback)
4. Stubbed proxy with broken networksetup (configd hiccup simulation)

Plus log grep cheatsheet, cleanup steps, and known limitations (sudo+TCC not CI-able).

Branch

Branch: fix/dns-cancel-149
Commits: 3873345 (primary root cause fix) + 0191132 (this hardening follow-up)
Both pushed to origin. Closing this issue once reviewed.