作者：catcatyu（xxx@example.com）

为什么要阻止升级

RevokeMsgPatcher 通过对客户端二进制做特征 patch，实现 PC 微信 / QQ 的防撤回等能力。特征是跟具体版本绑定的，客户端一升，偏移和指令序列往往就失效。

社区 PR huiyadanli/RevokeMsgPatcher#1193 （fix: update QQNT anti-recall patterns）把 QQNT 防撤回特征更新到了：

也就是说：

• 你装了更高版本的 QQNT / 微信，这个 PR 里的规则不一定还能匹配；
• 腾讯客户端默认会后台检查 + 热更新/补丁下载，一重启就可能悄悄升上去；
• 想稳定用防撤回，就得先把版本钉住，再跑 patch 工具。

本文记录在 Windows 宿主机上实际踩过的路径：只拦 dldir*.qq.com 不够；QQNT 和微信 4.x 的更新通道、本地缓存位置都不一样。

说明：这是延后升级，不是永久锁死。服务端若强制最低版本，旧客户端仍可能无法登录。也不要用来路不明的「免更新破解版」。

历史版本从哪里下

当前版本已经高于 patch 上限时，需要先降回可用版本，再立刻做防更新。不要去搜来路不明的「绿色版 / 免更新破解包」；社区有专门归档安装包的仓库（Release 资产，可自行核对哈希）：

配合本文目标上限时，优先找：

• QQNT：9.9.20-36330（或 PR / 工具说明支持的最近一档）
• 微信：4.1.9.30（Weixin 4.x）

建议流程：

1. 卸载当前过高版本（或至少退出客户端）
2. 从上述仓库的 Releases 下载对应安装包
3. 安装完成后先不要登录，立刻做本文后面的 hosts / 清缓存 / 锁目录
4. 再登录，并运行 RevokeMsgPatcher

仓库由第三方维护，安装包是否完整、是否被服务端拒绝登录，以你本机实测为准；下载后尽量核对 Release 里公布的校验信息。

先确认当前版本

QQNT

安装目录常见：

1

C:\Program Files\Tencent\QQNT\

看当前热更新配置：

1

C:\Program Files\Tencent\QQNT\versions\config.json

关键字段：

1
2
3
4
5

{
  "curVersion": "9.9.20-36330",
  "readyVersion": "",
  "readyType": ""
}

• curVersion：正在用的版本目录名
• readyVersion 非空：本地已经下好/解压好，提示「新版本已就绪」，重启就会切过去

进程命令行里也能看到：

1

--app-path="C:\Program Files\Tencent\QQNT\versions\9.9.20-36330\resources\app"

微信（新版 Weixin 4.x）

新版安装目录是 Weixin，不是老的 WeChat：

1
2

C:\Program Files\Tencent\Weixin\
C:\Program Files\Tencent\Weixin\4.1.9.30\

用户数据与更新缓存：

1
2

%AppData%\Tencent\xwechat\
%AppData%\Tencent\xwechat\update\

更新组件：

1

%AppData%\Tencent\xwechat\xplugin\plugins\WeixinUpdate\<id>\extracted\WeixinUpdate.exe

总原则：更新分两段

所以会出现：

• hosts 已生效，但客户端仍提示「发现新版本 / 新版本已就绪」——正常；
• 点「立即更新」仍能下——说明走了别的域名，或IPv6 / 已建立连接没被拦；
• 点了就能装——说明包早就下完了。

一、QQNT：真正的热更新域名不是 dldir

1. 特征串（从 major.node 里能抠到）

1
2
3

https://qqpatch.gtimg.cn
https://qqpatch.gtimg.cn/hotUpdate_new
https://qqpatch.gtimg.cn/dynamic_module/

实际下载时 DNS 缓存里还出现过腾讯下载 CDN 变体，例如：

1
2

downv6.ydcdn.tcdnos.com
downv6.aly.tcdnos.com

（会随线路变化，以本机 DNS 缓存 / 抓包为准。）

2. 本地落地位置

热更新包会进：

1
2
3
4
5

C:\Program Files\Tencent\QQNT\versions\
  9.9.20-36330\          ← 当前版本目录
  9.9.xx-xxxxx\          ← 已解压的新版本
  9.9.xx-xxxxx.zip       ← 下载中的包（有时还会出现奇怪的 .zip.zip）
  config.json

若 config.json 里已有：

1
2

"readyVersion": "9.9.32-51246",
"readyType": "HOT_UPDATE"

则界面就是「新版本已就绪」——不必再下载。

3. hosts（管理员编辑）

路径：C:\Windows\System32\drivers\etc\hosts

建议同时写 IPv4 + IPv6（只写 127.0.0.1 时，IPv6 仍可能通）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# QQNT 热更新
127.0.0.1 qqpatch.gtimg.cn
::1 qqpatch.gtimg.cn

# 实测出现过的下载 CDN（可按抓包增减）
127.0.0.1 downv6.ydcdn.tcdnos.com
::1 downv6.ydcdn.tcdnos.com
127.0.0.1 downv6.aly.tcdnos.com
::1 downv6.aly.tcdnos.com
127.0.0.1 down.ydcdn.tcdnos.com
::1 down.ydcdn.tcdnos.com
127.0.0.1 down.aly.tcdnos.com
::1 down.aly.tcdnos.com
127.0.0.1 downv6.tcdnos.com
::1 downv6.tcdnos.com
127.0.0.1 down.tcdnos.com
::1 down.tcdnos.com

然后：

1

ipconfig /flushdns

验证：

1

ping qqpatch.gtimg.cn

应指向 127.0.0.1。

4. 清掉「已就绪」的新版本

1. 托盘彻底退出 QQ
2. 删除高于目标版本的目录和 zip，例如不要的 9.9.32-*
3. 编辑 versions\config.json，保证：

1
2
3
4

"curVersion": "9.9.20-36330",
"readyVersion": "",
"readyInstaller": "",
"readyType": ""

4. 再启动 QQ

可选加固：给 versions 目录去掉普通用户的写入权限（过狠可能影响正常运行，慎用）。

5. 副作用

• qqpatch.gtimg.cn 还承载部分主题 / 动态资源，拦截后个别皮肤资源可能异常。
• tcdnos.com 若被其它腾讯下载共用，也可能受影响。

二、微信 Weixin 4.x：dldir + 本地 update 目录

1. 二进制里的下载入口

Weixin.dll 里能看到类似：

1
2
3
4

https://dldir1.qq.com
https://dldir1v6.qq.com
https://dldir1v6.qq.com/weixin/Universal/Windows/XPlugin/updateConfigUniWin.xml
https://support.weixin.qq.com/update/

老办法「只 hosts 几个 dldir」对下载有帮助，但：

1. 要补 IPv6 ::1，否则 v6 线路可能绕过；
2. 若 %AppData%\Tencent\xwechat\update\ 里已经有完整 patch，点更新照样能装。

2. 本地更新缓存长什么样

示例（版本号按你机器上的为准）：

1
2
3
4
5
6
7

%AppData%\Tencent\xwechat\update\
  download\4.1.11.55\Weixin.dll.zip
  download\4.1.11.55\Weixin.exe.zip
  download\4.1.11.55\patch.zip
  patch\4.1.11.55\Weixin.dll
  patch\4.1.11.55\Weixin.exe
  ...

同时进程列表里可能出现：

1

WeixinUpdate.exe

路径类似：

1

%AppData%\Tencent\xwechat\xplugin\plugins\WeixinUpdate\9013\extracted\WeixinUpdate.exe

3. hosts

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 微信 / 腾讯通用下载域（IPv4 + IPv6）
127.0.0.1 dldir1.qq.com
::1 dldir1.qq.com
127.0.0.1 dldir1v6.qq.com
::1 dldir1v6.qq.com
127.0.0.1 dldir2.qq.com
::1 dldir2.qq.com
127.0.0.1 dldir3.qq.com
::1 dldir3.qq.com
127.0.0.1 dldir4.qq.com
::1 dldir4.qq.com
127.0.0.1 dldir5.qq.com
::1 dldir5.qq.com
127.0.0.1 dldir6.qq.com
::1 dldir6.qq.com

1

ipconfig /flushdns

4. 删缓存 + 锁 update 目录

1. 退出微信（含托盘）
2. 结束残留的 WeixinUpdate.exe
3. 删除整个：

1

%AppData%\Tencent\xwechat\update

4. 重建空目录后，对 update：拒绝当前用户 / Users 的写入、修改、删除（Administrators / SYSTEM 保留完全控制）。

这样即使检查到更新，也写不进缓存。

5. 防火墙拦 WeixinUpdate.exe（推荐）

Win + R → wf.msc → 出站规则 → 新建规则 → 程序 → 选中上述 WeixinUpdate.exe → 阻止连接。

插件版本目录（如 9012 / 9013）可能并存，每个路径各建一条，或更新后检查是否换了路径。

主程序 Weixin.exe 不要整进程出站全拦，容易直接没法登录/收消息。

6. 副作用

• dldir*.qq.com 是腾讯通用下载域，QQ 安装包、其它腾讯软件下载也可能受影响。
• 锁 update 后，官方热更新基本失效——对「钉死 4.1.9.30」是预期行为。

三、推荐操作顺序（想钉在 RevokeMsgPatcher 可用版本）

以目标 QQNT 9.9.20-36330、微信 4.1.9.30 为例：

1. 先确认当前就是目标版本；若更高，从历史版本仓库装回：
   • QQNT：PRO-2684/qqnt-version-history
   • 微信：cscnk52/wechat-windows-versions
2. 立刻改 hosts（QQNT 的 qqpatch + 微信的 dldir，都带 ::1）。
3. 立刻清 QQNT versions 里多余版本 + 清空 readyVersion。
4. 立刻清微信 xwechat\update，并锁写 + 拦 WeixinUpdate.exe。
5. 再运行 RevokeMsgPatcher （含 PR #1193 那套特征）。
6. 日常少点「立即更新」；看到「已就绪」优先当本地缓存，先清再谈拦域名。

四、怎么确认拦截生效

DNS

1
2

ping qqpatch.gtimg.cn
ping dldir1v6.qq.com

应解析到 127.0.0.1 / 本机。

QQNT

• versions 下不应再长出新的大体积 zip / 新版本目录；
• config.json 的 readyVersion 应保持空。

微信

• xwechat\update 下不应再出现 download\ / patch\ 大文件；
• 若仍弹更新但装不上、写目录失败，说明权限锁在起作用。

仍能下载时

1. 在下载过程中看 DNS 缓存：

1

Get-DnsClientCache | Where-Object { $_.Entry -match 'qq|weixin|gtimg|tcdnos|dldir' }

2. 看进程出站连接（Get-NetTCPConnection -OwningProcess <pid>），把新域名补进 hosts。
3. 已建立的 TCP 连接不会因改 hosts 立刻断，需退出客户端再试。

五、和 RevokeMsgPatcher 的关系（再强调一次）

防更新的目的不是「永远不用新版本」，而是：

把客户端钉在 patch 特征仍然匹配的版本上，避免热更新把防撤回打失效。

PR #1193 侧当前明确测过 / 面向的上限是：

• QQNT：9.9.20-36330（含私聊 C2C 被动撤回路径）
• 微信：4.1.9.30

版本一涨，需要重新找特征、更新 patch.json / 资源，而不是指望旧二进制一直能用。
上游合并进度、后续版本支持范围以仓库与 PR 讨论为准：
https://github.com/huiyadanli/RevokeMsgPatcher/pull/1193

六、恢复方法（简要）

1. 从改 hosts 前的备份恢复 C:\Windows\System32\drivers\etc\hosts，或删掉本文相关段落。
2. ipconfig /flushdns
3. 删除防火墙规则「Block WeixinUpdate outbound*」
4. 恢复 xwechat\update 目录权限（去掉 Deny 写入）
5. 需要升级时再走官方更新即可

小结

只拦 dldir、不管本地已就绪包，是最常见的「hosts 设了还是在更」原因。
为了配合 RevokeMsgPatcher 的版本上限，应把「拦域名 + 清缓存 + 必要时权限/防火墙」当成一套流程，而不是单点技巧。

本文2026-07-25首发于猫猫鱼的小窝，最后修改于2026-07-25

作者：catcatyu（xxx@example.com）

背景

打开超星学习通（chaoxing.com）时页面一直加载缓慢，浏览器开发者工具发现 static.wisweb.com 和 p2.cldisk.com 两个资源域名 DNS 解析失败（ERR_NAME_NOT_RESOLVED）。排查发现系统 DNS 指向了本地 dnscrypt-proxy（127.0.0.1:53），而 dnscrypt-proxy 配置了通过 xray 代理访问 Cloudflare DoH，形成了一条脆弱的依赖链。

问题根因

原来的 DNS 解析链路：

系统 DNS (127.0.0.1:53)
  → dnscrypt-proxy
    → http_proxy (127.0.0.1:10808)
      → xray 代理
        → Cloudflare DoH (cloudflare-dns.com)

这条链路存在多个单点故障：

1. dnscrypt-proxy 依赖 xray 代理：http_proxy = 'http://127.0.0.1:10808' 配置导致所有 DNS 查询都要经过 xray
2. xray 节点域名需要 DNS 解析：xray 连接的节点域名 d4.fjh1997.top 本身需要 DNS 查询，存在循环依赖风险
3. 重启即崩：dnscrypt-proxy 重启后缓存清空，需要重新 bootstrap 连接 Cloudflare，但如果 xray 代理此时未就绪，整个 DNS 系统瘫痪

需求

• 默认域名走普通 DNS（快速、稳定、不依赖代理）
• 白名单域名（Google、GitHub 等）走 Cloudflare DoH，通过 xray SOCKS5 代理加密访问
• DoH 或代理故障时自动回退到普通 DNS
• 不能有循环依赖

方案选型

尝试 dnsproxy（AdGuard）

dnsproxy 支持按域名分流上游，但有两个致命问题：

1. 不支持 HTTP 代理：HTTPS_PROXY 环境变量无效，直连 Cloudflare 被 GFW reset
2. 不支持 http:// scheme作为 DoH 上游：日志报 unsupported url scheme: http

尝试用 Python 写中继脚本弥补，但需要自签证书、额外维护一个进程，方案过于复杂。

最终选择：mosdns-x

mosdns-x 是一个灵活的 DNS 路由器，原生支持：

• fast_forward 插件的 socks5 参数 — 直接通过 SOCKS5 代理转发 DoH 请求
• dial_addr 参数 — 直接指定 DoH 服务器 IP，避免 DNS 循环依赖
• primary/secondary + fast_fallback — 优雅的故障回退机制
• data_provider — 白名单域名文件，支持 auto_reload 热更新

部署

macOS 安装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 通过代理下载（直连 GitHub 可能慢）
curl -sL --proxy socks5://127.0.0.1:10808 \
  -o /tmp/mosdns.zip \
  "https://github.com/pmkol/mosdns-x/releases/download/v26.05.25/mosdns-darwin-arm64.zip"

unzip /tmp/mosdns.zip -d /tmp/mosdns-bin
cp /tmp/mosdns-bin/mosdns /opt/homebrew/bin/mosdns
chmod +x /opt/homebrew/bin/mosdns

mosdns version
# version: v4.6.0, build time: 26.05.25

白名单域名文件

创建 /opt/homebrew/etc/mosdns/whitelist.txt，每行一个域名，后缀匹配（google.com 会匹配 www.google.com 等）：

# Google
google.com
googleapis.com
gstatic.com
youtube.com
ytimg.com
ggpht.com
googlevideo.com

# GitHub
github.com
githubusercontent.com
githubassets.com
github.io

# 社交媒体
twitter.com
x.com
twimg.com
t.co
facebook.com
instagram.com
whatsapp.com

# AI
openai.com
anthropic.com
claude.ai
chatgpt.com

# 其他
wikipedia.org
wikimedia.org
cloudflare.com
microsoft.com
apple.com

mosdns 配置文件

创建 /opt/homebrew/etc/mosdns/config.yaml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

log:
  file: ""
  level: error

data_providers:
  - tag: doh_whitelist
    file: /opt/homebrew/etc/mosdns/whitelist.txt
    auto_reload: true

plugins:
  # 缓存
  - tag: cache
    type: cache
    args:
      size: 4096
      lazy_cache_ttl: 86400

  # 默认上游: AliDNS 普通 DNS (快、稳、不依赖代理)
  - tag: forward_default
    type: fast_forward
    args:
      upstream:
        - addr: "223.5.5.5"
          trusted: true
        - addr: "223.6.6.6"
          trusted: true

  # DoH 上游: Cloudflare DoH 经 xray SOCKS5 代理
  # dial_addr 直接指定 IP，无需 DNS 解析，避免循环依赖
  - tag: forward_doh
    type: fast_forward
    args:
      upstream:
        - addr: "https://cloudflare-dns.com/dns-query"
          dial_addr: "1.1.1.1:443"
          socks5: "127.0.0.1:10808"
          trusted: true
          idle_timeout: 30

  # 白名单域名匹配
  - tag: query_is_whitelist
    type: query_matcher
    args:
      domain:
        - "provider:doh_whitelist"

  # 白名单处理: DoH 优先，超时回退到普通 DNS
  - tag: whitelist_handler
    type: sequence
    args:
      exec:
        - primary:
            - forward_doh
          secondary:
            - forward_default
          fast_fallback: 300
          always_standby: false

  # 主流水线
  - tag: main_sequence
    type: sequence
    args:
      exec:
        - cache
        - if: query_is_whitelist
          exec:
            - whitelist_handler
            - _return
        - forward_default

servers:
  - exec: main_sequence
    timeout: 5
    listeners:
      - protocol: udp
        addr: "127.0.0.1:53"
      - protocol: tcp
        addr: "127.0.0.1:53"

macOS launchd 服务

创建 /Library/LaunchDaemons/com.mosdns.plist：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.mosdns</string>
    <key>ProgramArguments</key>
    <array>
        <string>/opt/homebrew/bin/mosdns</string>
        <string>start</string>
        <string>-c</string>
        <string>/opt/homebrew/etc/mosdns/config.yaml</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
    <key>StandardErrorPath</key>
    <string>/opt/homebrew/var/log/mosdns.log</string>
</dict>
</plist>

加载服务并切换系统 DNS：

1
2
3

sudo launchctl load /Library/LaunchDaemons/com.mosdns.plist
networksetup -setdnsservers Wi-Fi 127.0.0.1
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Windows 部署为系统服务

Windows 不建议把 mosdns.exe 直接放进注册表启动项或交互式计划任务。mosdns.exe 是控制台程序，这样做在登录时会弹出黑框；如果同时配置了多个启动入口，还会出现多个实例争用 53 端口、任务返回 0xFFFFFFFF 等问题。

mosdns-x 自带 Windows 服务管理功能，正确做法是将其注册为系统服务。以下步骤已在 Windows 11、mosdns-x v4.6.0（build 26.05.25）上验证。

相关脚本下载

本文配套脚本已放在站点静态目录，可直接下载：

也可从 GitHub 仓库路径获取：static/files/mosdns/

一键下载健康检查到 C:\mosdns 并注册任务（管理员 PowerShell）：

1
2
3
4

New-Item -ItemType Directory -Path C:\mosdns -Force | Out-Null
Invoke-WebRequest https://cat.fjh1997.top/files/mosdns/healthcheck.ps1 -OutFile C:\mosdns\healthcheck.ps1
Invoke-WebRequest https://cat.fjh1997.top/files/mosdns/install-healthcheck.ps1 -OutFile C:\mosdns\install-healthcheck.ps1
powershell -ExecutionPolicy Bypass -File C:\mosdns\install-healthcheck.ps1

1. 准备目录和文件

从 mosdns-x Releases 下载 mosdns-windows-amd64.zip，解压后整理成：

1
2
3
4
5
6

C:\mosdns\
├── mosdns.exe
├── config.yaml              # 示例: /files/mosdns/config.windows.yaml
├── whitelist.txt            # 示例: /files/mosdns/whitelist.txt
├── healthcheck.ps1          # 可选 UDP 健康检查
└── install-healthcheck.ps1

示例配置与白名单可直接下载：

• config.windows.yaml → 保存为 C:\mosdns\config.yaml（按需改 SOCKS 端口/上游）
• whitelist.txt → C:\mosdns\whitelist.txt

Windows 版配置逻辑与前文一致，只需要把文件路径换成 Windows 路径。YAML 中推荐使用正斜杠，避免反斜杠转义：

1
2
3
4
5
6
7
8

log:
  file: "C:/mosdns/mosdns.log"
  level: error

data_providers:
  - tag: doh_whitelist
    file: "C:/mosdns/whitelist.txt"
    auto_reload: true

中间的 plugins 配置直接沿用前文。servers 可以同时监听 IPv4 和 IPv6 回环地址：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

servers:
  - exec: main_sequence
    timeout: 5
    listeners:
      - protocol: udp
        addr: "127.0.0.1:53"
      - protocol: tcp
        addr: "127.0.0.1:53"
      - protocol: udp
        addr: "[::1]:53"
      - protocol: tcp
        addr: "[::1]:53"

先在管理员 PowerShell 中检查版本和配置能否启动：

1
2
3

Set-Location C:\mosdns
.\mosdns.exe version
.\mosdns.exe start -c C:\mosdns\config.yaml

看到四个监听器正常启动后按 Ctrl+C 退出，再安装服务。

2. 安装并启动 Windows 服务

仍在管理员 PowerShell 中执行：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

Set-Location C:\mosdns

# 注册为开机自动启动的 Windows 服务
.\mosdns.exe service install -d C:\mosdns -c C:\mosdns\config.yaml

# install 只负责注册，不会立即启动
.\mosdns.exe service start

# 查看 mosdns 自带的服务状态
.\mosdns.exe service status

# 也可以通过 Windows SCM 查看
Get-Service -Name mosdns

正常情况下，服务应显示为 Running，启动类型为 Automatic，登录桌面时也不会出现控制台窗口。

该服务功能由 mosdns-x 内置的 service 子命令提供。官方说明其底层基于 kardianos/service，Windows 已实测可用，但仍建议安装后检查服务、监听端口和实际 DNS 解析结果。

3. 将 Windows DNS 指向本机

先查看正在使用的物理网卡名称：

1

Get-NetAdapter | Where-Object Status -eq Up

假设网卡名为 以太网，执行：

1
2
3

netsh interface ipv4 set dnsservers name="以太网" static 127.0.0.1 primary validate=no
netsh interface ipv6 set dnsservers name="以太网" static ::1 primary validate=no
Clear-DnsClientCache

如果使用 Wi-Fi，把命令中的 以太网 换成实际接口名。只需要修改当前上网的物理网卡，不要批量修改 WSL、Hyper-V、VMware、Tailscale、WireGuard 等虚拟网卡。

4. 验证服务、端口和解析

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 服务必须处于 Running
Get-Service -Name mosdns

# 127.0.0.1 和 ::1 的 TCP/UDP 53 应归同一个 mosdns PID
Get-NetUDPEndpoint -LocalPort 53
Get-NetTCPConnection -LocalPort 53 -State Listen

# 测试普通 DNS 和白名单域名
Resolve-DnsName baidu.com -Server 127.0.0.1 -DnsOnly
Resolve-DnsName google.com -Server 127.0.0.1 -DnsOnly
Resolve-DnsName github.com -Server 127.0.0.1 -DnsOnly

mosdns 服务会早于用户登录启动，而 xray 的 127.0.0.1:10808 可能稍后才就绪。此时白名单查询暂时走 secondary 普通 DNS 回退是预期行为；xray 启动后，后续查询会自动恢复使用 Cloudflare DoH。

5. 避免重复启动

确认服务运行正常后，不要再保留同名计划任务或注册表启动项。可以先检查：

1
2
3

Get-ScheduledTask -TaskName mosdns -ErrorAction SilentlyContinue
Get-ItemProperty HKCU:\Software\Microsoft\Windows\CurrentVersion\Run `
  -Name mosdns -ErrorAction SilentlyContinue

如果这些入口是以前手动创建的，可以删除：

1
2
3

Unregister-ScheduledTask -TaskName mosdns -Confirm:$false -ErrorAction SilentlyContinue
Remove-ItemProperty HKCU:\Software\Microsoft\Windows\CurrentVersion\Run `
  -Name mosdns -ErrorAction SilentlyContinue

服务日常管理命令：

1
2
3
4
5
6
7
8

Set-Location C:\mosdns
.\mosdns.exe service restart
.\mosdns.exe service stop
.\mosdns.exe service start

# 确实不再使用时才卸载
.\mosdns.exe service stop
.\mosdns.exe service uninstall

Windows 服务账户：为何默认是 LocalSystem，而不是用户态

mosdns.exe service install 注册的服务默认以 LocalSystem（SYSTEM） 运行。这不是“必须最高权限才安全”，而是工程取舍：

结论：

• 作为系统 DNS 转发器，更合理的模型是 服务 + 开机自启，而不是“用户登录后才起的用户态进程”。
• 若坚持更安全：可改为专用本地账户跑服务，而不是直接用交互用户会话；不必为了“用户态更安全”放弃 Windows 服务模型。
• 本文实测：UDP 上游假死与“是不是 LocalSystem”无直接关系——同一 LocalSystem 下 SYSTEM 裸发 UDP 到阿里 DNS 完全正常，问题在 mosdns 进程内复用的 UDP 连接。

Windows 默认上游建议多路兜底

生产环境建议默认上游不要只写两个 AliDNS，可加上路由器与备用公共 DNS，降低单一上游抖动：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

  - tag: forward_default
    type: fast_forward
    args:
      upstream:
        - addr: "192.168.1.254"   # 按实际网关修改；没有可删
          trusted: true
        - addr: "223.5.5.5"
          trusted: true
        - addr: "223.6.6.6"
          trusted: true
        - addr: "119.29.29.29"
          trusted: true

日志排查时临时把 log.level 调到 info，稳定后再改回 error。

Windows 踩坑：UDP 上游“假死”（2026-07 补充）

现象

• 服务显示 Running，127.0.0.1:53 也在听。
• 白名单域名（Google/GitHub，走 DoH + SOCKS5）仍正常。
• 默认域名（baidu、超星静态资源等，走明文 UDP 上游）全部超时：context deadline exceeded。
• 用户态用同一份 config.yaml 起 mosdns（监听高端口）则 UDP 上游完全正常。

容易误判成：

1. 上游 DNS 挂了
2. 和 ICS（SharedAccess）“抢上游端口”
3. LocalSystem 不能发 UDP

下面三条都能排除。

根因（已用抓包 + 管理员实验验证）

fast_forward 会对上游做 连接复用（进程内可见长期 connected 的 UDP：0.0.0.0:xxxxx → 223.5.5.5:53 等）。

在 Windows 上，服务跑久之后（休眠唤醒、网卡切换、Hyper-V/WSL 虚拟网卡抖动等），这些 connected UDP 可能进入“假死”：

进一步对照：

1
2
3
4

SYSTEM 进程 raw UDP → 223.5.5.5     ✅ 正常
假死中的 mosdns 服务（旧 PID）      ❌ 线上 0 包
重启后的 mosdns 服务（新 PID）      ✅ UDP 恢复
ICS (SharedAccess) 保持 Running     ✅ 不必为修 UDP 去关 ICS

因此：

1. 不是上游服务器坏了。
2. 不是 ICS 和 223.5.5.5 抢端口——上游在远端，客户端用的是临时源端口。
3. ICS 占 0.0.0.0:53 主要影响的是“谁当本机 DNS 服务端监听 53”；你的 mosdns 监听 127.0.0.1:53 可以并存。
4. 若本机还开 WSL2，微软文档要求 ICS/SharedAccess 参与 HNS/DNS，不要为了本机 DNS 长期禁用 ICS。

快速恢复（坚持 UDP 上游时）

管理员 PowerShell：

1
2
3

Restart-Service mosdns
Resolve-DnsName www.baidu.com -Server 127.0.0.1 -DnsOnly -Type A
Resolve-DnsName static.wisweb.com -Server 127.0.0.1 -DnsOnly -Type A

健康检查：失败才重启（推荐）

官方 idle_timeout 只作用于 TCP/DoT/DoH 等，不会回收明文 UDP 连接。要在坚持 UDP 上游的前提下自愈，使用配套脚本（healthcheck.ps1 / install-healthcheck.ps1 ）：

1. 周期性用 127.0.0.1 解析非白名单域名（走默认 UDP 上游）。
2. 仅失败时 Restart-Service mosdns，正常时零打扰。
3. 以 SYSTEM 计划任务运行（默认每 3 分钟）。

管理员一键安装：

1
2

# 已下载到 C:\mosdns 时：
powershell -ExecutionPolicy Bypass -File C:\mosdns\install-healthcheck.ps1

或直接从站点拉取（见上文「相关脚本下载」）。

这与早期“暴力 watchdog 杀进程”不同：仅探测失败才重启，正常时不碰服务。

日志默认写到 C:\mosdns\healthcheck.log。

排查清单（给未来的自己）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 1) 服务与监听
Get-Service mosdns
Get-NetUDPEndpoint -LocalPort 53 | Format-Table LocalAddress,OwningProcess

# 2) 是否在复用“假死”上游 socket（长期固定远程 53 很可疑）
$pid = (Get-CimInstance Win32_Service -Filter "Name='mosdns'").ProcessId
netstat -ano -p UDP | findstr $pid

# 3) 分流是否正常：默认域 vs 白名单
Resolve-DnsName www.baidu.com  -Server 127.0.0.1 -DnsOnly -Type A
Resolve-DnsName www.google.com -Server 127.0.0.1 -DnsOnly -Type A

# 4) 对照：本机直连上游是否正常（排除运营商/上游故障）
Resolve-DnsName www.baidu.com -Server 223.5.5.5 -DnsOnly -Type A

# 5) 仍异常：抓包看服务查询时有没有 192.168.x.x → 223.5.5.5 的 DNS
#    有请求无应答 → 上游/中间设备；完全无请求 → 假死连接或进程未真正 send

配置务必改 服务实际加载的路径 C:\mosdns\config.yaml（sc qc mosdns 可见），不要改用户目录里另一份拷贝。

架构说明

系统 DNS: 127.0.0.1 → mosdns (mosdns-x v4.6.0)
  │
  ├── 默认域名 → AliDNS 普通 DNS (223.5.5.5)
  │     快速、稳定、不依赖代理
  │     chaoxing.com, wisweb.com, cldisk.com 等
  │
  └── 白名单域名 → Cloudflare DoH (1.1.1.1:443)
        ├── 经 xray SOCKS5 代理 (127.0.0.1:10808)
        ├── dial_addr 直连 IP，无需 DNS 解析
        ├── 300ms 超时自动回退到 AliDNS
        │
        google.com, github.com, twitter.com 等

关键设计

避免循环依赖：dial_addr: "1.1.1.1:443" 直接指定 Cloudflare 的 IP，mosdns 连接 DoH 服务器时不需要先解析域名。xray 的 SOCKS5 入口也是 127.0.0.1:10808，本地直连无需 DNS。

自动回退：fast_fallback: 300 表示 DoH 请求超过 300ms 未响应时，自动发起普通 DNS 查询作为备选。always_standby: false 表示不预先发起备选查询，仅在超时后才回退，减少不必要的查询。

白名单热更新：auto_reload: true 让 mosdns 监控白名单文件变化。macOS 编辑 /opt/homebrew/etc/mosdns/whitelist.txt，Windows 编辑 C:\mosdns\whitelist.txt，保存后都会自动生效，无需重启服务。

Windows 服务模型：用内置 service 跑 LocalSystem，保证未登录也可解析；安全上若要收紧，优先考虑专用服务账户，而不是退回用户态启动项。

Windows UDP 自愈：明文 UDP 上游可能因连接复用假死；保留 UDP 策略时，用“探测失败才重启”的健康检查，而不是改成全站 DoH 或关掉 ICS。

验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 默认域名 - 走 AliDNS
nslookup www.chaoxing.com
# Name: bistatic-mh.aichaoxing.com
# Address: 140.210.88.45

nslookup static.wisweb.com
# Name: k1.gslb.ksyuncdn.com
# Address: 115.231.33.4

# 白名单域名 - 走 Cloudflare DoH via xray
nslookup google.com
# Name: google.com
# Address: 142.251.210.142

nslookup github.com
# Name: github.com
# Address: 20.205.243.166

清理旧服务

1
2
3
4
5
6
7
8
9

# 禁用 dnscrypt-proxy
sudo mv /Library/LaunchDaemons/homebrew.mxcl.dnscrypt-proxy.plist \
       /Library/LaunchDaemons/homebrew.mxcl.dnscrypt-proxy.plist.disabled

# 禁用 dnsproxy 和 doh-relay
sudo mv /Library/LaunchDaemons/com.dnsproxy.plist \
       /Library/LaunchDaemons/com.dnsproxy.plist.disabled
sudo mv /Library/LaunchDaemons/com.doh-relay.plist \
       /Library/LaunchDaemons/com.doh-relay.plist.disabled

配置文件位置

重启命令：

1
2

sudo launchctl unload /Library/LaunchDaemons/com.mosdns.plist
sudo launchctl load /Library/LaunchDaemons/com.mosdns.plist

总结

从"超星加载慢"到最终方案，经历了：

1. 诊断：浏览器 DevTools 发现 DNS 解析失败
2. 根因：dnscrypt-proxy 的 http_proxy 配置造成脆弱的代理依赖链
3. 尝试 dnsproxy：不支持 HTTP 代理，不支持 http:// scheme，方案失败
4. 尝试 Python 中继：可行但过于复杂，需要额外维护进程和自签证书
5. mosdns-x：原生 socks5 参数 + dial_addr + fast_fallback，完美满足所有需求

mosdns-x 的插件化设计非常灵活，fast_forward 插件的 socks5 参数直接解决了"DoH 走代理"的核心需求，dial_addr 避免了 DNS 循环依赖，primary/secondary + fast_fallback 提供了优雅的故障回退。配合 data_provider 的 auto_reload，白名单维护也非常方便。

Windows 上后续补充的经验：

1. 用系统服务，不要用户态启动项——为的是开机可用，不是“SYSTEM 更安全”。
2. 默认路径坚持 UDP 时，要防连接假死——表现为白名单还行、国内域全挂；重启服务即愈；可用健康检查自愈。
3. 需要 WSL2 时不要长期关 ICS——ICS 占 0.0.0.0:53 与 127.0.0.1:53 可并存；UDP 假死不是“和上游抢 53 端口”。

本文2026-07-06首发于猫猫鱼的小窝，最后修改于2026-07-06

作者：catcatyu（xxx@example.com）

问题现象

一开始我是从 Windows 的“设置 -> 系统 -> 可选功能 -> 查看功能”里添加 OpenSSH 服务器，界面一直停在“正在添加”，进度很慢：

后面不再等可选功能页面，改成用命令行安装和排查 OpenSSH Server：

1

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

命令执行很慢，长时间没有进度。即使给当前 PowerShell 加了代理，例如：

1
2

$env:http_proxy="http://127.0.0.1:10809"
$env:https_proxy="http://127.0.0.1:10809"

也不一定有用。

原因是 Add-WindowsCapability 背后不是简单的 PowerShell 下载，而是通过 Windows Update、BITS、CBS/TrustedInstaller 这些系统组件去获取 FoD（Features on Demand）内容。当前用户的环境变量代理不等于系统服务账户代理。

排查过程

先看 WinHTTP 代理：

1

netsh winhttp show proxy

再看代理端口是否真的在监听：

1

Get-NetTCPConnection -LocalAddress 127.0.0.1 -LocalPort 10809 -State Listen

如果使用 v2rayN/xray，通常 HTTP 代理端口是 127.0.0.1:10809；如果使用 Clash，常见端口是 127.0.0.1:7890。

然后看 CBS/DISM 日志：

1
2

Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern "FCAcquirerWUClient|DownloadProgress|0x"
Select-String -Path C:\Windows\Logs\DISM\dism.log -Pattern "OpenSSH|Add-Capability|0x"

我这里看到的关键日志是：

1

FCAcquirerWUClient: WULib DownloadProgress: [0 / 100]

也就是卡在 Windows Update 下载阶段，并不是 OpenSSH 本身安装慢。

还要检查 CBS 是否有待重启事务：

1
2

Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"

如果返回 True，建议先重启。CBS 有 pending reboot 时，Add-WindowsCapability 很容易卡住、失败或重复下载。

正确的代理配置

以 127.0.0.1:10809 为例，管理员 PowerShell 执行：

1

netsh winhttp set proxy proxy-server="http=127.0.0.1:10809;https=127.0.0.1:10809" bypass-list="localhost;127.0.0.1;<local>"

再给 BITS 的三个服务账户设置代理：

1
2
3

bitsadmin /util /setieproxy localsystem MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy networkservice MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy localservice MANUAL_PROXY 127.0.0.1:10809 NULL

重启相关服务：

1

Restart-Service wuauserv,bits,DoSvc,cryptsvc -Force

如果之前已经卡了很久，建议直接重启系统。我的情况就是代理配置正确后仍然卡在 0%，重启清掉 CBS pending 状态后才成功。

重新安装 OpenSSH Server

重启后确认代理程序已经启动，端口能连通：

1

Test-NetConnection 127.0.0.1 -Port 10809

然后执行：

1

dism.exe /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0

也可以继续使用 PowerShell：

1

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

注意 capability 名称最后是 0.0.1.0，不要写成 0.0.1.。

安装后启用 sshd

安装成功后检查文件和服务：

1
2

Test-Path C:\Windows\System32\OpenSSH\sshd.exe
Get-Service sshd

启用并启动服务：

1
2

Set-Service -Name sshd -StartupType Automatic
Start-Service -Name sshd

开放防火墙 22 端口：

1
2
3
4
5
6
7
8

New-NetFirewallRule `
  -Name "OpenSSH-Server-In-TCP" `
  -DisplayName "OpenSSH SSH Server (sshd)" `
  -Enabled True `
  -Direction Inbound `
  -Protocol TCP `
  -Action Allow `
  -LocalPort 22

如果规则已经存在，可以改成所有网络配置文件都生效：

1

Set-NetFirewallRule -Name "OpenSSH-Server-In-TCP" -Enabled True -Profile Any

验证

查看服务：

1

Get-Service sshd

正常应该是：

1
2

Status   : Running
StartType: Automatic

查看监听：

1

netstat -ano -p tcp | Select-String ":22 "

正常会看到：

1

TCP    0.0.0.0:22    0.0.0.0:0    LISTENING

局域网其他机器连接：

1

ssh 用户名@Windows主机IP

例如：

1

ssh fjh1996@192.168.1.10

总结

这个问题的关键点是：

1. http_proxy / https_proxy 只影响当前进程，不足以让 Windows Update 服务走代理。
2. Add-WindowsCapability 背后依赖 Windows Update、BITS 和 CBS。
3. 需要同时配置 WinHTTP 代理和 BITS 服务账户代理。
4. 如果 CBS 已经有 RebootPending，先重启，否则可能一直卡在 DownloadProgress: [0 / 100]。
5. 安装成功后还要启动 sshd 服务并检查防火墙规则。

最终有效流程就是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

netsh winhttp set proxy proxy-server="http=127.0.0.1:10809;https=127.0.0.1:10809" bypass-list="localhost;127.0.0.1;<local>"

bitsadmin /util /setieproxy localsystem MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy networkservice MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy localservice MANUAL_PROXY 127.0.0.1:10809 NULL

Restart-Service wuauserv,bits,DoSvc,cryptsvc -Force

dism.exe /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0

Set-Service -Name sshd -StartupType Automatic
Start-Service -Name sshd

本文2026-04-28首发于猫猫鱼的小窝，最后修改于2026-04-28

作者：catcatyu（xxx@example.com）

问题背景

宿主机 Windows（VMware Workstation 17.6.0），虚拟机 Windows 7 SP1 32位。遇到两个问题：

1. 宿主机无法连接虚拟机（ping 不通）
2. 修复网络后，VMware Tools 的复制粘贴功能不工作

以下是完整的排查过程。

问题一：宿主机无法连接虚拟机

现象

虚拟机 IP 为 192.168.191.129（NAT 模式），从宿主机 ping 100% 丢包：

ping 192.168.191.129
请求超时。
请求超时。
数据包: 已发送 = 2，已接收 = 0，丢失 = 2 (100% 丢失)

排查过程

检查宿主机网卡状态：

1

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, MacAddress -AutoSize

Name                          InterfaceDescription                       Status      MacAddress
----                          --------------------                       ------      ----------
以太网                        Intel(R) Ethernet Connection (22) I219-LM  Up          F4-F1-9E-42-D8-DD
VMware Network Adapter VMnet1 VMware Virtual Ethernet Adapter for VMnet1 Not Present 00-50-56-C0-00-01
VMware Network Adapter VMnet8 VMware Virtual Ethernet Adapter for VMnet8 Not Present 00-50-56-C0-00-08

关键发现：VMnet1（Host-Only）和 VMnet8（NAT）状态都是 Not Present，AdminStatus: Down。

再看 IPv4 地址分配：

1

Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, IPAddress, PrefixLength -AutoSize

InterfaceAlias              IPAddress   PrefixLength
--------------              ---------   ------------
以太网                      10.30.17.50           24
Loopback Pseudo-Interface 1 127.0.0.1              8

宿主机只有物理网卡有 IP，VMware 虚拟网卡完全没有加载，自然没有到 192.168.191.x 网段的路由。

同时 VMware NAT Service 虽然在运行，但网卡驱动本身没有加载：

1

Get-Service -Name 'VMware*' | Format-Table Name, DisplayName, Status -AutoSize

Name                   DisplayName          Status
----                   -----------          ------
VMware NAT Service     VMware NAT Service  Running
VmwareAutostartService VMware 自动启动服务  Stopped

根因

VMware 虚拟网卡驱动未正确加载，网卡处于 Not Present 状态。NAT Service 虽然在跑，但没有对应的虚拟网卡承载流量。

解决方法

打开 VMware Workstation → Edit → Virtual Network Editor → 点击 “Restore Defaults”（需要管理员权限）。这会重新创建 VMnet1/VMnet8 并重装虚拟网卡驱动。

如果不行，还可以：

• 在设备管理器中检查是否有被禁用或带感叹号的 VMware 网卡，右键启用或更新驱动
• 修复安装 VMware Workstation（运行安装程序选 Repair）

恢复后虚拟机 IP 变为 192.168.78.128，网络连通。

问题二：VMware Tools 服务启动失败

现象

网络恢复后，SSH 进入虚拟机发现 VMware Tools 没有正常工作。

排查过程

通过 SSH（paramiko）远程执行命令检查（注意：这台 VM 是 Windows 7，不是 Linux）：

1

sc query VMTools

SERVICE_NAME: VMTools
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 183 (0xB7)

VMTools 服务状态为 STOPPED，退出码 183（ERROR_ALREADY_EXISTS）。

同时检查进程：

1

tasklist | findstr /i vmtoolsd

发现 vmtoolsd.exe（PID 1868）在用户会话（Console Session 1）里运行着——这是用户态的托盘进程，但系统服务层面的 VMTools 没有启动。

根因

之前异常退出后残留了用户态 vmtoolsd.exe 进程，占用了资源，导致系统服务启动时报错 183（ERROR_ALREADY_EXISTS，资源冲突）。

解决方法

1
2
3
4
5

:: 先杀掉残留的 vmtoolsd 进程
taskkill /f /im vmtoolsd.exe

:: 然后重新启动服务
net start VMTools

执行后服务恢复正常：

SERVICE_NAME: VMTools
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0

问题三：复制粘贴仍然不工作

现象

VMTools 服务正常运行后，宿主机和虚拟机之间的复制粘贴仍然不可用。

排查过程

第一步：检查用户态进程

复制粘贴功能依赖两个 vmtoolsd.exe 进程：

• 系统服务进程（Session 0）：负责基础的 Guest-Host 通信
• 用户态进程 vmtoolsd.exe -n vmusr（桌面会话）：负责加载 dndcp.dll 插件处理剪贴板同步和拖拽

检查发现只有系统服务进程在运行，用户态进程缺失。

确认插件文件存在：

1

dir "C:\Program Files\VMware\VMware Tools\plugins\vmusr"

dndcp.dll（拖拽和复制粘贴插件）文件完好。

注册表中 VMware User Process 启动项也存在，但重启后用户态进程就是没有自动拉起。

第二步：尝试手动启动用户态进程

由于 SSH 会话处于 Session 0（服务会话），直接 start 无法在 Session 1 的桌面上创建进程。通过创建批处理文件 + 计划任务的方式在用户桌面会话中启动：

1
2
3

echo start "" "C:/PROGRA~1/VMware/VMware Tools/vmtoolsd.exe" -n vmusr > C:/vmusr.bat
schtasks /create /tn "StartVMusr" /tr "C:/vmusr.bat" /sc once /st 00:00 /f /rl highest
schtasks /run /tn "StartVMusr"

启动后确认两个进程都在运行：

• PID 1384 — Services 会话（系统服务）
• PID 2772 — Console Session 1，ADMIN 用户（用户态）

但复制粘贴仍然不工作，而且重启虚拟机后用户态进程又消失了。说明手动拉起只是临时方案，根本原因在别处。

第三步：检查 VMX 配置

检查虚拟机的 .vmx 配置文件（D:\Windows 7\Windows 7.vmx），发现只有：

isolation.tools.hgfs.disable = "FALSE"

缺少 copy/paste 相关的配置项。在 VMware Workstation 17 上，如果没有显式启用，默认可能是禁用的。

通过 rpctool 在 Guest 内确认 isolation 状态均为 UNSET，说明 VMX 层面没有显式配置。

根因

两个原因叠加：

1. VMX 配置文件中缺少 isolation.tools.copy.disable = "FALSE" 和 isolation.tools.paste.disable = "FALSE" 的显式配置，在 Workstation 17 上默认行为可能是禁用
2. 由于 isolation 配置缺失，用户态 vmtoolsd -n vmusr 进程无法正常自动启动（负责剪贴板同步的进程缺失）

也就是说，用户态进程不自动启动的根本原因就是 VMX 里缺少 isolation 配置。加上配置后，重启虚拟机用户态进程就能正常自动拉起了。

解决方法

关闭虚拟机，在 .vmx 文件中添加以下三行：

isolation.tools.copy.disable = "FALSE"
isolation.tools.paste.disable = "FALSE"
isolation.tools.dnd.disable = "FALSE"

然后重新启动虚拟机。启动后验证：

• VMTools 服务正常运行（RUNNING）
• 用户态 vmtoolsd -n vmusr（Console Session 1）自动启动——之前一直无法自启的问题也一并解决
• 复制粘贴功能恢复正常

总结

本文2026-04-16首发于猫猫鱼的小窝，最后修改于2026-04-16