开发者用Clash打通GitHub与SSH代理工作流指南

先拆分工作流：GitHub 请求不只有一种代理方式

开发者日常访问 GitHub，通常同时包含网页访问、Git over HTTPS、Git over SSH、IDE 扩展通信、Copilot 请求、npm 或其他包管理器下载。这些请求虽然都指向互联网，但使用的网络入口并不完全相同。Clash 的系统代理开关可以帮助浏览器和部分桌面应用接管 HTTP、HTTPS 请求，却不能保证终端命令、SSH 连接和后台开发工具自动使用代理。

因此，配置开发者代理时不建议只打开 Clash 后就直接测试 git clone。更可靠的做法是先确认 Clash 内核正在运行、当前配置已经选择可用节点，再确认本地监听端口，最后分别为 Git、SSH、终端环境和包管理器设置代理。每一层都应该能够单独验证，这样出现故障时才能判断是节点、端口、协议还是应用配置的问题。

准备 Clash：确认端口、模式与节点状态

开始配置前，打开 Clash Verge、Clash Verge Rev、Clash for Windows、ClashX、Clash for Android 或其他兼容 mihomo 的客户端，先确认当前配置已经启用。进入代理页面选择一个明确可用的节点，排查阶段建议暂时固定节点，不要一边测试一边让 URL Test 或自动策略组频繁切换。这样可以避免节点切换造成的偶发超时。

接着查看客户端的端口设置。常见配置会提供 HTTP 端口、SOCKS5 端口或 mixed-port。若使用 mixed-port，同一个本地端口通常可以接收 HTTP 代理和 SOCKS5 代理请求，但最终仍应以客户端和内核实际显示为准。下面的 7890 只是示例，不能直接假定你的端口也是这个值。

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

allow-lan: false 表示只允许本机访问监听端口，适合个人电脑的默认安全状态。如果把监听地址暴露给局域网，其他设备可能使用你的代理端口，也会增加未授权访问和流量滥用风险。开发者工作流通常只需要本机终端和 IDE 访问 Clash，因此不应为了“让命令能连上”而随意开启局域网共享。

在 Clash 中使用规则模式时，GitHub、npm registry 和其他开发服务可能被不同规则分配到不同策略组。出现异常时，打开连接列表，执行一次网页访问或 Git 请求，确认目标域名是否出现、命中了哪条规则，以及最终使用的是具体节点、DIRECT 还是 REJECT。必要时可短暂切换全局模式进行对照，但测试完成后应恢复规则模式，避免影响日常分流。

1. 确认内核状态为运行中，配置页面没有 YAML 解析错误。
2. 确认代理策略组不是空值，并手动选择一个可用节点。
3. 记录 HTTP、SOCKS5 或 mixed-port 的实际端口。
4. 打开连接记录，确认 GitHub 域名请求能够被 Clash 观察到。
5. 先使用浏览器测试，再配置终端和 Git，逐层增加变量。

配置终端：让命令行工具使用 Clash

在 macOS、Linux 和部分 Windows 开发环境中，许多命令行工具会读取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 环境变量。变量名称通常不区分大小写，但不同程序支持范围不完全一致。HTTP 和 HTTPS 请求可以指向 Clash 的 HTTP 或 mixed-port；需要 SOCKS5 的程序则应使用 SOCKS5 端口或支持 SOCKS5 的 mixed-port。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

上面的写法适用于当前 Shell 会话。若确认代理长期需要使用，可以把它放入 zsh、bash 或其他 Shell 的启动文件，但不建议直接在不清楚影响范围时全局写入。长期设置可能让内网 Git 服务、公司域名、数据库工具和本地开发服务器也经过代理。NO_PROXY 可以排除本机地址和需要直连的内网域名，例如：

export NO_PROXY=localhost,127.0.0.1,::1,.internal.example

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:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

变量设置后，应在同一个终端窗口中验证。可以使用支持代理参数的请求工具访问 GitHub 的公开页面，观察 Clash 连接列表是否出现对应域名。若命令提示无法解析代理地址，通常是变量格式错误；若连接到本机端口立即被拒绝，应检查 Clash 是否运行或端口是否写错；若建立连接后超时，则继续检查节点和规则匹配。

退出终端或关闭会话后，临时变量通常会失效。为了避免忘记当前终端到底继承了哪些设置，可以分别使用 env、printenv 或 PowerShell 的 Get-ChildItem Env: 查看。不要把包含账号密码的代理 URL 写入公共脚本、代码仓库或终端截图。

配置 Git HTTPS：优先使用 Git 自己的代理项

GitHub 的 HTTPS 远程地址通常形如 https://github.com/组织/仓库.git。Git 会通过 libcurl 建立 HTTPS 请求，系统代理是否生效取决于 Git 构建方式和当前环境，因此更明确的做法是为 Git 配置代理。若 Clash 提供 HTTP 或 mixed-port，可以在 Git 中设置 HTTP 代理地址：

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

--global 会把设置写入当前用户的 Git 配置，适用于个人电脑上的多数仓库。若只想让某一个仓库使用代理，可以进入仓库目录后去掉 --global：

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

配置完成后，用以下命令检查实际值和来源：

git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'

Git 配置可能同时来自系统级、用户级和仓库级文件，后读取或作用域更具体的值可能覆盖前面的设置。遇到“明明改了代理但 Git 仍然不通”，先查看 --show-origin 输出，不要盲目重复写入。某些公司网络还会设置自定义 CA 证书，若错误信息是 certificate verify failed，应区分代理连接问题与证书信任问题，不要直接使用关闭 SSL 校验的方式绕过。

如果不再需要 Git 的全局代理，可以删除对应配置：

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

删除前应确认是否存在其他项目依赖这些设置。测试 Git HTTPS 时，建议使用详细输出查看请求停在哪一步，但公开日志中可能包含远程地址、用户名或内部域名，分享前应清理敏感信息。

配置 Git SSH：使用 ProxyCommand 连接 GitHub

SSH 远程地址通常形如 [email protected]:组织/仓库.git。它不是 HTTP 请求，Git 的 http.proxy 对 SSH 远程地址不起作用。要让 SSH 经过 Clash，需要让 SSH 客户端先连接本地 SOCKS5 端口，再由 Clash 转发到 GitHub 的 22 端口。最常见的方法是在 SSH 配置中使用 ProxyCommand。

macOS、Linux 以及部分 Windows 环境可以使用支持 SOCKS5 的 nc 或其他连接转发工具。编辑用户目录下的 SSH 配置文件：macOS 和 Linux 通常是 ~/.ssh/config，Windows OpenSSH 通常对应用户目录下的 .ssh\config。添加类似内容：

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

其中 -x 指定 SOCKS 代理地址，-X 5 表示使用 SOCKS5，%h 和 %p 会由 SSH 替换成目标主机和端口。若你的 nc 版本不支持这些参数，命令会直接失败；不同操作系统自带的 netcat 参数并不统一。此时应换用系统中已经安装、且明确支持 SOCKS5 的连接工具，并按照该工具的语法调整 ProxyCommand，不要机械复制其他平台命令。

配置后先测试 SSH 握手：

ssh -T [email protected]

GitHub 可能返回“成功认证但不提供 Shell”的提示，这通常说明 SSH 密钥已经被识别，并不代表出现错误。首次连接还可能要求确认主机指纹，应核对来源后再接受。若需要观察 SSH 在代理链路中的详细过程，可以使用：

ssh -vT [email protected]

调试输出中如果显示无法执行 nc，问题在本地转发工具；如果本地代理连接被拒绝，检查 Clash 端口；如果已经建立 SOCKS 连接但 GitHub 仍然超时，再检查节点、规则、目标端口和当前网络。SSH 密钥本身只负责身份认证，不负责代理转发。不要为了修复网络问题反复生成密钥，也不要把私钥内容发送给他人。

动手配置：按最小变量完成一次 clone 与 push

下面是一套适合新环境的操作顺序。它的重点不是一次性修改所有工具，而是先完成一条可重复的链路，再逐步扩展到 npm、IDE 和 Copilot。执行过程中建议每一步都观察 Clash 的连接记录，确认请求确实经过预期的代理策略。

1. 固定节点：在 Clash 的代理页面选择一个可用节点，暂时不要使用会频繁切换的自动策略。
2. 确认网页访问：开启系统代理，用浏览器打开 GitHub，检查 Clash 是否记录了 GitHub 相关连接。
3. 选择远程协议：团队已有 SSH 密钥并希望使用 SSH 时，配置 ~/.ssh/config；否则可以先使用 HTTPS。
4. 验证 Git：使用 git ls-remote 读取仓库引用，比完整 clone 更节省时间，也更容易判断认证与网络阶段。
5. 执行 clone：确认引用读取成功后再克隆仓库，观察下载过程中是否出现连接重置或长时间停顿。
6. 验证 push：在测试分支提交一个无敏感内容的变更，分别确认 SSH 密钥或 HTTPS 凭据能够完成认证。

git ls-remote https://github.com/example/project.git
git clone https://github.com/example/project.git

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

上面的仓库地址只是格式示例，应替换成你有权限访问的实际仓库。HTTPS 测试失败时，先检查 Git 的代理项和凭据；SSH 测试失败时，先检查 ssh -vT 的 ProxyCommand；两种协议都失败时，再回到 Clash 连接列表和节点状态，避免只修改 Git 配置。

如果 HTTPS 可以使用而 SSH 不通，通常说明 HTTP 代理路径正常，但 SSH 的 SOCKS5 转发没有配置好。相反，如果 SSH 可用而 HTTPS 失败，则应查看 Git 的 HTTP 代理、证书、凭据管理器和远程地址是否正确。两种协议都能访问但 clone 很慢，问题可能来自节点带宽、仓库体积、Git LFS、目标线路或本地磁盘，而不一定是代理入口。

npm 与 IDE：处理依赖下载和 Copilot 请求

npm、pnpm 和 yarn 通常访问 registry 的 HTTPS 地址。它们可能读取环境变量，也可能读取各自的配置文件。使用 npm 时，可以查看当前代理设置：

npm config get proxy
npm config get https-proxy
npm config get registry

如果需要为 npm 单独设置代理，可以使用：

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

registry 不一定要改成陌生的镜像地址。开发团队应根据项目锁文件、供应链要求和公司政策选择官方 registry 或经过审核的内部镜像。代理只改变请求经过的网络路径，不会自动解决包版本冲突、registry 不存在目标版本、私有包认证失败或证书配置错误。

如果项目使用 pnpm 或 yarn，也要查看它们自己的配置和环境变量。多套配置同时存在时，当前目录的项目配置、用户配置和 Shell 变量可能产生覆盖关系。安装失败时先记录实际 registry、HTTP 状态码和错误类型，再判断是代理超时、权限拒绝、包不存在还是 TLS 验证失败。不要因为出现网络错误就删除锁文件或关闭证书校验。

VS Code、JetBrains 系列和其他 IDE 可能有独立的 HTTP 代理设置。IDE 主程序读取系统代理，不代表扩展宿主、内置终端、语言服务器和 Copilot 进程一定全部采用同样的配置。Copilot 登录失败、模型请求超时或扩展持续显示离线时，应在 IDE 的网络设置中确认代理地址，再查看扩展日志和 Clash 连接记录。

• 浏览器正常、IDE 不通：检查 IDE 是否启用了独立代理，以及是否需要重启扩展宿主。
• IDE 页面正常、终端 npm 不通：检查终端是否继承 Shell 变量，以及 npm 是否有单独配置。
• GitHub 正常、Copilot 登录失败：检查相关服务域名是否被规则错误地分配到 DIRECT 或 REJECT。
• 依赖下载偶发失败：检查节点稳定性、registry 负载、并发连接数和包管理器重试设置。

安全与维护：代理配置不要变成新的泄露入口

开发者代理配置中可能同时出现订阅地址、Git 凭据、SSH 私钥、npm token 和企业内部域名。订阅链接本身往往带有访问权限，不能贴到公开 issue、仓库 README、聊天群或调试截图中。Git 的远程地址也可能包含用户名或特殊认证信息，分享日志前应进行脱敏。

不要把代理账号密码直接写入公共 Shell 配置或 Git 仓库。如果确实需要带认证的代理，应使用操作系统凭据管理、环境变量注入或团队批准的密钥管理方式。SSH 私钥文件应限制权限，Windows、macOS 和 Linux 的具体权限机制不同，但共同原则是只允许当前用户使用，并为不同用途使用独立密钥。

配置长期运行时，建议定期检查以下项目：

1. Clash 客户端和 mihomo 内核仍处于受支持状态，配置字段没有被新版本弃用。
2. Git 的全局代理没有意外影响公司内网仓库和本地服务。
3. NO_PROXY 中包含本机地址以及确实需要直连的内网域名。
4. npm、IDE 和终端没有保存已经失效的代理或登录凭据。
5. 关闭 Clash 后，系统代理、TUN 和路由状态能够恢复正常。

如果开发机需要在多个网络环境中切换，可以保留“代理开启”和“代理关闭”的明确脚本或配置记录，但不要让脚本静默修改系统路由、证书或防火墙。每次升级客户端后，先用网页、Git HTTPS、Git SSH 和包管理器各做一次小测试，再恢复大型项目的自动构建任务。

常见故障排查：从错误位置反推配置层

Git HTTPS 提示代理连接失败

先执行 git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'，确认 Git 实际使用的地址与 Clash 端口一致。若端口拒绝连接，检查内核状态和端口占用；若代理建立后超时，查看 Clash 中是否出现 GitHub 连接以及最终策略。若显示证书错误，则检查企业证书、系统时间和 Git 的 CA 配置，不要直接设置 http.sslVerify false。

SSH 提示 connect 或 ProxyCommand 错误

使用 ssh -vT [email protected] 查看 SSH 是否成功执行转发命令。若提示找不到 nc，需要安装或替换支持 SOCKS5 的工具；若参数不兼容，应按照当前工具的帮助文档修改命令。若 SSH 连接根本没有出现在 Clash 的连接列表中，说明请求可能没有进入本地 SOCKS 端口。

clone 中途断开或速度很慢

先区分仓库体积、Git LFS、节点速度和本地磁盘因素。固定节点后重复读取引用，再进行浅克隆或较小仓库测试。若所有仓库都慢，检查节点负载和线路；若只有某个大型仓库慢，检查 LFS 对象、服务端限制和连接稳定性。不要用不断提高超时时间掩盖丢包或节点不稳定。

关闭 Clash 后终端仍然无法联网

检查 Shell 中是否残留 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，再检查 Git、npm 和 IDE 的独立代理设置。TUN 模式还需要确认虚拟接口、路由和 DNS 是否恢复。如果只有当前终端受影响，通常是会话变量；如果整个系统受影响，则继续查看系统代理和网络扩展状态。

FAQ：开发者代理配置的四个问题