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

先分清 Git、SSH 与 Clash 的代理边界

开发者遇到 GitHub 访问超时、git clone 下载缓慢或 SSH 推送失败时，通常不是“Clash 没有代理”这么简单。Git 的 HTTPS 和 SSH 是两条不同的连接路径：使用 https://github.com/... 时，Git 会通过 HTTP 客户端发起 HTTPS 请求；使用 [email protected]:... 时，Git 会调用本机的 OpenSSH，通过 TCP 连接远程服务器的 22 端口。Clash 的系统代理、命令行环境变量、Git 配置和 SSH 配置，也分别作用在不同层级。

因此，排查时应先确认仓库地址类型，再决定配置方法。浏览器能打开 GitHub，只能说明浏览器使用的代理有效，并不能证明终端、Git 或 SSH 会自动沿用同一代理。反过来，终端能够执行 git fetch，也不代表所有软件包管理器都已经走代理。

配置 Clash 的命令行代理基础

对 Git、curl、npm、pip 等命令行工具而言，最稳定的第一步是让 Clash 内核监听本机代理端口，并在当前终端会话中显式设置代理变量。HTTP 代理适合处理 HTTPS 请求，因为客户端会向 HTTP 代理发送 CONNECT 请求；SOCKS5 代理则适合支持 SOCKS 协议的程序。

mixed-port: 7890
socks-port: 7891
allow-lan: false
mode: rule
log-level: info

在 macOS、Linux 或 WSL 中，可以按当前 Shell 设置环境变量。使用 socks5h 时，域名解析也交给 SOCKS 代理处理，能够减少本地 DNS 解析错误；如果使用 socks5，部分工具可能先在本机解析域名。

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

curl -I --connect-timeout 10 https://github.com
env | grep -i proxy

Windows PowerShell 使用不同的变量写法：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7891"
$env:NO_PROXY="localhost,127.0.0.1"

curl.exe -I --connect-timeout 10 https://github.com

环境变量只对当前终端进程及其子进程生效。重新打开终端后，如果没有写入 Shell 配置文件或 PowerShell 配置，变量就会消失。也不建议把带有代理账号和密码的完整 URL 长期写入公共配置，因为终端历史、进程列表和诊断日志都可能暴露凭据。

按层测试代理是否生效

1. 在 Clash 客户端中确认内核正在运行，并查看本机监听端口。
2. 使用 curl -I https://github.com 测试 HTTPS 代理是否可达。
3. 使用 curl --socks5-hostname 127.0.0.1:7891 -I https://github.com 单独测试 SOCKS5。
4. 在 Clash 连接记录中确认请求确实出现，而不是被系统直连。
5. 最后再执行 git ls-remote，区分 Git 自身配置与普通 curl 的差异。

curl -x http://127.0.0.1:7890 -I https://github.com
curl --socks5-hostname 127.0.0.1:7891 -I https://github.com
git ls-remote https://github.com/example/project.git

为 Git HTTPS 配置代理与分流

如果仓库使用 HTTPS，可以直接为 Git 设置 http.proxy。虽然配置项名称是 http.proxy，它同样会影响通过 HTTPS 访问的 Git 远程地址。推荐先使用命令级参数验证，再决定是否写入全局配置。

git -c http.proxy=http://127.0.0.1:7890 \
  ls-remote https://github.com/example/project.git

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

如果只希望 GitHub 走 Clash，而公司 GitLab、局域网代码服务器或内部域名保持直连，可以使用按主机匹配的配置。Git 支持通过 URL 匹配规则覆盖默认设置，配置后应使用 git config --show-origin --get-regexp 'http.*proxy|url.*insteadOf' 检查最终来源。

git config --global http.proxy ""
git config --global https.proxy ""

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

不同 Git 版本对带协议和路径的键解析略有差异。更容易维护的方式，是把代理写入环境变量，再通过 Git 的 URL 作用域或单次命令测试。若全局代理导致公司仓库无法访问，可对特定域名设置空代理，或直接删除全局配置：

git config --global --unset http.proxy
git config --global --unset https.proxy

git config --global http.https://git.example.com.proxy ""

凭据、证书与下载速度问题

Git 连接超时与身份验证失败是两类不同问题。代理建立成功后，如果返回 401、403 或要求输入凭据，应检查令牌、SSH 密钥或凭据管理器，而不是不断更换 Clash 节点。GitHub 已不再接受账户密码作为 Git HTTPS 的常规认证方式，通常需要个人访问令牌或系统凭据管理器。

不要为了绕过代理证书提示而执行 git config --global http.sslVerify false。这会关闭所有 Git HTTPS 证书校验，扩大中间人攻击风险。若企业网络使用合法的 TLS 检查设备，应按照组织提供的根证书配置 http.sslCAInfo，并确认代理本身没有替换证书。

下载大型仓库时，可以观察是首个连接慢，还是持续传输速度慢。前者常与 DNS、TCP 建连或规则选择有关；后者可能受节点带宽、Git LFS、远端限速或 HTTP/2 行为影响。先查看 Clash 连接记录和 Git 的详细日志，再针对单一问题调整。

GIT_CURL_VERBOSE=1 \
git -c http.proxy=http://127.0.0.1:7890 \
clone https://github.com/example/project.git

为 SSH 仓库配置 SOCKS5 代理

SSH 不会读取 Git 的 http.proxy。当远程地址是 [email protected]:组织名/仓库名.git 时，Git 最终调用的是 ssh，需要使用 OpenSSH 的 ProxyCommand 把 SSH 连接交给 SOCKS5 代理。最常见的辅助工具是系统自带的 nc，也可以使用支持 SOCKS5 的 connect 或 ncat。

macOS 与多数 Linux 发行版可以编辑 ~/.ssh/config。文件权限建议设置为用户可读写，避免 SSH 因权限过宽而拒绝读取。

Host github.com
    HostName github.com
    User git
    Port 22
    ProxyCommand nc -X 5 -x 127.0.0.1:7891 %h %p
    ServerAliveInterval 30
    ServerAliveCountMax 3

其中 -X 5 表示 SOCKS5，-x 127.0.0.1:7891 指向 Clash SOCKS5 入站，%h 和 %p 会由 SSH 替换为目标主机与端口。不能把 mixed-port: 7890 随意填到这条命令中，除非所用工具明确支持通过 HTTP CONNECT 建立 SSH 隧道。

不同平台的 SSH 命令差异

Windows 10、Windows 11 和较新的开发环境通常包含 OpenSSH 客户端，但系统中的 nc 不一定可用。可以使用 Git for Windows 附带的 connect.exe，或安装并确认路径稳定的 ncat.exe。示例中的路径必须替换为本机真实路径：

Host github.com
    HostName github.com
    User git
    Port 22
    ProxyCommand C:/Tools/connect.exe -S 127.0.0.1:7891 %h %p

如果使用 Ncat，常见写法如下：

Host github.com
    HostName github.com
    User git
    ProxyCommand C:/Program Files/Nmap/ncat.exe --proxy 127.0.0.1:7891 --proxy-type socks5 %h %p

路径包含空格时，应根据 OpenSSH 在当前平台的解析方式进行转义或改用不含空格的工具路径。完成配置后先运行详细测试，不要直接反复执行推送：

ssh -Tvvv [email protected]
git ls-remote [email protected]:example/project.git

日志中如果出现 Executing proxy command，说明 SSH 已经调用代理命令；如果立即提示 nc: command not found，问题在辅助工具路径；如果代理命令能启动但连接超时，应检查 Clash SOCKS5 端口、GitHub 规则和当前策略组。

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

git remote set-url origin git@github-proxy:example/project.git

用 TUN 覆盖不读取系统代理的开发工具

环境变量和 Git 配置只对遵循这些设置的软件有效。一些编译器、IDE 内置下载器、容器运行时、虚拟机、代码索引服务和原生更新组件可能忽略系统代理，也不读取 HTTP_PROXY。这类程序在系统代理已开启时仍然连接超时，才有必要考虑 Clash TUN。

TUN 通过虚拟网络接口接管系统 IP 流量，再交给 mihomo 进行规则匹配。它的覆盖范围比单独配置 Git 更大，因此启用前应先确认客户端拥有管理员权限或网络扩展权限，并确保系统中没有其他 VPN、网卡加速器或透明代理同时修改路由。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: false

dns:
  enable: true
  enhanced-mode: fake-ip

上面的字段仅用于展示思路，实际配置要以当前 mihomo 版本和客户端界面支持情况为准。启用 TUN 后，建议先保持 allow-lan: false，不额外开放局域网访问；确认 Git、SSH 和包管理器运行正常后，再根据需要配置局域网设备访问。

为开发流量设置可观察的规则

规则应优先覆盖明确的域名，而不是把所有流量长期设置为全局代理。GitHub 常见域名包括 github.com、api.github.com、raw.githubusercontent.com、objects.githubusercontent.com 和部分 Git LFS 下载域名。实际连接还可能跳转到 CDN 或项目自身的包存储域名，因此不能只凭仓库主页域名判断全部流量。

rules:
  - DOMAIN-SUFFIX,github.com,开发代理
  - DOMAIN-SUFFIX,githubusercontent.com,开发代理
  - DOMAIN-SUFFIX,githubassets.com,开发代理
  - DOMAIN-SUFFIX,gitlab.com,开发代理
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,DIRECT

策略组名称必须与配置中的实际名称一致。若订阅已经提供“节点选择”或“自动选择”，可以在本地覆写中引用已有策略组，避免重复维护节点。规则顺序也很重要：内网域名、局域网地址和公司代码平台应放在通用匹配规则之前，否则可能被错误送入代理。

DNS 方面，TUN 与 fake-ip 配合时，部分企业内网域名、私有注册表和 SSH 主机名可能需要加入 fake-IP 过滤或 nameserver-policy。遇到“域名解析成功但连接到错误地址”的情况，应同时检查 Clash DNS 日志、系统解析结果和实际规则命中，而不是只修改节点。

让包管理器沿用同一套代理策略

代码协作之外，依赖下载往往是第二个高频问题。npm、pnpm、Yarn、pip、Cargo、Go 和 Docker 对代理变量的支持并不完全一致。建议先使用会话级环境变量验证，再把稳定配置写入对应工具的用户配置文件。

npm、pnpm 和 Yarn 的配置可能保存在用户目录中，切换网络环境后要注意旧代理地址仍然存在。npm 还可能同时配置 proxy、https-proxy 和 noproxy，如果只删除其中一个，工具仍可能继续使用旧设置。

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890
npm config set noproxy "localhost,127.0.0.1,.internal"

npm config list

Go 模块下载通常还受 GOPROXY 影响。代理解决的是网络连接，模块代理地址解决的是 Go 如何获取模块，两者不是同一个配置。私有模块应配合 GOPRIVATE 和组织规定的认证方式，不要为了下载公共依赖而把所有域名都加入私有范围。

go env -w GOPROXY=https://proxy.golang.org,direct
go env -w GOPRIVATE=git.example.com/*
go env | grep -E 'GOPROXY|GOPRIVATE'

常见故障的定位顺序

当配置完成后仍然失败，可以按照“端口—代理—规则—认证—工具”的顺序缩小范围。每次只修改一个变量，并保留修改前后的命令输出，避免同时切换 TUN、DNS、策略组和 Git 配置后无法判断真正原因。

• Clash 没有连接记录：请求没有进入内核，检查 Git 配置、环境变量、SSH 的 ProxyCommand 以及程序是否绕过系统代理。
• 连接记录显示直连：规则没有命中预期策略，检查域名、端口、规则顺序和最终策略组。
• HTTP 返回 401 或 403：网络路径通常已经建立，继续检查令牌、组织权限、凭据管理器和服务端访问策略。
• SSH 提示连接超时：检查 SOCKS5 端口、nc 或 ncat 参数，以及目标端口 22 是否被当前网络阻断。
• SSH 主机密钥警告：不要直接删除所有 known_hosts。先核对主机名和官方公布的指纹，再处理单条旧记录。
• Git LFS 下载失败：LFS 请求可能访问不同域名，需在连接记录中确认实际目标，并为对应域名补充规则。
• 容器内下载失败：宿主机的 127.0.0.1 对容器而言通常指向容器自身，不能直接当作宿主机 Clash 地址；应按容器网络模式配置可达地址和代理变量。

git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'
ssh -G github.com | grep -i -E 'proxycommand|hostname|port'
curl -v -x http://127.0.0.1:7890 https://github.com
git remote -v

常见问题