1 背景：モデル集約 API と OpenRouter の位置づけ
ローカル IDE や自作スクリプトから複数ベンダーのモデルを切り替えたいとき、公式 SDK をベンダーごとに入れ替える代わりに、OpenAI 互換のエンドポイントへベース URL だけ差し替える運用が広がっています。OpenRouter はその代表例で、マルチモデル APIとして一つのキーでモデル ID（例：anthropic/claude-3.5-sonnet、openai/gpt-4o）を指定して推論できます。クライアント側から見ると HTTPS の向き先は主に openrouter.ai に集約される一方、ブラウザでダッシュボードやドキュメントを開くとサブドメインや静的 CDN、決済まわりの別ドメインが混ざり、単一サフィックスだけでは説明が足りない瞬間が出ます。
ここで Clash 分流の出番です。単に「プロキシ ON」ではなく、DOMAIN-SUFFIX で OpenRouter 用の束を定義し、必要なら Rule Provider としてファイルを分離しておくと、社内の直リストや GEOIP ルールとの評価順を読みやすく保てます。本稿は公式のホスト一覧を保証するものではなく、接続ログを正にルールを育てる手順と、IDE 連携時の典型的な切り分けに絞ります。利用規約・課金・API キーの取り扱いは公式ドキュメントと社内ポリシーを優先してください。
2 コンソール・API・付随ホストの分岐
OpenRouter の利用で開発者マシンから出るトラフィックは、ざっくり次のように整理できます。第一に、推論 API として openrouter.ai 上の /api/v1 系（チャット補完など）。第二に、Web コンソールとドキュメント、モデル一覧やランキングなどのブラウザ UI。第三に、ログインや課金で一般的な SaaS と同様に、決済・メール・ステータスに代表されるサードパーティのホストが混ざる場合があります。実務では「OpenRouter の本体は DOMAIN-SUFFIX,openrouter.ai でまず覆う」が出発点になりますが、ブラウザの開発者ツールや Clash の接続ログに stripe.com や status.openrouter.ai のような名前が出たら、それぞれ既存の「決済」「監視」用ルールへ寄せるか、チーム方針に合わせて追記します。
重要なのは、API とコンソールが同じレジストラドメインでも、クライアントスタックが違えばプロキシの見え方が違う点です。たとえば Python の requests は環境変数 HTTPS_PROXY を見る一方、Electron ベースの IDE は OS のシステムプロキシや独自設定を見ます。TUN モードでトラフィックを仮想 NIC に揃えるか、シェル・IDE・ランタイムに同じローカルポートを明示するかで「出口の一貫性」を先に確保しないと、ルールを足しても再現性のない挙動が残ります。
3 単一ベンダー記事との棲み分け
本サイトの日本語ブログには、ChatGPT／OpenAI、Claude／Anthropic、DeepSeek のように、単一クラウドのドメイン設計に寄せた記事が既にあります。これらは「そのベンダー直叩き」の経路を安定させるのに強く、企業アカウントや地域制限の話題とも相性がよいです。
一方、OpenRouter はフロントのホストを共有しつつ、モデル ID で上流を切り替える設計なので、ルール設計の焦点は「OpenRouter の束をどこに置くか」と「IDE が同時に別ベンダー API を直叩きしないか」の二点に移ります。本稿は前者を主役にし、後者は Cursor／GitHub Copilot 向けの記事と組み合わせて読むと、ローカル開発の全体像がつながります。
4 DOMAIN-SUFFIX：openrouter.ai を土台に
多くの環境では DOMAIN-SUFFIX,openrouter.ai 一行で、API プロキシ向けの HTTPS とブラウザのコンソール閲覧の両方を同じアウトバウンドに載せられます。サブドメイン（例：status.openrouter.ai）も同サフィックスに含まれるため、まずは広く取ってから、職場ポリシーで不要な広がりがあれば分割する、という順が安全です。上流モデルごとに別ドメインへ振り分けるのは OpenRouter 側の仕事であり、クライアントの Clash ルールは「OpenRouter への出口」を安定させることに専念すると理解しやすくなります。
すでに購読しているグローバルリストに似た行が含まれていても、MATCH や GEOIP より上に独自の OpenRouter ブロックを置かないと、意図せず DIRECT や別セレクタへ滑ることがあります。接続ログで失敗したリクエストの SNI を確認し、どのルール行に当たったかを追跡してください。企業プロキシや TLS インスペクションを挟む環境では、証明書エラーが先に出ることもあるため、ルール以前に TLS エラーを疑うのも定石です。
5 YAML 例と Rule Provider ファイル
以下は Mihomo／Clash Meta 互換の rules に追記するイメージです。AI_DEV_PROXY は手元のプロキシグループ名に置き換え、MATCH より上に配置してください。長期運用では同内容を rule-providers 経由の外部ファイルに切り出し、リポジトリでバージョン管理するとチーム共有が楽になります。コメントは仕様に従い英語のみとします。
# Place ABOVE MATCH. Replace AI_DEV_PROXY. Extend from connection logs if needed.
rules:
- DOMAIN-SUFFIX,openrouter.ai,AI_DEV_PROXY
# Optional: if your browser hits third-party checkout hosts, route them explicitly:
# - DOMAIN-SUFFIX,stripe.com,AI_DEV_PROXY
# rule-providers example (merge into your profile as appropriate):
# rule-providers:
# openrouter-ai:
# type: http
# behavior: classical
# url: "https://example.com/rules/openrouter.yaml"
# path: ./rules/openrouter.yaml
# interval: 86400
# rules:
# - RULE-SET,openrouter-ai,AI_DEV_PROXY
Rule Provider に分けた利点は、集約型ゲートウェイ固有の行を「AI 開発用」のセットとして差し替えやすいことです。グローバルな購読リストを毎日入れ替えるのではなく、OpenRouter だけを短い YAML で持ち、残りはコミュニティ Provider に任せる二層構えにすると、変更の影響範囲が読みやすくなります。interval を極端に短くしすぎないことも、購読元への負荷と設定の安定性のバランスになります。
6 Mihomo コアとログ運用
Mihomo（Clash Meta 系）コアを使う場合、外部コントローラ経由のログと、クライアント GUI の接続ビューを併用すると、ルールの当たり外れを早く潰せます。OpenRouter のような単一レジストラに見えるサービスでも、HTTP/2 の多重ストリームや長めのストリーミング応答では、ノードの輻輳やタイムアウトが表面化しやすいです。セレクタで別アウトバウンドへ切り替えて比較し、レイテンシより安定性を優先するノードを選ぶと、チャット補完の体感が変わります。
また、rule-providers を複数マージしているときは、同一ドメインが二つのセットで別アウトバウンドに割り当てられていないか、プレビューや生成結果の rules を一度ながめて確認してください。上流のモデル名が増えても、OpenRouter 側のホストが増えるとは限らない一方、ダッシュボード周りのフロントエンドはアップデートで静的アセットのホストが増えることはあり得ます。そのたびにログを正としてサフィックスを足す運用が続きます。
7 Cursor／GitHub Copilot とのプロキシチェーン
Cursor や GitHub Copilot を OpenRouter と併用するとき、IDE は GitHub・Microsoft・OpenAI など別ドメインへ同時に接続します。OpenRouter 用のルールだけ整えても、拡張機能の取得やサインインが別経路で失敗すると「AI 全体が不安定」に見えます。Cursor と Clash、Copilot と Clash の各記事で触れているように、システムプロキシと TUN、環境変数の三つのどれを信頼の線にするかを先に決めると、切り分けが速くなります。
アプリケーション設定で OpenRouter のベース URL を指した場合、ランタイムは HTTPS_PROXY を無視する実装もあります。そのときは TUN で全体を覆うか、IDE が参照するプロキシ設定を明示的に合わせる必要があります。複数ツールを行き来する開発者ほど、「OpenRouter 専用ルール」より出口の一貫性を先に揃える方が結果的に楽、というパターンが多いです。
8 DNS・TUN・社内ポリシー
名前解決とルールの結果が食い違うと、ログ上は openrouter.ai にマッチしているのに実パケットが別経路へ出る、という混乱が起きます。Clash 内の DoH、FakeIP、fallback-filter の扱いは DNS 実務記事に詳しいので、ブラウザの Secure DNS と Clash の DNS を二重に有効にして挙動が読めなくならないことだけ強調します。
TUN を有効にすると、環境変数を設定し忘れた CLI も同じルーティングに乗りやすくなります。一方で企業 VPN やスプリットトンネルと衝突する場合があるため、企業 VPN と Clash を併用する記事の考え方とあわせて、デフォルトルートの優先順位を確認してください。ストリーミング応答の途中でノードが切り替わるとセッションがリセットされるため、長い推論ジョブではセレクタを固定する運用も検討に値します。
9 トラブルシューティング
- ブラウザのコンソールは開くが API だけ 403／401： 認証ヘッダとモデル ID を確認。経路は通っているがキー不正のケースが多いです。合わせてログで SNI が
openrouter.aiに届いているか確認します。 - curl は成功するが IDE からだけ失敗： IDE がプロキシを無視していないか、別のベース URL を向いていないかを確認。TUN で揃えるか、IDE 側のプロキシ設定を合わせます。
- 課金やメール確認だけ失敗： 決済ドメインが OpenRouter 本体と別出口に落ちていないかログで確認し、必要なら
DOMAIN-SUFFIXを追記します。 - 途中で切断される： ノードのパケットロスや HTTP/2 の長時間ストリーム切断を疑い、セレクタで別アウトバウンドへ切り替えて比較します。
- ルールを足したら国内サイトが遅い：
DOMAIN-KEYWORDの広げすぎや、GEOIP,JP,DIRECTより上に誤った行が来ていないか順序を見直します。
10 まとめ
OpenRouter のようなマルチモデル APIは、開発者の手元から見れば主に openrouter.ai への HTTPS に集約されますが、ブラウザのコンソール・決済・監視など周辺ホストが絡むと、Clash 分流の評価順と出口の一貫性が成否を分けます。DOMAIN-SUFFIX で土台を作り、不足分を接続ログから Rule Provider 化してチームで共有すると、2026 年の AI 開発ワークフローでも保守しやすいセットになります。
Mihomo コアとログを前提に、Cursor や GitHub Copilot など IDE 側の記事と線でつなげば、単一ベンダー向けの記事群と重ならない切り口で全体像を補完できます。DNS と TUN の細部は専門記事に譲りつつ、まずはプロキシチェーンの再現性を取り戻すことが安定運用の近道です。
単純な HTTP プロキシの ON/OFF より、ルールと DNS を一体で扱える Clash 互換スタックの方が、モデル集約型 API と IDE の併用に強い場面が多いです。一度 OpenRouter 向けの短いルールファイルを整備する投資は、モデル ID を増やして試行錯誤するほど効いてきます。
