2026 年、Kimi（Moonshot）を安定して使う：
Web と API の Clash 分流（DOMAIN-SUFFIX と Rule Provider）

1 背景と、国産 LLM 記事群との棲み分け

2026 年時点でも、長文要約・オフィス作業補助・コード支援といった用途で、中国系プロダクトの呼び水として Kimi の名が挙がることは多いです。法人や開発者目線では、ブラウザでチャットを触りながら、同時に API キーを発行して自社スクリプトや IDE プラグインから https://api.moonshot.cn や https://api.moonshot.ai へ飛ばす、という二段展開を踏む人も少なくありません。課題は、プロキシの有無・DNS の答え・FakeIP や TUNの組み合わせによって、同じ端末上でアプリ間の挙動が揃わない点に現れがちなことです。Clash 系クライアントの「ルール＋アウトバウンド」設計に寄せておくと、トラブル時に接続ログの SNIとルール行を往復しながら追記しやすくなります。

本サイトのギークブログでは、すでにDeepSeekを始め、海外ベンダ向けのChatGPT、Geminiなど、ベンダー別にドメイン列を分けた記事が揃いつつあります。Kimi／Moonshot は、API のベース URL とチャット用ホストの最上位ドメインが deepseek.com や aliyun 系と異なるため、汎用の「海外 AI」一括ルールに頼ると漏れや過剰マッチの両方が出やすい典型例です。粗い GEOSITE 一枚より、moonshot.cn / moonshot.ai といった公式に紐づく自前の短いルールを土台にし、Rule Providerで配布用リストを分離する、という二段のほうが長期運用向きです。

2 Web・API・コンソールで触るホストを分類する

実際のホスト名はプロダクト改修で追加・廃止されるため、導入後はMihomo の接続パネルやログで、表示された SNI を都度照合するのが確実です。設計上は次の束に分けると、ルール行を書きやすくなります。

• コンシューマ向け Web（Kimi チャット）： kimi.moonshot.cn や www 等、ブラウザで長文会話の UI を表示する層。静的アセット、認証、計測のために *.moonshot.cn 配下へ分散している場合があります。
• API オープン・プラットフォーム： キー発行、料金、ドキュメント閲覧は platform.moonshot.cn が文書上の出発点であることが多いです。ブラウザでキーをコピーした直後に CLI から api へリクエストする流れでは、管理画面と API を同じ出口に載せると体験が揃います。
• OpenAI 互換 API（.cn 側）： 多くのサンプルでベースは https://api.moonshot.cn/v1 です。SDK は HTTPS_PROXY を解釈する例と、独自スタックで OS プロキシを無視する例が混在します。
• 国際向け .ai エンドポイント： ドキュメント上 https://api.moonshot.ai 系が案内される場合、中国本土向け .cn と最上位サフィックスが異なり、ルールで両方の DOMAIN-SUFFIX を用意しないと片系だけ DIRECT に落ちる、という差が生じます。どちらを使うかはアカウント条件と契約に従います。
• 企業サイト・ブランド： moonshot.cn トップの案内、採用・報道向け子ドメインなど。チャット用と混ざっても、広めの DOMAIN-SUFFIX,moonshot.cn を一枚敷けば、静的ページも同じ方針に乗りやすいです。

DeepSeek や通義系との違い（キーワード衝突を避ける）

月之暗面（企業名の中国語表記）の Moonshot では、deepseek.com や dashscope 系と交差するドメインは限定的です。既存の「国産大モデル」専用リストに DeepSeek だけ入っていた場合、Kimi を併用するなら 同じ policy 行に moonshot. 系を足すか、PROXY-KIMI のような専用セレクタを分け、ログで帯域を比較する、といった拡張が素直です。

3 ルールモードとプロキシグループの置き方

推奨は mode: rule です。Kimi 向けに PROXY-KIMI などのセレクタ／url-test グループを一つ挟めば、長文ストリーミングの挙手が悪いノードを比較しやすくなります。グローバル方式は中国本土向きサービスまで遠回りし、DIRECT 固定では api 系だけ揺れる、といった板挟みに陥りがちなので、少なくとも moonshot.cn / moonshot.ai については意図した出口へ明示的に揃える方が安全です。

購読のテンプレートに「中国本土サイト」「海外サイト」等の大きな MATCH 行がある場合、その前段に Moonshot 用の DOMAIN-SUFFIX や RULE-SET を挿入し、意図せぬ別アウトバウンドに吸われないようにします。社内利用では、IDE 全般のプロキシはCursor 記事の方で補完できます。Kimi 主体であっても、同じ mode: rule と TUN か環境変数のどちらを正とするかを README に揃えておくと、チーム内の再現性が上がります。

4 YAML に書く例と Rule Provider

以下はイメージです。グループ名や既存行との衝突は、バックアップを取ったうえで手元の購読に合わせてください。行コメントは英語のみにします。

# Example: route Kimi / Moonshot properties
rules:
  - DOMAIN-SUFFIX,moonshot.cn,PROXY-KIMI
  - DOMAIN-SUFFIX,moonshot.ai,PROXY-KIMI
  - DOMAIN,api.moonshot.cn,PROXY-KIMI
  - DOMAIN,api.moonshot.ai,PROXY-KIMI
  - DOMAIN,platform.moonshot.cn,PROXY-KIMI
  - DOMAIN,kimi.moonshot.cn,PROXY-KIMI
  # rule-providers:
  #   moonshot:
  #     type: http
  #     behavior: classical
  #     url: "https://example.com/rules/moonshot.txt"
  #     path: ./rules/moonshot.yaml
  #     interval: 86400
  # rules:
  #   - RULE-SET,moonshot,PROXY-KIMI

DOMAIN-SUFFIX 二行で moonshot.cn / moonshot.ai の下位を一括覆い、api・platform・kimi のように高頻度にログに出るホストを DOMAIN で明示する二段にすると、新人でも読みやすいです。Rule Provider のリモート先は信頼できる配布元に限定し、更新間隔と手元追記行の前方優先（上に行くほど先に照合）を意識してください。キーワード系の DOMAIN-KEYWORD,moonshot は無関係のサイトを巻き込みやすいため、本番用途ではサフィックスとログ追記を優先します。

コンテナや CI から API を呼ぶ場合、プロキシを設定しないと OS のトラッフィック分割に任せます。シェルからは https_proxy 系を併用するか、TUN モードで仮想 NIC から同一ゲートに流し、環境差を減らす方法が扱いやすいです。

5 DNS・FakeIP・TLS を同時に考える

ホスト数は多くはありませんが、DNS の答え方が FakeIP と実 IP で食い違うと、ブラウザは成功しても CLI だけ解決失敗、という二重挙動が起き得ます。Mihomo では nameserver と fallback、Meta カーネル DNS 実務記事で扱うように fallback-filter を定番化しておき、OS の DNS と二重定義にしないのが近道です。特に .ai / .cn の権威の差は、一見した地理と実経路のイメージとズレることがあります。

TLS 層では、SNI が api.moonshot.cn であっても、企業中間プロキシのインスペクションで証明書チェーンが合わない、といった事象は他クラウド API と同様に起こり得ます。エラー文が証明書関連なら、まず職域ポリシーと信頼ストアを疑い、プロキシ抜きの場合は、ルールで意図せず DIRECT へ落としていないかをログで照合します。API キーは平文のリポジトリに入れず、秘密管理系や CI のマスク付き変数に限定するのは共通の原則です。

6 動作確認の進め方

まずブラウザで kimi のチャットを開き、ログイン（該当する場合）と送受信が最低限行えるところまで持ち上げます。同じ端末のターミナルで、利用予定のベース（api.moonshot.cn か api.moonshot.ai）に向けた TLS 接続の確立、続けてオプションヘッダ付きの軽量 GET／POST が返るかを見ます。ここでだけ失敗するなら、ルールより先に環境変数未設定か CLI のプロキシ無視を疑い、セレクタで出口を一つずつ切り替えて再現性を比較します。OpenAI 互換のパス名やヘッダ形式は、必ず当該日のドキュメントを正とし、古い日本語解説のコピーだけに頼らないでください。

レート制限と課金

ネットワークが正常でも、利用枠超過で 429 や課金エラーは返ることがあります。ダッシュボード上の消費量と突き合わせ、バッチ処理を組むなら指数バックオフやリトライ上限をアプリ内に入れ、単一ノードへの固執を減らすと、分流が正しいかの切り分けがしやすくなります。

7 トラブルシューティング

• ブラウザは成功・CLI だけ失敗： システムプロキシと HTTPS_PROXY、TUN の有無のどれが CLI に効いていないかを再確認。シェル起動方法によっては、GUI で設定した変数が継承されていないパターンがあります。
• 401 / 403 / Invalid key： ルール以前に、キー期限・IP 制限・ヘッダの打ち間違い、複数アカウント取り違えを疑い、プラットフォームで再発行して突き合わせます。
• ストリームが途中で途切れる： 採用ノードの損失率や、長接続の切断。セレクタを変え、別リージョンに出るか比較します。
• 新子ドメインでだけ失敗： ログ上の SNI を DOMAIN もしくは DOMAIN-SUFFIX として追記し、Rule Provider のリストに反映できるかを検討。
• ルール追加後、国内向け他サイトが遅くなった： GEOIP,JP,DIRECT 等との行順を点検し、意図しない前方マッチが起きていないか確かめます。

8 まとめ

Kimi（Moonshot、中国語名で月之暗面とも）を、チャット用の moonshot.cn 系と、api.moonshot.cn／api.moonshot.ai を含む API プロキシ経路の両方にわたり、Clash 分流のルールで一貫させると、ブラウザ・IDE・CI をまたいだ挙動の再現性が上がります。粗いカテゴリ分けだけに頼ると漏れと過剰を両方生みがちなので、公式に沿った DOMAIN-SUFFIX を核に、必要なら Rule Providerでチーム内配布用リストを分離し、DeepSeek 記事やQwen 系のような国産大モデル専用の枠と併用して整備するのが現場向きです。

まずは上記サフィックスと API 用 DOMAIN を YAML に加え、接続パネルで SNI の取り漏れを確認し、DNS の深掘りはDNS 解説へ回す、という段取りで十分です。ルール行の追加とログの往復に慣れれば、他ベンダの HTTPS API にも同じ手順を転用しやすくなります。

多機能なルール付きクライアントは、一見オーバースペックに見えて、長文ストリームや二系統ドメイン（.cn / .ai）をまたいだ通信ほど、出口と名前解決を一つの設定言語に揃えられる利点が効いてきます。Kimi のような、オフィス向け需要の高い国内発モデルほど、早めにテンプレを固定しておく価値があります。

→ 無料で Clash をダウンロードし、Kimi（Moonshot）の Web と API の経路を揃えて整える