进阶配置 预计阅读 15 分钟

开发者Clash配置指南：TUN模式打通Git、npm与AI工具

开发者每天面对 GitHub 拉取失败、npm 依赖下载缓慢、Docker Hub 超时和 Copilot 无法连接等问题。本指南以真实开发工作流为主线，配置 Clash TUN 模式与终端代理，让常用工具获得更稳定的网络连接。

先把开发工具的代理边界分清楚

开发者遇到 GitHub 拉取失败、npm 安装缓慢、Docker Hub 超时或 AI 编程工具无法连接时，问题不一定出在同一个地方。浏览器可以打开网页，只能说明浏览器当前使用的代理路径可用；它不能证明 Git、Node.js、Docker、终端和编辑器也会读取同一套设置。不同工具可能分别使用系统代理、环境变量、应用内代理，或者完全绕过这些设置。

Clash 的 mixed-port 通常同时接受 HTTP 代理和 SOCKS5 代理，常见端口是 7890，但实际使用时必须以 Clash Nyanpasu、Clash Verge Rev 或 Mihomo 客户端当前显示的端口为准。TUN 模式则通过虚拟网络接口接管更多网络连接，使不读取代理环境变量的程序也有机会进入 Clash 的规则处理流程。

接管方式 主要覆盖范围 典型开发场景 常见限制
系统代理 遵守操作系统代理设置的应用 浏览器、部分桌面软件 终端和开发工具不一定读取
环境变量 当前终端及其启动的子进程 curl、Git、npm、部分 CLI 只对读取变量的程序有效
应用内代理 单个软件自己的网络模块 Docker、IDE、包管理器 配置分散，容易与全局设置冲突
TUN 模式 经过虚拟网卡的更多 TCP、UDP 流量 不支持代理变量的应用、部分 AI 工具 需要系统权限，并可能受 DNS 与路由影响

先完成 TUN 模式的基础配置

在 Windows、macOS 或 Linux 上启用 TUN 前，先确认代理核心已经正常运行，当前配置能够访问目标站点，并且系统中没有同时运行两个 Clash 客户端。Clash Verge、Clash Verge Rev 和其他 Mihomo 客户端的菜单名称可能略有不同，但通常可以在「设置」或「网络」区域找到 TUN 开关。

  1. 导入并启用一份有效配置，确认「代理」页面可以看到节点和策略组。
  2. 进入「设置」→「端口」或对应的 Clash 设置页面，记录 mixed-port、控制端口和 TUN 状态。
  3. 先使用规则模式测试普通 HTTPS 请求，确认节点和规则没有整体失效。
  4. 在「设置」→「TUN 模式」中启用 TUN。首次启用时，Windows 可能弹出管理员权限确认，macOS 可能要求允许网络扩展或系统扩展。
  5. 启用后重新打开终端和需要联网的应用，让它们重新建立连接。部分程序会缓存旧的 DNS 或连接，单纯切换开关不一定会立即刷新。

TUN 配置中常见的关键参数包括虚拟网卡名称、自动路由、严格路由、DNS 劫持以及 IPv6 处理。不同核心版本的字段名称和默认值可能不同，不建议直接把网上的完整配置覆盖到现有订阅上。更稳妥的做法是先备份配置，再只调整确实需要的选项。

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

dns:
  enable: true
  enhanced-mode: fake-ip

上面的片段只用于说明配置结构，是否支持以及具体字段写法要以当前 Mihomo 核心和客户端版本为准。auto-route 通常用于把系统流量路由到 TUN 接口，auto-detect-interface 用于识别当前实际联网接口；如果设备存在 VPN、虚拟机网卡、Docker 网卡或多个无线网卡，自动识别结果仍需结合日志核对。

DNS、路由与排除规则

TUN 模式下，DNS 行为会直接影响开发工具。域名解析失败、解析到不可达地址、IPv6 优先但 IPv6 链路不可用，都可能表现为 Git 或 Docker 连接超时。启用增强 DNS 后，应确认 DNS 请求确实由 Clash 处理，并查看日志中是否出现反复的解析失败。

启用 TUN 后不要立刻同时修改 DNS、代理模式和策略组。建议先用一个固定节点测试，确认 TUN 能接管连接，再恢复自动策略组。这样可以把“虚拟网卡没工作”“规则走了 DIRECT”和“节点本身不可用”区分开。

为终端建立可控的代理环境

即使已经开启 TUN，也建议为 Git、npm 和 curl 设置明确的终端代理。环境变量的好处是路径清晰、容易临时关闭，也方便在 TUN 出现异常时进行对照测试。HTTP 代理一般写成 http://127.0.0.1:7890；SOCKS5 代理可写成 socks5://127.0.0.1:7890。涉及域名解析时，优先使用支持远程解析的 socks5h 形式。

临时设置与取消

Linux、macOS 和使用 WSL 的终端可以执行：

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:7890

curl -I https://github.com
npm ping

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

Windows PowerShell 的写法不同：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5h://127.0.0.1:7890"

curl.exe -I https://github.com

Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY

环境变量通常只对当前终端窗口及其子进程生效。使用 VS Code、JetBrains IDE 或其他图形化编辑器时，如果编辑器不是从这个终端启动，它可能看不到临时变量。长期设置可以写入 PowerShell 配置文件、Shell 配置文件或操作系统用户环境变量，但不建议把代理写入公共脚本、项目仓库或 CI 配置，因为其中可能包含认证信息，也会让没有运行 Clash 的环境无法执行命令。

配置 Git 与 npm 的稳定访问路径

Git：优先使用明确的全局配置

Git 不一定会自动读取所有终端环境变量，因此可以直接为 Git 设置代理。使用 HTTP 代理时：

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 http.proxy
git config --global --get https.proxy

如果混合端口的 SOCKS5 入口工作正常，也可以使用：

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

Git 的代理配置主要影响 HTTP(S) 远程仓库。如果项目使用 SSH 地址，例如 [email protected]:org/repo.git，上面的设置通常不会直接改变 SSH 连接。可以将远程地址改为 HTTPS，或者为 SSH 单独配置跳转方式；开发环境中如果只是为了稳定拉取公开仓库，改用 HTTPS 往往更容易维护。

git remote -v
git ls-remote https://github.com/example/project.git
git clone https://github.com/example/project.git

如果之前设置过错误代理，Git 可能一直连接一个已经关闭的端口。可以查看所有来源的配置：

git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'

确认后删除不需要的配置：

git config --global --unset http.proxy
git config --global --unset https.proxy

npm：区分代理设置与镜像源

npm 的访问路径由 registry、proxy、https-proxy 和环境变量共同影响。先查看当前设置：

npm config get registry
npm config get proxy
npm config get https-proxy

如果希望通过 Clash 访问当前 registry，可以设置：

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

代理端口正常但下载仍然缓慢时，不要立即重复切换节点。先确认 registry 地址是否是预期的源，再检查 npm 日志中的错误。镜像源和代理是两件事：镜像源决定从哪个仓库获取包，代理决定连接该仓库时是否经过 Clash。团队项目应通过项目文档或锁文件约定 registry，不要在个人电脑上静默改源后把结果带入构建脚本。

处理 Docker Hub 与 AI 工具的特殊连接

Docker CLI、Docker Desktop、Copilot 以及其他 AI 编程工具经常使用独立的网络进程或后台服务。它们可能不读取当前 Shell 的代理变量，也可能因为证书校验、长连接、WebSocket 或 HTTP/2 行为与普通网页不同。因此，必须分别验证，不要用“浏览器能打开”作为唯一结论。

Docker Desktop 与镜像拉取

Docker Desktop 的引擎通常运行在独立的虚拟环境中。即使宿主机终端已经设置 HTTP_PROXY，Docker daemon 也未必继承。应在 Docker Desktop 的设置页面查找 Resources、Proxies 或 Network 相关选项，根据当前版本填写 HTTP 和 HTTPS 代理地址，然后重启 Docker Desktop。

docker info
docker pull hello-world
docker pull node:22-alpine

如果 docker info 正常但 docker pull 超时，查看 Docker Desktop 日志和 Clash 连接记录，确认实际请求的域名是否命中代理策略。镜像拉取还可能涉及认证服务、内容分发域名和多个重定向地址，只放行一个域名并不一定足够。对于本地开发中的容器访问宿主机服务，不要简单把所有容器流量都交给代理；应区分镜像下载路径和应用运行时访问路径。

Copilot 与 AI 编程工具

AI 编程工具通常需要访问登录服务、API 接口、模型服务和持续连接端点。编辑器能启动不代表扩展已经成功建立认证连接。先打开编辑器的输出面板或日志面板，记录失败的域名、状态码和错误类型，再在 Clash 连接页面确认这些请求是否出现。

可以用编辑器启动的终端执行基础连通性测试，也可以用 curl 明确指定代理。测试结果只能证明某个域名和某条路径可用，不能替代应用本身的认证流程。不要为了让 AI 工具“能连上”而关闭 TLS 证书校验；这会削弱连接安全性，也可能隐藏中间代理或系统证书配置问题。

用分层验证确认配置真正生效

完成配置后，建议按照由近及远的顺序验证。第一层验证本地端口，第二层验证代理核心和节点，第三层验证具体开发工具，最后再恢复自动策略和复杂规则。每次只改一个变量，保留成功命令和失败时间，后续查看日志会更容易。

  1. 本地端口：执行 curl -I -x http://127.0.0.1:7890 https://github.com，确认混合端口可以建立连接。
  2. 域名解析：分别测试 GitHub、npm registry、Docker 相关域名和 AI 工具日志中出现的域名，确认 DNS 没有持续失败。
  3. 规则命中：在 Clash 连接页面查看请求进入的是预期策略组，而不是误命中 DIRECT 或错误的代理组。
  4. 工具功能：依次执行 git ls-remote、npm ping、docker pull hello-world，不要同时启动多个大任务。
  5. 稳定性：连续观察 10 至 15 分钟，检查节点是否频繁切换、连接是否大量重试，以及 TUN 是否造成本地服务不可访问。
现象 优先检查 不建议立即做的事
浏览器正常，Git 失败 Git proxy、SSH/HTTPS 远程地址、终端变量 反复重装 Clash
npm 能解析但下载超时 registry、节点稳定性、长连接与规则 盲目删除锁文件
Docker Desktop 全部超时 Docker daemon 的独立代理配置 只修改 Shell 的 proxy 变量
AI 工具登录失败 应用日志、认证域名、WebSocket 与账户状态 关闭证书校验
开启 TUN 后本地服务异常 路由、DNS、局域网网段和 bypass 设置 把所有流量永久设为全局代理

日常使用中，可以保留一组最小化配置：Clash 运行一个稳定的混合端口，TUN 负责覆盖不读取代理设置的应用，终端通过环境变量或 Git/npm 的明确配置访问外部服务，局域网和本地开发地址通过 NO_PROXY 或规则保持直连。遇到问题时先恢复到这组基线，再逐项加入自动策略、额外 DNS、容器网络和编辑器代理，通常比一次修改十多个参数更快定位。

下载 Clash 客户端 按系统选择安装包