对开发者来说，网络问题往往不是「完全打不开」这么简单，而是集中出现在最影响效率的环节：GitHub clone 卡在半路、npm 安装依赖时反复 ETIMEDOUT、pip 下载速度忽快忽慢、Homebrew 更新长时间没有响应，或者 Docker 拉取镜像时一直停留在 Pulling。浏览器能够访问某个网站，并不代表 Terminal、IDE、SSH 客户端和 Docker 守护进程都使用了同一条网络路径。它们可能不读取系统代理，也可能因为 DNS、规则顺序或代理协议不同而走向完全不同的出口。
本文以 Clash Verge Rev 或其它支持 Mihomo 内核的 Clash 客户端为例，整理一套适合日常开发机的终端代理工作流：先确认混合端口，再配置 shell 环境变量；随后根据 Git、SSH、npm、pip、Homebrew 和 Docker 的连接特点选择规则分流或 TUN 模式；最后通过日志、curl 和实际命令验证请求是否真的命中预期策略。文中的端口、策略组和域名只是示例，请以你当前客户端界面和订阅配置显示的内容为准。
开发工作流中最常见的代理断点
开发工具的网络请求通常具有几个明显特点。第一，它们不一定使用浏览器的代理设置。Node.js、Python、Go 和 Rust 工具链各自采用不同的 HTTP 客户端，有些会读取 HTTPS_PROXY，有些只在特定版本中读取，有些则只支持命令行参数。第二，开发任务经常访问多个域名。例如一次 npm install 可能先访问 npm registry，再访问 GitHub 获取 git 依赖；Docker 拉取镜像时还会涉及认证服务、镜像仓库和 CDN。只代理其中一个域名，仍然可能得到「安装失败」的结果。
第三，长时间运行的服务与当前终端不是同一个进程环境。你在 Terminal 中执行 export HTTPS_PROXY，只影响当前 shell 及其子进程，并不会自动影响 Docker Desktop、IDE 图形进程、systemd 服务或另一个已经打开的终端窗口。因此，排查时不要只问「Clash 有没有开启」，而要分别确认请求由谁发起、是否继承代理变量、最终被哪条规则处理。
| 场景 | 常见表现 | 优先检查 |
|---|---|---|
| Git HTTPS | clone 超时、fetch 中断、TLS 握手失败 | HTTPS_PROXY、Git 代理配置、GitHub 规则 |
| Git SSH | 22 端口超时、Permission denied 之外的连接错误 | SSH ProxyCommand、TUN、企业网络限制 |
| npm 与 pip | registry 访问慢、依赖下载失败 | registry 地址、代理变量、NO_PROXY |
| Homebrew | 更新卡住、下载 formula 或 cask 失败 | 环境变量、Git 请求、镜像源策略 |
| Docker | pull 超时、认证成功但镜像层下载失败 | Docker daemon 的独立代理设置、TUN |
先在 Clash 中确认端口与策略
打开 Clash Verge Rev 后，先进入设置或常规页面，确认是否存在 Mixed Port（混合端口）。混合端口通常同时接受 HTTP 和 SOCKS5 请求，开发工具使用它比分别记忆两个端口更方便。常见地址是 127.0.0.1:7890，但这只是社区中常见的示例，实际端口可能是 7897、7898 或其他数值。不要直接复制别人的端口，否则环境变量看似已经设置，实际可能连接到一个没有监听的端口。
接着打开连接面板，准备观察请求命中情况。测试时可以用一个明确的 HTTPS 地址，例如 GitHub API 或 npm registry。你需要关注的不只是「请求有没有出现」，还要看它的最终策略、连接耗时和目标主机名。如果列表中显示 DIRECT，但你的目标是让该请求通过代理，就应先检查规则顺序；如果完全没有记录，则可能是应用没有发起请求、走了系统之外的网络栈，或被 DNS 与连接方式绕开了当前内核。
HTTPS_PROXY；如果代理地址要求用户名或密码，也应按照客户端显示的完整格式填写。
为终端配置 HTTP 代理与排除列表
对 Git HTTPS、npm、pip 和多数基于 HTTP 的开发工具来说，最容易维护的方案是在 shell 中设置代理环境变量。macOS 和 Linux 通常使用 zsh 或 bash，可以在当前会话先临时验证：
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1,.local,公司内网域名其中 HTTPS_PROXY 负责 HTTPS 请求，HTTP_PROXY 兼容部分仍使用明文 HTTP 代理语义的工具，ALL_PROXY 则给某些客户端提供兜底。大小写变量的兼容性并不完全一致，遇到工具不认变量时，可以同时设置大写和小写版本。Windows PowerShell 可使用 $env:HTTPS_PROXY 查看当前值，长期配置则应根据你使用的是 PowerShell、Git Bash 还是 IDE 终端分别设置。
NO_PROXY 很重要。它用于让本机服务、回环地址、开发环境域名和企业内网保持直连，避免请求被送入外部节点后无法访问。例如本地 Kubernetes、数据库、Docker 网桥、公司 GitLab 或私有 npm registry，通常不应该套用公共代理。排除列表可以使用域名后缀，但不同程序对通配符的支持并不一致；如果发现规则没有生效，先把具体主机名写出来测试，不要一开始就使用过于复杂的通配符。
确认变量生效后，再用最小请求验证，而不是直接开始安装几百个依赖：
env | grep -i proxy
curl -I https://github.com
curl -I https://registry.npmjs.org如果 curl 能够稳定返回响应，但 npm 或 pip 仍然失败，问题就从「基础链路」缩小到了具体工具的代理实现、证书校验或 registry 配置。反过来，如果 curl 也超时，应回到 Clash 连接日志检查规则命中和节点状态。
Git、SSH、npm、pip 与 Homebrew 的分流方法
Git HTTPS：优先保持配置简单
Git 使用 HTTPS 时，通常可以继承 shell 中的代理变量。为了避免全局配置残留旧端口，建议先查看当前配置：
git config --global --get http.proxy
git config --global --get https.proxy如果已经写入过失效地址，可以删除后只保留环境变量，或者明确写入当前混合端口。两种方式不要长期混用，否则换端口时很容易出现「环境变量是新的，Git 配置却是旧的」的矛盾。企业 Git、局域网代码仓库和内网域名应加入 NO_PROXY 或通过 Clash 规则指定 DIRECT，公共 GitHub 请求则交给代理策略组。
Git SSH：HTTP_PROXY 通常不能直接解决
SSH 使用的是独立协议，简单设置 HTTPS_PROXY 往往不会让 [email protected] 自动走代理。如果网络限制了 22 端口，可以考虑通过 SSH 的 ProxyCommand 把连接交给本地代理工具，或者在确认风险和服务端支持的前提下使用 GitHub 提供的替代 SSH 端口。配置完成后，用 ssh -T [email protected] 测试认证与网络；看到认证成功但提示不提供 shell，通常说明连接已经建立，不要把它误认为失败。
SSH 配置要特别注意私钥安全和主机指纹校验。不要为了「先连上再说」而关闭严格主机密钥检查，也不要把私钥内容粘贴到脚本、日志或在线排障工具中。若只是拉取公开仓库，HTTPS 配合代理往往更容易管理；需要频繁提交、签名和多账号操作时，再为 SSH 单独设计稳定的代理链路。
npm、pip 与 Homebrew：分清 registry 和代理
npm 安装失败不一定代表 npm registry 被阻断，也可能是某个依赖通过 GitHub、Release 下载地址或自定义 tarball 获取。先查看实际 registry，再用 curl 单独测试；不要为了追求速度随意切换到来源不明的镜像。公司项目如果有私有 registry，应让私有域名直连或走企业网络，公共 registry 则按团队安全规范决定是否代理。
pip 的情况类似。Python 包索引、源码包、构建依赖和系统证书可能来自不同位置。建议确认 Python、pip 与虚拟环境指向同一套解释器，并检查 pip 是否单独保存了旧代理配置。Homebrew 则同时依赖 Git、下载站点和 GitHub 资源，单纯给某个下载地址设置代理并不能覆盖全部请求。更可靠的做法是让公共域名通过 Clash 规则分流，把公司内部镜像和本地服务明确保留为直连。
什么时候启用 TUN，以及如何验证 Docker
规则分流 + 环境变量适合大多数开发机：请求边界清晰，哪些工具走代理、哪些内网服务直连都能逐项控制。它的不足是某些二进制不读取代理变量，或者 IDE、后台服务与当前 shell 拥有不同的环境。此时可以考虑 Clash 的 TUN 模式，让虚拟网卡和路由层接管更多流量，减少「浏览器正常、某个 CLI 不通」的漏网情况。
启用 TUN 前，先关闭或记录其它 VPN、企业安全客户端、虚拟机网络和 Docker 网络设置。多个程序同时修改路由表、DNS 或虚拟网卡时，可能出现 DNS 泄漏、局域网不可达、容器访问宿主机失败等问题。建议先用规则模式完成基础验证，再只开启 TUN 测试一个目标；如果网络表现变差，应优先回退到可控的环境变量方案，而不是同时修改节点、规则和 DNS。
Docker 是最容易被误判的场景之一。你在宿主机 Terminal 中设置代理，并不一定会影响 Docker daemon；Docker Desktop、Linux 上的 systemd 服务和远程 Docker 主机都可能拥有独立的代理配置。先确认镜像请求到底由哪台机器发起，再在对应的 Docker 设置或服务配置中写入代理。对于私有 registry、局域网镜像仓库和数据库，必须规划好 NO_PROXY，否则容器可能把内部请求错误地送到公共节点。
验证 Docker 时，先用体积较小、来源明确的镜像进行测试，观察 Clash 连接面板是否出现认证域名、registry 域名和内容分发域名。若只看到认证请求而镜像层下载失败，说明问题可能发生在后续 CDN 或规则匹配，而不是账号登录。若完全看不到连接，则检查 Docker daemon 是否使用了宿主机代理、是否运行在虚拟机内，以及 TUN 是否覆盖了该网络命名空间。
建立可重复的开发代理检查清单
稳定的工作流不应依赖「今天突然能用」。每次更换客户端、订阅、节点或公司网络后，都可以按照固定顺序检查：第一，确认 Clash 内核正在运行，混合端口确实处于监听状态；第二，确认当前终端变量、Git 配置和工具配置没有指向旧端口；第三，用 curl 测试一个公共 HTTPS 域名和一个需要直连的内网域名；第四，在连接面板检查目标主机的最终策略；第五，再执行 Git、npm、pip 或 Docker 的最小操作。
如果请求表现为 401、403 或权限拒绝，优先检查令牌、SSH Key、registry 登录状态和仓库权限，不要把所有业务错误都归咎于代理。如果是 ETIMEDOUT、ECONNRESET、TLS 握手失败或连接列表显示错误策略，则重点查看规则、DNS、节点负载和应用是否真正继承了代理。每次只改一个变量，并记录修改前后的连接面板结果，才能在复杂开发环境中快速定位根因。
与只依赖浏览器扩展的方案相比，Clash 的优势在于能够把终端环境变量、规则分流、TUN 接管和连接日志放进同一套可观察的工作流；而一些轻量代理工具往往只能覆盖浏览器，遇到 SSH、Docker daemon 或后台构建任务时就需要额外拼接配置。若你经常在 GitHub、npm、pip、Homebrew 与 Docker 之间切换，Clash Verge Rev 提供的端口管理和策略命中反馈能让排障从「反复重试」变成可验证的工程步骤；相比配置分散、平台支持有限的同类工具，先按本文方式搭好规则与 TUN 的边界，再选择适合自己系统的客户端，会更容易获得稳定且可维护的开发网络体验。