なぜHubの「プル」は感覚が違うのか
Hub経由の取得は、単一のHTMLページの読み込みではありません。メタデータ、リダイレクト、CDN上の大容量Blob、場合によってはGit LFSの伸びるパス、Pythonからはhuggingface-hubのHTTPレンジ要求の連打に分散します。どれか一つでも意図せぬDIRECTに落ち、途中で揺れると、レジューム有無やTLSの扱い次第で、見かけ上は同じ「遅い」なのに原因が別物になります。まず考えるべきは「トップのドメイン表」より実行時の接続ログに出るFQDNと使っているツールのスタック（git、git-lfs、huggingface-cli、transformersなど）です。
症状の分類：帯域より「中身の入れ替わり」
典型的な訴求は、① 数％で止まる・再開のたびに同じ箇所：長いTCP上でパケット欠落や経路揺れ、あるいは誤ルートによる帯域制御。② 名前解決だけ妙に遅い：DoH、OSリゾルバ、FakeIP周りの二重物語。③ 突然のTLS或いは接続リセット：SNI付きのHTTPSが、期待する出口に乗る前に別ポリシーへ。ここを雑に「拡張ルール1本」で直そうとすると、Hub側のエッジが増減するたびに壊れます。DNSの層の整理はMetaコアのDNSまわりの稿と併読すると、用語の対応づけが速いです。
接続先の束：huggingface.coとまわり
本番運用のホスト名は常に揺れ得る一方、実務上はまずhuggingface.co、cdn-lfs.huggingface.co などのLFS系、認証まわりでhf.co 短縮、追加でCloudFront等の取り巻きがログに乗ることがあります。大切なのは、静的に「全部これ」と決め切らず、手元のクライアントで一度フル取得を試し、Clash系の接続履歴に出たサフィックスを束ねる考え方です。ルール配列の上から先勝ちの穴は、ルール順とMATCHの稿で扱った通り、広い行が上にあると例外が死にます。
実務のコツ：PythonやCLIはプロキシ環境変数（HTTP(S)_PROXY 等）を読むか、まったく読まないかが実装差で分かれます。ブラウザが通っていても、ターミナル取得だけ詰まるのはここを疑う価値があります。
分流：Hubまわりを一つの出口に束ねる
ログに出たFQDNを、同一のプロキシグループへ寄せるのが分かりやすい解です。国別の大きなGEOIP,CN,DIRECTや巨大なRULE-SETの上側に、DOMAIN-SUFFIXで小さな例外を乗せるイメージです。キーワード条件は当たりすぎ注意なので、実行時名を優先してください。
# Example sketch — align Hub-related HTTPS to one group
# Replace YOUR_PROXY_GROUP with your proxy-group name; verify keys for your core
rules:
- DOMAIN-SUFFIX,huggingface.co,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,hf.co,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,cdn-lfs.huggingface.co,YOUR_PROXY_GROUP
上記は例であり、利用中のコアとクライアントの文法に合わせる必要があります。自宅LANのDIRECTと併用するなら、LANとfake-ip-filterの棲み分けも一緒に点検します。
DNSと「長いTCP」
大容量のプルは長時間同じ出口に張り付くほど、DNSと実経路のズレの影響を受けやすくなります。FakeIP利用時にnameserverやnameserver-policyの分割が多いほど、解決元が混在すると一時的に挙動が不規則になることがあります。変更したら、一度接続中の取得プロセスを切り、DNSキャッシュの混ざりを減らすのが手堅いです。HTTPSのSNIをルールに回したい場合は、Snifferの稿でドメインの見え方を押さえてからHubへ戻ると、切り分けが速くなります。
DoHとキャッシュ、TTL
ブラウザ独自のDoH、OS、Clash内DoH、の三層は、平常時は便利でも障害時に「どこで名前が固まったか」が曖昧になります。切り分け中だけ一時的に一本化して事実を取るのは有効です。職場回線のポリシーは必ず守ってください。
ツールの差：git-lfsとhuggingface-cli
git clone 経由のLFSは、HTTPSとSSH、資格情報ヘルパーの振る舞いが別物です。SSHでPullしている場合、まず22番の向き先がClash外に出ていないかを疑い、HTTPS中心ならSNI付きのルール側に戻るのが定石です。huggingface-cli download はトークンとレート制御の行も含め、ログ上はHTTPクライアントの連続要求として見えます。混線を減らすなら、一度小さなファイルで経路を確認してから、数ギガのBlobへ進むのが安全です。WindowsとGitの併用整理は、前述のWSL2稿の「ターミナルと出口」の節を参照すると、同族の話題がつながります。
作業チェックリスト（短い順）
- 使用ツール（Python／git／CLI）を一つに絞り、再現手順を固定する。
- Clashの接続履歴で、失敗時刻近傍のFQDN・出口名・ルールを抜き出す。
rules:の上側に、Hub向けの細かい行が到達するか確認し、足りなければ上へ移す。- FakeIPと
nameserverの食い違いがないか、DNS系設定を点検する。 - 必要ならプロキシ環境変数を揃え、長寿命プロセスは再起動して経路を取り直す。
コンプライアンス
学術・職域・契約回線のもとで、外部へモデルやデータを出す行為そのもの、またはプロキシの利用が禁じられている場合があります。許可範囲内でのみ、他人のトークンや有償枠の境界を越えた中継を行わないでください。本稿は技術的な切り分けの共有であり、特定サービスの利用規約違反を助長する意図はありません。
注意：掲載のYAMLは例示です。正しいキー名は利用中のMihomoその他のコア版と、GUIの書き出し形式に従ってください。
まとめ
Hugging Faceのモデルやデータ取得は、分流一本、DNS一本では片付きません。大容量の取得は接続の継続性に敏感なので、まずはログでFQDNを固め、Clashのルール上位置と名前解決の物語を一致させる方が、固定ドメイン表より再現性が高いです。同じクライアントを長時間触る作業は、ルールと可観測性（ログ）が揃った環境のほうが、試行のストレスが下がります。
導入や更新手順の確認、配布物の取得は、当サイトのダウンロードページを主な導線にすると、インストールとリポジトリ閲覧の目的が混ざりにくいです。オープンな仕様と実装差が併走する分野なので、まずは手元のログを静かに揃えましょう。