先分清三条链路：Git、SSH 与 Homebrew 各自如何连接
开发者常遇到这样的情况：浏览器已经能通过 Clash 访问代码托管平台，终端里的 git clone 却停在连接阶段；HTTPS 仓库能拉取，改用 SSH 地址后又超时；最后，即使 Git 已经恢复，brew install 仍可能卡在下载依赖。这通常不是一个开关没有打开，而是三类程序使用代理的方式并不相同。浏览器通常会读取系统代理设置，命令行程序则可能使用自己的代理配置、环境变量，或者直接发起普通网络连接。
因此，可靠的做法是把问题拆成「Clash 是否运行」「终端是否能到达 Clash 本机端口」「具体应用是否将请求交给代理」「规则是否把目标域名送到预期出站」四层。只有浏览器能访问，并不能证明 Git SSH 代理已经配置；只有 curl 成功，也不能证明 SSH 和 Homebrew 的所有下载请求都走了相同路径。先确定每个客户端的连接方式，再选择系统代理、环境变量、应用级配置或 TUN，排障会清楚得多。
下文以本机 Clash 的 mixed-port 为例，假设端口是 7890，SOCKS 端口是 7891。实际值应以 Clash Verge、Clash Verge Rev、Mihomo 或其他客户端当前配置为准，不要直接照抄示例端口。mixed-port 通常同时接受 HTTP 代理与 SOCKS 代理请求；SOCKS 端口则应按客户端配置的协议使用。先在客户端确认核心正在运行、端口正在监听，再开始修改 Git 或 Shell 设置。
终端代理变量：让支持代理的命令行工具接入 Clash
对 curl、不少使用 libcurl 的工具以及部分依赖下载程序而言，终端环境变量是快速验证代理链路的办法。在 macOS 或 Linux 的当前 Shell 中，可以临时设置 HTTP_PROXY、HTTPS_PROXY 与 ALL_PROXY，再用轻量请求测试。这里的变量只是告诉应用「代理服务器在哪里」，不会替 Clash 决定最终节点；出站选择仍由当前模式、规则和策略组控制。
当前终端会话的临时设置
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"
curl -I https://github.com
使用 SOCKS 代理时，socks5h 中的 h 表示域名解析也交给代理端处理；这在本机 DNS 结果与代理出口网络不一致时尤其有用。若客户端没有启用 SOCKS 端口，或你选择直接使用 mixed-port，就按实际监听协议调整变量，不要只改端口数字而忽略协议类型。部分程序只读取小写的 http_proxy、https_proxy 或 all_proxy，若请求仍然直连，可在当前 Shell 中同时设置大小写形式，并查看程序文档确认其变量支持情况。
变量仅对当前终端及其子进程生效：从这个 Shell 启动的 Git 或 Homebrew 命令可能继承设置，而从图形界面启动的编辑器、终端或后台任务不一定继承。若只是短时间验证，临时导出比写进全局配置更容易回滚；若准备长期使用，再把变量写入实际使用的 Shell 启动文件，并确认交互式终端、登录 Shell 与自动化任务确实会读取该文件。
测试时先请求一个 HTTPS 页面，并观察 Clash 的连接日志是否出现对应域名。如果 curl 报无法连接到 127.0.0.1，优先检查核心状态、监听地址和端口是否一致；如果请求能建立但目标仍无法访问，则查看日志中的规则、策略组和节点状态。对于公司 VPN、容器或远程开发环境，命令所在的网络命名空间可能看不到宿主机的回环地址，宿主机的 127.0.0.1 并不总是容器或远程主机上的 Clash 地址。
Git HTTPS：配置仓库访问代理并验证实际命中
Git 访问仓库常见两种 URL：以 https:// 开头的 HTTPS 地址，以及以 git@ 开头的 SSH 地址。前者通常可使用 Git 自身的 http.proxy 配置，也可能受运行环境的代理变量影响。为了让行为明确、便于诊断，可以先给 Git 配置本机 HTTP 代理，再用只读取远端信息的命令进行测试。不要在命令行参数、远端 URL 或配置文件里写入代理账号密码，尤其避免把凭据提交到仓库。
为 Git 设置本机 HTTP 代理
git config --global http.proxy http://127.0.0.1:7890
git ls-remote https://github.com/OWNER/REPOSITORY.git
请把示例仓库替换成你有权访问的真实仓库。git ls-remote 会查询远端引用，不会像克隆那样下载整个工作树，适合先验证认证和网络路径。运行后同时检查终端报错与 Clash 连接日志：如果日志里没有仓库域名，Git 可能没有读取预期配置、进程环境不同，或者请求尚未到达应用层；如果记录显示命中直连规则，则应检查规则顺序和目标域名匹配，而不是盲目调整 Git 参数。
--global 会影响当前用户下的多个仓库。如果只想代理某个项目，可以进入仓库目录使用不带 --global 的设置，让配置写入该仓库的本地 Git 配置。这样适合工作项目与个人项目需要不同网络策略的情况；但本地配置可能随仓库迁移或重新克隆而消失，因此要明确记录其用途。检查当前生效值时，可用 git config --show-origin --get http.proxy 查看设置来源，避免用户级、系统级和仓库级设置互相覆盖却不自知。
若某个内部代码站应当直连，不要把全局代理误认为分流规则。可以对特定域名设置 Git 的 URL 级代理例外，或将内部域名加入 Clash 的直连规则；选择哪一层，取决于你希望规则由 Git 管理还是由 Clash 统一管理。团队环境中，集中维护在 Clash 规则里的好处是不同命令行工具可以共享路由意图；应用级设置则更便于为单个开发工具做独立验证。无论采用哪一种，都应避免同时堆叠多层互相矛盾的例外。
测试通过后，记录这项配置影响的范围。如果要恢复 Git 对代理变量或系统设置的默认行为，可用 git config --global --unset http.proxy 删除用户级代理项；删除前先用 --show-origin 确认设置确实来自全局配置，以免误以为清理成功，实际还有仓库级设置正在生效。
Git SSH：用 ProxyCommand 转发 SSH 连接
SSH 仓库不会自动使用 Git 的 http.proxy，也不一定读取 HTTPS_PROXY。SSH 客户端需要单独知道如何连接远端的 22 端口；此外，一些代码托管服务允许通过 HTTPS 端口提供 SSH 服务，但具体主机名、端口和认证要求应以服务商文档为准。遇到 SSH 超时，先运行详细模式的连接测试，确认问题发生在 DNS、TCP 建连、SSH 握手还是密钥认证阶段，再决定是否需要代理。
一个常见做法是通过本机 SOCKS5 端口运行支持代理参数的 nc，并在 SSH 配置中指定 ProxyCommand。不同系统预装的 netcat 版本参数可能不同；若当前 nc 不支持 -X 或 -x，不要反复更换参数猜测，而应查明该版本的选项，或安装可信的兼容工具。下面是适用于支持相应参数的 netcat 的示意配置：
SSH 配置示例：按本机工具与服务商信息调整
Host github.com
HostName github.com
User git
ProxyCommand nc -X 5 -x 127.0.0.1:7891 %h %p
ServerAliveInterval 30
ServerAliveCountMax 3
将配置写入用户目录下的 ~/.ssh/config，并确保文件权限符合 SSH 客户端要求。该规则只匹配示例中的 github.com，对 GitLab、自建 Git 服务或其他主机需要使用各自的 Host 匹配段。不要把整个 Host * 都强制交给代理，除非你确实希望所有 SSH 连接都经过同一条代理路径；否则，服务器管理、内网跳板机和代码托管请求可能被错误地混在一起。
保存后先运行 ssh -vT [email protected]，观察调试输出里是否执行了代理命令、能否完成 SSH 握手，以及服务端返回的认证提示。代码托管平台可能在认证成功后仍提示「不提供 Shell」，这并不一定代表连接失败；应以服务商给出的 SSH 身份验证响应和实际 Git 操作为准。若代理命令无法启动，检查工具是否安装、参数是否受支持以及 SOCKS 端口是否监听；若已连上远端但显示公钥拒绝，则转而检查密钥路径、SSH agent 和账户授权，不要继续更换代理节点。
还要注意 SSH 使用的域名解析位置。由 SOCKS 代理处理目标域名时，域名解析行为可能与本机直接解析不同；如果代理命令接收的目标被本机先解析成 IP，可能导致规则日志难以按域名匹配。遇到这类问题，应检查工具参数、Clash 日志中的目标信息和规则命中结果，并以该版本工具文档为准。不要为了方便把私钥内容写进 SSH 配置或脚本；代理只负责网络路径，密钥仍应由 SSH 的标准认证机制管理。
Homebrew：处理公式、源码与二进制下载链路
Homebrew 的一次安装并不总是只有一个下载请求。它可能先查询公式与版本元数据，再下载预编译 bottle，也可能因为平台、版本或公式定义而拉取源码、Git 仓库或额外依赖。下载地址还可能经过重定向，最终落到不同的对象存储或 CDN 主机上。因此，看到 Homebrew 在一个步骤失败时，不应只凭公式名称推断目标域名；应以终端输出与 Clash 连接日志中实际出现的主机为依据，判断失败发生在元数据查询、Git 拉取还是文件下载阶段。
对常见安装流程，先在同一个终端设置前文的代理变量，再分别执行不改变软件状态的诊断命令与目标安装命令。若使用的 Homebrew 版本或下载组件不读取你设置的变量，检查其当前文档和实际子进程环境；不要假设所有版本都会通过同一种网络库处理代理。对于由 Git 拉取的依赖，还要确认 Git 自身的代理配置与 SSH 配置是否适用于那个远端，避免 HTTPS 请求已经走代理，而 SSH 源码仓库仍直连超时。
一个实用的排查顺序是：先确认 brew 能取得公式信息；再观察安装输出是否进入 bottle 下载；如果失败，检查最后出现的请求域名和 TLS 或超时错误；最后用相同终端环境对目标 URL 做一次轻量连通性验证。Homebrew 使用的 URL 可能随公式版本、操作系统架构和上游发布方式变化，所以不建议把几年前整理的 CDN 主机清单当成永久规则。规则应围绕当前日志里真实出现的域名维护，并通过 Clash 连接面板确认命中的是预期策略组。
若公司网络要求内部制品库直连、公共代码托管服务走代理，可以在 Clash 里把内部域名配置为直连，再让未匹配的相关下载域按规则进入代理；若你只希望某个 Homebrew 命令临时走代理，则在启动该命令的终端会话中设置变量，完成后关闭会话或撤销变量即可。不要把临时测试变量无意写入系统范围的启动脚本，尤其是在多人共用的开发机上，以免其他工具也继承代理设置并出现难以追踪的行为变化。
TUN 与分流：覆盖未读代理变量的工具并缩小排障范围
如果工具链里包含不读取代理变量的原生程序、多个子进程，或由图形界面启动且没有继承终端环境的应用，TUN 模式可以在网络层接管更多流量，让应用不必逐个配置 HTTP 代理。它适合希望减少程序级设置的开发者，但并不意味着所有请求都会自动按预期分流：Clash 仍需正确运行，系统权限、路由、DNS 和规则配置也要配合。开启 TUN 前先确认当前客户端内核支持该模式，并留意它与公司 VPN、虚拟机网络、容器和其他网络过滤软件的冲突。
混合使用 TUN 与应用代理时，要避免无意形成代理回环。例如，应用把请求发到 Clash 本机端口，而 TUN 又把这个连接再次捕获并转发，可能造成重复转发或无法连接。对于本机代理监听地址、绕过规则和 DNS 行为，应按客户端的 TUN 文档与现有配置逐项核对。改动前保存当前配置，先只开启一种覆盖路径做基准测试；确认 Git HTTPS、SSH 和 Homebrew 分别正常后，再决定是否保留额外的环境变量或应用级代理。
遇到故障时，可以按现象快速缩小范围：所有命令都无法连接本机端口，优先查 Clash 核心与端口；只有 Git HTTPS 失败，检查 Git 代理配置和 HTTPS 认证；只有 SSH 失败，检查 ProxyCommand、netcat 参数与 SSH 密钥；只有 Homebrew 失败，沿安装输出找到真正失败的子步骤和下载主机。如果终端测试成功、图形应用失败，则比较两者的进程环境，并确认图形应用是否使用系统代理或 TUN。每次只变更一个因素并记录测试结果，能让问题复现与回滚都更容易。
还应把安全边界纳入日常配置。本机代理端口通常只应供本机程序使用；除非你了解访问控制和局域网风险，不要为了让其他设备连接而随意监听所有网络接口。不要把代理凭据、访问令牌或 SSH 私钥写进公共仓库，也不要为了测试代理而关闭系统防火墙或证书校验。若公司网络有固定出口、审计或合规要求，应先遵循组织策略，再讨论代理规则的灵活性。
相比只依赖浏览器系统代理的传统用法，开发工作流更需要分别照顾 HTTPS、SSH 与包管理器的连接行为；而只给每个应用硬编码代理，又容易产生端口不一致和配置散落的问题。Clash V.CORE 可以把规则分流、TUN 覆盖与本机代理入口放进同一套可检查的工作流，配合连接日志逐项验证 Git、SSH 和 Homebrew 实际走向。若你希望在统一界面里管理这些代理路径并减少反复排查，可前往下载页选择适合自己平台的版本。