Git、npm、pip 和 Docker 在终端里报连接超时，不一定是节点本身不可用。常见原因是命令行程序没有读取系统代理设置，而 Clash 的系统代理通常只影响遵循操作系统代理配置的应用。mihomo 内核的 TUN 模式则通过虚拟网络接口接管更多系统流量，使终端程序即使不支持 HTTP 代理，也有机会按 Clash 规则转发。

不过，TUN 不是“打开后所有连接必定走代理”的开关：流量仍会根据规则选择代理、直连或拒绝；容器、虚拟机和后台服务也可能有独立的网络路径。建议先确认客户端和内核正常，再逐层验证 TUN、域名规则与具体开发工具。

终端为什么不一定跟随系统代理

系统代理一般通过操作系统提供的 HTTP、HTTPS 或 SOCKS 代理设置生效，但命令行工具是否使用它，取决于工具自身。浏览器可能已经走代理，Git 却仍尝试直连；npm 能访问注册表，也不代表 Docker 后台服务使用同一条路径。把代理端口填进某个工具的配置，能够解决该工具的问题，但逐个配置容易遗漏子进程、构建脚本和其他尚未设置的工具。

TUN 模式在系统网络层建立虚拟接口，并由内核接收、识别和路由流量。它适用于没有代理选项或没有读取系统代理环境变量的程序。连接被接管后，最终走向仍由 Clash 规则和策略组决定：匹配到 DIRECT 就直连，匹配到代理策略组才会使用所选节点。TUN 不会自动修复节点故障、DNS 上游错误或目标站点限流。

方式适合场景主要边界
系统代理浏览器及会遵循系统设置的桌面应用部分 CLI、后台服务和容器不读取系统代理
工具代理变量或专属设置只需配置 Git、npm 等少数工具需逐个维护，环境变量可能未传给服务进程
TUN 模式需要接管更多系统网络流量的桌面环境依赖权限、路由和 DNS；虚拟机或容器需单独验证

通常先用系统代理或单个工具代理做小范围验证，再启用 TUN 处理需要统一接管的流量。TUN 开启后仍可以保留工具级代理，但两层代理可能造成重复转发、环路或难以判断实际出口；排查时先清除不必要的工具代理设置。

启用 TUN：按平台检查权限与接管状态

桌面客户端的菜单名称会随版本变化，常见入口是「设置」→「网络」或「TUN 模式」。启用前确认当前配置使用支持 TUN 的 mihomo 内核，并检查客户端是否提示安装服务、授予网络权限或以管理员权限重启。仅在配置文件里出现 tun: 字段，不代表虚拟接口已经成功创建；应同时查看客户端状态和运行日志。

  • Windows：在 Clash Verge Rev 等客户端中打开 TUN 开关，按提示批准 UAC 权限或安装服务。若开关无法保持开启，查看服务状态、安全软件拦截和日志中的权限错误。测试结束后确认关闭 TUN 能恢复原有网络。
  • macOS：按客户端提示授权网络扩展或 VPN 配置。首次批准后，系统设置中可能还需要确认相应的网络扩展权限。Apple Silicon 与 Intel 的客户端构建不同，不能仅凭客户端名称推断内核或权限状态。
  • Linux：TUN 通常需要访问 /dev/net/tun 以及设置路由的权限。使用图形客户端时查看其服务提示；直接运行 mihomo 时，要确认运行用户拥有所需权限，并检查发行版的防火墙、策略路由和 DNS 管理器是否冲突。

不同系统及客户端可能使用各自的服务安装方式，具体按钮位置以当前版本界面为准。启用后先确认状态显示已运行，再测试终端请求；如果客户端显示 TUN 已开但没有连接记录，可能是流量未进入接口、目标使用了其他网络命名空间，或该请求被系统代理以外的机制处理。

对直接维护 mihomo 配置的用户，下面是可参考的局部配置，不是完整配置文件。先核对当前内核版本支持的字段，并与客户端配置合并，避免重复出现顶层 tun:。日志和实际路由比仅复制示例更重要。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - "any:53"

rules:
  - DOMAIN-SUFFIX,github.com,开发代理
  - DOMAIN-SUFFIX,registry.npmjs.org,开发代理
  - DOMAIN-SUFFIX,pypi.org,开发代理
  - DOMAIN-SUFFIX,registry-1.docker.io,开发代理
  - MATCH,开发代理

示例中的 开发代理 必须替换成配置里真实存在的策略组名称；规则按从上到下顺序匹配，兜底规则放在最后。Docker 镜像拉取可能涉及多个注册表、认证服务和镜像 CDN 域名，仅添加一条注册表域名规则不保证所有部署都覆盖。实际使用时要从内核连接记录中核对被请求的域名，再按需要补充规则。dns-hijack 仅处理符合配置的 DNS 流量，不等于所有应用都已使用代理 DNS，也不应把这段片段当作防泄漏保证。

为 Git、npm、pip 与 Docker 验证分流

先切换到规则模式，确认代理策略组已选中可用节点。按工具逐个发起短请求，并在客户端的连接或日志页面查找对应域名、命中规则和出站策略。若请求没有出现在连接记录里，先检查 TUN 是否真正接管终端流量；若记录显示直连，则检查规则顺序和域名是否匹配；若显示代理但失败，再检查节点、DNS 和远端服务。

  • Git：用 git ls-remote 测试一个自己有权访问的仓库。Git 的 HTTP、HTTPS 与 SSH 连接路径不同；为 HTTPS 设置的代理不一定影响 SSH。若使用 SSH，需单独检查目标地址、端口和路由，不要看到 Git 超时就立即认定 TUN 失效。
  • npm：可执行 npm ping --registry=https://registry.npmjs.org/ 验证注册表访问。安装依赖时还可能访问包元数据、压缩包 CDN 或自定义 registry；检查日志中的实际主机名，不要假设所有包都只从一个域名下载。
  • pip：可执行 python -m pip index versions 包名 测试索引访问，也可检查当前索引配置。企业或项目可能使用私有 PyPI 镜像；应按实际索引域名配置分流，并确认镜像的证书和访问权限。
  • Docker：先测试 docker pull 指定的镜像，再检查 Docker daemon 日志和 Clash 连接记录。Docker CLI 负责向后台服务提交请求，真正联网下载镜像的通常是 daemon；Docker Desktop 还可能经过虚拟机网络，因此不能只看当前终端的环境变量就判断后台流量已接管。

开发站点的域名与服务端点可能随地区、镜像配置和认证流程变化。以连接日志为准逐步补规则，不建议把整个开发域名空间都无差别地放进代理组。需要保留直连的内部 Git、公司镜像或局域网服务，可以为已确认的域名添加更靠前的直连规则；同时检查规则是否被更早的宽泛规则抢先匹配。

TUN 之外的补充方案：临时代理环境变量

如果不需要全局接管，或者当前环境无法创建 TUN，可以临时为终端设置代理变量。以下示例假设客户端在本机监听 HTTP 代理 127.0.0.1:7890；端口应以客户端界面实际显示为准。端口未启动、只监听其他地址，或代理类型不匹配时，变量设置正确也会连接失败。

# macOS / Linux：仅对当前终端会话生效
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7891
export NO_PROXY=localhost,127.0.0.1,::1,.internal

# 清除当前会话的代理变量
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

7891 只是常见示例，并不保证你的客户端启用了 SOCKS 端口；如果没有对应监听，请删除 ALL_PROXY 或改成实际端口。socks5h 通常表示域名解析也交给 SOCKS 代理处理；使用 HTTP 代理时按工具支持设置变量。部分程序只读取小写变量名，遇到差异时可按该工具文档同时设置对应的小写名称。

Windows PowerShell 可在当前会话中设置变量，例如 $env:HTTPS_PROXY="http://127.0.0.1:7890"；关闭该终端后设置通常不再保留。若工具通过服务、IDE 或容器后台运行，当前交互终端的变量未必会传递给它。NO_PROXY 用于声明不走代理的主机或网段，内容应尽量精确；过宽的排除项可能让本来需要代理的请求意外直连。

环境变量与 TUN 可以作为不同接管层使用，但不建议未经验证就同时配置。若打开 TUN 后连接记录显示相同流量又经过本地代理端口，先清除工具代理变量，再重新测试。工具级配置需要长期保留时，记录修改位置和恢复命令，避免在公共机器或共享 shell 配置中留下敏感代理地址。

TUN 与终端连接故障排查

出现超时、解析失败或连接重置时，先保持节点、网络和测试地址不变，每次只修改一个因素。以下顺序能区分“流量未接管”“规则走错”“域名解析异常”和“代理出口不可用”，避免一开始就同时改 DNS、MTU 与规则。

  1. 确认接管状态：在客户端检查 TUN 是否运行，查看日志是否有权限、创建接口或路由失败。关闭并重新打开 TUN 后，用同一条命令重试。
  2. 确认请求实际经过哪里：打开连接记录，查看目标域名、命中的规则与策略组。没有记录时，检查虚拟机、容器、SSH 会话或后台服务是否使用了另一套网络环境。
  3. 检查域名解析：确认域名能解析，并查看当前配置中 DNS 上游、DNS 劫持和规则解析行为。不要仅凭某个 DNS 测试页面判断开发工具的连接一定走了同一条解析路径。
  4. 分开验证节点和目标服务：使用浏览器或另一个已知可用的网络请求测试节点出口；若只有某一个注册表或仓库失败，核对该服务状态、认证信息、证书和限流提示。
  5. 检查网络冲突：退出其他 VPN 或代理工具，检查虚拟机网卡、容器网络、局域网路由和系统防火墙。确认问题后再逐一恢复需要的工具。
症状优先检查判断依据
浏览器可用，终端超时TUN 状态、终端是否被接管、代理变量连接记录中是否出现终端目标域名
有连接记录但策略为直连规则顺序、目标域名与策略组日志显示的规则和出站结果
域名解析失败或间歇失败DNS 上游、劫持设置、其他 VPN 的 DNS同一域名在配置调整前后的解析结果
Docker 失败而宿主机请求正常Docker daemon、Desktop 虚拟机与后台代理设置daemon 日志及实际镜像请求的连接记录
所有目标同时失效节点状态、默认路由、权限与端口监听客户端日志和一个简单 HTTPS 请求

MTU 通常不是终端代理超时的第一排查项。只有出现特定网络下大响应卡住、TLS 握手异常或分片相关迹象，并且更换接入网络后表现不同，才值得对照测试 MTU；修改前保存原值，并在同一节点、同一目标下复测。不要为了一个仓库偶发失败就全局改路由表、关闭防火墙或开放 DNS 监听。

常见问题

开启 TUN 后，终端流量是不是一定走代理？

不一定。TUN 扩大的是流量接管范围，具体出站仍由规则决定，可能是代理、直连或拒绝。检查连接记录中的规则与策略组；如果目标没有进入记录，继续检查进程所处的容器、虚拟机或后台服务网络。

已经开启 TUN，还需要设置 HTTP_PROXY 吗？

一般先不要重复配置。TUN 的目标之一就是接管不读取代理变量的流量。只有需要限定某个工具使用不同代理，或 TUN 暂时不可用时，才考虑工具级代理；设置后如出现回环或重复转发，应先清除变量再比较。

Git 能用，但 npm、pip 或 Docker 仍然超时，原因是什么？

这些工具可能访问不同注册表、镜像、认证服务或 CDN，Docker 还常由后台 daemon 发起下载。分别检查失败请求对应的主机名、日志中的出站策略、工具索引配置和服务端认证，不要假设一个域名规则覆盖全部依赖下载。

关闭 TUN 后仍然无法联网，应该怎么恢复？

先确认客户端已停止虚拟接口或服务，再检查系统代理是否仍开启、其他 VPN 是否接管路由，以及系统 DNS 和网络连接是否恢复。按客户端提供的停止或重置方式操作，不要直接删除系统路由；若原网络仍异常，重启客户端或系统后再逐项核对。