OpenRouter API が総タイムアウト気味？モデルゲートウェイ域名を Clash（mihomo）で分流し、開発者向けプロキシ経路を安定させる（2026）

1. なぜ「ゲートウェイなのに」タイムアウトが断続するのか

第一の理由は、ユーザーが意識しているホスト名が一つでも、実際の TLS 接続は複数に分かれることです。ダッシュボードの HTML、JavaScript バンドル、計測スクリプト、外部の認証ウィンドウへ誘導されるフローなどが、同一ドメインのパス配下に見えても、別名の CDN エッジへ向くことがあります。api.openrouter.aiのような API エンドポイントだけをプロキシに載せ、フロントの残りが直結のままだと、画面は開くのに鍵の保存や課金画面の XHR だけが固まるといった非対称な症状が起きます。

第二に、OpenRouter 自体が「どの実モデルにも同じレイテンシ」とは限らないというアプリ側の性質があります。上流プロバイダのレート制限や地理的ポリシーはゲートウェイの外側にあり、同一 API キーでもモデルごとに失敗種別が変わることがあります。その区別つきにくいログをすべて経路のせいにまとめてしまうと、プロキシ設定を増やしても芯が残ります。

第三に、url-test や自動フォールバックで全体を回しているとき、OpenRouter 向けだけ別ノードへ落ち続ける細い抜け道が残っている典型です。MATCH より上に DOMAIN ルールが無い、またはルール評価順が購読テンプレの末尾固定で上書きできていない場合、リクエストごとに遅延のばらつきが大きい出口へ分散し、体感では「API が不安定」の一点に収束します。まずコアログでホスト単位にどの proxy-groups が選ばれたかを見ることが近道です。

2. 既存シリーズ記事との違い（IDE・npm・単一クラウド）

当サイトでは、Cursor 向けの IDE・拡張・npm エコシステム、Gemini CLI と Google 側パッケージ取得、Model Context Protocol と npm／GitHubなど、開発者が毎日触る名前空間ごとに稿を分けています。OpenRouterはそのいずれとも重なり得ますが、本稿はモデルゲートウェイとしての openrouter.ai 系サフィックスと、ログに現れた関連ホストを束ねる観点が主題です。VS Code 拡張や社内 npm だけを直したくて MCP 側を読み、ここだけを読んでもゲートウェイの背後にある静的ドメインは足りません。逆も然りです——両方のログが出たら両方見るのが運用になります。

Anthropic や単一クラウド特化稿とはホスト集合が異なり、チャット製品ひとつの固定 IP 神話に寄せない方が長期的にメンテしやすいです。サービス側の構成変更は開発者ニュースより先にログに現れるため、本稿でも「この一覧が永久不変」とは約束しないスタンスを明示します。購読の入れ替えとセットで読み、実際にマッチさせたい名前を足してください。

サービス規約順守やアカウント状態は、本稿が扱う出口と名前解決の外側にあります。HTTP 応答本文に明示的な拒否がある場合は、プロキシの前に順番を並べ替えてください。

3. まず押さえるドメインと「ログで足す」前提

出発点として、多くの利用者環境ではopenrouter.aiおよび*.openrouter.aiに API と管理画面の本体が載る構成が見られます。ただしフロントの最適化の都合で別サブドメインやサードパーティの読み込みが増えることはよくあり、ここだけをDOMAIN-SUFFIXしたあとにも開発者ツールのネットワークタブに赤い行が残ることがあります。残ったホスト名をその場で YAML に追記する習慣が、運用ではいちばんコスト効率が高いです。

認証や課金で広く一般に使われる決済／本人確認ドメインへ遷移する場合があります。それらまで同一の開発者策略に広げすぎると、国内サイトの購読更新や別仕事まで同じ遅いノードへ乗ってしまう副作用が出やすいです。広い suffix を安易に足すより、ログに名前が現れたときだけ足す方が安全というのは MCP・GitHub 稿でも繰り返している原則と同じです。

ルールの評価順は ルールルーティング解説のとおり、具象的な DOMAIN 行ほど上位に置くのが鉄則です。GUI によっては「追記」と「prepend」の意味が別になるため、並びが期待どおりかを一度だけ確認すると事故が減ります。

4. mihomo ルール例：OPENROUTER 策略へ DOMAIN-SUFFIX

実務では「モデルゲートウェイ用」または「開発者共通」など名前のわかりやすい策略グループを一つ決め、その中にチーム共有の安定ノードまたは低遅延 url-test の別名をぶら下げます。以下は構造サンプルです。プロキシ名とドメインは環境で置き換え、コメントは英語です。

# proxy-groups: dedicate one bucket for gateway traffic
proxy-groups:
  - name: OPENROUTER
    type: select
    proxies:
      - LOW_LATENCY_ASIA
      - NODE_TEAM_DEFAULT
      - DIRECT

# rules: keep above broad GEOIP/MATCH — verify order in GUI
rules:
  - DOMAIN-SUFFIX,openrouter.ai,OPENROUTER
  - MATCH,PROXY

ブラウザ以外に単体のプロセスだけを分けたい場合は PROCESS-NAME の併用もありですが、OS によって実行ファイル名が異なるので、ログの綴りに合わせてください。TUN 利用時はトラフィックがそもそもコアに入っているかも先に確認します。TUN モードの解説と合わせ、ループやスプリット設定の競合がないかを見ます。

HTTPS が IP 評価のまま進みドメインルールに届かないときは DNS ではなくSniffer や SNI側の話になることがあります。症状がそれらしいときはSniffer とログの稿へ進んでください。この稿ではゲートウェイ名がログに載る前提で進めます。

5. 策略グループ：固定出口と url-test の選び方

総じてレイテンシが読めないクロスボーダー回線では、自動選択だけに任せず「このゲートウェイはこのノード」のメモがあるとチーム開発が楽です。selectで固定すると逆に単一経路の障害に脆くなるので、親グループとして url-test、子として手動選択の二段構えにする構成もあります。いずれにせよDOMAIN-SUFFIX でゲートウェイを先に引き離すことが前提です。

OpenRouter で長いストリーミング応答を扱うと、単純な HTTP レイテンシより経路のアイドルタイムアウトが表面化することがあります。商用ノード側のタイムアウト値までここでは触れませんが、同じモデルでも短い応答だけ成功する場合はログに残る切断理由とセットで上流ドキュメントを当たるべきです。プロキシで「だけ」変わるなら複数経路での比較が意味を持ちます。

チーム開発ではこの稿のグループ名を README に固定文言で載せるだけでも、個人環境ごとのドラフト設定差による切り分け地獄を減らせます。mihomo の表現力は自由度が高いので、自由度の分だけ口頭伝承を文書とログで置き換えるのが運用です。

6. DNS（fake-ip）とブラウザ・OS の二重解決

enhanced-mode: fake-ipのもとでは、名前解決のパイプラインとルール評価のパイプラインが密接につながります。ブラウザのセキュア DNS が先に名前を確定してしまうと、コア側のログでは綺麗に見えているつもりが、画面上だけ期待と違う出口に繋がることがあります。Windows とブラウザの組み合わせではセキュア DNS とシステム代理の稿が詳しく、macOS での観察の型は同系列の環境セットアップ記事が参考になります。

DoH と fake-ip の整合だけを深く踏み込みたい場合はClash Meta の DoH 稿を読み替え、「上流を DoH にしたうえで、ブラウザが二重に握らない」順に戻してください。fake-ip と redir-host の哲学比較自体は対照稿に譲り、本稿ではゲートウェイのルール評価に焦点を置きます。

名前解決の結果が安定してもICMP ではなく HTTPS のハンドシェイクで詰まるなら、その段階でノード側のポートや証明書検証へ進みます。DNS と TLS のどちらで止まっているかをログの行種別で区別する癖をつけると、OpenRouter に限らず他ゲートウェイでも再利用できます。

7. 開発者向けプロキシ：CLI・IDE・コンテナのズレ

HTTPS_PROXY と システムプロキシと TUNが混在すると、shell では通るコードがGUI アプリだけ別ルートになる典型が出ます。OpenRouter はどちらからでも叩けるため、このズレが顕在化しやすいです。curl -v https://openrouter.ai/...を同一マシンの二つのコンソール（ローカルとコンテナ内）で比較し、SNI と接続タイムアウトの経路情報を揃えてください。

WSL や Docker で開発している場合は、ホスト側 Clash とコンテナ環境変数の整合が別レイヤになります。ゲートウェイのドメインはルールに含めていても、コンテナ側のNO_PROXYに引っかかり直結へ落ちることがあります。リストを読み直して、無意識の例外を減らします。

逆にすべてを巨大な PROXY にぶら下げてしまうと、国内の速度制限サイトまで遠回りになり、開発体験が逆に崩れます。ゲートウェイとコードホスティング、パッケージレジストリをそれぞれ別バケツに分割するか、ログで広がりすぎている策略を定期的に監査すると長持ちします。

8. プロキシでは直らない失敗の見分け方

HTTP 402 や明示的な課金メッセージ、API キー無効・スコープ不足といった応答本文が返っているときは、出口を変えても結果は変わりません。まず状態コードと応答本文の JSON フィールドを保存し、サービス側のステータスページや開発者フォーラムの既知事例と照らします。レート制限はしばしば再試行間隔よりも上流のモデルキューが原因であり、タイムアウト秒の延長とトレードになります。

TLS が途中で書き換えられる企業検査プロキシ配下でも、開発者ゲートウェイは失敗します。自分のクリップボードにあるルート証明書を信じすぎず、失敗環境だけopenssl s_client 等でチェーン確認するのも一手です。mihomo だけを疑うフェーズではありません。

総じて、ログにドメインと策略が揃っているのにのみタイムアウトが続くなら上流やローカルのソケット調整へ、揃っていないなら本章までの DNS・ルール順・プロセス差へ戻る分岐になっているかを頭のチェックリストに載せておくと迷子になりにくいです。

9. よくある質問

Q. OpenRouter 専用の公式ルールセットはありますか。
A. コミュニティルールにも載ることがありますが、サービス側の構成変更と購読品質で陳腐化します。ベースセットを信じるより、自チームが実際に出た名前を増やしていく運用が堅実です。

Q. SSE や WebSocket で途切れるのも同じ切り分けですか。
A. 接続種別により中間ボックスやノード側の IDLE タイムアウト挙動は変わりますが、まずドメインと策略の一致確認は共通です。そのうえでトランスポート固有のフラグメントや再試行を読みます。

Q. 他モデルゲートウェイにもルールを流用できますか。
A. suffix は異なります。同一 YAML を機械複製しないでください。名前空間を分けるとログの読みやすさが維持されます。

Q. API だけ IPv6 が理由でコケる気がします。
A. デュアルスタック環境では IPv6 リーク関連の稿と合わせ、意図せぬ迂回がないかを確認してください。OpenRouter が原因かどうかはログの宛先ファミリーで別れます。

10. まとめ

OpenRouter のようなモデルゲートウェイでは、ユーザーが入力するチャットひとつに対しても静的アセット／API／上流プロバイダの複数レイヤが重なるため、ホスト単位での策略と名前解決の一貫性を揃えることがタイムアウト対策の中核になります。mihomo のルール評価順、fake-ip とブラウザ DoH の二重解決、開発者環境でのプロセス差を順に潰していけば、「とりあえず全部 PROXY」の曖昧な設定よりログで説明できる形に近づきます。Cursor や Gemini CLI、MCP 周辺と組み合わせる読者には、それぞれの専門稿との棲み分けを意識してルールセットを増やしてください。

一方で、GUI が薄くルール一覧を隠したり、doh など下層の設定を触れなかったりするクライアントでは、同じ問題が起きても観測と再現が難しく、設定の変更理由を将来の自分に説明できないまま積み上がりがちです。コアログとYAMLの差分を残せる構成は、モデル統合時代の開発者プロキシでは特に強みになります。その意味で、mihomo 互換スタックや観測しやすい GUI を選ぶ価値は大きく、機能の広さだけでなくトラブル時に自分で読み返せるかを基準に据えると、ゲートウェイの断続タイムアウトにも強くなれます。→ 無料で Clash をダウンロードし、快適な接続体験を試すところから、観測可能な環境へ置き換えていくことも検討してみてください。