原理解析 预计阅读 14 分钟

Clash开发者终端TUN代理配置与工作流指南

客户端面板里那个跳动的延迟数字,很多人把它当成"这条线路好不好用"的唯一依据。但 80ms 和"用起来流畅"之间,中间隔着测试目标、丢包率、带宽瓶颈和链路拥塞四道坎。本文拆开延迟数字的测量方式,说明它到底反映了什么、又遗漏了什么,并给出几种更贴近真实浏览体验的自测手段。

配置 预计阅读 10 分钟

如果你每天都要使用 GitHub、npm、pip、Docker Hub 或 AI 编程工具，单独设置环境变量往往无法覆盖完整工作流。本指南从开发者视角出发，配置 Clash TUN 模式与终端分流，让 Git、包管理器、容器工具和 IDE 更稳定地访问开发基础设施。

为什么开发工作流不能只依赖终端代理变量

开发者常见的代理配置，是在终端里写入 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY。这种方法简单直接，curl、Git、npm、pip 等命令行工具通常都能识别其中一部分变量。但它只对主动读取环境变量的进程有效，不能覆盖所有开发场景。

例如，Git 可能使用自己的全局代理设置，npm 和 pip 也各自有配置文件；Docker CLI 发出的请求还可能由 Docker Desktop 后台服务处理，和当前终端不是同一个进程环境。IDE 中的扩展、语言服务器、自动更新模块，也未必继承启动 IDE 时的终端变量。即使变量已经写对，子进程、后台服务和图形界面程序仍然可能绕过代理。

TUN 模式解决的是流量接管层问题。Clash 或 mihomo 创建虚拟网络接口，把符合路由范围的 IP 流量导入内核，再由规则判断应该直连、使用代理组，还是拒绝连接。这样，应用不需要知道代理端口，也不必实现 SOCKS5 或 HTTP CONNECT 支持，仍然可以被统一接管。

先理解边界:TUN 不是“所有程序必然代理”。它接管的是经过系统路由、且没有被排除的网络流量。应用自身的代理设置、证书校验、独立 VPN、局域网访问和容器虚拟网络，都可能改变最终结果。

配置前准备:客户端、权限与端口规划

本文以支持 mihomo 内核的 Clash Verge Rev、Clash Nyanpasu、FlClash 等客户端为参考。不同客户端的开关名称可能略有差异，但核心配置都围绕 TUN、DNS、路由和代理组展开。开始之前，先确认当前配置文件确实由 mihomo 内核加载，而不是仍在使用功能较旧的 Clash 内核。

  • 确认内核状态。在客户端的设置或内核页面查看当前内核名称与运行状态。TUN、Fake-IP、规则集等功能需要内核版本支持，界面上有开关不代表配置一定被成功加载。
  • 准备管理员权限。Windows 创建虚拟网卡、修改路由表通常需要管理员权限；macOS 需要批准网络扩展或系统扩展。权限被拒绝时，TUN 开关可能打开后立即关闭。
  • 检查端口占用。常见的 HTTP、SOCKS、混合端口不能和其他代理软件重复监听。多个客户端同时运行时，最容易出现“面板显示已启动，但终端连接失败”。
  • 记录现有 VPN 和公司网络配置。TUN、企业 VPN、网关安全软件都可能修改路由表。不要在没有记录原配置的情况下同时启用多个流量接管工具。

如果主要需求是 Git、npm、pip 这类明确支持代理的工具，可以先使用混合端口验证链路。常见配置是 HTTP 代理端口 7890、SOCKS 端口 7891，但实际端口必须以客户端当前配置为准，不能直接照抄示例。

mixed-port: 7890
mode: rule
allow-lan: false
log-level: info

mixed-port 同时接受 HTTP 代理和 SOCKS5 连接，适合给终端工具统一使用。配置修改后，先在客户端执行一次配置检查或重新加载，确认日志中没有 YAML 缩进、字段拼写和端口占用错误，再继续开启 TUN。

mihomo TUN 与 DNS 的基础配置

TUN 配置的重点不是简单勾选“增强模式”，而是让虚拟网卡、DNS 解析和路由接管形成一套完整链路。下面是一份用于理解字段关系的基础示例，具体参数仍应根据客户端版本和操作系统调整。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback:
    - https://1.0.0.1/dns-query

enable 控制 TUN 是否启用；stack: mixed 是较常用的兼容选择，由内核结合不同协议栈处理流量；auto-route 让内核尝试写入必要路由；auto-detect-interface 用于识别当前真正出网的网卡。使用 Wi-Fi、以太网、移动热点或虚拟网卡频繁切换的设备，自动识别通常比手工固定接口更方便。

strict-route 会更严格地处理系统路由，减少流量绕过 TUN 的机会，但也可能影响局域网、企业 VPN、虚拟机和容器网络。开启后如果公司内网地址无法访问，应检查路由与排除项，而不是直接反复切换代理节点。

开发环境通常建议启用 mihomo 的 DNS 接管，否则域名查询可能仍由系统 DNS 直接完成。Fake-IP 模式会为域名返回本地保留网段中的假地址，内核再依据映射关系恢复域名并进行规则匹配。这样，GitHub、包仓库和容器镜像域名更容易命中域名规则，也能减少应用自行解析导致的分流偏差。

注意:198.18.0.0/16 是常见的 Fake-IP 网段示例，但如果公司 VPN、虚拟机或实验网络正在使用相同地址段，就会发生路由冲突。出现内网连接异常时，优先检查 fake-ip-range 与现有网段是否重叠。

DNS 服务器地址也不应机械复制。DoH、DoT 和普通 UDP DNS 的可达性取决于当前网络与规则。若上游 DNS 本身必须经过代理，应确保 DNS 配置与规则策略匹配；如果 DNS 查询全部指向不可达的服务器，表现可能是所有域名都打不开，而不是单个节点故障。

开发者常用域名的分流与直连边界

开启 TUN 后，开发工作流是否稳定，主要取决于规则。建议把“开发基础设施”与“本地资源”分开考虑。GitHub、npm、PyPI、Docker Hub、常用 AI 服务属于需要根据网络环境选择代理的目标；公司 GitLab、内网制品库、数据库、NAS 和本地开发服务，通常应该直连。

  • 代码托管。github.com、githubusercontent.com、githubassets.com 常常不是同一个域名链路，不能只添加一个主域名就认为所有 Git 操作都会命中同一规则。
  • JavaScript 包管理。npm 的 registry、包 tarball、脚本中引用的二级下载地址可能不同。若只代理登录页面，实际安装阶段仍可能访问失败。
  • Python 包管理。pip 默认访问的索引地址和企业内部镜像地址应区分处理。内部镜像通常应直连，公共索引则按网络环境选择代理。
  • 容器工具。Docker Hub 的认证、镜像清单和具体 layer 下载可能经过不同域名。Docker Desktop 还可能运行在独立后台环境中，不能只验证当前 shell 就下结论。
  • 本地与企业网络。公司 GitLab、私有 npm registry、私有 PyPI、内网 DNS、*.local 和 RFC1918 私有地址应优先加入直连或 Fake-IP 排除范围。

规则顺序非常重要。一般应先处理明确的内网和本地地址，再处理特定开发服务，最后使用兜底规则。伪配置示例如下：

rules:
  - DOMAIN-SUFFIX,company.example,DIRECT
  - DOMAIN-SUFFIX,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  - DOMAIN-SUFFIX,npmjs.org,PROXY
  - DOMAIN-SUFFIX,pypi.org,PROXY
  - MATCH,DIRECT

上面的代理组名称只是示例，必须替换成当前配置中真实存在的组名。若规则写成了不存在的策略组，内核会在加载时报告错误，或者相关请求无法按预期处理。对于域名规则和 IP 规则都可能命中的目标，要结合日志确认最终采用的是哪一条。

终端代理变量与 Git、npm、pip 的配置方法

TUN 启用后，终端工具即使不设置代理变量，很多 TCP 连接也能被系统接管。但保留显式代理变量仍有价值：它能让工具明确使用 HTTP 或 SOCKS5 代理，减少对系统路由的依赖，也方便在不启用 TUN 时单独测试。推荐先统一使用混合端口，再根据工具特性做细分。

# macOS / Linux，当前终端会话
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1,.local,10.0.0.0/8,192.168.0.0/16

# Windows PowerShell，当前会话
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"
$env:NO_PROXY="localhost,127.0.0.1,::1,.local"

NO_PROXY 很重要。没有排除本机和内网地址时，访问本地开发服务器、公司内网接口或数据库可能被错误送进代理。不同工具对 CIDR、通配符和前导点域名的支持并不完全一致，因此不要把复杂的排除逻辑全部寄托在环境变量上，必要时同时配置工具自身的直连规则。

Git 可以单独设置 HTTP 代理，便于确认 Git 行为是否和系统代理一致：

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

# 查看当前设置
git config --global --get-regexp 'http\..*proxy'

# 取消 Git 全局代理
git config --global --unset http.proxy
git config --global --unset https.proxy

如果 Git 通过 SSH 访问仓库，http.proxy 不会自动作用于 SSH。此时应使用 Git 的 HTTPS 地址，或者为 SSH 单独配置代理命令。不要为了“让 GitHub 能用”而全局代理所有 SSH 连接，否则公司内网仓库和局域网主机也可能被错误转发。

npm 和 pip 也可以使用各自的配置：

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890
npm config get proxy

pip config set global.proxy http://127.0.0.1:7890
pip config list

企业环境中如果同时存在公共源和私有源，建议优先配置准确的 registry，而不是简单地把所有请求都代理出去。私有包仓库可能依赖公司证书、内网 DNS 或单点登录，经过公共代理反而会触发证书错误、登录重定向失败或权限异常。

Docker、IDE 与后台服务的验证顺序

Docker 是最容易让开发者误判的场景。执行 docker pull 时，命令行客户端只是向 Docker 引擎发出请求；在 Docker Desktop 中，真正访问镜像仓库的往往是后台虚拟机或守护进程。因此，当前 shell 中的 HTTP_PROXY 生效，不等于 Docker 引擎已经配置代理。

验证时先区分运行方式。Linux 上通常检查 Docker daemon 的代理配置与服务重启状态；Windows 和 macOS 上则检查 Docker Desktop 的 Resources、Proxies 或网络设置页面。修改后重新启动引擎，再观察拉取镜像时的日志。不要只用浏览器访问 Docker Hub 判断配置成功，因为浏览器和 Docker 引擎可能走完全不同的网络路径。

  • 先执行 docker info，确认客户端能够连接当前 Docker 引擎。
  • 再执行小体积公共镜像的拉取测试，观察是认证失败、DNS 失败、超时还是 TLS 错误。
  • 检查私有 registry 是否应该加入 NO_PROXY 或 Clash 的直连规则。
  • 如果容器内部还要访问外部服务，单独检查容器的 DNS、默认网关和环境变量；宿主机 TUN 正常不代表容器内流量已经按同样规则处理。

IDE 也应分层验证。编辑器主程序、扩展市场、Git 集成、终端、语言服务器和调试器可能分别使用不同的网络实现。先在 IDE 内置终端执行 curl 或包管理命令，再测试扩展市场和语言服务。如果只有某个扩展失败，优先查看该扩展是否提供独立的 HTTP 代理设置，而不是修改全局 TUN 配置。

常见故障的定位方法与安全收尾

开发场景的故障排查要避免同时改动多个开关。建议按照“内核—TUN—DNS—规则—应用配置”的顺序定位，每一步只验证一个层面。

  1. 确认客户端内核正在运行，并查看日志中是否出现 TUN 创建失败、端口占用或配置解析错误。
  2. 关闭 TUN，只保留混合端口，使用 curl -x http://127.0.0.1:7890 https://example.com 测试显式代理链路。
  3. 重新开启 TUN，使用不设置代理变量的 curl 测试同一目标，比较两种结果，判断问题在应用代理还是系统接管。
  4. 检查 Clash 日志中的目标域名、命中规则、代理组和最终节点，确认请求没有被错误地匹配到 DIRECT。
  5. 对失败域名执行 DNS 检查，区分解析失败、连接超时、TLS 证书错误和远端拒绝。不同错误不应使用同一种修复方式。
  6. 最后检查防火墙、公司 VPN、杀毒软件网络过滤、容器虚拟网卡和其他代理客户端是否产生冲突。
# 仅用于验证显式 HTTP 代理
curl -v -x http://127.0.0.1:7890 https://example.com

# 查看当前终端变量
env | grep -i proxy        # macOS / Linux
Get-ChildItem Env: | Select-String -Pattern "PROXY"  # PowerShell

# 查看域名解析结果
nslookup github.com
dig github.com

安全提醒:不要把带有订阅凭据、私有仓库令牌或内部域名的完整日志直接发布到公开渠道。排查前可以保留时间、错误类型和规则名称，但应删除访问令牌、认证头、私有主机名与个人路径。

稳定的开发工作流通常不是“永远开启全局代理”，而是让每一层职责清楚：TUN 负责接管不支持代理的应用，终端变量负责明确支持代理的工具，Clash 规则负责区分公共服务与内网资源，Git、npm、pip 和 Docker 再根据自身运行方式做补充配置。完成调整后，分别测试代码拉取、包安装、镜像拉取、IDE 扩展访问和内网服务，确认代理范围与直连范围都符合预期，再把配置固定到日常工作环境中。

下载客户端
下载客户端