Clash 三种模式区别

先理解 TUN：让终端流量进入规则链

Clash TUN 模式适合处理不读取系统代理设置的命令行程序，但它不是“自动修复所有终端网络”的开关。启用后，客户端通过虚拟网络接口和系统路由接管符合条件的 IP 流量，再交给 mihomo 等内核按当前模式、规则和策略组处理。Git、npm、pip 等工具通常可以因此走规则分流，而不必分别设置代理环境变量。

这条链路要分成两步看：先确认请求确实进入 Clash，再确认规则把请求交给了预期策略。终端命令返回超时，可能是 TUN 没有接管、系统权限不足、DNS 解析异常、规则命中直连，也可能是节点或目标服务器不可达。只看到客户端显示“TUN 已开启”，不能证明每个连接都已被正确接管。

启用前检查客户端、权限与端口

先记录客户端名称、版本、内核版本、操作系统版本，以及当前系统代理和 TUN 的状态。Clash Verge、Clash Verge Rev、Mihomo Party 等客户端的页面布局与权限机制会随版本变化，因此不要把某一版本的菜单路径照搬到另一客户端。优先在设置中查找“TUN”“虚拟网卡”“服务模式”或相近选项，并阅读客户端对平台权限的提示。

Windows：确认服务或管理员权限

在 Windows 上，TUN 通常需要创建虚拟网卡、调整路由或由客户端服务协助完成。若界面提示安装服务、授权驱动或以管理员身份运行，应使用客户端提供的正规入口完成授权；不要从不明来源单独下载驱动。启用后检查客户端日志中的接口创建、路由设置和权限错误。若 TUN 开关立即回弹，先处理服务未运行、权限被拒绝或虚拟网卡创建失败，不要反复切换规则配置。

macOS 与 Linux：按系统提示授权

macOS 可能要求批准网络扩展或 VPN 配置，并在系统设置中确认允许。不同 macOS 版本的隐私与网络扩展页面名称有所差异，按客户端提示检查授权状态；系统升级后也要留意原有授权是否仍有效。Linux 则需确认当前客户端使用的 TUN 实现具备创建接口和设置路由的权限，容器化运行时还可能需要额外的网络能力。不要通过长期以 root 身份运行整个桌面会话来绕过权限问题。

启用前也要排查其他 VPN、虚拟机、容器网络和安全软件是否占用路由或过滤流量。一次只调整一个因素，并记录原始状态；如果启用 TUN 后局域网、公司内网或 Docker 网络异常，先关闭 TUN 做对照，再检查排除网段和路由，而不是同时修改 DNS、规则和网卡设置。

按顺序配置 TUN 与开发规则

建议先保持现有订阅、规则和节点不变，只启用 TUN。进入客户端设置页，启用 TUN 或虚拟网卡选项，按系统要求完成服务安装和授权，然后确认运行日志没有持续出现接口创建失败、路由设置失败或权限拒绝。若客户端提供“自动路由”“严格路由”或“绕过网段”等选项，先保留默认值；只有出现明确的路由冲突或内网访问问题时，再根据日志与网络环境调整。

随后确认内核使用规则模式，并检查开发相关域名最终会落到哪个策略。Git 托管站点、软件包仓库和镜像服务可能使用多个域名或 CDN，不能假定只给一个主域名添加规则就覆盖所有下载请求。通过客户端连接记录查看实际访问的域名、命中规则、策略组和最终节点；规则顺序也很重要，宽泛的 MATCH 应放在兜底位置，不能挡住前面的专用规则。

# 配置示意：策略名称必须已经存在于当前配置中
mode: rule
tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
rules:
  - DOMAIN-SUFFIX,code.example,开发代理
  - DOMAIN-SUFFIX,packages.example,开发代理
  - MATCH,默认策略

上面的域名和策略名只是说明格式的占位示例，不是可直接用于真实服务的规则清单。mihomo 配置字段是否可用、默认值和平台行为取决于当前内核版本与客户端封装；应以客户端生成的有效配置和对应版本文档为准。若客户端接管 TUN 选项，不要再把示意配置整段重复粘贴到订阅覆写中，以免出现字段冲突。

避免 TUN 与环境变量互相干扰

启用 TUN 后，命令行通常无需设置代理变量。若 shell 启动文件中已有 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，应用可能先通过显式代理连接，再由 TUN 接管到本地代理端口，形成重复代理或回环。排查时先查看变量而不是盲目删除：

# macOS / Linux：查看当前 shell 的代理变量
env | grep -i proxy

# PowerShell：查看当前会话的代理变量
Get-ChildItem Env:*proxy*

如果变量指向已经关闭的端口，例如 127.0.0.1:7890，显式代理会先失败，TUN 未必有机会补救。确认代理变量是否由当前终端、开发容器或组织策略设置；移除后重新打开终端再测试。对需要隔离的项目，可以只在当前 shell 会话中临时设置或清除变量，避免改动全局配置。

分层验证 Git、npm 与 pip

验证时先选一个可以稳定访问的仓库或包源，并记录测试时间、当前模式和选中的策略。先确认客户端连接面板能看到目标连接，再分别运行命令行测试。不要同时升级工具、切换节点、改 DNS 和编辑规则；每轮只改变一个条件，才能判断结果是由 TUN、出口策略还是应用自身代理设置造成。

Git：区分代理配置与 TUN 接管

先查看 Git 是否保存了显式代理设置。若 TUN 已正常接管，旧的 Git 代理配置可能指向失效端口或另一条出口。下面的命令只读取配置，不会改动：

git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'
git ls-remote https://code.example/team/project.git HEAD

将示例地址替换为有权限访问的仓库。若 ls-remote 能返回提交哈希，说明这次 Git 请求完成了远端通信，但不能单独证明所有 Git 域名和传输方式都正常。若日志看不到对应连接，检查 TUN 接管和目标是否被绕过；若能看到连接但命中直连，检查规则及策略组；若命中代理仍超时，测试另一个节点并查看 DNS 与节点日志。

npm 与 pip：观察包源、证书和超时

npm 可能使用配置文件中的 registry，也可能受项目级、用户级或环境变量影响。可先查看当前 registry 和代理配置，再执行不会安装依赖的元数据查询：

npm config get registry
npm config get proxy
npm config get https-proxy
npm view example-package version

若 npm 的 proxy 或 https-proxy 指向错误地址，TUN 不一定能覆盖这项应用级配置。先确认是否有意保留显式代理，再进行单变量对照。只有出现证书错误时才检查证书链与系统时间；不要把关闭 TLS 校验当作网络修复办法。

pip 的网络请求也可使用环境变量或配置文件中的代理设置。测试时选择实际使用的 Python 环境，避免把系统 Python 与虚拟环境混淆：

python -m pip --version
python -m pip index versions example-package

不同 pip 版本及包源对 index 子命令的支持可能不同；若命令不可用，可使用团队认可的包名执行一次只检查版本或依赖解析的查询。确认访问的是预期索引地址，私有仓库可能要求认证，不应将令牌粘贴进公开日志或截图。若浏览器能访问而 pip 失败，进一步核对命令使用的解释器、索引地址、代理变量和认证配置，而不是直接认定 TUN 失效。

Docker 镜像拉取：检查守护进程的网络路径

docker pull 的网络请求通常由 Docker daemon 或 Docker Desktop 的后台组件发起，不一定由当前终端进程直接发起。所以，终端已经进入 TUN 并不代表 Docker 的下载请求必然沿同一条路径。Linux 上的 Docker Engine 通常由后台服务负责拉取镜像；Docker Desktop 则通过其虚拟化网络转发请求。还要考虑容器内网络、宿主机网络和守护进程代理是不同层次。

先查看当前 Docker 上下文，再运行一个小型、可访问的镜像拉取测试，并同时观察客户端连接记录：

docker context show
docker info
docker pull hello-world

如果请求没有出现在 Clash 连接记录中，检查 Docker daemon 或 Docker Desktop 的网络模式、系统代理设置和 TUN 路由；如果出现连接但命中直连，检查镜像仓库域名规则；如果代理策略已命中但失败，查看仓库认证、镜像限流、DNS 和出口连通性。镜像拉取可能先访问认证服务，再连接镜像仓库和 CDN，因此需要观察失败阶段涉及的域名，不能只针对一个仓库主机名添加规则。

Docker daemon 的代理设置应按所用操作系统和 Docker 版本的管理方式配置。Linux 服务级代理与当前 shell 的 HTTP_PROXY 不是一回事；Docker Desktop 也有自身的网络与代理设置。修改服务配置后通常需要按平台要求重启服务，且应避免把认证令牌写入不受保护的共享配置。容器启动后的应用是否走代理，还取决于容器内环境变量、网络和镜像本身，与拉取镜像的过程不能混为一谈。

按现象排查并安全回退

如果所有终端命令都失败而浏览器正常，先看客户端连接记录是否出现命令对应的域名，再判断是否存在旧的代理环境变量、Git 配置或包管理器配置。若只有某个工具失败，优先检查该工具的配置与请求目标；若终端、浏览器和 Docker 同时异常，则更应检查 TUN 权限、路由、DNS 或当前节点。相同域名在不同程序中可能经由不同代理路径，不要只凭一个成功案例推断全局正常。

1. 确认接管入口：检查 TUN 状态、系统服务或网络扩展授权，并在连接面板观察测试时是否产生新连接。
2. 确认规则与策略：记录目标域名、命中规则、策略组和实际出口；检查是否有靠前的宽泛规则。
3. 检查名称解析：比较客户端 DNS 记录与系统解析结果，留意企业内网域名、Split DNS 和本地 DNS 劫持。
4. 排除显式代理冲突：查看环境变量、Git 配置及 npm、pip 配置，确认是否仍指向旧端口。
5. 单独验证节点与目标：保持规则不变，只更换一个节点或测试一个已知可用的目标，避免一次改动多个变量。

如果启用 TUN 后无法访问内网或网络整体中断，使用客户端提供的关闭 TUN或恢复路由入口，确认系统网络恢复后再检查日志。不要在不清楚作用范围时执行批量删除路由、重置所有网络接口或关闭防火墙的命令。向他人提交日志前，遮盖订阅地址、节点凭据、访问令牌、用户名和内网域名；保留错误时间、错误类型、目标端口及策略命中信息即可。

常见问题

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

通常不需要为了让普通终端流量进入代理而额外设置。若某个工具必须使用显式代理、开发环境有专用出口，或 TUN 无法接管该运行环境，可按工具或项目要求配置代理变量。配置前确认变量指向正在运行的本地监听端口，并注意多个代理变量可能造成重复代理或回环。

浏览器可以访问，Git 克隆仍失败，应该先看哪里？

先查看客户端连接面板有没有对应的 Git 域名，再检查 git config 中是否保留了旧代理。没有连接记录时，排查 TUN 路由和接管范围；有连接但策略不对时，核对规则和策略组；已经命中代理但失败时，再看节点、仓库权限、DNS 和目标服务状态。

为什么 TUN 正常，Docker pull 还是超时？

拉取镜像的请求可能由后台 daemon 或 Docker Desktop 虚拟网络发出，不一定经过当前终端的应用代理路径。检查 Docker 上下文、守护进程代理和客户端连接记录，并观察认证服务、镜像仓库及 CDN 等多个请求阶段。容器运行后的网络问题则要另行排查。

TUN 是否会自动把所有流量都代理到节点？

不会。TUN 负责接管符合条件的网络流量，分流结果仍由当前运行模式、规则、策略组和节点选择决定。绕过列表、系统路由、权限、DNS 及具体平台实现也会影响接管范围。要确认实际行为，应结合连接记录和规则命中结果验证。