在终端里执行 git clone 时连接长时间没有响应，运行 npm install 又反复出现超时，未必是代码仓库或包管理器出了问题。常见原因是浏览器已经通过 Clash 代理联网，但启动命令的 shell、IDE 集成终端或后台任务并没有继承系统代理设置。对于这类不一定遵循 HTTP 代理环境变量的进程，Clash TUN 模式可以从网络路由层接管流量，让终端应用也进入 Clash 的规则与策略体系。
本文以 Clash Verge Rev 与 Mihomo 内核常见设置为例，介绍如何开启 TUN、验证命令行流量是否被接管，并检查 Git、npm、pip 与 Docker 的实际连接。不同客户端版本的菜单名称、权限提示和内核选项可能略有差异，请以你正在使用的版本为准。下文默认你已经导入可用配置，并且知道自己的订阅或配置来源可信；代理使用也应遵守所在地法律法规及工作单位、学校的网络政策。
为什么终端代理会失效：系统代理不等于所有进程都走代理
Clash 的系统代理通常是设置一个本地 HTTP 或 SOCKS 代理端口，再由支持相应代理机制的应用主动连接它。浏览器通常能读取操作系统代理设置，但终端程序的行为取决于具体实现：有的会识别 HTTPS_PROXY，有的只支持配置文件中的代理参数，还有的完全按系统路由直接发起连接。于是，浏览器访问正常，并不能证明 git、Node.js 脚本或构建工具也走了同一条路径。
TUN 模式会创建虚拟网络接口，并通过路由规则接管符合条件的 IP 流量，再交给 Mihomo 按规则分流。它不是把所有程序都改造成 HTTP 代理客户端，而是在更靠近网络层的位置处理出站连接。因此，对忽略代理环境变量的 CLI、运行时或开发工具，TUN 往往比逐个设置代理更省事。需要注意的是，TUN 接管的是网络流量，不会自动修复错误的 Git 凭据、失效的 npm 镜像、服务端限流或程序自身的证书错误。
先区分症状，有助于避免一上来就改复杂配置：
- 浏览器正常、终端超时：优先检查命令是否继承代理变量，或尝试 TUN 接管。
- 终端能连接，但速度慢或偶发断开：检查 Clash 连接记录中的策略组、节点与连接状态，再判断是否为节点负载或目标服务的问题。
- 返回 401、403 或认证失败：更可能涉及凭据、访问权限或服务端策略，不应把所有错误都归因于代理。
- 域名解析失败或访问到了错误地址：除了路由，也要核对 DNS 模式、系统 DNS 和应用是否使用自带解析器。
TUN 与环境变量怎么选：按工具特性决定
如果工具明确支持标准代理变量，显式设置 HTTPS_PROXY 与 HTTP_PROXY 通常更容易控制，也方便只让特定终端会话走代理。Clash Verge Rev 里的本地端口要以当前配置为准：检查客户端的端口设置，确认目标端口是 HTTP 代理端口还是混合端口，再把实际地址写入环境变量。常见示例中的 7890 并非所有安装都相同，不能不经核对直接照抄。
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
# 检查当前 shell 实际加载的代理变量
env | grep -i proxy上面的端口只是示例；如果配置使用不同端口，请替换为客户端显示的值。ALL_PROXY 是否生效取决于应用使用的网络库，socks5h 中的远程 DNS 语义也不是每个程序都支持。变量设置只影响当前 shell 及由它启动的子进程，已有的终端、IDE 或后台服务不会因为修改了 shell 配置文件就自动刷新。对于按需代理、只给一两个工具使用代理的场景，环境变量往往更清晰；对于不读取代理变量、工具种类多或希望统一分流的场景，可以考虑 TUN。
选择 TUN 也不意味着必须放弃规则分流。Clash 仍会依据当前配置决定连接走代理、直连还是其他策略。开发者通常希望公共代码托管与外部包源按规则访问，同时让公司内网 Git、局域网服务、测试环境和本地容器网络保持可达。启用前先检查配置中已有的局域网、私有网段与直连规则；若把所有流量都送入代理策略组，可能反而导致内网服务不可用。
DIRECT，则应检查规则与策略，而不是反复更换终端命令。
动手配置：开启 TUN 并验证终端流量
第一次启用时建议只改动 TUN 相关设置，不要同时更换订阅、DNS 模式和规则集。这样一旦出现异常，回退与定位都更简单。不同系统需要的授权不同：桌面客户端可能请求管理员权限、创建网络扩展或安装虚拟网卡组件；只有在确认客户端来源可信时，才按系统提示授权。
- 更新并检查配置。在 Clash Verge Rev 中刷新当前配置，确认当前模式、代理策略组和节点可用。先记下现有的系统代理状态与端口设置，便于之后对照或恢复。
- 找到 TUN 设置。在设置页面中查找 TUN、虚拟网卡或网络接管选项。部分版本会把相关项目放在内核或服务设置下。确认当前使用的内核支持 TUN，并按界面提示安装或启动所需服务。
- 选择合理的路由选项。初次测试优先沿用客户端推荐的默认设置。若界面提供自动路由、严格路由、DNS 劫持等选项，不要仅凭名称同时启用所有开关；先查阅当前版本说明，弄清其对默认网关、DNS 和局域网访问的影响。
- 启用 TUN 并完成授权。保存设置后开启 TUN。系统弹出权限请求时核对应用名称和操作内容。若界面显示启动失败，先查看客户端日志中的权限、驱动或端口错误，再按对应提示处理，不要通过关闭系统安全功能来绕过报错。
- 确认规则与流量。打开 Clash 的连接面板，在终端执行一次目标访问命令，并按域名或时间查找新连接。确认连接被 Mihomo 捕获，且最终策略符合预期；如果显示直连，先检查规则顺序、域名匹配和策略组选择。
- 测试常用开发工具。分别执行 Git、npm、pip 等小型请求。每次只测试一种工具，并观察连接记录是否新增，避免将缓存命中误认为网络请求成功。
可以先用一个不涉及账号和敏感数据的 HTTPS 请求验证链路。下面以 curl 为例；使用真实、可访问的测试网址，并结合 Clash 面板核对连接，而不要只根据终端是否返回内容下结论。
curl -I --connect-timeout 10 https://github.com
git ls-remote https://github.com/git/git.git HEAD若 curl 能返回 HTTP 响应，且连接面板能看到对应主机和预期代理策略，说明至少这条请求已经进入 Clash。随后用 git ls-remote 检查 Git 的 HTTPS 访问。它只读取远端引用信息，不会克隆整个仓库，适合作为较轻量的验证。若 Git 提示认证失败但连接已正常建立，应继续检查仓库权限、凭据管理器或访问令牌，而不是只调整 TUN。
Git、npm、pip 与 Docker：逐个检查应用层行为
Git：先分清仓库使用 HTTPS 还是 SSH。上面的 git ls-remote 测试的是 HTTPS；如果日常仓库地址以 git@ 开头，则使用 SSH，目标端口、代理支持方式与 HTTPS 不同。TUN 可以尝试接管 SSH 连接，但仍需通过连接记录确认实际路由。公司自建 Git、内网域名或私有 IP 应确认规则允许直连或走企业网络，避免把内网代码仓库错误地送到公共代理节点。若只在某个仓库失败，还要检查远端 URL、SSH key 和仓库权限。
npm：运行 npm config get registry 查看当前 registry。若它指向企业内部镜像或你主动设置的镜像站，TUN 并不会自动替你更改源；它只影响请求的网络路径。可以选择一项实际要安装的依赖执行测试，并查看连接记录中的目标域名。若代理连接已成功但安装仍报包不存在、版本冲突或脚本执行失败，应分别检查 lockfile、registry 内容和项目脚本。不要为了测试随意清空全局缓存或改写团队项目的锁文件。
pip：先检查项目使用的 Python 环境与 pip 配置，确认是否设置了自定义 index URL。虚拟环境、容器和 IDE 可能使用与当前终端不同的解释器或配置文件，因此在一个 shell 里验证成功，并不必然代表另一个开发环境也采用相同设置。测试时可以请求一个已知存在的包版本，并同时观察 Clash 连接面板；如果 pip 没有产生预期请求，检查缓存、私有包源和环境隔离，而不是把无网络请求当成 TUN 故障。
Docker：这是最容易出现「宿主机正常，容器里失败」的场景之一。Docker 容器拥有自己的网络命名空间、DNS 和出站路径，具体流量是否经过宿主机的 TUN，取决于操作系统、Docker 网络模式和客户端路由设置。不要想当然地认为启用 TUN 后每个容器都会自动使用相同规则。先在宿主机测试，再在容器内运行同类请求，并比较连接记录；同时检查容器 DNS、Docker Desktop 的网络实现和镜像构建阶段的代理设置。构建时的代理参数与容器运行后的代理配置也不是一回事。
判断结果时，建议记录三项信息：命令及其退出码、终端输出的错误类别、Clash 连接面板中的目标主机与策略。这样可以把问题拆成「没有流量进入内核」「规则命中不符合预期」「代理链路连接失败」或「网络正常但应用层拒绝」几类。仅凭一个 ETIMEDOUT 很难区分这些原因，而这三项对照通常足以缩小排查范围。
TUN 常见问题：DNS、权限与其他 VPN 冲突
开启后普通网站也打不开：先关闭 TUN，确认是否恢复，再查看 Clash 日志与 DNS 设置。若系统 DNS 请求被接管但上游解析不可用，表现可能是所有域名都失败，而不只是终端工具。逐项检查当前配置的 DNS 上游、DNS 劫持选项和系统网络状态；修改时一次只变更一项，并用相同域名重复测试。若只有个别域名异常，也要检查规则和域名解析结果是否匹配当前网络环境。
TUN 开关打开后立即关闭：常见原因包括授权未完成、虚拟网卡或服务启动失败，以及其他软件已占用网络扩展或路由资源。先查看客户端日志中的具体错误，再核对系统权限状态。不要连续重复点击开关，也不要把重装客户端作为第一步；记录错误时间与提示内容，通常比反复尝试更容易找到原因。
与公司 VPN、虚拟机或其他代理软件冲突：多套工具可能同时修改默认路由、DNS 或流量过滤规则。典型表现是启用 TUN 后公司内网地址无法访问、VPN 连接被切断，或虚拟机网络异常。进行对照测试时，应遵循组织的 IT 要求，避免擅自关闭受管理的安全软件。若确实需要同时使用，先确认哪套软件负责默认路由与 DNS，再依据双方文档配置兼容方式；无法确认时，回退到单一工具的系统代理或环境变量方案通常更安全。
IDE 里的命令和外部终端表现不同：IDE 可能早于代理启动，使用独立环境变量，也可能把任务交给容器或远程开发环境执行。分别在外部终端、IDE 集成终端和实际执行任务的环境里运行 env | grep -i proxy，并观察触发请求后连接面板是否出现新记录。若任务跑在远程 SSH 主机、开发容器或 CI runner 中，本机的 TUN 通常不会直接接管远端机器的网络；需要在流量实际发出的那一端排查。
常见问题
开启 TUN 后还需要设置 HTTPS_PROXY 吗？
不一定。TUN 的目标之一就是接管没有主动使用代理变量的网络连接，因此很多本机终端命令可以在不设置变量时工作。但某些工具会优先读取环境变量，若变量指向错误端口或已关闭的本地代理，反而可能造成连接失败。建议先在一个新终端中检查代理变量，再通过连接面板验证实际路径；不需要时可在当前会话取消变量后重新测试。
TUN 是否等于全局模式？
不等于。TUN 描述的是流量如何进入 Mihomo，最终由哪条策略处理仍取决于客户端模式、规则顺序与策略组选择。启用 TUN 后，连接仍可能命中 DIRECT。如果希望某类域名走代理，应确认规则确实匹配并指向预期策略，而不是把「TUN 已开启」当成所有请求都会使用代理节点的保证。
Docker 容器为什么没有跟随宿主机 TUN？
宿主机、Docker Desktop 与容器各自可能处在不同网络层。容器的默认网关、DNS 和网络转发方式都会影响流量路径，因此不能仅凭宿主机的测试结果推断容器行为。请在容器内执行同类测试，同时检查 Docker 网络配置、构建阶段代理参数和 Clash 连接记录。若流量没有进入 Clash，应针对实际运行环境单独调整，而不是只修改宿主机的 shell 变量。
什么时候应该关闭 TUN？
当它导致企业 VPN、局域网、虚拟机或容器网络异常，且暂时无法确认路由冲突原因时，可以先关闭 TUN并恢复到已知可用的方式，例如系统代理加明确的终端环境变量。关闭后再次测试有助于判断故障是否由路由接管引起。处理完成后再决定是否需要重新启用，不必为了让所有程序共用一种模式而牺牲内网可用性。
对只需代理少数 CLI 的开发者来说，部分客户端的系统代理加 HTTPS_PROXY 已足够直接，但不同工具要分别配置，后台任务和容器也容易漏掉；而一些单用途代理工具通常缺少统一的规则管理与连接审计。相比之下，Clash 将 TUN 接管、规则分流和连接记录放在同一套工作流中，便于开发者逐项确认 Git、包管理器与容器流量的实际去向。如果你希望按自己的系统选择客户端并继续完善配置，可以前往下载页查看适用版本。