开发者在浏览器里能打开代码托管平台，不代表终端里的 git、npm、pip 和 Docker 就会自动走代理。命令行工具可能不读取系统代理设置，SSH 又使用独立的传输协议；Docker CLI、Docker daemon 与构建容器也可能各自拥有不同的网络出口。结果往往是网页正常、依赖安装超时、镜像拉取失败，或公司内网地址被误送到代理节点。本文以 Clash Verge Rev 和 Mihomo 内核为例，梳理终端代理的设置顺序，说明如何用环境变量、规则分流与可选 TUN 模式覆盖常见开发工作流，并通过连接记录逐项验证流量实际走向。

先记住一个实用原则：代理变量决定应用如何连接代理，Clash 规则决定代理连接最终走哪个策略。只设置环境变量并不意味着所有目标都会走代理；只开启 TUN 也不能保证规则判断正确。建议先确认端口和基础连接，再逐个配置工具，最后才考虑扩大接管范围。示例中的端口均为常见值，请以客户端「设置」或「端口」页面实际显示的 mixed-port、HTTP 端口和 SOCKS 端口为准。

先确认 Clash 端口与终端代理范围

Clash Verge Rev 通常可以开启系统代理，并提供 HTTP、SOCKS 或 mixed-port 监听端口。mixed-port 允许同一个端口接收常见 HTTP 代理与 SOCKS 请求，便于为终端设置统一入口。常见示例是 127.0.0.1:7890，但不同配置可能使用其他端口；不要因为命令能执行就假设端口正确，应先在客户端设置中核对监听地址与端口。

在 macOS、Linux 或 WSL 的 shell 中，可在当前会话临时设置代理变量：

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
export NO_PROXY=localhost,127.0.0.1,::1,.公司内网域名

HTTP_PROXY 和 HTTPS_PROXY 应填写客户端接受 HTTP CONNECT 的代理端口；ALL_PROXY 则适用于支持 SOCKS 的程序。SOCKS 端口要以实际配置为准，socks5h 中的 h 表示域名解析也通过代理进行，具体是否支持取决于工具所用的网络库。环境变量名称的大小写兼容性因程序而异；若某个工具仍不认代理，可检查其文档是否要求小写的 https_proxy。

NO_PROXY 用于排除不应经过代理的地址，至少应考虑本机回环地址、开发服务器域名、内网 Git 主机和企业制品库。域名后缀的匹配方式并非所有客户端都完全相同，CIDR 网段支持也因工具而异；不要直接把一整段内网地址写进去后就认为所有应用都会理解。可先从明确的主机名开始，再针对实际使用的工具测试。

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:7891"
$env:NO_PROXY = "localhost,127.0.0.1,::1,.公司内网域名"

这种设置关闭终端后就会失效，适合先验证再决定是否写入 shell 配置文件。长期使用时，可以把代理命令收在单独的脚本或环境文件中，需要时再加载；这样切换公司网络、访问内网或排查直连问题时，不必反复编辑多个配置。还要注意，从桌面菜单启动的 IDE、登录后自动运行的任务与手动打开的终端不一定共享同一组环境变量。

先做最小测试：在准备运行开发命令的同一个终端执行 env | grep -i proxy，确认变量确实存在；然后通过客户端连接面板观察一次外部 HTTPS 请求。若面板没有对应连接，先检查程序是否支持代理变量、端口是否正确，以及进程是否在另一个容器或虚拟机里。

Git HTTPS 与 SSH：两种传输方式分别设置

Git 使用 HTTPS 克隆或推送时，常见 Git for Windows、macOS 与 Linux 构建通常可以使用代理环境变量，但也可能受到 Git 自身配置或凭据管理器的影响。先在当前会话设置 HTTPS_PROXY，再执行一次不会修改远端内容的读取操作，并在 Clash 连接面板确认目标主机命中预期策略。若代理变量被其他进程继承，Git 也可能继续使用旧端口；重启终端或 IDE 后再复测，能够排除环境残留。

不要为了让一个 HTTPS 仓库可用，就把全局 Git 代理永久写成所有仓库共用的固定值。全局配置容易让公司内部 Git、局域网自建服务也被代理；而代理地址改变后，Git 可能仍指向失效端口。若确有固定需求，应考虑按仓库或主机范围配置，并记录如何撤销。用 git config --show-origin --get-regexp 'http\\..*proxy|https\\..*proxy' 检查来源，再用 git config --global --unset http.proxy 等命令清除不再需要的配置；执行前确认配置作用域，避免误删团队共享设置。

Git SSH 与 HTTPS 不同：HTTPS_PROXY 通常不会自动代理原生 SSH 连接。若仓库地址是 git@主机:组织/项目.git，可选择继续使用直连、通过 Clash SOCKS 端口配置 SSH 的代理命令，或改用服务商支持的 HTTPS 克隆方式。通过 SSH 代理时，配置应限定在目标主机，避免把所有 SSH 服务器都送往同一出口。例如，在 ~/.ssh/config 的对应 Host 段设置受支持的 SOCKS 转发命令，并将端口替换成 Clash 实际 SOCKS 端口。

Host code.example.com
    HostName code.example.com
    User git
    ProxyCommand nc -x 127.0.0.1:7891 -X 5 %h %p

这里的 nc 选项依赖系统所带的 netcat 实现，不同 macOS、Linux 发行版或 Windows 环境的参数可能不同；应先确认本机 nc 支持 SOCKS5，再使用该写法。验证顺序建议是先运行 ssh -T [email protected]，确认 SSH 握手和主机密钥提示正常，再执行 Git 操作。若只得到权限拒绝，应转查 SSH 密钥与账号权限；若连接超时，则查看 Clash 是否记录了对应主机及所选策略。切勿用关闭主机密钥检查的方式解决网络问题。

npm 与 pip：代理变量、注册表和证书要分开排查

Node.js 生态中的 npm、部分包管理器和依赖下载库会读取代理环境变量，但行为可能随版本和所用 HTTP 客户端而变化。先设置 HTTPS_PROXY 并执行一次普通的包元数据查询；若连接面板显示代理命中而请求仍失败，检查错误是否来自注册表认证、证书链、限流或依赖包本身。网络代理可以建立通路，但不能修复错误的 registry 地址、过期令牌或包版本冲突。

也可以在 npm 配置中指定代理，但这会使代理设置持久化在用户或项目配置中。团队项目通常不应把个人机器的 127.0.0.1 代理地址提交到仓库；否则其他开发者和 CI 运行器可能无法安装依赖。修改前用 npm config get proxy 与 npm config get https-proxy 查看当前值，完成后在同一台机器上检查结果。若公司使用内部 npm registry，应确保其域名通过 NO_PROXY 或 Clash 的直连规则保留在内网路径，避免凭据或私有包请求绕行不必要的出口。

pip 常见安装请求也可通过代理环境变量转发。使用虚拟环境时，注意环境变量通常由启动该环境的 shell 继承；若安装命令由 IDE、任务调度器或 CI 执行，单独在交互式终端导出变量并不能证明那个进程也有相同设置。安装速度慢时，可分别确认 DNS 解析、TLS 连接和 Python 包索引地址，不要一开始就关闭 TLS 证书验证。对内部 PyPI 镜像，应检查索引 URL、认证方式及其是否应走直连，避免把内部访问问题误归因于外部节点。

npm 与 pip 的镜像选择属于仓库配置，代理属于网络传输路径，二者可以同时存在，但作用不同。切换镜像能改变请求目标，却不能保证目标地址可达；设置代理能改变连接出口，却不会自动把公共仓库替换成公司镜像。排障时一次只改一项：先确认索引地址，再看 Clash 连接记录，最后判断是否需要修改代理或分流规则。若不同项目使用不同 registry，优先使用项目或虚拟环境范围的设置，减少全局配置对其他工作区的影响。

Docker：区分 CLI、daemon、构建与容器运行时

Docker 最容易出现「终端已经有代理，镜像还是拉不下来」的情况，因为发起外网请求的未必是当前 shell 里的 Docker CLI。docker pull 的镜像下载通常由 Docker daemon 完成；在 Docker Desktop 中，daemon 位于虚拟化环境内，桌面系统的代理设置、Clash TUN 和终端环境变量之间并非简单的一对一关系。先根据 Docker Desktop 的代理设置和当前网络模式确认 daemon 如何出站，再看 Clash 连接面板里是否出现镜像仓库域名，而不是只检查 CLI 的环境变量。

docker build 又多一层：构建步骤运行在 BuildKit 或构建容器中。即使 daemon 能拉取基础镜像，构建阶段运行的 npm install 或 pip install 也可能没有代理；反过来，把代理变量传入构建环境，也不代表 daemon 拉镜像的请求会使用同一设置。仅在确有需要时通过构建参数或受支持的 BuildKit 配置传递代理，并避免把代理凭据写入镜像层、构建日志或最终镜像环境变量。完成后检查镜像历史与容器配置，确认没有留下敏感的代理地址或认证信息。

容器运行时的代理则是另一项配置。容器内的程序不会必然继承宿主机 shell 的变量；可在运行容器时显式传入适用环境变量，或通过镜像与编排平台的专用配置管理。与此同时，容器访问宿主机服务时要特别留意 localhost 的含义：容器中的 127.0.0.1 指向容器自身，不是宿主机上的 Clash。Docker Desktop、Linux Docker Engine 和 Kubernetes 的宿主机访问方式各有差异，不能把一个系统上的地址照搬到另一个系统。

如果使用 TUN 模式测试 Docker，请分步骤验证：先确认宿主机自身能否通过代理访问仓库，再检查 daemon 所在网络环境，最后检查构建或容器内的请求。Linux 上还要考虑 Docker 网桥、转发规则与防火墙；Windows 和 macOS 上则要考虑 Docker Desktop 的虚拟网络路径。出现 DNS 失败时，区分容器 DNS、Docker daemon DNS 与 Clash DNS 设置；只看到「拉取失败」不足以判断是节点问题。错误若明确是认证拒绝或镜像仓库不存在，应回到凭据和镜像名称排查。

Clash 规则分流与 TUN：从可控方案逐步扩大范围

开发机日常优先采用规则模式加显式代理变量：需要代理的公共服务按域名进入代理策略组，国内公共服务、公司内网 Git、内部制品库及本地开发地址则保留直连。规则写入位置取决于配置来源；如果订阅会定期更新，不要直接改一个稍后会被覆盖的生成文件，应使用客户端支持的覆写、规则集或自定义配置入口。规则顺序也很重要：过早匹配的宽泛规则可能抢先命中，让你后面添加的精确条目看起来「存在却不起作用」。

可从连接面板中记录实际目标域名，并核对连接主机、进程（若客户端能显示）、最终策略和节点。如果 Git 主机显示为 DIRECT，而你预期它走代理，先检查域名规则与规则顺序；如果显示为代理策略但访问仍超时，再测试节点或远端服务。不要仅凭 IP 地址判断域名规则，因为 CDN、域名解析方式和连接嗅探都会影响匹配结果。对于内网地址，则要确认解析结果、路由和规则都符合公司网络要求。

TUN 模式通过虚拟网络接口接管更多应用流量，适合不读取代理环境变量的二进制、部分桌面工具，或希望减少漏配的场景。它不是所有终端问题的万能修复：TUN 下流量仍受路由与规则策略影响，错误规则照样可能把请求送错出口。启用前先阅读客户端权限提示，确保与系统 VPN、企业安全代理、虚拟机网卡和其他 VPN 客户端没有冲突；在受管理的工作设备上，还应遵守组织的网络政策。

建议用小范围验证代替一次性「全开」：先在规则模式下测试一个公共 HTTPS 服务和一个内网地址；再开启 TUN，分别观察这两个目标的连接记录和访问结果。确认 TUN 能补上确实漏掉的流量后，再将它纳入日常配置。若启用后本地开发服务器、数据库或容器网络不可达，先临时关闭 TUN 对照，再检查 DNS、路由与绕过列表；不要同时更改 DNS、规则和系统代理，否则很难知道是哪项变化引起故障。

每次修改后都应保留一组可重复的检查项：外部 HTTPS 请求是否进入预期策略组；内网 Git 和制品库是否保持原有路径；localhost、容器网桥和本地开发端口是否仍可访问；关闭 Clash 后相关命令是否能按预期恢复直连或明确失败。可把当前配置、端口、环境变量来源和常见测试命令记在个人开发文档中。出现问题时先清除过期的 Git 或包管理器代理配置，再重新打开一个干净终端测试，通常比反复重装客户端更快找到原因。

常见问题

开启 Clash 系统代理后，终端还需要设置环境变量吗？

不一定，但很多 CLI 和 SDK 不会自动读取操作系统的系统代理设置。先在目标终端查看代理环境变量，并通过 Clash 连接面板确认请求是否进入内核。如果连接列表没有该请求，可先为当前 shell 设置 HTTPS_PROXY 再测试；如果已经命中正确策略，就不必重复叠加多种代理配置。

设置了 HTTPS_PROXY，为什么 Git SSH 仍然超时？

SSH 与 HTTPS 是不同的连接方式，HTTPS_PROXY 通常只影响使用 HTTP 代理的客户端，不会自动转发原生 SSH。请确认仓库 URL 是 HTTPS 还是 SSH；SSH 场景应按需为对应主机配置 SOCKS 代理命令，或者使用服务商支持的 HTTPS 仓库地址，并分别检查密钥权限与网络连通性。

Docker 拉取镜像失败，但 curl 能通过代理访问外网，怎么办？

先确认请求由哪个组件发起。镜像拉取通常由 Docker daemon 负责，构建步骤与容器内程序则可能各有一套代理环境；宿主机 curl 成功并不能证明这些组件使用相同网络。检查 Docker Desktop 或 Docker Engine 的代理设置、daemon 日志与 Clash 连接记录，再根据失败发生在拉取、构建还是运行阶段逐项处理。

公司内网地址应该加入 NO_PROXY，还是写 Clash 直连规则？

两者解决的层次不同。NO_PROXY 让支持该变量的应用绕过显式 HTTP 代理；Clash 直连规则则决定已经进入 Clash 的连接使用哪种策略。若连接由 TUN 接管，环境变量可能不起作用，因此内网域名和地址通常还应在 Clash 规则中明确保持直连，并用实际连接记录验证。

只依赖各工具自身的代理配置时，Git、包管理器和 Docker 往往需要分别设置，升级或切换运行环境后也容易遗漏；而只开启全局 TUN，又可能让内网仓库、本地服务和容器网络受到不必要影响。Clash 的规则分流、连接记录与可选 TUN 可以把出口选择集中管理，再配合工具级代理变量补齐应用差异。若你希望按自己的终端工作流逐步验证这些设置，可以从适用于当前系统的 Clash 客户端开始。

前往下载 →