OpenRouter がタイムアウト？Clash で openrouter.ai API を分流する実測ステップ（2026）

OpenRouter と Clash：開発者プロキシの「API だけ詰まる」すきま

2026 年、複数の大規模言語モデルを1 本の API キーから選べるモデルルーティング型のサービスが、個人開発から小規模チームまで広く使われています。その代表格のひとつが OpenRouter（公式サイトや API が openrouter.ai ドメイン配下に載るプラットフォーム）です。ブラウザで料金やモデル一覧はすぐ開けるのに、curl や IDE、バックエンドからの HTTPS リクエストだけがタイムアウトしたり、TLS ハンドシェイクで止まったり——そんなとき、原因が「プロキシを完全に切ると通る」タイプなら、ブロックというより出口の品質と名前解決、そして Clash の分流（ルールでホストごとに出口を変える設計）の噛み合わせを疑うのが早いです。

本稿は、すでに公開している Cursor IDE 向けの分流記事と役割を分け、OpenRouter のドメインと API エンドポイントに焦点を当てます。エディタ周辺の CDN や別ホストは Cursor 記事のほうが詳しいため、ここでは「openrouter.ai に向くトラフィック」を中心に、ログと実測で追える手順に絞ります。

なぜ「画面は速いのに API だけ遅い」のか

ダッシュボードや静的ページは軽い HTML／アセットで済む一方、チャット補完やストリーミング応答は長い HTTPS 接続に載り、途中のノードが不安定だとクライアント側では単なるAPI タイムアウトに見えます。また、SDK や CLI が参照するベース URL がブラウザのブックマークと同じホストとは限らず、環境によっては openrouter.ai 直下の /api/v1/... 系へ集約されていることが多いです。購読ルールが「海外サイトをまとめて 1 つの select」のままだと、軽いリクエストと重いストリームが同じ出口に載り、後者だけが律速になることがあります。

さらに、エラーメッセージが TLS や証明書まわりに見える場合でも、実体は「途中のプロキシやキャリアが長いセッションを切っている」「解決した IP が意図しない経路に載っている」など、ネットワーク経路の問題であることが少なくありません。そこで DOMAIN-SUFFIX でサービス本体側を明示的に切り出し、用途に合うプロキシグループへ寄せると改善しやすいです。

注意：エンドポイントやドメイン構成は変更され得ます。本稿の一覧は設計の出発点であり、実際の接続先はクライアントのログやネットワークキャプチャで確認してください。利用規約・課金・法令はご自身の契約と環境に従って判断してください。

コピー用：openrouter.ai 周辺のホスト例

実務の出発点として、次のような DOMAIN-SUFFIX を挙げます。クライアント（公式 SDK、サードパーティラッパー、自前 HTTP）によって追加ホストが出るため、タイムアウト時は必ず接続ログで足し引きしてください。

  • サービス／API の基底：openrouter.ai（Web と API が同じサフィックス配下にまとまりやすい典型）
  • サブドメイン：環境によって api.openrouter.ai のような名前がログに出る場合は、上位の openrouter.ai 1 行で覆えることが多いが、実測で別ホストがあれば DOMAIN 行で補強する
  • 決済・認証まわり：ダッシュボード連携で別ドメインが増える場合がある。失敗しているリクエストのホスト名を優先してルールに追加する
  • CDN や静的配信：ブラウザだけ通して CLI だけ失敗するときは、API ホストが静的配信と分離されているかをログで確認する

ルールの型そのものはルール分岐の詳解ガイドと共通です。DOMAIN-KEYWORD,openrouter のような広い書き方は、意図しないホストまで同じ出口に載せる恐れがあるため、まず DOMAIN-SUFFIX,openrouter.ai を優先してください。

OpenRouter 専用プロキシグループを切る理由

デフォルトでは、海外向けトラフィックが一つの url-test や select にまとまっていることが多いです。動画視聴や一般ブラウジングと同じ出口に、長めの API セッションが載ると、帯域の輻輳や事業者側の挙動の影響を受けやすくなります。OPENROUTER_PROXY のような名前の独立プロキシグループを切り、openrouter.ai 向けトラフィックだけそこへ流すと、(1) 一般トラフィックのノード切り替えと独立して低遅延・高安定の出口に固定しやすい、(2) ログ上でどのホストがどの出口か追いやすい、(3) 「ダッシュボード用と API 用で出口を分ける」といった運用にも展開しやすい、という利点があります。

評価順：OpenRouter 行をどこに置くか

Clash 系の rules: は上から順に評価され、最初の一致で打ち切られます。OpenRouter 向けの行を末尾に追記したつもりが、上段の GEOIP や巨大な RULE-SET に先に飲み込まれている——というのは典型的なパターンです。より具体的な行を、大雑把な締め行より上に置き、保存後は順序を目視してください。外部ルールプロバイダーを併用している場合、明示ルールが埋もれていないかも確認が必要です。

YAML の骨格例（概念サンプル）

キー名やインデントは利用中のコア・GUI に合わせてください。ここでは OPENROUTER_PROXY を用意し、rules から参照するイメージだけ示します。

proxy-groups:
  - name: OPENROUTER_PROXY
    type: select
    proxies:
      - 🇺🇸 低遅延・長接続向け
      - 🇯🇵 安定
      - 🌐 自動選択

rules:
  - DOMAIN-SUFFIX,openrouter.ai,OPENROUTER_PROXY

このあとに社内ドメインや国内 GEOIP、最後に MATCH などを続けます。グループ名は既存構成と衝突しないようリネームしてください。追加入力がログに出たら、そのホスト用に DOMAIN 行を足すのが安全です。

モデルルーティングと「どのホストへ飛ぶか」

OpenRouter の価値は、リクエスト本文でモデル名を切り替えつつ、認証と課金の窓口を一本化できる点にあります。クライアントから見ると、多くの呼び出しは最終的に openrouter.ai 上の REST エンドポイントへ向かい、サーバー側で各プロバイダーへモデルルーティングされます。したがって Clash 側の設計では、「上流のモデル名」より先にクライアントが実際に接続しているホスト名をログで押さえるのが実務的です。別サービス（直接 OpenAI や Anthropic の公式 API を叩く設定など）へ向いている場合は、ホスト名が openrouter.ai ではなくなるため、本稿のルールとは別ブロックが必要になります。ChatGPT／Claude 向け分流と併せてホストごとに整理してください。

ノード選定：タイムアウトを減らす観点

遅延テストの数値だけが良くても、途中で切断が多いノードではAPI タイムアウトに見えることがあります。実務では次を意識すると切り分けが速いです。

  • 遅延より切断の少なさ：同一プロバイダー内で地域やプロトコル（REALITY／Hysteria2 等）を変え、ストリームが最後まで流れるか比較する
  • CLI と IDE を分けて観測：片方だけ失敗するときは、HTTPS_PROXY や TUN 未捕捉プロセスが原因のことが多い。OS 全体へ透過させる手順はTUN モード完全ガイドが参考になります
  • GEOIP との競合：解決済み IP が別ルールに先にマッチし、DOMAIN-SUFFIX より IP 側が優先されていないか確認する

DNS・TLS：タイムアウトに見える別要因

ルールはドメイン行と IP 行が混在します。DNS が Clash の想定とずれていると、YAML は正しそうでも実接続は別経路に落ちます。典型例は次のとおりです。

  • ブラウザや OS の Secure DNS が Clash 外で先に解決し、想定外の IP が宛先になる
  • Fake-IP と、一部プロセスだけ直叩きするシステム DNS が混在し、マッチと実接続の関係が追いにくくなる
  • 中間プロキシやフィルタが長い TLS セッションを切り、クライアントではタイムアウトや証明書エラーに見える

対策の方向性は「名前解決の経路をできるだけ一本化し、TUN や DNS ハイジャックを併用するならその前提でルールを読む」ことです。設定変更後は DNS キャッシュのクリアと、OpenRouter への再接続をセットで確認してください。

検証チェックリスト（そのまま試せる順序）

  1. 失敗しているクライアント（curl、SDK、IDE プラグイン）のログから、実際に接続しようとしているホスト名をメモする
  2. Clash の接続ログまたはダッシュボードで、該当ホストが OPENROUTER_PROXY（または同等のグループ）に乗っているか確認する
  3. 同じプロファイルのままノード地域やプロトコルだけを切り替え、タイムアウトの再現性が変わるか比較する
  4. ブラウザでは通るが CLI だけ失敗するときは、プロキシ環境（環境変数・TUN・システムプロキシ）を揃えて再試行する

よくある誤解と切り分け

DOMAIN-KEYWORD で雑にまとめる

手早い反面、無関係なホストまで同じ出口に載り、期待しない挙動の原因になり得ます。まず openrouter.ai のような狭い DOMAIN-SUFFIX から始め、ログで漏れを足してください。

ルールを足したのに効かない

多くは順序かグループ名の綴りです。外部 RULE-SET を大量に載せている場合、明示ルールが下に埋もれていないかを確認してください。

OpenRouter ではない上流へ向いている

環境変数や設定ファイルで、別のベース URL が指定されていると、ホスト名が openrouter.ai になりません。エラーの前にリクエスト URL を確認してください。

まとめ

2026 年の開発者ツールチェーンでは、OpenRouter のように多モデル集約と1 本のキーを組み合わせる構成が一般的になりつつあります。「完全に繋がらない」より、API だけタイムアウトの相談が目立つ場合、原因の多くは単一ノードの遅延数値だけではなく、openrouter.ai 向けトラフィックが意図しない出口や不安定な経路に載っていることにあります。DOMAIN-SUFFIX でドメインを明示し、独立プロキシグループへ寄せ、評価順序とDNS（Fake-IP・Secure DNS）をセットで設計すると、長い応答やストリームの成功率が体感しやすく上がります。

用語や汎用手順は当サイトのチュートリアル・ドキュメントも参照できます。オープンソースの挙動を追う用途では GitHub 上のリポジトリも有用ですが、日々のクライアント入手と更新は説明の揃った配布ページのほうが取り違えが少ないです。Windows／macOS／Linux／モバイル向けビルドはダウンロードページから環境に合わせて選べます。ルールの基礎はルール分岐の詳解、OS 全体へ透過的に効かせたい場合はTUN ガイドと併読すると、本稿の設定がすぐ実装に落ちます。用途別にトラフィックを制御できる点が、チーム開発では特に実用的です。→ Clash クライアントを無料でダウンロードし、OpenRouter 向け分流を試す