跨境电商 Amazon Shopify

开发者Clash配置：Git、SSH与Homebrew代理工作流指南

Clash Team 2026年9月22日 约15分钟阅读

软件开发者使用 Clash 时，真正需要解决的往往不是浏览器能否打开网页，而是终端里的开发工具是否稳定：GitHub 仓库拉取超时、git push 卡在认证阶段、SSH 连接频繁断开，或者 Homebrew 下载依赖速度极慢。浏览器代理正常，并不代表命令行程序已经正确使用代理，因为 Git、SSH、Homebrew 和包管理器通常各自读取不同的代理配置。

本文以常见的 Clash Verge、Clash Verge Rev、Clash for Windows、ClashX 和 Mihomo 为例，建立一套适合日常开发的代理工作流。你将学会如何确认 Clash 端口、为终端设置临时或永久代理、让 Git 使用 HTTP 或 SOCKS5、通过 SSH 的 ProxyCommand 连接代码托管平台，并为 Homebrew 配置稳定的下载路径。示例默认 Clash 的 HTTP 代理端口为 7890、SOCKS5 端口为 7891，实际使用时请以客户端面板显示的端口为准。

先确认 Clash 端口与基础连通性

配置开发工具之前，第一步不是修改 Git，而是确认 Clash 本身正在运行，并且本机代理端口可以被终端访问。不同客户端的端口名称可能略有区别：Clash Verge 通常在设置或运行状态页显示 HTTP、SOCKS 和混合端口；Mihomo 配置文件中常见字段是 mixed-port、port 与 socks-port。

如果配置了 mixed-port，同一个端口一般可以同时接受 HTTP 代理和 SOCKS5 请求，适合简化终端设置。例如：

确认 Clash 监听端口
mixed-port: 7890      # HTTP 与 SOCKS5 共用
allow-lan: false       # 仅本机使用时更安全
mode: rule
log-level: info

端口确认后，可以用 curl 测试代理是否真的生效。测试时建议同时访问一个国内站点和一个需要代理的开发服务，这样能区分「端口没有监听」与「规则或节点不可用」两类问题。

测试 HTTP 与 SOCKS5 代理
# HTTP 代理测试
curl -I -x http://127.0.0.1:7890 https://github.com

# SOCKS5 代理测试，使用 socks5h 让域名解析也交给代理
curl -I --proxy socks5h://127.0.0.1:7891 https://github.com

# 查看当前 Clash 是否能访问 GitHub API
curl -x http://127.0.0.1:7890 https://api.github.com
优先使用 socks5h 而不是 socks5：socks5h 会把域名解析请求一起交给代理端处理，可以减少本地 DNS 污染或解析失败。若只写 socks5，部分工具可能先在本地解析域名，再把 IP 发给代理。

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

Git、Homebrew、npm、pip、cargo 等命令行工具通常能够读取标准环境变量。最常用的是 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY。其中，HTTPS_PROXY 虽然名称中包含 HTTPS，但它表示「访问 HTTPS 目标时使用的代理」，代理地址本身仍然可以是普通 HTTP 代理。

临时设置适合偶尔使用代理的场景。关闭当前终端窗口后，设置通常会自动失效，不会影响其他程序。

临时启用终端代理
# HTTP 代理方式，适合 Git 和大多数命令行工具
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

# 需要 SOCKS5 时使用 socks5h，支持域名由代理解析
export ALL_PROXY=socks5h://127.0.0.1:7891

# 检查变量是否生效
env | grep -i proxy

如果你长期需要代理，可以将设置写入 shell 配置文件。macOS 和大多数 Linux 发行版的新终端默认使用 zsh，配置文件通常是 ~/.zshrc；使用 Bash 时则可能是 ~/.bashrc。不建议无条件把代理写死在所有环境中，最好用函数控制开关，避免在公司网络、服务器或不需要代理的环境里产生意外影响。

用函数切换终端代理
# 写入 ~/.zshrc 或 ~/.bashrc
proxy_on() {
  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
  echo "Clash proxy enabled"
}

proxy_off() {
  unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
  unset http_proxy https_proxy all_proxy
  echo "Clash proxy disabled"
}

# 重新加载配置
source ~/.zshrc

# 使用
proxy_on
proxy_off

环境变量名称最好同时设置大写和小写版本，因为不同工具的实现并不完全一致。有些程序只读取大写变量，有些程序只读取小写变量。如果发现终端中的某个工具不听从代理设置，可以先检查变量是否存在，再查看该工具自身的代理配置。

Git：HTTP 与代理配置

通过 HTTPS 地址克隆仓库时，Git 可以直接使用 HTTP 代理或 SOCKS5 代理。推荐先使用 Git 自己的配置，而不是只依赖全局环境变量，因为这样可以明确控制 Git 行为，也方便在不同项目之间切换。

为 Git 设置全局代理
# HTTPS 仓库使用 HTTP 代理
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

# 如果客户端支持，也可以使用 SOCKS5
git config --global http.proxy socks5h://127.0.0.1:7891
git config --global https.proxy socks5h://127.0.0.1:7891

# 查看当前 Git 代理
git config --global --get-regexp 'http.*proxy'

如果只希望 GitHub 使用代理，而不希望公司 GitLab、内网代码仓库或国内镜像跟随代理，可以使用按域名匹配的配置。这样可以减少不必要的绕行，也避免内网地址因代理无法访问。

仅让 GitHub 走代理
# 清除全局代理，避免所有 Git 仓库都走代理
git config --global --unset http.proxy
git config --global --unset https.proxy

# 仅对 github.com 生效
git config --global http.https://github.com.proxy http://127.0.0.1:7890
git config --global https.https://github.com.proxy http://127.0.0.1:7890

# 删除按域名配置
git config --global --unset http.https://github.com.proxy
git config --global --unset https.https://github.com.proxy

设置完成后，用 git ls-remote 测试远程仓库比直接执行 git clone 更方便，因为它只读取远程引用，不会先下载完整项目。

  1. 执行 git remote -v，确认仓库地址是 HTTPS 还是 SSH。
  2. 对 HTTPS 仓库执行 git ls-remote https://github.com/组织名/项目名.git。
  3. 如果返回分支和标签列表，说明 Git 的 HTTPS 代理已经生效。
  4. 如果提示认证失败，优先检查 Token、凭据管理器或账户权限，不要把认证问题误判为代理问题。
不要把 Token 写进代理 URL：命令行历史、Git 配置和日志可能记录完整 URL。GitHub 推荐使用凭据管理器或 SSH 密钥；如果必须使用访问令牌，也应通过安全的凭据存储进行管理。

SSH 仓库的代理与 ProxyCommand

很多开发者发现浏览器和 HTTPS Git 都能使用，但 SSH 地址仍然连接超时。原因是 SSH 不会自动读取 Git 的 HTTP 代理配置。对于 [email protected]:组织名/项目名.git 这类地址，需要在 SSH 配置中明确指定代理命令。

Clash 通常不会直接提供一个名为「SSH 代理」的独立开关，而是通过 SOCKS5 端口转发 SSH TCP 连接。OpenSSH 自带的 nc 或系统中的 netcat 可以作为中间程序；不同系统的参数略有差异，macOS、Linux 和较新的 Windows OpenSSH 通常可以使用以下写法。

~/.ssh/config 配置 GitHub SSH 代理
# GitHub SSH over Clash SOCKS5
Host: github.com
    HostName: github.com
    User: git
    Port: 22
    ProxyCommand: nc -x 127.0.0.1:7891 %h %p
    IdentityFile: ~/.ssh/id_ed25519
    IdentitiesOnly: yes

其中，%h 会被替换为目标主机名，%p 会被替换为目标端口。IdentitiesOnly yes 可以避免 SSH 代理一次尝试过多密钥，减少出现 Too many authentication failures 的概率。如果你的系统中没有支持 -x 参数的 netcat，可以安装兼容版本，或改用 Python、connect-proxy 等本地转发工具。

配置完成后，先不要直接推送代码，使用详细日志测试连接：

测试 SSH 代理链路
# 查看 SSH 详细连接过程
ssh -vT [email protected]

# 查看当前仓库使用的远程地址
git remote -v

# 测试仓库远程引用
git ls-remote [email protected]:组织名/项目名.git

如果日志显示连接已经建立，但随后提示权限拒绝，说明代理链路大概率正常，问题转向 SSH 密钥或 GitHub 账户授权。可以使用 ssh-add -l 查看当前已加载的密钥，并检查公钥是否已经添加到代码托管平台。相反，如果日志停留在连接阶段并持续超时，则应检查 SOCKS5 端口、Clash 规则和节点可用性。

Homebrew 与依赖管理工具

Homebrew 的访问通常包含两类请求：访问 Git 仓库获取 Formula、Cask 元数据，以及从镜像或 GitHub Releases 下载实际软件包。只设置一个环境变量并不一定覆盖所有请求，因此建议先让终端代理正常工作，再根据下载日志判断具体失败环节。

在 macOS 或 Linux 上，Homebrew 通常会读取终端中的 http_proxy、https_proxy 和 all_proxy。可以先用代理函数启用环境，再执行更新或安装：

通过终端代理运行 Homebrew
# 同时设置大小写变量，兼容不同工具
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

# 检查 Homebrew 环境和仓库状态
brew config
brew doctor

# 更新索引并安装软件
brew update
brew install wget

如果 Homebrew 报错来自 Git 操作，可以检查 Homebrew 仓库地址和 Git 代理配置；如果 Git 操作成功但二进制下载失败，则可能是下载域名没有命中代理规则，或当前节点不适合大文件传输。建议在 Clash 的连接面板中观察实际请求域名，再为相关域名调整规则，而不是盲目让所有流量都走代理。

同一套终端代理也可以服务其他开发工具，但每个工具的配置方式仍有差异：

  • npm：使用 npm config set proxy 和 npm config set https-proxy，也可以读取环境变量。
  • pnpm：通常继承 npm 配置，但应通过 pnpm config get proxy 确认实际值。
  • pip：可以使用 --proxy 参数或 pip.ini、pip.conf 配置。
  • cargo：一般读取系统代理变量，也可以在 ~/.cargo/config.toml 中单独指定。
  • Docker：Docker 守护进程与当前 shell 是两个环境，终端变量不会自动传递给后台服务，需要单独配置 daemon 代理。

规则分流与常见故障排查

开发者代理不应该简单理解为「所有流量都走代理」。更合理的方式是让 GitHub、GitLab、代码发布平台和必要的依赖下载域名走代理，国内镜像、局域网地址和公司内部服务直连。这样可以降低延迟、节省节点带宽，也减少访问内网服务时的路由冲突。

可以在 Clash 配置中为常见开发平台增加域名规则，并将它们放在通用规则之前。策略组名称需要替换为你自己的实际名称。

开发场景的分流规则示例
rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  - DOMAIN-SUFFIX,githubassets.com,PROXY
  - DOMAIN-SUFFIX,gitlab.com,PROXY
  - DOMAIN-SUFFIX,github.io,PROXY
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

排查时可以按照「端口、环境变量、工具配置、规则、认证」的顺序进行，不要一次修改多个地方。下面是最常见的故障与处理方向：

  • curl 连接拒绝：通常表示端口错误、Clash 未启动，或客户端只监听了其他端口。先在面板确认 HTTP、SOCKS5 或混合端口。
  • 浏览器正常但 Git 不通：浏览器可能使用了系统代理或 TUN 模式，而终端没有代理变量。执行 env | grep -i proxy 并检查 Git 配置。
  • HTTPS Git 可以用但 SSH 不通：Git 的 HTTP 代理不会作用于 SSH，需要在 ~/.ssh/config 中添加 ProxyCommand。
  • SSH 报认证失败：检查密钥路径、公钥授权和 ssh-add 状态。代理连接成功不等于账户认证成功。
  • Homebrew 更新成功但安装下载失败：观察失败 URL，确认该域名是否命中代理规则，并检查节点是否支持稳定的大文件传输。
  • 内网 GitLab 无法访问：检查是否错误地设置了全局代理，必要时清除 Git 全局代理，改用按域名配置。
  • 切换网络后配置失效：确认 Clash 的系统代理、TUN 模式和终端代理是否重复启用。多层代理可能导致连接循环或延迟增加。
推荐的验证顺序：先用 curl 验证代理端口，再用 git ls-remote 验证 Git，最后用 ssh -vT 验证 SSH。每一步只验证一个环节，定位问题会比直接反复执行 git clone 更快。

完成配置后，建议把个人开发环境整理成一份可迁移的清单：记录 Clash 的 HTTP 和 SOCKS5 端口、终端开关函数、Git 的全局或按域名代理、SSH 配置中的密钥路径，以及需要直连的内网域名。这样即使更换客户端或电脑，也只需要替换端口和节点名称，不必重新摸索整套工作流。对于团队环境，则应避免把个人代理地址、密钥和包含敏感信息的配置提交到仓库中。

Clash 在开发场景中的价值，不只是让某个网页加载更快，而是把 Git、SSH、Homebrew 和各种依赖工具纳入统一、可观察、可切换的网络路径。先确认端口，再选择合适的协议；让 HTTPS 工具使用 Git 或环境变量代理，让 SSH 通过 SOCKS5 的 ProxyCommand 转发，同时用规则把外网开发平台与内网服务合理分流，就能在稳定性、安全性和速度之间取得更好的平衡。

立即开始

用 Clash 掌控你的流量

支持 Windows、macOS、Linux、Android 与 iOS，灵活规则，开箱即用。

免费下载 查看设置指南 →
立即开始

用 Clash 掌控你的流量

支持 Windows、macOS、Linux、Android 与 iOS，灵活规则，开箱即用。

免费下载 查看设置指南 →
下载 Clash
全平台支持，一键流量控制，无需复杂配置
免费下载