为什么开发者需要一条统一的命令行代理链路

软件开发时，网络问题很少只影响一个程序。你可能在浏览器里能打开项目主页，却发现 Git clone 卡在连接阶段；也可能 npm install 已经拉到一半，随后因为 tarball CDN 超时失败；Python 虚拟环境创建成功，执行 pip install 时却无法获取轮子文件；Docker Desktop 看似正常，真正拉取镜像时又报 i/o timeout。这些现象通常不是单一软件的故障，而是不同开发工具各自使用了不同的网络栈、代理读取方式和 DNS 解析路径。

传统的系统代理主要服务于浏览器和遵守操作系统代理设置的桌面应用。终端程序则复杂得多：Git 可能读取自己的配置，Node.js 依赖环境变量或包管理器设置，Python 工具通常使用 HTTP_PROXY、HTTPS_PROXY，Docker Desktop 还可能运行在独立的虚拟机或后台服务中。只打开 Clash 的系统代理开关，并不能保证所有开发流量都会沿着同一条链路发送。

Clash TUN 模式的价值在于把代理位置前移到网络层。启用 TUN 后，Mihomo 内核创建虚拟网卡并接管符合条件的 TCP、UDP 流量，应用不需要逐一理解 HTTP 代理，许多原本不会读取系统代理的程序也能被统一纳入规则系统。它不是万能的网络加速器，也不会自动修复错误的节点和规则，但能显著减少「浏览器能用、终端不能用」这类分裂状态。

先记住边界：TUN 负责接管流量，规则负责决定流量去哪里，DNS 负责把域名解析成地址。三者任何一个环节配置不当，最终都可能表现为命令行超时。因此排查时不要只反复更换节点，应同时观察 Clash 连接日志、目标域名和实际命中的策略组。

Clash TUN、系统代理与环境变量如何分工

在开发机上，建议把三种代理方式理解成不同层级，而不是互相替代的按钮。系统代理适合浏览器、即时通信软件以及明确遵循 PAC 或系统 HTTP 设置的应用；它配置简单、影响范围可控，但不覆盖所有原生网络库。环境变量代理适合临时运行的脚本、CI 命令和容器构建过程，可以精确控制某个终端会话，却需要每个 shell 或工具正确继承变量。TUN 模式位于更底层，适合需要让多个运行时共享一套分流规则的本机开发环境。

Clash 客户端常见的「混合端口」同时支持 HTTP 和 SOCKS5 请求。假设本机混合端口为 7890，HTTP 代理变量可以写成 http://127.0.0.1:7890，而某些只支持 SOCKS5 的工具则需要使用 socks5://127.0.0.1:7890。端口号必须以客户端设置页显示的实际值为准，不能机械照抄示例。开启 TUN 后，环境变量仍然有用：它可以帮助某个工具明确走指定代理，也方便在 TUN 关闭时保留一条可验证的备用路径。

在 Windows、macOS 和 Linux 上，客户端界面名称可能不同，但排查逻辑基本一致。Clash Verge Rev、Mihomo Party 等桌面客户端通常能在设置页安装或启用 TUN 服务；移动端的 TUN 逻辑则受系统 VPN 权限约束，不应直接套用桌面端步骤。对于开发者工作站，建议先确认 Mihomo 内核版本、服务权限、自动路由和自动检测出口网卡均处于正常状态，再把问题交给规则层处理。

  • 浏览器访问异常：优先检查系统代理、DNS 和浏览器自身的安全 DNS 设置。
  • 终端完全不通：先确认 TUN 服务已运行，再检查默认路由与虚拟网卡是否创建。
  • 只有某个工具失败：检查该工具的环境变量、独立代理配置和证书错误，不要立即改成全局模式。
  • 内网或本地服务受影响：使用 NO_PROXY，并在规则中保留局域网、回环地址和公司域名的直连路径。

按开发工具拆分 Git、包管理器与镜像流量

开发工具的域名链路并不相同，最稳妥的方式是按用途建立少量清晰的策略组，而不是把所有境外域名粗暴地塞进一个巨大规则。GitHub 代码仓库、发布附件、原始文件和 Git LFS 可能使用不同的主机名；npm 先访问 registry 获取元数据，随后再从 CDN 下载压缩包；PyPI 的索引与文件分发也可能发生域名跳转；Docker 则同时涉及镜像仓库、认证服务和内容分发网络。

Git 与 SSH：HTTPS 和 SSH 要分别验证

使用 HTTPS 地址拉取仓库时，Git 通常可以通过自己的 http.proxy 配置，或者继承系统与 TUN 路由。使用 SSH 地址时，连接目标通常是远端主机的 22 端口，很多网络环境会限制该端口，即使浏览器访问同一代码托管平台也不代表 SSH 能通。此时可以考虑使用代码托管平台提供的 HTTPS 克隆地址，或在确认服务商支持的前提下，将 SSH 通过一个明确的 TCP 转发端口发送。

不要一开始就把代理永久写入全局 Git 配置。更好的做法是先在当前项目或当前用户范围内验证，然后用 git config --show-origin --get-regexp proxy 查看实际生效来源。若连接日志显示请求根本没有进入 Clash，说明是 Git 配置或 TUN 接管问题；若已经命中正确策略组但仍返回认证失败，则应转向令牌、SSH Key 或仓库权限排查。

npm、pnpm、yarn 与 pip：索引能通不等于安装能通

Node.js 包管理器最容易制造「元数据正常、安装仍失败」的错觉。npm view 或 npm ping 只验证了 registry 的一部分路径，而真正安装时还会访问包的 tarball 地址。如果规则只覆盖了 registry.npmjs.org，没有观察日志中的 CDN 主机名，安装大型依赖时仍可能出现 ETIMEDOUT、ECONNRESET 或校验失败。pnpm 的内容寻址存储、yarn 的镜像设置也可能让同一包走出不同的请求链。

pip 同样不能只测试索引首页。执行安装时，pip 会读取简单索引，再下载具体的 wheel 或 source archive。建议先在一个干净的虚拟环境中执行小型测试，确认 Python 解释器、pip 版本和代理变量一致，再观察 Clash 连接列表中出现的真实域名。对于企业内网或自建镜像，应把内部源设为直连或专用策略，避免所有依赖请求都绕到公共代理。

Docker：客户端代理与容器构建代理不是一回事

Docker 的难点在于「谁在发起请求」。Docker Desktop 的镜像拉取可能由后台引擎完成，终端里的 docker pull 只是发送控制请求；而 docker build 中执行的 RUN npm install 或 RUN pip install，又是构建容器内部的进程在联网。你在宿主机终端里设置的代理变量，不一定会自动进入 Docker daemon 和每一个构建阶段。

因此需要分别检查 Docker Desktop 的代理设置、daemon 的镜像仓库配置，以及构建时显式传递的 HTTP_PROXY 和 HTTPS_PROXY。如果宿主机启用了 TUN，Docker Desktop 使用的虚拟网络仍可能与宿主机路由存在差异。连接日志中若只有宿主机请求而没有镜像仓库请求，应优先检查 Docker 引擎网络，而不是继续调整 Clash 规则。

动手配置：用五步建立开发机 TUN 工作流

下面以支持 Mihomo 内核的桌面客户端为例。不同客户端的菜单名称会有差异，但核心选项通常包括配置文件、TUN、系统代理、DNS、规则模式和连接日志。建议先备份当前配置，避免一次修改太多项目后无法判断是哪项设置造成影响。

  1. 确认内核与端口：打开客户端的设置或关于页面，确认当前使用的是 Mihomo 内核，并记录混合端口、API 端口和 SOCKS 端口。不要假设默认端口一定是 7890。
  2. 导入并检查配置：导入可信订阅或本地 YAML，先用规则模式运行，确认策略组、DNS 和代理节点能够正常加载。第一次排查不建议直接使用全局模式，因为它会掩盖规则遗漏。
  3. 安装 TUN 服务：在客户端中安装 Service Mode、系统服务或对应权限组件，按操作系统提示授权。开启 TUN 后检查虚拟网卡是否出现，并确认自动路由与自动检测出口网卡已开启。
  4. 保留本地直连：确保 127.0.0.0/8、局域网网段、公司内网域名、Git 私有域名和本地开发端口不会被无意送入代理。必要时设置 NO_PROXY，避免脚本访问数据库或 Kubernetes API 时绕远路。
  5. 逐项验证开发工具：先测试域名解析，再测试 Git HTTPS，随后测试 npm 或 pip，最后测试 Docker。每完成一项就查看 Clash 连接日志，记录请求主机名、命中的规则和实际节点，不要同时运行多个大型安装命令。

可以使用以下命令做基础自检，命令本身不代表所有工具都会采用同样的代理路径：

curl -I https://github.com
git ls-remote https://github.com/example/project.git
npm ping
python -m pip index versions pip
docker pull hello-world

如果这些测试都成功，仍要分别验证真实项目。Git 仓库可能启用了 LFS，npm 项目可能包含私有包，pip 项目可能依赖企业源，Docker 镜像也可能来自私有 registry。开发工作流的可靠性不应只用一个公共网站的响应来判断，而应以你实际使用的仓库和依赖链为准。

调试技巧：测试时先固定一个稳定节点，暂时关闭自动测速或故障转移。长时间下载、Git LFS 和 Docker layer 对中途换节点很敏感，策略组在会话中途切换可能造成连接重置。确认规则无误后，再恢复 url-test 或 fallback 策略。

分流设计：把可维护性放在速度之前

开发者配置 Clash 时，最常见的误区是追求一份「覆盖所有域名」的超长规则列表。域名清单越长，维护成本越高，也越容易把公司服务、开源镜像和私有仓库误判到错误出口。更好的思路是围绕工作流建立少数几类策略：代码托管、Node 包、Python 包、容器仓库、AI 或文档服务，以及本地和企业内网。

代码托管与包管理器可以共享一个基础代理组，但不建议完全绑定同一个自动选择策略。Git clone 和 Docker layer 对持续连接稳定性更敏感，而 npm 元数据请求则更关注整体成功率。若某个节点适合网页访问，不一定适合长时间传输大文件。可以先设置手动选择组用于排障，确认各类流量稳定后，再根据需要切换到 url-test。

DNS 方面，fake-ip、redir-host 和系统解析各有适用场景。启用 TUN 后，fake-ip 能帮助内核更完整地识别域名并执行规则，但部分本地服务、企业认证、虚拟机网络和特殊应用可能不适合 fake-ip。遇到「域名在浏览器能解析，终端却连不上」时，应同时查看 DNS 日志和连接日志，确认应用连接的是域名还是缓存过的 IP，而不是盲目更换 DNS 服务器。

开发场景 优先检查 常见误区
Git HTTPS Git 代理配置、仓库域名、LFS 请求 只测试主页，不测试实际仓库
SSH 拉取 端口可达性、SSH 配置、密钥认证 把 SSH 失败误判为 HTTP 代理故障
npm / pnpm / yarn registry、tarball CDN、证书与缓存 只验证元数据，不验证完整安装
pip 索引源、wheel 下载地址、虚拟环境变量 把企业镜像和公共源混用
Docker daemon、Desktop、构建阶段的代理继承 以为宿主机代理会自动传入容器

常见故障：从连接日志反推问题位置

当 TUN 开启后出现断网，不要立刻删除配置。先关闭 TUN，确认系统代理或显式环境变量是否仍能访问基础网站；如果备用路径也失败，问题可能在节点、订阅或本地网络。若只有 TUN 失败，则重点检查服务权限、自动路由、虚拟网卡、DNS 劫持以及其他 VPN、杀毒软件或企业安全客户端是否产生冲突。

如果 Clash 连接列表里完全看不到 npm、pip 或 Docker 的目标域名，说明流量没有被客户端接管，常见原因包括进程运行在虚拟机、容器或 WSL 中，或者 TUN 没有覆盖对应接口。此时可以先在同一环境中显式设置代理变量，验证应用自身是否支持代理，再决定是否调整路由。对于 WSL、Docker Desktop 和远程开发容器，应把宿主机与来宾环境分别看待。

如果日志显示请求已命中代理，但仍然超时或反复重置，则继续观察是 DNS、TLS、认证还是传输阶段失败。TLS 握手失败可能与系统时间、证书存储、企业中间人证书有关；HTTP 401 或 403 多半是令牌和权限问题；下载到一半断开则更像节点稳定性、连接复用或策略组切换问题。将错误分类后再调整，通常比反复切换全局模式更快。

不要忽略安全性：代理变量会被部分程序记录在诊断日志、进程列表或构建输出中。不要把带有账号密码的代理 URL 写入公开仓库，也不要把订阅链接、私有 registry Token 和 SSH 私钥提交到 Git。完成排障后，清理临时变量并检查 shell 历史记录。

市面上一些同类代理工具在开发场景下要么只提供简单的系统代理开关，要么把 TUN、DNS、规则覆写和日志拆散在多个难以理解的页面里，遇到 Git、包管理器与 Docker 同时异常时，往往很难判断流量究竟卡在哪一层。Clash 官网 更适合把这套工作流按「内核接管、规则分流、连接日志、工具验证」逐层整理，既能保留显式环境变量的可控性，也能用 TUN 减少重复配置；如果你希望按照本文步骤搭建一套清晰、可回滚的开发者代理环境，不妨前往下载并从混合端口与 TUN 基础设置开始。