为什么浏览器正常，终端命令仍然失败

浏览器可以打开网页，并不能证明 Git、npm、Docker 等命令行程序也经过了 Clash。浏览器通常会读取操作系统代理，或由代理扩展单独设置；终端程序则可能使用自己的代理配置、环境变量，或者直接建立网络连接。系统代理主要面向遵循系统代理设置的应用，不会自动接管所有进程的网络流量。

TUN 模式通过创建虚拟网络接口接收系统流量，再由 mihomo 按配置中的规则处理。它可以覆盖许多不读取 HTTP 代理设置的终端程序，但“接管流量”不等于“所有连接都走代理”：在规则模式下，连接仍由规则决定走代理组、直连还是拒绝；只有选择全局代理模式时，匹配到的流量才会统一使用代理策略。局域网地址、系统服务和客户端排除列表也可能继续直连。

  • 网页可用，Git 超时：Git 可能没有读取系统代理，或仓库域名被规则分到直连。
  • npm 下载失败：检查注册表地址、DNS 解析和规则命中情况；浏览器缓存或登录状态不能代表 npm 请求路径。
  • Docker 拉取失败：Docker CLI 会把请求交给 Docker Engine，实际网络连接可能由后台守护进程或 Docker Desktop 虚拟机发起，不能一概当成当前终端进程。
  • 开启 TUN 后网络异常：优先检查虚拟网卡、路由、DNS、权限和其他 VPN，不要先删除订阅或重写整份配置。

开启前先核对内核、端口与系统权限

操作前记录客户端名称、内核版本、活动配置、当前模式、混合代理端口和已有 VPN 状态。Clash Verge、Clash Verge Rev 等图形客户端的菜单名称和内核能力会随版本变化；文章中的字段适用于支持相应 mihomo 配置的版本，不能据此认定所有标注为 Clash 的旧内核都支持相同选项。

  1. 打开客户端的「关于」「内核」或运行信息页面，确认当前运行的是 mihomo，并记下版本号。不要只凭客户端名称判断内核。
  2. 备份当前配置或导出一份副本，确认当前配置能正常加载，并记录 TUN 开启前的网络状态。
  3. 在客户端设置中查找「TUN」「虚拟网卡」或「服务模式」。按提示授予管理员权限；部分平台需要安装或启动服务，普通用户权限不足时可能创建接口失败。
  4. 确认系统没有同时运行另一款 VPN、虚拟网卡代理或会修改默认路由的网络工具。排查期间一次只运行一个流量接管工具。
  5. 先使用规则模式测试，不要同时切换全局模式、DNS 覆写和大量自定义路由。保留一个可回退的正常配置。

如果客户端允许在界面中启用 TUN，优先用界面开关；客户端可能会生成或覆写内核字段。以下片段仅展示 mihomo 配置结构，应合并到现有配置的顶层，而不是替换订阅。一个配置文件只能有一个顶层 tun:，实际支持字段应以运行内核版本和客户端说明为准。

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53

auto-route 用于让系统路由把符合条件的流量导入 TUN；strict-route 在支持的平台上用于减少流量绕过 TUN 的情况。DNS 劫持字段用于接收匹配的 DNS 请求，不代表所有应用的加密 DNS 都会自动交给 mihomo。若配置加载时报未知字段或接口创建失败，应先核对内核版本、客户端覆写和系统权限，再决定是否调整字段。不要复制网上一整份配置覆盖订阅，避免丢失节点、规则和代理组。

启用 TUN 后，先确认规则确实命中

在客户端的「设置」中开启 TUN，按系统提示授权或启动服务，再确认客户端显示运行中。随后打开 mihomo 的「连接」或「日志」页面。仅看到虚拟网卡已创建，不能证明终端流量已成功转发；需要发起实际请求，并观察是否出现对应连接记录、目标域名和所选策略。

用一条命令逐层验证

  1. 先测试普通网络：关闭 TUN 后确认当前网络本身可用。若基础网络已断开，先处理 Wi-Fi、网关、企业认证或 DNS。
  2. 启用 TUN 后测试 HTTPS：Windows 使用 curl.exe，macOS 和 Linux 通常使用 curl。测试时设定短超时，避免命令长时间挂起。
  3. 观察 mihomo 连接记录：如果请求完全没有进入记录，检查 TUN 是否启用、权限是否足够、目标进程是否被排除，以及是否存在另一条默认路由。
  4. 检查策略结果：有记录但策略显示 DIRECT 时，查看规则顺序和目标域名；出现代理组名称时，确认该组已选择可用节点。
  5. 按同一目标复测：调整一项规则或 DNS 设置后，再运行相同命令。不要同时换节点、换 DNS 和改路由，否则结果无法定位。
curl -v --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null

在 Windows PowerShell 中请使用 curl.exe，避免命令别名造成参数行为不同；输出目标可改为 NUL。这里的 example.com 只是连通性示例。若请求超时，先结合日志判断是 DNS 查询无响应、代理节点连接超时，还是目标服务拒绝；仅凭 curl 的最终错误文字，不足以确定故障层级。

终端测试建议覆盖三类请求：访问已知可直连的站点、访问需要代理的目标，以及访问公司或家庭局域网服务。第一类验证基础路由，第二类验证代理策略，第三类确认本地地址没有被错误送往远端。若业务域名需要代理，应让规则明确命中对应代理组；不要为了一个域名直接把所有连接改为全局代理。

现象优先检查判断方法
没有连接记录TUN 服务、权限、路由和进程排除项用新的 curl 请求并同时观察连接页
记录显示直连但目标不可达规则顺序、域名规则与代理模式查看命中的规则及策略结果
记录显示代理但连接超时节点状态、代理组选择和出口可达性先用客户端的节点测试及日志对照
域名失败，IP 请求表现不同DNS 接管、上游 DNS 与缓存分别检查解析结果和连接日志
只有 Docker 拉取失败Docker Engine、Desktop 网络与镜像仓库区分主机终端请求和守护进程请求

Git、npm 与 Docker 的逐项排查

Git：先看请求是否经过 TUN，再核对 Git 自身代理

运行 git remote -v 确认仓库地址使用 HTTPS 还是 SSH。HTTPS 请求通常能通过系统路由进入 TUN；SSH 使用独立端口和协议，可能被规则、网络防火墙或节点策略单独处理。先在客户端连接记录中搜索仓库域名，再检查实际错误是 DNS 失败、连接超时还是认证失败。认证失败通常不是 TUN 路由问题。

如果曾为 Git 单独设置代理，可用 git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy|core\.sshCommand' 检查来源与值。不要把含用户名、密码或令牌的输出贴到公开工单。只有在明确需要 Git 显式使用本地 HTTP 代理时，才配置相应代理地址；端口必须以客户端显示的混合端口为准，例如示例端口 7890，不可默认认为每台设备都相同。已经依赖 TUN 时，先移除过期的 Git 代理配置再测试，避免请求指向未运行的旧端口。

npm：检查注册表、环境变量和配置来源

先查看 npm config get registry 与 npm config get proxy，再查看 npm config get https-proxy。若注册表域名不能解析，排查 DNS 与规则；若能连接但返回认证或权限错误，应检查注册表登录状态和包权限。不要把 npm config list 的完整输出直接公开，其中可能包含私有注册表地址或凭据。

npm 通常可以使用 HTTP 代理配置，也可能继承进程环境变量；具体取决于 npm 版本、配置文件和运行环境。使用 TUN 时不必为了让 npm“识别代理”而机械地设置多个环境变量。若设置了 HTTP_PROXY、HTTPS_PROXY 或 npm 的专用代理项，先确认它们指向正在监听的代理端口；测试时可暂时清除旧变量，再比较 TUN 连接记录。代理变量通常按进程启动时的环境读取，新开终端后再复测更可靠。

Docker：区分 CLI、守护进程与容器网络

docker pull 虽然从终端输入，但镜像下载一般由 Docker Engine 发起。Linux 上，Docker Engine 常作为独立服务运行；Docker Desktop 也可能通过自己的虚拟机或网络层访问外部。因此，主机 TUN 日志里没有明显的 CLI 请求，不代表 Docker Engine 一定使用了主机终端的代理环境变量。

先用普通 curl 测试目标网络，再执行一次 Docker 拉取并查看 Engine 或 Desktop 日志。确认故障发生在主机、守护进程还是容器内部后，再按 Docker 对应平台的配置方式处理代理；不要把容器中的 HTTP_PROXY 当作 Docker Engine 的代理设置。若只有容器内的程序失败，还要分别检查容器 DNS、网络模式、镜像仓库策略和容器自身环境变量。Docker 网络通常涉及虚拟接口和转发规则，调整 TUN 路由前应保留原设置并逐项复测。

处理冲突与常见问题

当浏览器、终端和容器表现不一致时，先按“请求从哪里发出—是否进入 TUN—命中哪条规则—使用什么出站”的顺序排查。TUN 故障往往不是订阅本身损坏；反复更新订阅、重装客户端或同时开启多个代理工具，会增加变量而不一定提供有效线索。

  • 端口占用：TUN 与本地 HTTP 代理监听端口是不同功能。检查客户端实际端口和日志，不要把控制 API 端口误当作代理端口，也不要为了开启 TUN 随意修改混合端口。
  • 路由冲突：企业 VPN、虚拟机、容器网络和其他代理工具可能修改默认路由。先逐个退出非必要工具复测；需要并行使用时，再依据平台支持配置路由排除或网段策略。
  • DNS 异常：域名解析失败而 IP 连接正常时，检查 DNS 劫持、上游可达性和应用内置加密 DNS。修改后清理相关缓存或重启测试进程，避免把旧解析结果当成新配置效果。
  • 网络恢复失败：关闭 TUN 后若网络仍异常，检查客户端是否正常停止服务、系统代理是否恢复，以及默认路由和 DNS 是否仍被修改。必要时先断开其他 VPN，再重启网络连接。

常见问题

开启 TUN 后，还需要打开系统代理吗？
通常不需要把两种方式同时作为必需条件。TUN 负责虚拟网卡流量接管，系统代理负责让遵循系统设置的应用使用代理。先单独测试 TUN；如果客户端或特定应用有明确要求，再按实际情况启用系统代理。

TUN 开启了，为什么 Git 仍显示连接超时？
先看 mihomo 连接记录。如果没有记录，检查接口、权限、进程排除和路由；如果有记录，检查规则命中、策略组、节点和 Git 使用的协议。SSH、HTTPS 与不同仓库域名可能走不同规则。

Docker 拉取失败，可以只给终端设置代理变量吗？
不一定。命令行通常将请求交给 Docker Engine，代理设置要按 Docker Engine 或 Docker Desktop 所在环境配置。先区分主机 curl、Docker 拉取和容器内请求，再决定应修改哪一层。

全局模式能解决所有命令行问题吗？
不能。全局模式改变的是 mihomo 对已接管连接的策略选择，不会修复无权限创建 TUN、DNS 不可达、Docker Engine 独立网络或服务端认证失败。定位完成后，优先用规则模式控制需要代理的目标，并为局域网和本地服务保留合理路由。