Hugging Face 下模型或 LFS 总卡住？Clash 分流 hf 域名与节点实测（2026）

为什么「网站能开」，下载模型或 LFS 却像抽风

2026 年要做本地推理、微调或数据实验，Hugging Face Hub 仍然是最常见的模型与权重入口。很多人在一台已开代理的电脑上会遇到一种错觉：浏览器打开 huggingface.co 的仓库页、README 和讨论区都正常，一旦用 huggingface Hub 命令行、transformers 的自动下载、或 Git LFS 去拉几 GB 到几十 GB的权重，进度条就时快时断，甚至报超时、TLS 中断、EOF 一类错。这往往和「你压根没开 Clash」无关，而和不同主机名、不同协议阶段走了不同出口有关：网页静态资源、REST API、Git LFS 批量接口、以及 cdn-lfs 等大对象直链，并不保证命中同一条你随手配的「全局代理」路径。

本文从大文件拉取与 Git LFS 这条线切入，讲清 huggingface.co、hf.co 短链、以及 LFS 存储与 CDN 边缘在请求链上的位置，并给出在 Clash 分流里把 Hugging Face 系成组收纳、配合 DNS 与节点的实测思路。我们不展开 IDE 里对话类 API 或各家聚合 LLM 网关（那些域名与使用场景和 Hub 大文件流不同），也刻意与站内流媒体、游戏 CDN 等专文区隔——你若还没理清 mode: rule 与规则顺序，可先读 Clash 规则分流与路由 打底，再回来叠本文的 Hugging Face 专项。

Hugging Face 一次「完整下载」会经过哪些主机名

粗略地说，从 Hub 拿大文件时，你至少会碰到几类不同职责的海外资源：① 主站与 API，多落在 huggingface.co 及其子域；② 短链与部分跳转常用 hf.co；③ Git LFS 的 batch 与对象拉取，除主站子域外，还常见指向对象存储与 CDN 边缘的专用主机名（社区讨论里常把其中一类概括为 cdn-lfs 或类似lfs 专用存储域——具体命名会随产品迭代微调，以你本机 nslookup、或客户端日志中解析到的 FQDN 为准）。④ 使用官方 Python 库时，还会发起与元数据、鉴权、重试相关的一系列请求。若你的规则里只写了「浏览器常见的 www」，或把大流量误伤成 DIRECT，就会表现为：小页面能开，模型下载却在一半掉到直连烂路上。

因此，Clash 分流的目标不是背下一串永远不变的 IP，而是把 DOMAIN-SUFFIX 覆盖到你实际会解析到的那棵域名树，让同一类业务（本例中的 Hub 与 LFS）进入同一策略组。策略组里再放一个对大文件友好的节点或手工固定节点，减少「前一半走 A、后一半走 B」导致的重连。若你刚导入订阅、尚未把规则跑通，可先按 Clash 订阅导入教程 把基础链路理顺，再添加下文 YAML 中的片段。

规则怎么写：独立策略组 + 置顶 Hugging Face 专用后缀

在 mode: rule 下，建议单独建一个 proxy-groups 项，例如名为 HuggingFace，内部用 select 让你手动锁定一个出口（大文件场景下，往往比高频率的 url-test 更稳，见下一节）。在 rules: 中，用较高优先级插入若干 DOMAIN-SUFFIX 行，把 huggingface.co、hf.co 以及你在日志中看到的 LFS 相关子域，统一指向 HuggingFace 这一组。若你使用 mihomo 系内核并维护远程规则集，请确认「通用去广告/国内直连」规则没有在更前面把某条 *.huggingface.co 误标成 DIRECT，否则再精细的子域也进不了代理。远程规则与本地行冲突时，排查思路可参考 Rule Provider 与规则集更新排障。

下面是一段仅作结构示意的片段（把 你的代理组 换成你订阅里实际存在的名称，顺序按你使用的产品版本调整，不必逐字照抄；YAML 在客户端里以「能加载、能命中」为准）。

proxy-groups:
  - name: "HuggingFace"
    type: select
    proxies:
      - "你常用的稳定大带宽节点"
      - "DIRECT"
      - "REJECT"

rules:
  - DOMAIN-SUFFIX,huggingface.co,HuggingFace
  - DOMAIN-SUFFIX,hf.co,HuggingFace
  # add more DOMAIN rules after you see actual LFS / CDN FQDNs in logs
  - MATCH,你的默认策略

写完后，用核心日志或连接面板看大文件段是否确实命中 HuggingFace 组。若只命中了主站、而对象域名仍走默认组，说明还缺了若干子域或 CDN 域，需要把日志里新出现的 FQDN 再补成 DOMAIN 或 DOMAIN-SUFFIX 规则，直到整条下载链路齐套。

DNS 与 fake-ip：解析错了，规则写全也会「看起来不生效」

在启用 fake-ip 或本机有多个 DNS 出口 时，容易出现「我明明写了 DOMAIN，连接却仍像直连」的现象：因为先解析、后匹配的链条里，若 DNS 不经过 Clash 或混用了系统 私人 DNS / 路由器 DNS，内核拿到的可能不是与规则模块一致的那张地址表。大文件与 Git LFS 还涉及多段长连接与断点续传，对中途更换解析或切换组更敏感。操作建议是：在排障期暂时减少变量，保证与代理相关的查询走内核 DNS 配置，并避免同一台机器上并行两套「各算各的」的解析。若延迟测试、UDP 与 DNS 行为都异常，可先对照 节点全红与 DNS 排障 缩小范围，再回来微调 Hugging Face 专用规则，而不是先怀疑权重文件本身「坏了」。

节点怎么选：模型下载要的是「能扛连续写盘」，不是「测速个位数 ping」

和网页浏览不同，模型下载更关心的是长时间 TCP 稳定、对端带宽、以及少抖动。某些 url-test 很美的节点，未必扛得住数小时、数十 GB 的流式传输；而手工固定的「中等延迟但稳」的出口，往往更省心。若你的策略组在下载过程中因健康检查或自动切换而反复换边，客户端会频繁重连、重协商，表面就像「Git LFS 总卡住」或 huggingface 工具链「进度倒退」。在确认规则命中无误后，可以优先在 select 中锁一个节点完整跑完大文件，再试对比其他节点。这与视频点播里「为 DRM 与地区锁一个出口」的思路相近，但对象换成了大对象下载，不依赖与 Netflix、Disney+ 等长视频平台那套专文，避免把两套域名清单混用。

huggingface-cli、Git 与 LFS 环境变量要和服务端分流对齐

在终端用 huggingface-cli、git lfs 或 Python 里触发 Hub 时，走的环境变量是该 shell 的 HTTP(S)_PROXY 或应用自身配置，不一定会自动跟随你在 Clash 图形界面里填的「系统代理」。很多用户在本机用TUN 模式或把终端也纳入透明转发，就是为了避免「GUI 有代理、命令行还直连」的断层。若你尚未理清 TUN 与规则模式的关系，可结合 TUN 模式与全局代理 做一轮对照；本文只强调一点：命令行大文件与浏览器小页面必须在**同一套转发逻辑**下测试，否则你会对着网页「一切正常」而忽略终端仍在直连 cdn-lfs 类主机。

Xet 与不断演进的存储层：以日志里的真实域名为准

Hugging Face 侧的对象存储与加速方案会随时间演进，网上粘贴的「固定 IP 或固定三级域」可能在你发文当月仍有效、下月已迁走。最稳妥的维护方式是：遇到卡住时，打开核心连接日志与解析记录，把新出现的、指向对象存储的 FQDN 收进你本地的 DOMAIN 规则。不要把本文当作「终局清单」，而当作分层的排查与收纳方法：主域先盖住，缺口再按日志补全。这样你的 Clash 分流才能与 Hub 的演进同频，而不是和某篇过期教程绑定。

可操作的自检顺序（从快到慢）

1. 确认是持续大流量卡，而不是偶发 503：用同一网络在不挂代理与挂代理下各试一次，缩小到「仅某条域名链」再改规则。
2. 在 mode: rule 下，检查 huggingface.co、hf.co 与日志中出现的 LFS/CDN 域是否都命中同一策略组。
3. 在下载过程中避免节点自动轮询，用手工 select 锁一个稳定出口长测。
4. 核对 DNS 与 fake-ip，避免与系统/路由器解析打架。
5. 终端工具与浏览器二选一或统一走 TUN，避免「一半走系统代理、一半直连」的错觉。

小结

把 Hugging Face 与 Git LFS 相关主机名在 Clash 分流里成组、置顶、与 DNS 同频，再把大文件下载从「自动选最快」切到「长时间稳定」的节点策略，会显著减少「页能开、包下不完」的错位体验。与单纯调 API 的聚合服务或 IDE 插件场景相比，Hub 的痛点更多在大对象、长连接、多域名协作，规则也应按这条链来收束。若你准备换一款图形客户端、但仍沿用可自定义规则的 Meta 系内核，可以从本站 下载页 获取与系统匹配的安装包，再按上文清单自测。相比反复重装 Python 与 Git，一次性把 hf.co 到 cdn-lfs 的命中路径对齐，日常拉模型会省心得多。→ 立即免费下载 Clash，开启流畅上网新体验