一、brew 为什么会「看起来像卡死」而不是单纯慢？

很多人把brew 卡住误解成「网速不够」，但更常见的情况是链路根本拼不完整：brew 首先会通过 Homebrew formula API 拉公式元数据，确认版本与 bottle 可否使用；随后在下载源码包、taps、二进制资产或补丁时跳到 GitHub Releases；部分 bottle 会直接走 GitHub Releases 文件域，亦可能落入 容器镜像宿主。上述每一步往往对应不同的子域与 TLS 会话，若前置规则先命中了宽泛的直连，而随后又需要代理侧的出口才能握手成功，就会在终端呈现出百分比不动、光标闪烁的假象——其实是若干 HTTP 会话在超时边缘重试。

此外，Corporate 与本机防火墙偶尔会对长尾 CDN 前缀做 DPI 限速，也会让大包下载看似挂起。遇到这种情况，单纯「换一个 brew 镜像」而未梳理出站一致性，往往只是把故障点从另一个主机名搬到了你不熟悉的域名列表里。因此我们优先建议：在Clash Verge Rev一类的图形客户端打开连接面板，复现问题时过滤 github、brew、ghcr、brew.sh 等关键字——你会看到到底是谁在卡住，而不是凭空猜订阅坏了。

二、理解 Homebrew 常见下载拓扑（与你的规则表对齐）

下面分类并不穷举每一项未来可能新增的宿主，但覆盖了 2026 年实测里最容易与分流表打架的几类职责，便于你把规则写成「可读职责」而不是死记硬背主机字符串：

  • formula 公式站与 Bottle API：formulae.brew.sh 以及官方记录的 JSON 端点是版本与二进制可用性的第一站；命中失败会表现为卡在「Fetching」早期。
  • Git 代码与 tarball：github.com、codeload.github.com 往往承担源码快照；与大文件 Releases 混在一起时，易被「只代理主站忽略 codeload」一类疏漏拦住。
  • Release 二进制与补丁：objects.githubusercontent.com、带 github.com 路径的资产链接、 occasionally pkg.github.com——任何一条没被 DOMAIN-SUFFIX 或足够靠前的规则接住，都会造成「formula 拿到了，安装却卡住」的典型分叉。
  • 容器镜像宿主：ghcr.io 等用于某些 bottle／镜像分发；如果你在规则里只记得 github.com，而忽略了 GHCR，就会得到「主页能 clone、brew 二进制拉不下」的矛盾现象。

把这些职责拆开来写规则，比在论坛里抄写一整段来历不明的「brew 镜像站配置」更值得长期维护；当你下次升级到新 macOS CLI 套件时，也不至于因为上游路径微调而整块失效。

三、终端层：brew 到底有没有走到 Clash？

macOS图形浏览器通常遵守系统 HTTP 代理栈，但 brew 背后的 Ruby／curl／git 组件并不总是能自动继承。HTTPS_PROXY / ALL_PROXY 指向本地混合端口是很多资深用户的第一步；具体写法与同机其它 CLI 完全一致，可参考《Mac 终端 curl、Git、npm 通过环境变量走 Clash》，这里只强调三件事：

  1. 代理 URI 一般用 http://127.0.0.1:端口 指向 Mihomo／Clash 的 mixed-port（常见 7890），由内核再向上游走 SOCKS／TLS；避免把 brew 写成只能识别 SOCKS 的 URI，除非你确认当前工具链适配。
  2. 同时使用大写与小写变量名（HTTPS_PROXY 与 https_proxy）以对齐不同依赖的惯例，减少玄学故障。
  3. 若你为部分命令加上了 sudo，要记得 macOS 会清洗环境变量：sudo brew 往往并不推荐，也会让你误以为「我已 export」却永远不生效。
避免 sudo brew _strip 代理上下文

长期习惯用管理员权限重装软件包时，sudo 后的进程可能看不到你在用户 Shell 中的 HTTPS_PROXY。优先保持用户态 brew，若确需特权操作，须在安全前提下单独评估或使用白名单脚本，而不要假设代理变量会自动透传。

当你不想维护一堆 export 细节时，可评估TUN 模式：内核把更多进程统一交给 Clash 决策，再配合本文下一节的分流规则顺序，往往比手写每个 CLI 变量的覆盖面更大。缺点是依赖驱动授权与局域网／企业 VPN场景的额外协调；可按《Clash TUN 模式开启方法》评估是否值得为你这台开发机常驻开启。

快速嗅探 brew 走的是不是 127.0.0.1

在新开的终端会话里只对当前窗口 export 完成后，可先跑 curl -x http://127.0.0.1:你的混合端口 -I https://www.google.com/generate_204 --max-time 10 或任意轻量 HTTPS 探针确认代理本身可用，再在同一窗口尝试 brew——这样可把「内核规则问题」与「brew 根本不会用代理」快速拆开。

四、用连接日志读出「卡住的那条域名」

有了代理层或 TUN 之后，下一阶段就是让 Clash 自己的证据说话。在Clash Verge Rev的连接列表（或等价面板）执行下列动作：

步骤 1：先清空／过滤噪音

开启实时刷新，清空旧条目或按时间排序，然后开始一次简短的 brew install 复现实验——避免把昨天浏览器的条目误当成 brew。

步骤 2：搜索阶段关键字

过滤 brew.sh、github、ghcr.io、codeload、objects 等前缀，盯住SNI／Host 与命中策略组是否一致——若你看到某些主机名始终是 DIRECT，而同一时间窗内其它条目走代理，极可能就是规则顺序分叉。

步骤 3：对照失败码

TLS 超时、 RST、或远端 403 都能在日志语义里区分开；别把「Handshake timeout」误判成「镜像站坏了」，前者往往是路径或 DPI 所致。

如果你按上述面板仍只看到零星条目，多半是根本没进核：回到上一节核对 export／TUN，或检查是否误关闭了「设为系统代理」却忘记开 TUN 的补丁场景。系统化报错分类仍可对照《Clash 常见报错解决方案》。

五、YAML 分流思路：请先替换策略组占位符

下面是一段仅作对照的伪代码级规则草稿，请将 PROXY 换成你配置文件里确实存在的策略组名称，并保持它们出现在过于宽泛的 MATCH／「国内域名直连」大段之前：

# Example only — replace PROXY with your real policy-group name
rules:
  - DOMAIN-SUFFIX,brew.sh,PROXY
  - DOMAIN-SUFFIX,ghcr.io,PROXY
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  - DOMAIN-KEYWORD,codeload,PROXY
  - DOMAIN,api.github.com,PROXY

为什么刻意同时写后缀与关键字？因为很多 Release 链路会跳到若干CDN 边缘，Host 可能比记忆里的 github.com 更长；仅用单条DOMAIN,github.com往往在复杂订阅合并后吞不下全部变体。Mihomo还支持通过规则提供者（rule-provider）载入社区维护的规则集——若你走这条路，要特别留意合并顺序：某些「国内加速器」前缀若过于激进，可能会在 PROXY 之前先行直连，从而在日志里制造出「看起来像随机失败」的表面现象。

若你不想手抄 YAML，纯图形用户在 Verge Rev 里也能拖拽顺序，但请务必在保存后复核当前激活配置文件是否为你编辑的那一版，避免因 Profile 多套副本产生「改了但永不生效」的挫败感。

六、DNS、fake‑ip 与「解析分叉」的补充说明

当你已经确认出站策略一致但仍偶发卡住，可把怀疑转向解析链路：fake-ip 对某些长连接工具的握手节奏更敏感；企业内网劫持或运营商 DNS 也会把 CDN 前缀解析到你不可达的地址。务实的顺序是：先稳住规则与会话出站，再微调 nameserver-policy 或等价配置，把 github.com、githubusercontent.com、brew.sh、ghcr.io 交给更可验证的加密 DNS上游——字段语法因内核迭代略有出入，请以你当前 Mihomo／Clash 发行版的官方文档为准，而不是死记几年前的gist。

若你希望保持最小变更面，可先尝试在非 fake-ip Profile 上做对比实验：A/B Profile 往往比玄学「刷 DNS 缓存」更有信息量。

七、与国内镜像方案的取舍（不是互斥）

许多中文社区会推荐使用各类 HOMEBREW_* 环境变量切换到境内镜像：tuna、bfsu、ustc 等前缀都曾在不同时期帮助大家扛过链路抖动。坦率说，这是一条工程上有效的方法，但它带来两类长期成本：可用性巡检（镜像自身也会维护窗口）与你团队内脚本／CI 的一致性（有人忘记 export，有人硬编码旧的 bottle 前缀）。当你的主要瓶颈其实是海外 Release／GitHub CDN而没有稳定校内镜像 SLA 时，在 Clash 层把整条 GitHub／brew.sh 拓扑统一交给可信节点池往往更直白——至少你能用日志自我解释每一次的失败。

此外，镜像并不能替你把CocoaPods、Rustup、pnpm、Docker Hub等其它工具的域名一并救回来；而一个维护良好的Mihomo 分流表反而能顺带覆盖更多开发者日常路径。镜像与分流可以并存：HOMEBREW_* 负责把 API 前缀指到更近的宿主，Clash 仍兜底那些跳出镜像逻辑的补丁与私有 tap。

八、图形客户端侧的「出门前」核对表

  • 系统代理／TUN 状态：当前激活模式是否与「你执行 brew 的终端」在同一个网络平面？某些沙箱 IDE 内置终端会使用隔离网络栈。
  • 绕过局域网与内网前缀：是否把 127.0.0.1／LAN 与公司 Git 前缀安全地写入 NO_PROXY，以避免把不该出站的私有仓库误塞进海外节点。
  • 自动策略与健康检查：若你为 GitHub／brew 配置了 url-test／fallback 一类自动组，请确认探针宿主与真实下载路径一致，避免「面板显示绿而 Release 二进制仍掉线」的假阳性。
  • 进程级特例：少数安全／终端复用插件可能注入自己的代理钩子；遇到「同一台机器只有两个终端 behavior 不一致」时不要急于删配置，先试最小复现脚本。

九、常见问题

下面几个问题来自论坛与工单中的高频措辞，措辞尽量贴近读者的原始搜索句式，便于你与本文主体交叉索引。

浏览器能上 GitHub，brew 却仍超时——是不是没走代理？

很大概率是的，或更准确地说：部分子域没走你希望的那条链路。请回看「日志」小节，确认 codeload 与objects 一类后缀是否与 github.com 页面请求共享同一出站策略意图。

只有 brew update 慢、brew install 正常，也需要改规则吗？

update 往往在短期内请求大量元数据与高并发的小型 JSON；这比单独拉一个大 tarball 更受RTT／DNS／小包代理处理影响。可把 update 卡住时的主机名列表单独截图保存，再在规则中为这些后缀补一条靠前的 PROXY——不要泛泛换节点。

报错里出现 TLS handshake timeout／certificate verify failed 分别意味着什么？

Handshake 超时偏向路径或 RST；证书校验失败则更可能是中间人代理或公司防火墙替换证书，与订阅线路本身无关——此时应在企业合规前提下与安全团队协同，而不要盲信「关了验证就好」一类的野路子建议。

在 CI／自动化里也要这样吗？

CI 往往需要可读、可重复的 HTTP(S) PROXY 出站，或使用自带 runner 的官方缓存；别把交互式TUN GUI假设带进 headless Shell。本篇聚焦人机共用的桌面 macOS 开发环境；若你在 GitHub Actions 侧遇到 rate limit，应优先使用官方令牌与 caching，而非把个人 Clash 节点硬编码进去。

十、结语：别把「卡住」笼统归罪于镜像或节点名

Homebrew 与上游开源生态绑得很紧：brew install 的卡死现象，多数情况下都能还原成「某条GitHub CDN或formulae.brew.sh API请求没有按你预期出站」的工程问题。仅换镜像或只开系统代理不关规则，往往只是把症状挪到下一轮升级；而一个能在连接面板里说清楚谁直连、谁走代理的Clash 分流配置，再配合可选的命令行代理环境变量或 TUN，才更贴近开发者真实下载链路。反观那些只能整网「全局梯子」的方案，很难为 formula、源码与 Release 三套职责分别保留局域网直连与公司 Git 安全策略；而单靠手工 export 却很难覆盖沙箱／子进程链路。综合来看，图形化且内置 Mihomo 内核的Clash Verge Rev能够把端口、分流、DNS 与可视化日志放在同一工作台里，大幅降低「修了 brew 却把 npm／Copilot／Docker 另一条链弄断」的回滚成本。若你希望少走拼接 YAML 的夜路，把精力留给编译与调试本身，不妨试试本站提供的桌面客户端：→ 立即免费下载 Clash，开启流畅上网新体验