开发者Clash配置：Git、SSH与Homebrew全链路代理指南

开发者为什么需要单独设计 Clash 代理链路

对开发者来说，网络问题往往不是「网页打不开」这么简单，而是分散在代码拉取、依赖安装、远程登录、镜像下载和接口调用等多个环节。浏览器能够打开 GitHub，并不代表终端里的 git clone、git push、ssh 或 brew install 也能稳定完成。原因在于这些程序通常拥有各自的 DNS 解析、代理识别和 TLS 连接逻辑，有些读取系统代理，有些只读取环境变量，还有些只支持 SOCKS5 或完全不识别图形客户端设置。

因此，开发者配置 Clash 时，不建议一开始就把所有流量切换成全局代理。更可维护的方式是把工作流拆成几类：GitHub、代码托管平台和容器镜像属于开发服务；Homebrew、npm、pip 等属于包管理服务；SSH 则是独立的 TCP 连接；企业内网、局域网和国内镜像通常应继续直连。这样既能减少不必要的代理流量，也能在出现问题时通过 Clash 日志快速判断是规则未命中、终端没有使用代理、DNS 解析异常，还是节点本身不可用。

本文以 Clash Verge、Clash Verge Rev、Mihomo 以及其他能够提供 HTTP、SOCKS5 或 mixed-port 的客户端为背景。不同客户端的菜单名称可能不同，但核心思路一致：由 Clash 负责规则分流与节点选择，由 Git、SSH 和终端工具负责明确使用哪个本地代理入口。macOS 与 Windows 的命令写法会有所差异，配置完成后都应使用最小化测试逐层验证，不要直接用一次大型项目拉取来判断整个链路是否正常。

GitHub 与代码托管平台的分流规则

Git 的常见访问并不只有一个域名。通过 HTTPS 拉取仓库时，通常会访问 github.com、api.github.com 以及用于对象存储、发布附件或静态资源的其他主机；通过 SSH 拉取时，连接目标通常是 github.com 的 22 端口，但也可能改用 443 端口。GitLab、Bitbucket、企业代码平台则使用不同的域名体系。只给网页主域写规则，可能导致仓库页面可以打开，但 Release 附件、子模块或 API 请求仍然直连。

对公开平台而言，可以把明确使用的域名后缀放入同一个策略组，例如命名为 DEV_GIT。规则优先使用 DOMAIN-SUFFIX，而不是过于宽泛的关键词匹配。假设你只使用 GitHub，规则可以围绕 github.com、githubusercontent.com 和实际日志中出现的资源域名逐步补充；如果还使用 GitLab，则单独加入 gitlab.com，不要因为「都是代码托管」就默认它们共享所有基础设施。

规则顺序同样重要。自定义 GitHub 规则应放在过于宽泛的广告、地域或直连规则之前，但局域网、回环地址和明确的内网域名通常仍要优先直连。对于 Mihomo 配置，可以使用类似下面的说明性片段，策略组名称必须替换成你当前配置中真实存在的名称：

Git 服务分流示例

rules:
  - DOMAIN-SUFFIX,github.com,DEV_GIT
  - DOMAIN-SUFFIX,githubusercontent.com,DEV_GIT
  - DOMAIN-SUFFIX,gitlab.com,DEV_GIT
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

这段内容不是可以直接覆盖订阅配置的完整文件，而是帮助你理解规则位置。订阅更新后，本地手写规则可能被覆盖，因此应确认客户端是否支持配置覆写、规则追加或本地配置合并。每次修改后，先在 Clash 的连接面板中过滤 github、gitlab 等关键词，确认请求命中了预期策略组，再执行完整的仓库操作。

Git HTTPS 代理：配置、验证与清理

如果远程仓库地址是 https://github.com/user/project.git，Git 会通过 HTTP 或 HTTPS 客户端发起连接。最直接的做法是为 Git 配置本地 HTTP 代理，例如 Clash 的 mixed-port 或 HTTP 端口。macOS、Linux 与 Windows PowerShell 的环境变量写法不同，但 Git 自身的配置命令可以跨平台使用。需要注意的是，端口必须以你的 Clash 设置为准，不能机械照抄常见的 7890 或 7897。

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|https\..*proxy'

配置后可以先执行一个轻量操作，例如查看远程地址、读取公开仓库的引用，或者使用 git ls-remote 测试，而不是立即下载几百兆的历史记录。若 Clash 日志没有任何对应连接，说明 Git 配置没有生效、命令实际调用了另一个 Git 二进制，或者代理地址与端口填写错误。若日志出现连接但仍失败，则继续检查策略组、TLS 错误、节点可用性和目标域名是否完整。

对公司内网仓库，不建议无条件使用全局代理。可以针对某个域名设置独立规则，或者使用 Git 的按主机配置，让公网 GitHub 走代理、内部 GitLab 走直连。示例中的 insteadOf 适合处理远程地址统一改写，但它会改变 Git 看到的 URL，团队协作时要记录清楚，避免把本地临时设置误提交到项目文档。

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

最后一组命令用于清理全局代理。很多「关闭 Clash 后 Git 仍然报错」的问题，根源就是代理地址已经写入 ~/.gitconfig，而不是 Clash 仍在运行。排障时应同时检查 Git 配置、Shell 环境变量和系统代理，三者只要有一处残留，就可能造成表面上难以解释的行为。

SSH 推送失败：22 端口、443 端口与 SOCKS5

SSH 与 HTTPS 最大的区别，是它不是普通的网页请求。Git 的 SSH 远程地址通常类似 [email protected]:team/project.git，连接目标是 TCP 22 端口。许多网络环境会限制或丢弃 22 端口，即使浏览器和 HTTPS Git 都正常，git push 仍可能停在连接阶段。此时首先运行 ssh -T 或带详细日志的 SSH 命令，观察是否真的到达远端，而不是反复更换 GitHub 账号密钥。

在支持 SSH over 443 的代码托管平台上，可以在 SSH 配置中把主机映射到 443 端口。对于 GitHub，常见思路是使用其 SSH 443 入口；但具体域名、认证策略和企业平台能力应以目标服务的官方文档为准。端口改成 443 只能绕过部分网络限制，并不会自动让 SSH 通过 Clash。Clash 仍需要接收这条 TCP 连接，或者由 SSH 调用本地 SOCKS5 代理。

SSH 使用本地 SOCKS5 的示例

Host github.com
    HostName ssh.github.com
    Port 443
    User git
    ProxyCommand nc -x 127.0.0.1:7891 -X 5 %h %p

上面的 nc 参数只适用于支持 SOCKS5 代理选项的 netcat 版本。macOS 自带工具、Homebrew 安装的新版工具以及 Windows 环境中的 OpenSSH 组件，参数可能不同。Windows 用户也可以使用支持 SOCKS5 的辅助程序，或在 Mihomo 中启用 TUN，让 SSH 作为普通系统 TCP 流量被接管。不要看到命令报错就直接认定密钥错误，先用 ssh -vvv 区分「无法连接代理」「无法连接远端」和「远端拒绝认证」。

如果使用 Clash 的 TUN 模式处理 SSH，需要留意路由冲突、管理员权限和企业 VPN。TUN 能覆盖不读取环境变量的程序，但它也会扩大接管范围，可能让内网 Git、数据库或远程办公系统误走代理。更稳妥的做法是先使用显式的 SSH 代理配置验证链路，再决定是否需要 TUN。验证通过后执行一次小分支推送，并在 Clash 日志中确认目标主机、端口和策略组都符合预期。

Homebrew、终端环境变量与依赖下载

Homebrew 的操作至少包含两类请求：一类是访问 Homebrew 自身的 API、Formula 或 Cask 元数据，另一类是从源码仓库、GitHub Release 或镜像 CDN 下载实际文件。即使 brew update 成功，后续安装二进制仍可能因为另一个下载主机直连而失败。因此排障时要分别观察元数据请求和文件下载请求，不能只测试一个域名。

对 macOS 和 Linux，临时环境变量是比较清晰的验证方式。若 Clash 提供 HTTP mixed-port，可以先在当前 Shell 中设置 HTTP_PROXY、HTTPS_PROXY 和小写变体；如果要让支持 SOCKS5 的程序使用代理，再设置 ALL_PROXY。这些变量只影响当前 Shell 及其子进程，关闭终端后通常不会继续存在，适合确认问题是否确实来自代理路径。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
brew update
brew install wget

Windows PowerShell 可以使用 $env:HTTP_PROXY 和 $env:HTTPS_PROXY 设置当前会话变量。若在 Windows Terminal、Git Bash、PowerShell 和 IDE 集成终端之间切换，要分别确认变量是否继承，因为它们未必使用同一份启动配置。IDE 内置终端还可能由图形程序启动，环境变量与系统登录时的状态不同，出现「独立终端可用、IDE 里失败」并不罕见。

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
brew update

如果 Homebrew 仍然失败，先执行 env | grep -i proxy 或 Windows 对应的环境变量查看命令，排除旧端口、错误协议和不可达地址。然后在 Clash 日志中搜索实际失败的主机。若请求没有出现，说明 Homebrew 可能使用了自己的下载器、代理变量名称不匹配，或者流量被 DNS 与网络栈提前拦截；若请求出现但命中 DIRECT，则应调整规则；若命中代理后返回 403 或校验失败，则要进一步检查镜像、缓存和文件完整性，不要简单重复下载。

跨平台排错清单与长期维护方式

一套可复用的排错顺序应该从「进程是否发出请求」开始，而不是先换节点。第一步确认 Clash 核心正在运行，本地端口确实监听，并且客户端当前加载的是你正在编辑的配置。第二步用浏览器或简单命令测试本地代理入口。第三步让 Git、SSH、Homebrew 分别发起一次最小请求，同时观察连接日志。第四步核对规则命中结果和实际策略组。只有在请求已经命中正确策略、但握手或传输仍失败时，才值得重点检查节点质量、协议兼容和远端服务状态。

长期维护时，建议把端口、策略组和规则意图写进团队内部的开发环境说明，但不要把个人节点、订阅地址或带认证信息的配置提交到 Git 仓库。对于个人电脑，可以保留一份不含敏感信息的检查表：Clash mixed-port 是多少、HTTP 与 SOCKS5 分别是什么、Git 是否设置代理、SSH 是否使用 443、Homebrew 是否依赖环境变量。每次升级客户端、切换内核或更换网络环境后，按这份清单复核，通常比重新安装所有开发工具更快。

最后还要注意安全边界：代理配置可能影响依赖下载和代码上传，企业环境应遵守出口审计、密钥管理和软件供应链政策；不要为了让命令成功而关闭 TLS 校验、跳过包签名或使用来源不明的镜像。Clash 的连接日志用于定位路由，不应被当作保存访问令牌的地方。确认规则稳定后，可以把不需要代理的内网域名、私有网段和本地开发服务明确设置为直连，减少误路由和隐私暴露。

相比只提供系统代理开关的轻量工具，单独为 Git、SSH 和 Homebrew 手写代理往往缺少统一日志、规则分流和跨应用接管能力；而只依赖全局 VPN 又容易让内网仓库、私有镜像和本地服务走错出口。Clash V.CORE 可以把域名规则、HTTP/SOCKS5 入口、TUN 接管与连接日志放在同一套工作流中，既方便开发者按工具排错，也能保留国内镜像和企业网络的直连策略。如果你希望把这套开发者代理链路落地到 macOS 或 Windows，建议先前往下载，再按照本文的最小测试顺序逐项启用。