1 なぜ「モデル取得だけ」分流が要るのか
Qwen3 のような大規模チェックポイントは、単一の HTML ページからではなく、Git LFS やオブジェクトストレージ、CDN へのリダイレクトを経由して届きます。開発者が体感しやすいのは、「huggingface.co のモデルページは表示できるのに、huggingface-cli download がタイムアウトする」「ModelScope の Web UI は快適なのに、実ファイルのホストだけ別ドメインで詰まる」といったパターンです。原因の多くはマルウェアではなく、ブラウザと CLI が参照するプロキシの差、あるいは rules の評価順で一部のサフィックスだけ意図しない DIRECT に落ちていることにあります。
国境をまたぐピアリングや輻輳は日々変わるため、固定の「公式ドメイン一覧だけで完結」は難しく、接続ログに出た SNI を正に追記する運用が現実的です。Clash 互換（Mihomo）では DOMAIN-SUFFIX で倉庫ドメインを束ね、漏れた CDN 名を追いかけると、大モデル権重ダウンロードの再現性が上がります。社内規程・利用規約・輸出管理は必ず優先してください。
2 既存記事との棲み分け（DeepSeek・Gemma・OpenRouter）
本サイトの日本語ブログでは、DeepSeek はブラウザと api.deepseek.com などAPI と Web の一貫性が主題です。Gemma 4 と Hugging Face は Google 系 UI と HF・LFS の二正面が中心で、Google のサフィックスが厚めになります。OpenRouter は openrouter.ai への集約と IDE 連携が主役です。
本稿はこれらと重ならないよう、Qwen 系列のオープンウェイトを Hugging Face と ModelScope の両系統から引くことにフォーカスします。つまり「マルチモデル API の束ね方」ではなく、倉庫・データセット・（必要なら）クラウド API コンソールに対応するドメインを、同じクライアント設定の中で整理する、という切り口です。
3 Hugging Face：モデルカード、hf.co、LFS／CDN
Qwen の公式リポジトリやコミュニティミラーは、表向き huggingface.co と短縮 hf.co を行き来します。大容量ファイルは cdn-lfs.huggingface.co などLFS／CDN 用ホストへ誘導されることがあり、ルールが huggingface.co だけだと取りこぼします。Hugging Face 向けには、まず DOMAIN-SUFFIX,huggingface.co と DOMAIN-SUFFIX,hf.co を同じアウトバウンドに載せ、ログで LFS 名を確認して追記するのが安全です。
Python の huggingface_hub や huggingface-cli は環境変数 HTTPS_PROXY を参照しますが、ブラウザは OS や独自設定を見るため、TUN モードで仮想 NIC に揃えるか、シェルと IDE に同じプロキシを明示する必要があります。ここがズレると「HF だけ不安定」に見えます。
4 ModelScope（魔搭）：modelscope.cn とストレージ配下
ModelScope はアリババ系のモデル・データセット配布プラットフォームで、日本語圏の開発者にも利用者が増えています。Web と API の入り口は www.modelscope.cn／modelscope.cn に集約されがちですが、実際の大容量ダウンロードはオブジェクトストレージ（例：*.aliyuncs.com 系）へリダイレクトされるケースがあります。サフィックスを広げすぎると Alibaba 全体が同一出口に乗るため、まずは DOMAIN-SUFFIX,modelscope.cn を切り、接続ログで実際に出たストレージホストを最小限追加するのが無難です。
ModelScope 公式の CLI／SDK 利用時も、HTTPS クライアントはターミナル環境に依存します。HF 側と同じセレクタ名にまとめるか、帯域重視ノードだけ別グループに分けるかは、チームの課金とポリシー次第です。いずれにせよ MATCH より上に置く行の順序を誤らないことが重要です。
5 通義千問クラウド API（DashScope）と混同しない
オープンウェイトの取得とは別に、クラウド上で 通義千問 を叩く場合は DashScope（例：dashscope.aliyuncs.com）などAPI エンドポイントが主戦場になります。ここは「モデルファイルのバイト転送」とはトラフィック特性が異なるため、帯域より低遅延・TLS 安定を優先するセレクタを割り当てたい場合があります。ルールでは DOMAIN または十分に絞った DOMAIN-SUFFIX で API ホストだけを指し、HF／ModelScope のダウンロード用セレクタと混ぜないと、ログ上の切り分けが難しくなります。
コンソールやドキュメント閲覧が alibabacloud.com／aliyun.com 系に及ぶこともあるため、企業アカウントでは社内ゼロトラストや固定出口と衝突しないかもあわせて確認してください。
6 rules の YAML 骨格（例）
以下は Mihomo／Clash Meta 互換の追記イメージです。AI_MODEL_PROXY は手元のプロキシグループ名に置き換え、GEOIP や国内 DIRECT より上に置くかどうかは環境依存です。コメントは仕様に従い英語のみとします。
# Place ABOVE MATCH. Replace AI_MODEL_PROXY. Extend from connection logs.
rules:
- DOMAIN-SUFFIX,huggingface.co,AI_MODEL_PROXY
- DOMAIN-SUFFIX,hf.co,AI_MODEL_PROXY
# Uncomment if logs show LFS/CDN hosts:
# - DOMAIN-SUFFIX,cdn-lfs.huggingface.co,AI_MODEL_PROXY
- DOMAIN-SUFFIX,modelscope.cn,AI_MODEL_PROXY
# Optional: cloud inference API (narrowly scoped)
- DOMAIN-SUFFIX,dashscope.aliyuncs.com,AI_MODEL_PROXY
# If downloads hit OSS hosts, add ONLY what your logs show, e.g.:
# - DOMAIN-SUFFIX,oss-cn-hangzhou.aliyuncs.com,AI_MODEL_PROXY
aliyuncs.com を丸ごと指定すると Alibaba 全体が同じ出口になり得るため、本番ではログで確認したホストだけを追加する運用を推奨します。逆に、取得専用に高帯域ノードを割り当てたい場合は AI_MODEL_DOWNLOAD のような別セレクタを切り、API 用 AI_MODEL_PROXY と分離すると運用が楽になります。
7 Rule Provider に切り出す
コミュニティの Rule Provider に「開発者向け SaaS」カテゴリが含まれていれば再利用できますが、Qwen3 リリース直後や CDN 変更時はリスト更新にラグが出ます。運用上は、(1) ローカル rules に HF／ModelScope の核となる数行を置く、(2) 落ち着いたら Provider の更新に寄せる、(3) Git 管理なら Pull Request に「追加したドメインとログ根拠」を残す、の三段が現実的です。rule-providers の interval は短くしすぎないよう注意してください。
8 Git LFS、huggingface-cli、ModelScope SDK
git clone ＋ LFS は長時間セッションになりやすく、途中切断時の再開コストが大きいです。CLI に HTTPS_PROXY が無いと、Clash のルールが正しくてもパケットが別経路へ出ます。Git 側には http.proxy を設定するか、TUN でプロセス差を吸収します。ModelScope の Python SDK も同様に、仮想環境ごとにプロキシを揃えてください。
並列ダウンロードで同一ノードの帯域を食いつぶさないよう、ジョブ数とセレクタの固定／切替を計画的に。CI から引く場合はランナーの環境変数と Clash 側をセットで見直すと早いです。
9 DNS・TUN・名前解決の食い違い
CDN や OSS のエッジは DNS 応答で変わります。ブラウザの Secure DNS と Clash 内の DoH／FakeIP を二重に有効にすると、ルールにマッチしているのに実パケットだけ別経路、という混乱の元になります。詳細は Mihomo DNS の実務記事を参照し、名前解決のパスを一本化してください。長時間転送中はセレクタの自動切替で接続が切れないよう、ジョブ中は出口を固定する運用が無難です。
10 トラブルシューティング
- Web は開くが LFS／OSS だけ失敗： ログの SNI を特定し
DOMAIN-SUFFIXまたはDOMAINを追記。CLI のプロキシ有無を確認。 - HF は通るが ModelScope だけ遅い／不通：
modelscope.cnとストレージホストの両方が同じ意図した出口か確認。 - API は動くが重み取得だけ別経路： DashScope と OSS／HF をルール上で分離しすぎていないか、セレクタ名を見直す。
- 途中で切断： ノードのパケットロスや帯域上限を疑い、ダウンロード用に別アウトバウンドを試す。
11 まとめ
2026 年も Qwen3 をはじめとする Qwen 系列は、Hugging Face と ModelScope の両方から大モデル権重を取得する開発フローが一般的です。Clash 分流では huggingface.co／hf.co と modelscope.cn を束ね、LFS・OSS・CDN をログで補い、必要なら DashScope を狭く指定してクラウド API と切り分けます。Rule Provider は便利ですが、リリース直後はローカル上書きと併用すると安定しやすいです。
分散ドメインと長時間転送に強いのは、単純な HTTP プロキシ切替より、ルールと DNS を一体で扱える Clash 互換スタックの強みです。検証サイクルを短くしたいチームほど、一度 DOMAIN-SUFFIX セットを整備する投資が効いてきます。
