api.moonshot.cnとkimi.comは同じポリシーグループにまとめてよいですか？

動かすことはできますが、切り分けのしやすさでは分離を推奨します。チャットWebは静的CDNや認証ドメインが増え、APIは長いストリーミングでプロキシ品質の影響を受けやすいからです。KIMI-WEBとMOONSHOT-APIのように用途別グループに分け、ルール右端だけを揃えると、ログ上のpolicyが読み取りやすくなります。

OpenAI互換SDKのbase_urlだけ差し替えたのにタイムアウトばかりです。Clash側で何を見ますか？

まず実際にTLSで繋いでいるFQDNを確定してください。互換エンドポイントでも、証明書のSANとSNIはapi.moonshot.cnなどベンダー固有の名前になります。Clashログで該当接続のmatched policyを確認し、意図したMOONSHOT-APIに載っているか、より広いRULE-SETやGEOIPに落ちていないかを見ます。名前解決はDNSモードとfake-ipの影響も疑います。

中国向けホストを海外出口のプロキシに流すと悪化しますか？

利用者の所在地・ISP・ノード品質次第で、往復が伸びてタイムアウトしやすくなることもあれば、逆に直結が不安定な環境ではプロキシの方が安定することもあります。地理の常識より、同一ホストでDIRECTと別出口を切り替え、ClashのログとクライアントのRTT・エラーを比較するのが確実です。

platform.moonshot.cnはログインできるのにapi.moonshot.cnだけ失敗します。

別FQDNです。ブラウザの開発者ツールやcurlでAPIホストだけpolicyが違うか確認し、DOMAIN行をAPI側に細かく足します。WAFやレート制限で403が返る場合は出口IPが原因のこともあるため、HTTPステータスとレスポンス本文をアプリログに残し、プロキシを変えて再現するかを見ます。

2026 Kimi／Moonshot APIタイムアウト：ClashでDOMAIN-SUFFIX実測

なぜ OpenAI／Anthropic 専門記事と分けて読むのか

Clash の rules は上から最初の一致だけが有効、という構文上のルールは、海外の api.openai.com や anthropic.com を想定した記事と共通です。しかし ムーンショット 周辺は、チャット製品の kimi.com、開発者向けコンソール・ドキュメントの platform.moonshot.cn、推論APIの核となる api.moonshot.cn、国際向けに案内されることのある api.moonshot.ai や platform.moonshot.ai など、証明書のSANと実ホスト名の集合 が OpenAI 線とは別系統です。ここを混ぜて「とりあえず PROXY 一括」にすると、ログ上は動いているつもりでも 意図しないノード に乗り、レイテンシ だけが伸びて read timeout に見える、という形で症状が出ます。

また、設定の寿命は 購読リンク（サブスクリプションURL） で取得したプロファイル更新とセットです。手書きルールが RULE-SET や MATCH に押し出されていないかは、購読の自動更新と同じ関心軸で定期的に確認してください。分流の共通語彙は YAMLルール分流ガイドを前提に、本稿では Kimi／Moonshot のホスト軸に絞ります。

「総タイムアウト」が指す層を分解する

利用者の体感ではすべて「遅い／切れた」に見えますが、切り分けでは次の層に分けます。第一に DNS が返るまでの遅さ、第二に TCP／TLS の確立、第三に HTTP の応答（ステータス行の有無）、第四に Server-Sent Events やチャンク転送 の途中切断、第五に SDK のタイムアウトやリトライです。Clashは主に第二層以降で どのpolicyに載ったか をログに残すツールであり、第一層は DNS fake-ip／redir-host の記事と接続して確認します。

2026年時点でも、長コンテキスト や エージェント用途 で接続を長く保つ要求が増え、プロキシ側の アイドル切断 やノード品質のばらつきが重なると、「タイムアウト値を伸ばせばよい」だけでは済まないことがあります。まずは 実FQDN と matched policy を揃えるのが先です。

ドメイン一覧：まず押さえるムーンショット系サフィックス（ログで要追補）

公開ドキュメントやコンソールでは、中国向けAPIの例として api.moonshot.cn、開発者ポータルとして platform.moonshot.cn が中心に挙がります。チャット体験の表側は kimi.com を起点に、計測・静的配信・認証まわりのサブドメインが増えることがあります。国際向けの *.moonshot.ai 系は、利用者の契約・エンドポイント設定とセットで現れるため、SDKのbase URLと実際のSNIが一致しているかを必ず確認してください。

本稿は特定のホスト名を「永久不変の正」とは断定しません。ブラウザの開発者ツール、curl -v、Clashの接続ログに出る Server Name をメモし、ルールは 実測FQDN に合わせて増やす運用が安全です。たたき台としては、WebとAPIとコンソールを分けて DOMAIN-SUFFIX を置く二層〜三層が扱いやすいです。

# Example placeholders — align policy names with your profile
rules:
  - DOMAIN,api.moonshot.cn,MOONSHOT-API
  - DOMAIN-SUFFIX,platform.moonshot.cn,MOONSHOT-CONSOLE
  - DOMAIN-SUFFIX,kimi.com,KIMI-WEB
  - DOMAIN-SUFFIX,moonshot.cn,MOONSHOT-CN
  # If your SDK uses moonshot.ai endpoints, add parallel DOMAIN lines:
  - DOMAIN-SUFFIX,moonshot.ai,MOONSHOT-AI
  # Keep these above broad RULE-SET / GEOIP / MATCH

DOMAIN-SUFFIX,moonshot.cn は下位を広く拾う一方、不要なホストまで同一出口に載せる可能性があります。逆に DOMAIN だけに絞りすぎると、公式が別ホストへ切り替えた瞬間に未命中で PROXY や MATCH へ落ちます。ここは「ログで増やす」運用が現実的です。

ポリシーグループ：KIMI-WEB と MOONSHOT-API を汎用 PROXY から分離する

実装の型としては、一般ブラウジング向けの PROXY と、チャットWeb向けの KIMI-WEB、API向けの MOONSHOT-API、コンソール向けの MOONSHOT-CONSOLE のように 用途別グループ を分け、ルール右端をそれぞれに割り当てます。url-test を流用する場合、長いストリーミング中にノードが切り替わると症状が悪化することがあるため、検証フェーズでは select で 手動固定 し、安定したら自動化、という順が安全です。

オーケストレーション基盤まで含めるとホストがさらに増えます。横断の話は LangGraph／n8n Cloud分流を参照し、本稿は Kimi／Moonshot単体 に焦点を保ちます。

DIRECT とプロキシの境界：跨境を含むときの考え方

利用者の所在地とターゲットデータセンターの組み合わせで、最適解は反転します。例えば中国本土向けの低遅延経路が期待できるホストを、海外の不安定ノードへ無意識に流していると、往復が不必要に伸びる ことがあります。逆に、利用者が海外にいて直結が不安定な場合は、品質の良いノード経由の方が成功率が上がることもあります。Clashでできるのは その接続がどのpolicyに載ったか を揃えることなので、「正しい地理学」より 同一ホストでDIRECTと別出口を切り替えて比較する のが実測では確実です。

この比較を行うときは、TUNモード と システムプロキシ の差でアプリだけ別経路になっていないかも確認します。手順の型は TUNとシステムプロキシの記事の切り分け順が使えます。

実測順：ログ → ルール順 → DNS → クライアント

第一に、失敗時の 実ホスト名 を確定する（SDKのbase URLと実際のSNIが一致しているか含む）。第二に、Clashログで matched policy を確認し、想定の MOONSHOT-API などに載っているかを見る。第三に、rules の順序が購読 RULE-SET に負けていないかを確認する。第四に、DNSモードを疑い、DNS記事の手順で名前解決を切り分ける。第五に、HTTPクライアントのタイムアウト・リトライを見直す。この順で、「プロキシをいじるべきか」「アプリをいじるべきか」がブレにくくなります。

開発者ツールでAPIを叩く場合、ターミナルやCIのプロセスが HTTPS_PROXY を見てブラウザと別出口になるケースは、Cursor／npm分流で触れている通りです。環境変数とClashの整合を揃えるのが先決です。

DeepSeek／火山稿との位置づけ DeepSeek／火山エンジン稿が deepseek.com と volcengine.com／volces.com 軸であるのに対し、本稿は kimi.com と moonshot.cn／moonshot.ai 系の 別ブランドのFQDN集合 を扱います。ルールの書き方は同じでも、ログに出る名前が違うため、記事を分けてブックマークしておくと運用が楽です。

よくあるブロック・タイムアウトの見え方（403、TLS、レート制限）

403 Forbidden や短い本文で切られる応答は、WAFやアカウント／リージョン制約、出口IPの評価が絡むことがあります。ここはClashだけでは直せず、公式コンソールの制限表示と照合しつつ、出口を変えたときに再現するか を見ます。TLS handshake failure は中間機器・誤ったプロキシプロトコル・証明書検証の失敗が混ざるため、curl -v でハンドシェイク直前まで到達するかを切り分けます。

502／503 は上流やゲートウェイの一時負荷の可能性もありますが、同時に 誤policy による再接続ループで「ずっと待つ」に見えることもあります。HTTPステータスが返っているなら、少なくともTLSとHTTPの最初の応答までは到達しています。一方、SDKのread timeoutはステータス以前に例外で落ちることが多いです。アプリログにステータス行が出るか、並行してClash側で該当接続のpolicyを確認します。

モバイル端末だけ症状が強い場合は、省電力・DNS・キャリア経路が絡みます。AndroidのノードとDNS も参照してください。

SDKのタイムアウトと再試行：指数バックオフの位置づけ

プロキシ設定が正しくても、read timeout が短いと長い生成の途中でクライアントが先に諦めます。一方、502／503 への即再試行はレート制限や重複投入のリスクがあります。実務では指数バックオフと、レスポンスヘッダの Retry-After 尊重が基本線です。Clash単体でリトライを完結させることはできませんが、誤policyへの再接続ループ を止めることはできます。

よくある質問（本文）

Grok や Perplexity の分流記事で足りませんか？

題材が異なります。当サイトでは Grok や Perplexity を別稿で扱っており、FQDN集合が交差しません。ムーンショット利用者は本稿と DeepSeek／火山を併読すると、国産LLM周りの切り分けが速くなります。

同一ノードでブラウザは速いのにPythonだけ遅い

仮想環境やIDE付属ターミナルがシステムプロキシを読んでいない、あるいは NO_PROXY の例外がズレているケースがあります。環境変数とClashのモードを揃えてから、もう一度APIホストへ単発リクエストを送ってください。

まとめ

2026年の Kimi／Moonshot API 利用では、OpenAI／Anthropic向け記事で慣れた openai.com 型の発想をそのまま当てはめず、kimi.com と platform.moonshot.cn／api.moonshot.cn、必要に応じて moonshot.ai 系など 実ログのFQDN から DOMAIN-SUFFIX と DOMAIN を積み上げるのが安全です。ポリシーグループ でWeb・コンソール・APIを分け、DIRECT と プロキシ の得失は環境で反転するため、同一ホストでpolicyを切り替えて比較し、DNS・TUN・SDKタイムアウトを順に疑うと、「総タイムアウト」という言葉の指す層がブレません。

設定は 購読リンク の更新で上書きされがちなので、エクスポートして手書きルールの位置を確認し、必要なら使い方ヘルプのモード説明と合わせて見直してください。

→ Clashを無料ダウンロード — Meta（mihomo）対応クライアントで、Kimi／Moonshot向けの出口をYAMLで再現しやすくできます。

ほかのチュートリアルは技術コラムからどうぞ。