api.openai.com と openai.com を DOMAIN-SUFFIX でまとめすぎると何が起きますか？

DOMAIN-SUFFIX,openai.com は下位ドメインを広く含むため、ブラウザのChatGPT、静的CDN、OAuthまわりまで同一ポリシーに乗ります。APIだけを低遅延ノードに固定したい場合は、まず DOMAIN,api.openai.com を上に置き、必要に応じて chat.openai.com などを個別に分けると、意図しないノード混線を減らせます。

Azure OpenAI も併用するときのルール分離のコツは？

Azure は *.openai.azure.com など別ホストになります。OpenAI直とAzureを同じ DOMAIN-SUFFIX,openai.com にまとめないで、ログで実際のホスト名を確認し、Azure用の DOMAIN-SUFFIX 行を別ポリシーに割り当てます。そうしないと、APIキーやリージョンが違う二系統が同一出口に乗り、タイムアウトやTLSの切り分けが難しくなります。

ストリーミング中の切断は Clash だけの問題ですか？

必ずしもそうではありません。上流のサーバ、中間機器の IDLE タイムアウト、クライアントSDKの read timeout、プロキシノードの品質が重なります。Clash側では該当ホストがどのポリシーに割り当てられたかをログで確認し、別ノードや DIRECT 試行、DNSの fake-ip／redir-host の切り分けを順に行います。

購読リンクで取得した RULE-SET より手書きルールを優先するには？

rules は上から最初の一致だけが有効です。OpenAI向けの手書き行を GEOIP や MATCH、広い RULE-SET より上に置き、購読更新後もエクスポートしたYAMLで順序を目視確認します。競合が続く場合は、Rule Provider の優先度や、カスタムルール欄の位置がクライアント実装でどう扱われるかも確認してください。

GPT‑5.2 APIのタイムアウト対策：ClashでOpenAIドメイン分流と再試行 2026

なぜ「GPT‑5.2と多モーダルAPI」はタイムアウトとセットで語られるのか

モデル世代が上がるほど、単純な短文生成だけでなく、ツール呼び出し、長いストリーミング、画像・音声など複数モダリティをまたぐリクエスト が増えます。結果として、サーバ側の処理時間が伸びるだけでなく、クライアントが待ち続ける時間 と 中間プロキシがアイドルとみなす時間 が衝突しやすくなります。ここで「Clashのせいで遅い」のか「ノードの品質が悪い」のか「SDKの read timeout が短い」のかが混ざると、ログだけでは迷子になります。

本稿の立ち位置は、海外APIを安定して使うためのネットワーク出口設計 です。分流の基本は YAMLルール分流ガイドで扱っている通り、rules は 上から最初の一致だけ が採用されます。OpenAI向けの記事では DOMAIN-SUFFIX,openai.com を例に出しましたが、タイムアウト対策では どのホスト名がどのポリシーに割り当てられたか をログで確認しながら、API核 と ブラウザ体験 を分けて議論するのが実務では効きます。

また、設定の見直しは 購読リンク（サブスクリプションURL） で取得したYAMLが更新されるたびに必要になることがあります。購読の更新タイミングやHTTPS取得の失敗は購読の自動更新トラブルシュートと整合します。ここでは、APIタイムアウトの切り分けに必要な範囲で、手書きルールをどこに挿すか だけを繰り返し強調します。

api.openai.com と *.openai.com：DOMAIN-SUFFIX の粒度を落とさない

実運用でよくあるのは、DOMAIN-SUFFIX,openai.com,AI-EXIT 一行で「OpenAIは全部この出口」と決めてしまうパターンです。設定は単純ですが、ChatGPTのWebフロント、OAuth、静的リソース、API が、すべて同じノード品質・同じ遅延特性に縛られます。APIだけ別の安定ノードに寄せたいときは、より狭い DOMAIN 行を上に積む のが定石です。

たとえば DOMAIN,api.openai.com,AI-API を先に置き、その下で DOMAIN-SUFFIX,openai.com,AI-WEB とする、といった二層です。これにより、バックエンドの長時間ストリーミング と ブラウザ体験 を分け、url-test のヘルスチェックURLやタイムアウトを API用グループだけ に寄せる余地が生まれます。逆に、細かく書きすぎてメンテが大変なら、信頼できるルールセットに任せつつ、ログで実際に出たホスト名だけ を追記する方法も現実的です。

# Example: API host first, then broader suffix (policy names are placeholders)
rules:
  - DOMAIN,api.openai.com,AI-API
  - DOMAIN-SUFFIX,openai.com,AI-WEB
  # ... keep above GEOIP / MATCH / large RULE-SET ...

ホスト名はサービス更新で変わりうるため、本稿の例は 切り分けのための構造 として読んでください。実際の接続先は、開発者ツールのネットワークタブや、Clashのログに出る Server Name をメモしてからルールに反映するのが安全です。

Azure OpenAI との併用：ホストを混ぜない

企業導入では Azure OpenAI と OpenAI 直 を併用することがあります。Azure側は *.openai.azure.com のような 別ホスト空間 に乗り、認証・課金・リージョンの前提がまったく異なります。ここを DOMAIN-SUFFIX,openai.com だけで束ねると、意図しない方のキーで叩いている のに同じ出口へ流れる、といった混乱が起きます。

実務では、Azure向けに 専用の DOMAIN-SUFFIX 行 と 専用ポリシーグループ を用意し、社内ルール（例：「本番はAzureのみ」）に合わせて rules の順序を固定します。Clashは万能ではなく、どのTCP接続がどのノードに乗ったか を整えるツールです。アプリ側のエンドポイントURLの誤りは、プロキシを直しても解決しません。

ポリシーグループと url-test：API用の「遅さ」を測る

タイムアウト対策でよく触るのが proxy-groups の url-test です。一般ブラウジング向けに短い間隔で切り替わる自動選択を、APIの長いストリーミングと共用すると、接続の途中で別ノードへ寄る といった事故が起きうるため、API専用グループ を分ける価値があります。

設定の考え方は、第一に url-test の url を「APIと相性のよい軽いエンドポイント」に寄せるか、あるいは select で 手動固定 して変動を止めるか、の二択です。第二に、interval や tolerance を短くしすぎないこと。第三に、ヘルスチェック自体がタイムアウト したときに「全ノード不健康」とみなされないよう、購読プロファイル側のデフォルト値を疑うことです。分流の全体設計は使い方ヘルプのルールモード説明とも整合的です。

なお、オーケストレーション基盤（LangGraphやn8n Cloudなど）まで含めると接続先ホストが増え、API単体の記事とは別の切り口になります。そうした横断の話は LangGraph／n8n Cloud 分流を参照してください。本稿は OpenAIのエンドポイント集合とタイムアウト に焦点を絞ります。

クライアント側のHTTPタイムアウトとストリーミング

プロキシとYAMLが正しくても、SDKのデフォルトタイムアウト が短いと、長い生成やマルチモーダル応答の途中でクライアントが先に諦めます。典型的には httpx／requests 系の read timeout、OpenAI公式SDKの timeout 引数、あるいはフレームワーク側の「全体でN秒」制限です。ここを伸ばすことは万能薬ではありませんが、サーバがまだ生成中なのにクライアントだけが切っている 状態を防ぐには必須のレバーです。

また、ストリーミング では「最初のバイトまでの時間（TTFB）」と「フレームが途切れないこと」が別問題です。前者はDNSやTCP接続、後者は中間機器のアイドルタイムアウトやノードの安定性に効かれます。Clash側では 該当ホストがどのポリシーに入ったか をログで確認し、TUNモード と システムプロキシ の違いによる挙動差は TUNとシステムプロキシの記事で整理されている切り分け順を参照してください。

再試行（リトライ）：指数バックオフと429／503

ネットワークの一時的な切断やレート制限に対して、即座に同じリクエストを連打する のは避けたいです。実務では 指数バックオフ（試行ごとに待機を伸ばす）と、429／503 のときに Retry-After を尊重する、が基本線です。冪等性のない操作を安易に再試行しない、というアプリ設計の話にもつながりますが、ここではネットワーク層の話に限定します。

Clashの設定だけでリトライを「完結」させることはできません。ただし、誤ったポリシーに乗った接続を繰り返し生成しない ことはできます。ルール順が崩れて DIRECT や遅いノードに落ちているとき、SDKはタイムアウトを繰り返すだけで状況が悪化します。まず ログで policy を確認し、必要なら DOMAIN 行を上に足す、という順序が再試行より先です。

DNSとログ：「タイムアウト」の半分は名前解決

fake-ip と redir-host の選択は、サイト表示全般に効きますが、APIクライアントも例外ではありません。症状が「最初のTLSだけ遅い」「特定ドメインだけ不安定」のときは、DNS fake-ipとredir-hostの記事の手順で、名前解決の経路を疑ってください。モバイル環境では Androidのノードタイムアウト記事とも補完的です。

まとめると、切り分けの実測順は次のようなイメージです。第一に 実ホスト名 をログで確定する。第二に rules のどの行に当たったか を確認する。第三に ポリシーグループとノード を疑う。第四に DNSモード と TUN／システムプロキシ を疑う。第五に SDKのタイムアウトとリトライ方針 を疑う。この順で「Clashをいじる場所」と「アプリをいじる場所」が分かれます。

よくある質問

GPT‑5.2 だから特別なルールが必須ですか？

モデル名そのものより、呼び出しパス（ホスト名） と 接続の持続時間 が支配的です。新モデルでクライアントやエンドポイントの組み合わせが増えると、従来よりタイムアウトが「見えやすく」なることはありますが、YAMLの型は従来の OpenAI 分流と同じです。分流の基礎編と本稿を対で読むと整理しやすいです。

企業プロキシとClashを二重に通すとどうなりますか？

二重プロキシや親プロキシの設定は、クライアントによっては CONNECT のネスト や認証ヘッダの扱いで切断が増えます。環境変数の HTTP_PROXY と Clash の関係は、開発者向けの Cursor／npm 分流でも触れている通り、どのプロセスがどのプロキシを見るか を揃えるのが先決です。

まとめ

2026年の GPT‑5.2 や マルチモーダルAPI は、単に「賢くなる」だけでなく、接続を長く保つ ことへの要求も上げます。Clash では DOMAIN-SUFFIX と DOMAIN の組み合わせで api.openai.com を明示的に扱い、Azure OpenAI ともホストを混ぜない。ポリシーグループ でAPI用の出口を分け、SDKのタイムアウト と 指数バックオフ付き再試行 をアプリ側で整える。この三層を同じ長さで見ると、「総タイムアウト」という言葉の指す層がブレずに済みます。

設定は購読YAMLの更新で上書きされることもあるため、エクスポートして 手書きルールの位置 を定期的に確認し、購読リンク の取得はネットワークが健全なタイミングで行うのが安全です。

→ Clashを無料ダウンロード — Metaコア対応クライアントを選び、OpenAI API用の出口をYAMLで再現しやすくできます。

ほかのチュートリアルは技術コラムからどうぞ。