📖 チュートリアル ⏱ 約17分で読めます

2026：ChatGPT 公式 Web／OpenAI API の Clash 分流ルールと DNS（実測）

ChatGPTやOpenAIの公式 APIは、ブラウザで触るWeb チャットと、curl や各種 SDK が叩く api.openai.com などのHTTP APIで、接続先ホスト名が分かれやすい典型例です。2026 年も検索需要が高い一方で、「ページは開くのにストリーミングだけ止まる」「API だけタイムアウトする」といった報告は、しばしば分流ルールとDNSの組み合わせの食い違いから生じます。本稿は Google Gemini 向け記事や DeepSeek 向け記事とドメイン集合を明確に分離し、OpenAI 公式の Web／認証周りと API エンドポイントを想定して、Clash（多くの場合 Clash Meta／Mihomo コア）でのドメインルール、DoH を含む名前解決、ルールの優先順位、ログによる実測手順までを日本語で整理します。サービス側のホスト構成はアップデートで変わり得るため、以下の YAML は出発点の例とし、自分の環境の接続ログを正としてください。

ChatGPT／OpenAI が「不安定」に見えるときの切り口

症状を分類すると切り分けが速くなります。(1) ブラウザの ChatGPT 画面だけ読み込みが遅い、ログインがループする、(2) ターミナルやアプリからの API 呼び出しだけ失敗する、(3) 課金・API キー管理のコンソールだけ別の挙動になる、というパターンです。(1) は chatgpt.com や静的アセット用ホストが意図せず DIRECT になっている、あるいは意図しない地域のプロキシに乗っていることが多く、(2) は API クライアントがシステムプロキシを読まない経路で出ており Clash のルールが効いていない、(3) は platform.openai.com など別サブドメインがルールから漏れている、が典型です。サーバー側だけで API キーを使う構成では端末の Clash は無関係ですが、開発用 PC から直接 API を叩く場合は、同じマシン上の Clash が名前解決と転送経路の両方に影響します。

用語の整理は チュートリアル、ルールの書き方は カスタムルールの解説 と併読するとスムーズです。Google 系は googleapis.com や gstatic.com が主役になりがちですが、OpenAI 公式は openai.com 系と chatgpt.com 系、oaistatic.com などブランドごとにホストが分岐しやすい点が、Gemini 記事をそのまま流用できない理由です。

分流の土台：proxy-groups に「OpenAI 用」を用意する

購読テンプレの PROXY をそのまま指すより、OpenAIProxy のような用途名のグループを select または url-test で用意し、rules からは常にそのグループ名を参照するのが運用しやすいです。ノードを差し替えてもルール本文を触らずに済み、Web と API を同じ出口に揃えるか、遅延や帯域の都合でAPI だけ別グループに分けるかも、名前を分けておけば後から変更できます。ネストや型の詳細は proxy-groups のガイド を参照してください。

💡 ヒント テンプレのグループ名と rules 内の綴りが一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」状態になりがちです。

Web と API：OpenAI 公式でよく現れるホストの考え方

ChatGPT の Web UIでは chatgpt.com が中心になり、静的リソースや CDN 的な経路として oaistatic.com などが併用されることがあります。オープンな製品情報やリンク集では openai.com 本体や www.openai.com が使われます。開発者向け APIのエンドポイントは、ドキュメント上 https://api.openai.com（多くのクライアントで /v1 プレフィックス付き）が代表例です。API キーや使用量の管理 UIでは platform.openai.com が現れることがあり、認証フローでは IdP 連携用の別ドメインが挟まる場合もあります。いずれもサブドメイン追加やエッジの前段変更で変化し得るため、以下は出発点の例です。実際にマシンが接続しているホスト名をログで確認してから、DOMAIN-SUFFIX を狭めたり広げたりしてください。

方針として、(A) Web・API・プラットフォームを同じ OpenAIProxy に寄せるのがシンプル、(B) 課金画面だけ別経路にしたい場合は platform.openai.com だけ別グループにする、などに分けられます。(C) DOMAIN-SUFFIX,openai.com の一括は手早いですが、意図しないサブドメインまで同じ出口に乗るため、まずはログで必要なサフィックスに絞るのが安全です。ルールの上から先にマッチした行が優先されることは カスタムルール記事 のとおりです。コミュニティの RULE-SET と併用する場合も、OpenAI 向けの例外を上に積むと意図した出口に寄せやすくなります。

rules:
  # Examples only — tune group name (OpenAIProxy) and domains to your logs
  - DOMAIN-SUFFIX,chatgpt.com,OpenAIProxy
  - DOMAIN-SUFFIX,openai.com,OpenAIProxy
  - DOMAIN-SUFFIX,oaistatic.com,OpenAIProxy
  - DOMAIN-SUFFIX,api.openai.com,OpenAIProxy
  - DOMAIN-SUFFIX,platform.openai.com,OpenAIProxy

サードパーティのラッパーサイトや非公式クライアントは別ドメインになることが多く、本稿のリストとは一致しません。その場合は接続ログに出たホストをそのまま DOMAIN や DOMAIN-SUFFIX で追加してください。OpenAI 互換エンドポイントを他社が提供する場合も、実際に TLS で繋いでいるホスト名は api.openai.com ではなく別名になるため、ドキュメントの base URL とログの FQDN を必ず突き合わせてください。

DNS と DoH：ルールより前に潰れる「名前解決」の落とし穴

分流ルールが正しくても、DNS が期待と違う応答を返すと、タイムアウトや証明書エラーに見えます。Clash／Mihomo 系では dns ブロックの fake-ip、redir-host、DoH の有無が挙動に直結します。テンプレの推奨設定から大きく外すと切り分けが難しくなることもあるため、まずは購読既定で再現する→ 問題が続くときに、(1) DoH エンドポイントの信頼性とレイテンシ、(2) nameserver-policy で openai.com や chatgpt.com だけ別 DNS に寄せる、(3) IPv6 の有無と OS の解決順、を一度に一項目ずつ変えるのが安全です。

ブラウザ独自の Secure DNS（DoH）と Clash 側の DNS が二重に効いていると挙動が読みにくいので、比較時にはブラウザ側を一時オフにする方法もあります。CLI やコンテナから API を叩く場合、システムプロキシを読まない経路があるとルールが効きません。そのときは TUN モード でトラフィックをコア側に寄せる案や、HTTPS_PROXY 環境変数の明示を検討してください。ルールの優先順位は、より具体的な DOMAIN を汎用の MATCH や広い RULE-SET より上に置く、という原則が API の取りこぼし防止に効きます。

動作モード：Rule・Global・Direct の使い分け

Rule が日常運用の基本です。Global は「すべてをプロキシへ」として、一時的にルール不足かノード品質かを切り分けるのに便利ですが、国内サイトまで遠回りになるため常時利用はおすすめしません。Direct はベースライン計測用に、Clash を事実上オフに近い状態で挙動を見るときに使います。ChatGPT だけ不調なときは Rule に戻し、該当ホストが意図したポリシーにマッチしているかをログで確認するのが定石です。トンネル型 VPN との違いは Clash と VPN の比較 も参照してください。

⚠️ 注意 API キーはクライアント側の設定ファイルや環境変数に平文で残りやすいです。リポジトリにコミットしない・共有 PC では権限を絞る、などセキュリティ面はプロキシ設定とは独立して必ず確認してください。

実測手順：ログで「宛先」と「採用ルール」を確認する

  1. 1

    Baseline（Direct または Clash 停止）

    まず Direct でブラウザから ChatGPT を開き、同じ端末から curl 等で api.openai.com への疎通を試し、症状が再現するかを記録します。これで「ローカル回線やプロバイダ側」の要因も見えます。

  2. 2

    Rule に戻し、Web と API それぞれでログを読む

    チャット操作と API リクエストの両方について、接続一覧／コアログで向いているドメインとマッチしたルール行（またはポリシー名）をメモします。リストにないホストが出たら、それが次に追加すべき行です。

  3. 3

    一行ずつルールを足して再計測

    DOMAIN-SUFFIX を追加し、同じ操作を繰り返します。一度に大量変更すると効いた変更が特定できません。意図と違う行にマッチしているときは、より具体的なルールを上へ移動します。

  4. 4

    DNS ログがあれば併記する

    名前解決結果がおかしい場合はルールより先に DNS を直します。クライアントが DNS ログを出せない場合は、ログレベルを上げる、別ツールで確認するなど環境に合わせてください。

この繰り返しが本稿でいう「実測」です。検索で見つかるドメイン一覧は参考にとどめ、自分のログを正としてメンテすると、UI やエンドポイント変更にも追従しやすくなります。中国本土や企業ネットのように、特定ネットワークで公式ドメインへの到達性が制約される場合でも、出口の品質・DNS・ルールの三つを同時に疑うと早く収束しやすいです。

よくある質問

ブラウザは快適なのに API だけ失敗する

ブラウザはシステムプロキシ経由でルールが効いているが、ターミナルや Docker がプロキシ設定を読んでいないパターンです。環境変数、TUN、または実行ユーザの違いを確認してください。

DOMAIN-SUFFIX,openai.com にしたら他の通信まで変わった

サフィックス一括は広くマッチします。影響が大きい場合はログで実際のホストを列挙し、必要なサブドメインだけに狭めてください。

職場・学校のネットワークでは？

組織ポリシーでプロキシ迂回が禁止されている場合があります。技術的に可能でも、規程と管理者の指示を優先してください。

まとめ

ChatGPTのようにWeb フロントと公式 APIが分かれているサービスでは、分流ルールをシーン別に整理し、DNS（DoH を含む） と Rule モードでのログ検証をセットにすると、「グローバルプロキシに頼らずに安定させたい」という目的に沿いやすくなります。本稿のドメイン例は出発点であり、ログに基づきルールを育てることが長く使うコツです。Google 向けの分流は Gemini の記事、中国発の API 例は DeepSeek の記事で別ホスト集合として扱っているため、混同せず参照してください。

クライアントの入手は 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。ルールの見える化と切り替えのしやすさは、他の汎用 VPN ツールに比べて Clash の運用体験が一段整理されやすい点にあります。

→ Clash を無料ダウンロードし、ChatGPT／OpenAI API 向けの分流と DNS を試す