📖 チュートリアル ⏱ 約19分で読めます

2026：Mistral／Le Chat を Clash で安定利用——欧州サイト・API のドメイン分流と DNS の段階実測

Mistral AI はフランス発の生成モデル提供者として、Le Chat のウェブ体験と 開発者向け API の両方で利用が広がっています。2026 年時点でも、ブラウザのチャット画面・console.mistral.ai・api.mistral.ai・ドキュメントや静的アセット用の CDN が別々の FQDNとして現れやすく、Clash（多くの場合 Clash Meta／Mihomo コア）では分流ルールが狭すぎる、または DNS（fake-ip と DoH）と噛み合っていないと、「トップは開くのに会話だけ失敗」「curl では通るのに IDE からだけタイムアウト」といった部分的成功に見えがちです。本稿は ChatGPT／OpenAI API 向け記事や Claude／Anthropic 向け記事とはホスト集合を明確に分離し、欧州サービスとしての Mistral／Le Chat に寄せたDOMAIN 束ねとRule モードでのログ実測までを日本語で整理します。エッジ構成は更新で変わり得るため、以下の YAML は出発点の例とし、自分の環境の接続ログを正としてください。契約・利用規約・職場ポリシーは必ず優先してください。

症状の型：ウェブ・コンソール・API を分けて観察する

Le Chat をブラウザで開いたとき、(1) ランディングや会話 UI の枠は表示されるがストリーミング応答や履歴取得だけがタイムアウトする、(2) console.mistral.ai のログインや課金まわりだけ別挙動になる、(3) ローカルから curl で api.mistral.ai は通るが、Python／Node の SDK や CI からだけ失敗する、というパターンに分けられます。(1) はフロント用ホストとバックエンド API 用ホストが DIRECT のまま、あるいは遅い／不安定なノードに分散していることが多く、(2) は認証や決済で別ドメインが挟まりルールの下の方で RULE-SET に飲まれている、(3) はターミナルと IDE／コンテナのプロキシ環境変数の差、または API だけ別のサブドメインがログに出ている、が典型です。開発者ツールのネットワークタブ、あるいはコアの接続ログで失敗しているリクエストのホスト名をメモしてからルールへ反映すると、当てずっぽうが減ります。

用語の整理は チュートリアル、ルールの書き方は カスタムルールの解説 と併読するとスムーズです。Web と API を同じ束ねで扱う切り口は DeepSeek 向け記事とも近いですが、対象ドメインは完全に別物なので混同しないでください。

分流の土台：proxy-groups に「Mistral 用」を切る

購読テンプレの PROXY をそのまま指すより、MistralProxy のような用途名のグループを select または url-test で用意し、rules からは常にそのグループ名を参照するのが運用しやすいです。欧州ロケーションの出口を期待する場合でも、まずはレイテンシと TLS エラー率が安定したノードに揃えるのが先決です。認証だけ別出口にしたい場合は、ログインで観測した IdP 用ホストだけ別グループに分ける、といった切り方もありますが、最初は束ねて動作確認してから狭めると切り分けが楽です。ネストや型の詳細は proxy-groups のガイド を参照してください。

💡 ヒント テンプレのグループ名と rules 内の綴りが一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」状態になりがちです。

ホストの考え方：Le Chat・コンソール・API（出発点）

Le Chat のブラウザ体験では chat.mistral.ai が中心になりやすく、製品アップデートに伴い関連するサブドメインが増えることもあります。開発者コンソールでは console.mistral.ai、REST API のベースとして公式ドキュメントで示される api.mistral.ai が前面に出ます。ドキュメント閲覧では docs.mistral.ai、コーポレートやランディングでは mistral.ai 本体や www.mistral.ai が現れやすいです。静的アセットやサードパーティの計測・フォントなどが別ホストに分かれると、一覧だけ整えても一つ足りない状態が残ります。

方針として、(A) 上記をまとめて MistralProxy に寄せるのがシンプル、(B) まずは DOMAIN-SUFFIX,mistral.ai を優先し、ログに出た例外だけ DIRECT や別ポリシーを足す、のどちらかから始めると安全です。サフィックス一括は手早い一方、将来 mistral.ai 配下に無関係なホストが増えた場合の影響範囲が気になるなら、(A) のようにログで必要な名前だけ列挙する運用が向きます。ルールの上から先にマッチした行が優先されることは カスタムルール記事 のとおりです。コミュニティの RULE-SET と併用する場合も、Mistral 向けの例外を上に積むと意図した出口に寄せやすくなります。

rules:
  # Examples only — tune group name (MistralProxy) and domains to your logs
  - DOMAIN-SUFFIX,chat.mistral.ai,MistralProxy
  - DOMAIN-SUFFIX,console.mistral.ai,MistralProxy
  - DOMAIN-SUFFIX,api.mistral.ai,MistralProxy
  - DOMAIN-SUFFIX,docs.mistral.ai,MistralProxy
  - DOMAIN-SUFFIX,mistral.ai,MistralProxy

上記に無いホストがログに出たら、それが次に追加すべき行です。短縮 URL や計測用の別ドメインがリダイレクトで混ざる場合は、開発者ツールで最終的に叩かれているホストを基準にしてください。地域・契約・企業プロキシによっては、経路を整えても利用が制限される場合があります。技術的な経路整備とアカウント側の許可は別問題なので、ダッシュボードのエラーコードも併記して判断してください。

DNS と DoH：fake-ip とルールを揃える

分流ルールが正しくても、DNS が期待と違う応答を返すと、タイムアウトや証明書エラーに見えます。Clash／Mihomo 系では dns ブロックの fake-ip、redir-host、DoH の有無が挙動に直結します。テンプレの推奨設定から大きく外すと切り分けが難しくなることもあるため、まずは購読既定で再現する→ 問題が続くときに、(1) DoH エンドポイントの信頼性とレイテンシ、(2) nameserver-policy で mistral.ai だけ別 DNS に寄せる、(3) IPv6 の有無と OS の解決順、を一度に一項目ずつ変えるのが安全です。

ブラウザ独自の Secure DNS（DoH）と Clash 側の DNS が二重に効いていると挙動が読みにくいので、比較時にはブラウザ側を一時オフにする方法もあります。Windows で一部 UWP やストアアプリがプロキシを読み違える場合は Windows 11 の UWP とシステムプロキシ記事も参照してください。CLI やコンテナから API を叩く場合は、HTTPS_PROXY 等が空だとルールの外に出ることがあるため、シェルと IDE の設定を突き合わせます。そのときは TUN モード でトラフィックをコア側に寄せる案も検討してください。

動作モード：Rule・Global・Direct の使い分け

Rule が日常運用の基本です。Global は「すべてをプロキシへ」として、一時的にルール不足かノード品質かを切り分けるのに便利ですが、国内サイトまで遠回りになるため常時利用はおすすめしません。Direct はベースライン計測用に、Clash を事実上オフに近い状態で挙動を見るときに使います。Le Chat だけ不調なときは Rule に戻し、該当ホストが意図したポリシーにマッチしているかをログで確認するのが定石です。トンネル型 VPN との違いは Clash と VPN の比較 も参照してください。

⚠️ 注意 本稿は正規アカウントと利用規約を前提とします。職場・教育機関ではプロキシ迂回が禁止されている場合があります。技術的に可能でも、規程と管理者の指示を優先してください。

実測手順：ログで「宛先」と「採用ルール」を確認する

  1. 1

    Baseline（Direct または Clash 停止）

    まず Direct でブラウザから Le Chat を開き、同じ端末から開発者ツールで主要リクエストのホスト名を控え、症状が再現するかを記録します。続けて curl -v https://api.mistral.ai/v1/models のように API の疎通も、許可された認証ヘッダの有無に注意しながら切り分けます。

  2. 2

    Rule に戻し、チャット・コンソール・API でログを読む

    会話投入、キー発行画面、SDK からのリクエストのそれぞれについて、接続一覧／コアログで向いているドメインとマッチしたルール行（またはポリシー名）をメモします。リストにないホストが出たら、それが次に追加すべき行です。

  3. 3

    一行ずつルールを足して再計測

    DOMAIN または DOMAIN-SUFFIX を追加し、同じ操作を繰り返します。一度に大量変更すると効いた変更が特定できません。意図と違う行にマッチしているときは、より具体的なルールを上へ移動します。

  4. 4

    DNS ログがあれば併記する

    名前解決結果がおかしい場合はルールより先に DNS を直します。クライアントが DNS ログを出せない場合は、ログレベルを上げる、別ツールで確認するなど環境に合わせてください。

この繰り返しが本稿でいう「段階実測」です。検索で見つかるドメイン一覧は参考にとどめ、自分のログを正としてメンテすると、UI やエッジ変更にも追従しやすくなります。別プロバイダの整理は Grok 向け記事 や IDE クラウド依存向け記事で別ホスト集合として扱っているため、混同せず参照してください。

よくある質問

ルールを足したのに API だけ失敗する

api.mistral.ai より下位のホストや、SDK が内部で参照する別エンドポイントが DIRECT に落ちているパターンです。失敗した URL のホストをログから拾い、DOMAIN ルールをリスト上位に置いてください。

DOMAIN-SUFFIX,mistral.ai にしたら他の通信まで変わった

サフィックス一括は広くマッチします。影響が大きい場合はログで実際のホストを列挙し、必要なサブドメインだけに狭めてください。

「欧州 AI」全般の科普記事と何が違う？

本稿は Mistral／Le Chat 向けに具体的な FQDN と API ベースを出発点として束ね、Clash のルール順・DNS・ログ実測まで踏み込んだ手順記事です。規制や市場の概説だけの記事とは目的が異なります。

まとめ

Mistral AIのようにブラウザの Le Chatとconsoleとapi.mistral.aiが分かれやすい体験では、分流ルールを用途別に整理し、DNS（DoH を含む） と Rule モードでのログ検証をセットにすると、「枠は見えるのに中身だけ不安定」といった症状に対処しやすくなります。本稿のドメイン例は出発点であり、ログに基づきルールを育てることが長く使うコツです。生成系の別路線は ChatGPT／OpenAI API 向け記事、動画生成まわりは Sora 向け記事の切り口とも役割が異なります。

クライアントの入手は 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。ソースコードや Issue は GitHub でも参照できますが、インストールパッケージの主入口は本站に揃えるのがおすすめです。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。用途ごとに出口を切り替えられる点では、端末全体を常時トンネルする汎用 VPN に比べ、Clash の運用体験が一段整理されやすい場面が多いです。

→ Clash を無料ダウンロードし、Mistral／Le Chat 向けの分流と DNS を試す