前言：为什么开发者需要单独配置代理
对于开发者来说，代理并不只是浏览网页时才需要。日常工作中的 GitHub 仓库访问、Git 推送、SSH 登录远程服务器、Homebrew 安装软件包、npm 或 pip 下载依赖，都可能因为网络延迟、域名解析异常或连接被重置而中断。最常见的表现包括：网页可以打开，但 git clone 长时间没有响应；HTTPS 推送反复提示超时；SSH 连接卡在握手阶段；Homebrew 显示下载失败，却无法明确指出是哪一环出了问题。
Clash 可以把这些命令行流量纳入统一的分流体系，但它不会自动替你理解每个开发工具的网络行为。浏览器通常会读取系统代理，而 Git、SSH、Homebrew 以及不同语言的包管理器，可能使用各自独立的代理设置。因此，真正稳定的方案应当同时考虑 Clash 的运行模式、代理端口、域名规则、Git 的传输协议以及终端工具的环境变量。
本文目标
建立一套清晰、可回滚的开发者代理工作流，让 Git、SSH、Homebrew 和常用命令行工具分别按照合适的方式连接，同时避免国内站点和内网服务被不必要地送入代理。
1先准备 Clash 的基础环境
开始配置前，建议使用支持 Mihomo 内核的桌面客户端，例如 Clash Verge Rev，或者使用其他能够提供本地 HTTP、SOCKS5 和增强模式端口的 Clash 客户端。不同客户端的界面名称可能略有区别，但核心参数基本一致：一个本地代理地址、一个端口，以及一组负责选择节点的策略组。
确认模式与端口
开发者场景优先使用 Rule（规则）模式。它可以让 GitHub、软件源和特定外部服务走代理，同时让公司内网、局域网设备和国内代码托管平台保持直连。Global（全局）模式适合短时间排查规则问题，不建议长期用于开发环境，因为它可能影响内网域名、数据库连接、容器服务和本地调试接口。
在 Clash 设置中确认以下信息，后续命令会用到：
- HTTP 代理端口：常见值为
7890，实际端口以客户端界面显示为准。 - SOCKS5 代理端口：常见值为
7891，适合支持 SOCKS5 的程序。 - 混合端口：如果客户端提供 Mixed Port，可以使用同一个端口同时处理 HTTP 和 SOCKS5 请求。
- 局域网连接：仅当手机、虚拟机或其他设备需要共享代理时才开启；普通开发者不必开放局域网端口。
为开发服务建立分流规则
规则的重点不是把所有流量都交给代理，而是确保真正需要访问的服务能够稳定匹配。建议将自定义规则放在订阅规则之前，避免被后面的通用规则抢先匹配。下面是一个思路示例，其中 Developer 代表你在配置中已经创建的策略组：
域名列表需要根据你的实际工作流调整。不要盲目添加大量未知域名，也不要把公司的内部域名交给代理。若某项服务使用多个 CDN 或跳转域名，可以先通过终端测试，再补充规则，而不是一开始就采用全局模式。
2动手操作：配置终端的代理环境
完成 Clash 基础设置后，可以先在当前终端会话中临时设置代理。这样做的优点是不会修改系统全局配置，测试结束后关闭终端即可恢复原状，特别适合确认某个命令是否能够通过 Clash 连接。
将端口替换为 Clash 客户端实际显示的端口。在 macOS、Linux 以及支持类 Unix Shell 的环境中，可以执行：
如果希望每次打开终端都自动生效，可以将这些内容加入 ~/.zshrc 或 ~/.bashrc，然后运行 source ~/.zshrc。但在公司网络、VPN 或需要访问内网的电脑上，建议先采用临时设置，确认不会影响内部服务后再持久化。
验证代理是否真的生效
测试时不要只看浏览器。可以使用 curl 请求一个明确的外部地址，并观察是否能够快速返回状态码：
第一条命令用于测试当前环境是否已经继承代理变量，第三条命令则明确指定 HTTP 代理。若明确指定代理可以成功，而第一条失败，通常说明环境变量没有加载或变量名称写错。若两者都失败，应回到 Clash 中检查客户端是否运行、策略组是否有可用节点，以及规则是否命中。
建议保留一份关闭命令
测试完成后可执行 unset HTTP_PROXY HTTPS_PROXY ALL_PROXY，避免终端继续携带旧代理。使用多个网络环境时，清理旧变量往往比反复修改 Clash 配置更快定位问题。
3Git：分别处理 HTTPS 与 SSH
Git 常见的远程地址有两种：以 https:// 开头的 HTTPS 地址，以及以 git@ 开头的 SSH 地址。两者的代理配置完全不同。很多人只配置了 Git 的 HTTP 代理，却仍然无法推送 SSH 仓库，原因就在于 SSH 不会读取 Git 的 HTTP 代理选项。
为 Git HTTPS 配置代理
如果仓库远程地址是 HTTPS，可以使用 Git 自己的配置：
配置后可以用以下命令确认结果：
若只想让 GitHub 使用代理，而不影响其他 Git 服务器，可以采用按主机匹配的写法：
不再需要代理时，及时删除配置，避免在 Clash 关闭后 Git 报错：
为 Git SSH 配置 SOCKS5 转发
SSH 通常连接远端的 22 端口，Git 的 http.proxy 对它不起作用。可以在 ~/.ssh/config 中为 GitHub 添加代理跳转。以下示例使用系统自带的 nc，部分系统可能需要将命令替换为支持 SOCKS5 的版本：
保存后执行 ssh -T [email protected] 测试认证。首次连接可能出现主机指纹确认提示，应先核对官方指纹或团队安全规范，再输入确认。若你的网络无法稳定访问 22 端口，也可以让 SSH 连接 GitHub 的备用 SSH 端口 443：
注意密钥安全
不要把私钥、代理凭据或完整的 SSH 配置提交到代码仓库。建议为不同平台使用独立密钥，并为私钥设置密码短语；如果怀疑密钥泄露，应立即在代码托管平台撤销并重新生成。
4Homebrew 与包管理器的代理策略
Homebrew 的安装过程可能涉及 Git 仓库、API 请求和二进制文件下载，因此单纯让终端开启代理并不一定覆盖全部环节。macOS 和 Linux 用户可以先继承终端环境变量，再根据下载阶段的错误信息单独排查。使用代理时，优先选择稳定节点，不建议在安装过程中频繁切换节点。
配置 Homebrew 下载代理
在当前 Shell 中设置代理后，可以执行常用诊断命令：
brew config 可以显示 Homebrew、Git 和系统环境信息，brew doctor 则有助于发现权限、路径或残留配置问题。若更新过程中出现某个下载地址超时，应先复制该地址，用 curl -I 单独测试；不要直接删除校验步骤，也不要使用来源不明的安装脚本。
npm、pip 与其他命令行工具
不同包管理器可以独立设置代理，因此最好记录每项修改，方便恢复。npm 示例：
pip 可以在一次命令中指定代理：
如果只是临时下载，优先使用一次性参数，而不是把代理写进长期配置。长期配置可能被带入容器、CI 任务或团队共享环境，造成不可预期的网络行为。对于 Docker、远程开发容器和 CI Runner，还需要在对应运行环境中单独传递代理变量，宿主机上的 Clash 设置不会自动进入容器内部。
5故障排查与日常维护
当 Git 或 SSH 仍然失败时，建议按照从底层到上层的顺序检查，不要同时修改多个组件。首先确认 Clash 正在运行，并查看代理端口是否监听；其次测试域名解析和 HTTPS 请求；最后再检查 Git 远程地址、SSH 密钥和具体命令的输出。
- 浏览器正常、Git 失败：检查 Git 是否设置了错误的旧代理，运行
git config --show-origin --get-regexp 'proxy'查看配置来源。 - HTTPS 可以、SSH 失败：检查
~/.ssh/config的主机名、端口、ProxyCommand和 SOCKS5 端口，并使用ssh -vT [email protected]查看握手过程。 - 域名能解析但连接超时：检查 Clash 规则是否命中正确策略组，以及节点是否过载；必要时切换到固定的开发者节点。
- 国内仓库变慢：确认是否误用了 Global 模式，或在规则中为公司域名、局域网网段和国内代码托管服务添加了
DIRECT。 - 终端代理时好时坏：检查当前 Shell 是否残留旧的
HTTP_PROXY、HTTPS_PROXY或ALL_PROXY，并确认大小写变量是否被工具识别。
完成配置后，建议把代理设置写成一份个人备忘录，记录 Clash 的端口、Git 的配置方式、SSH 使用的端口以及各包管理器的恢复命令。更换电脑或节点时，只需逐项验证，不必重新摸索。对于团队项目，还应将代理配置与项目代码分离，避免把个人网络环境写入仓库文档或自动化脚本。
推荐的最终工作流
Clash 使用 Rule 模式，Git HTTPS 使用按主机代理，Git SSH 使用独立的 SOCKS5 转发，Homebrew 和包管理器通过临时环境变量测试；确认稳定后再按需持久化，并为内网服务保留直连规则。
代理配置的价值不在于“所有流量都走得更远”，而在于让不同类型的连接走适合自己的路径。只要把 Clash 的规则、Git 的协议和终端工具的代理范围分开管理，即使更换节点、切换网络或升级客户端，也能快速定位问题并恢复开发效率。