まず症状を言語化する：ダッシュボード・API・認証が別問題に見える理由
OpenRouter の画面は単一ドメインに見えても、計測・アカウント・課金確認のために複数のサブドメインへ非同期的にリクエストが伸びる構成になりがちです。ユーザー体感としては「トップは開くのに設定だけ白画面」「モデル一覧は出るのに実行結果だけ返らない」「利用枠や請求のページだけタイムアウト」といった部分的成功が起きます。これはモデルの劣化というより、経路の分裂と名前解決の揺らぎで説明できることが多いです。ここでは慌ててモデルや温度パラメータをいじる前に、Clash の接続ログに現れる FQDN と策略名のペアをメモするだけでも切り分けが進みます。
マルチモデルゲートウェイほど「経路の細分化」が効いてくる
推論ルーティングが一枚岩になっているほど、アプリケーション側はホストを増やしやすく、CDN のエッジや認証トークンの検証地点も分散します。結果として、ブラウザタブはシステムプロキシを尊重して安定しても、ターミナルやコンテナ内の SDK は既定で直結し続ける、という非対称が残ります。またポリシーで地理的に振り分けるルールを多用していると、ドメイン単位ではなく実際に返ってきた IP の所在地で意図しないノードへ着地することもあります。だからこそ「一覧ドメインだけ規則へ足した」つもりでも API だけ別経路に滑り落ちるのです。
第1の一手：TUN でブラウザ・CLI・コンテナを同じ内核へ載せる
HTTP プロキシや PAC に依存すると、アプリごとの実装差がそのまま露出します。TUN は OS のルーティングテーブルから仮想 NIC に流すため、ブラウザと独自スタックを持つバイナリの隙間を狭めやすいです。Clash Verge Rev などの GUI ではスイッチ一つで有効化できますが、初回は管理者権限やネットワーク拡張の承認で止まっているように見えることがあります。Windows と macOS の具体的なクリック順は Clash Verge Rev の TUN ガイド に譲ります。ここで強調したいのは「ダッシュボードは見えるが API がダメ」というときほど、まず TUN を単独で試してログの変化を見る方が早い、という実務判断です。
実務のコツ：TUN とシステムプロキシを同時に有効にすると、どちらが効いているか読みにくくなることがあります。切り分けの初期は TUN 単体から始め、必要になった段階で mixed-port への環境変数を足すと筋が良いです。
分流ルールは固定リストよりログ優先で DOMAIN-SUFFIX に落とす
OpenRouter 公式が公開するエンドポイントやサブドメインは時間とともに増えます。ブログ記事に固定の「必須一覧」を並べても保守が追いつきません。運用上おすすめなのは、症状が出た操作の直後に接続ログへ並んだ openrouter.ai 配下や関連 CDN をそのまま DOMAIN-SUFFIX で拾うことです。すでに広い海外向けルールセットを読み込んでいても、実際には別のプロキシグループへ吸われていないか typo がないかはログでしか確定できません。MATCH に落ちる直前で意図した策略へ流れているかを必ず確認してください。
# Example sketch: observed hosts -> your policy group
rules:
- DOMAIN-SUFFIX,openrouter.ai,YOUR_PROXY_GROUP
# Add other suffixes you see in logs (CDN / auth helpers), not guesses.
YOUR_PROXY_GROUP は購読プロファイル内の実名に置き換えます。GEOIP だけに依存するとエッジ所在地で期待と違うノードへ送られることがあるため、タイムアウトが続くホストは個別指定の方が再現性が高いです。
DNS・FakeIP・DoH：ルール評価と実転送のズレを潰す
「ルールは足したのに効かない」ように見えるとき、実際にはアプリが OS の外側で別の DNS を叩いており、返ってきた実アドレスがルールの前提と食い違っているケースがよくあります。Clash Meta（Mihomo）で fake-ip を使う場合は、クライアント側で先に解決した結果とコア側の評価順序がずれると、不定期な失敗に見えます。ブラウザのセキュア DNS や別製品のフィルタが DoH を横取りしているときも同様です。細かなパラメータ設計は Meta コア DNS リーク防止ガイド に譲りつつ、OpenRouter のタイムアウト調査では「名前は取れたがTCPが詰まった」のか「名前そのものが不安定」のかをログと dig 相当の確認で分けると早いです。
SDK と自前サーバ：環境変数でプロキシ透過を補う
TUN が有効でも、コンテナや CI のジョブだけがホストのルーティングから外れる構成は珍しくありません。その場合は HTTPS_PROXY / ALL_PROXY をシェルやサービスユニットに足し、リッスンしている mixed-port や SOCKS に合わせます。社内では NO_PROXY にイントラネットのサフィックスを列挙し、不要な往復だけを直結させる運用もあります。リモート MCP や複数モデルを束ねる開発フローは MCP×Clash の記事とも題材が近く、外向き HTTPS が増えるほどログ起点のルール管理が効いてきます。
Handshake 失敗や長時間スタイルの切り分け
TLS のハンドシェイク以前で止まるときは、単純なタイムアウト値の問題ではなく、途中機器によるRSTや証明書検証エラーが混ざっていることがあります。一方で推論リクエストは応答本文が長く、HTTP レイヤでは数十秒単位を許容する実装もあります。ここで大事なのは「ブラウザの開発者ツールで見えるフェーズ」と「Clash ログの切断理由」を突き合わせることです。ダッシュボード側だけ HTTP/2 の多重ストリームで詰まり、API 側は別ホストで正常、という組み合わせも普通に起きます。
最短ワークフロー：迷わない順序で一度に片付ける
- Clash を Rule モードにし、購読と策略階層が読み込めているか確認する。
- 症状が出る操作を一つに絞り、直後の接続ログから
openrouter.ai周辺の FQDN を控える。 - TUN を有効化して同じ操作を繰り返し、ログの変化と策略の対応を比較する。
- 不足している
DOMAIN-SUFFIXや順序を調整し、MATCH に落ちる前に目的のグループへ流れるか確認する。 - DNS・FakeIP・ブラウザ側 DNS を見直し、他製品との競合がないか切り分ける。
- 必要なら環境変数やランタイム設定で SDK を明示プロキシへ寄せ、ダッシュボード表示と API を再試行する。
注意：利用規約・学校・企業ポリシーによりプロキシや経路変更が禁止されることがあります。適用法と社内ガイドラインを確認し、許可された環境でのみ設定を変更してください。
よくある質問
ブラウザでは開けるのに、コンソールの一部だけ固まるのはなぜ？
メイン HTML と API 呼び出し先が一致しないことが多いです。XHR や計測が別ホストへ伸びている場合、そちらだけが直結や不安定ノードへ流れ、画面の一部がタイムアウトします。ログで実際のホスト名を列挙してください。
ルールを増やしても HTTP クライアントだけ失敗する
プロキシ無視の実装か、コンテナがホストの TUN を見えていない可能性があります。TUN の到達範囲を確認し、必要なら HTTPS_PROXY で補強します。併せて DNS が実 IP を返してルールとずれていないかも確認してください。
会社の端末でも同じですか？
ゼロトラスト製品や MDM でブロックされている場合は手順どおりに進みません。情報システムの許可範囲で検証してください。
まとめ
OpenRouter のような集約ゲートウェイは、アカウント画面・課金確認・推論API がそれぞれ別ホストへ話しかけることがあり、モデル以前に経路と名前解決がボトルネックになります。Clash の TUN で OS レイヤの出口を揃え、ログを真として 分流ルールへ落とし、DNS・FakeIP・DoH の競合を潰せば、ダッシュボードの読み込み停滞や API のタイムアウトを再現性高く減らせます。対照的に、設定ファイルを手編集だけに頼り一行の綴り間違いで全体が不安定になる汎用ツールより、GUI でログ・ノード・購読更新が一目で追えるクライアントの方が、マルチホスト構成のトラブルシュートには向く場面が多いです。まだ試していない方は 無料で Clash をダウンロード し、本文の順に接続ログを取りながら TUN と DNS を整えてください。