1 背景とゴールをそろえる
2026 年時点でも、オフィスや学習シーンでの生成 AI利用は拡大しており、OpenAI は ChatGPT ファミリー、Assistants、リアルタイム API、エンタープライズ向け管理機能などを継続的に更新しています。利用者側のつまずきは、モデル選び以前に分散したドメインへの HTTPS が片方だけ不安定になることに現れがちです。SPA は静的アセット、認証、計測、バックエンド API を別ホストへ分け、開発者向けは api.openai.com へ直接接続します。システムプロキシ、環境変数、TUN の有無がバラバラだと、同じマシンでもアプリごとに出口が変わり、ログインは成功したのにストリーミングだけ途切れる、といった切り分けが難しくなります。
本稿のゴールは、帯域をむやみに広げることではなく、Rule モードで OpenAI 向けトラフィックを意図したアウトバウンドへ集約することです。IDE 連携全般はCursor と Clash の記事で扱っています。Google クラウド側はGemini／Google AI Studio 向けの記事、Anthropic はClaude 向けの記事が対応します。ここでは OpenAI のホスト設計に寄せ、粗い GEOSITE 一枚だけに頼らず、漏れと過剰マッチの両方を減らすことを意識します。
2 ChatGPT の Web と API が触るホストを押さえる
実際のホスト名はプロダクト更新で増減するため、最終的には Clash の接続ログで SNI を確認するのが確実です。それでも設計上、次のような束に分けて考えるとルールが書きやすくなります。
- コンシューマ向け Web（ChatGPT）：
chat.openai.comに加え、ブランド統合後はchatgpt.comや*.chatgpt.com配下のサブドメイン、OAuth や静的アセット用の CDN が混ざることがあります。単一のDOMAINだけでは足りない場面があります。 - コーポレート／ドキュメント（openai.com）：
openai.com、www.openai.com、開発者向けドキュメントやステータス、プラットフォーム UI はplatform.openai.comなど別名で切り出される場合があります。 - Chat Completions などの API： REST クライアントは通常
api.openai.comを向きます。SDK はHTTPS_PROXYを参照する場合と、独自の HTTP クライアントで OS プロキシを無視する場合があります。 - GEOSITE に頼りすぎない理由： 購読リストの「海外 AI」カテゴリは便利ですが、更新タイミングや分類粒度によっては OpenAI 専用のホストが未収録だったり、逆に不要なドメインまで同じプロキシに乗ったりします。安定性を優先するなら、自前の短いサフィックスリスト＋ログでの追記が扱いやすいです。
まずは失敗時に表示されるエラーが「名前解決」「TCP の拒否」「TLS ハンドシェイク」「HTTP 403／401／レート制限」のどれに近いかを分け、接続ログのドメインと突き合わせてください。ストリーミング応答は HTTP の長めのセッションになるため、パケット損失の大きいノードでは UI 上「途中で途切れる」ように見えます。
3 ルールモードとプロキシグループの置き方
推奨は mode: rule です。OpenAI 向けに PROXY-OPENAI のようなセレクタまたは url-test 付きグループを一枚挟み、遅延の安定したノードと、帯域はあるが不安定なノードを分けておくと、長めのストリーミング応答を比較しやすくなります。グローバルモードは国内向けサービスまで遠回りし、ダイレクト固定では API だけ失敗する、というジレンマが出ます。
購読テンプレートに既に「国外サイト」ブロックがある場合は、その直前に OpenAI 向けの明示ルールを置き、意図せず別タグのノードへ飛ばないようにします。セレクタで国や事業者を切り替える運用では、データ所在地や利用条件の表記とあわせて公式情報を確認してください。チーム開発では、どのプロセスがどのポートを見るかを README に書いておくと、新規メンバーの環境差を減らせます。
4 YAML に書くルール例と Rule Provider
以下はイメージです。proxy-groups 名やインデントは手元の設定に合わせてください。コメントは英語のみとします。
# Example: route OpenAI properties to a dedicated selector
rules:
- DOMAIN-SUFFIX,openai.com,PROXY-OPENAI
- DOMAIN-SUFFIX,chatgpt.com,PROXY-OPENAI
- DOMAIN,api.openai.com,PROXY-OPENAI
- DOMAIN,chat.openai.com,PROXY-OPENAI
- DOMAIN,platform.openai.com,PROXY-OPENAI
# Optional: remote rule-provider (path/interval are examples)
# rule-providers:
# openai:
# type: http
# behavior: classical
# url: "https://example.com/rules/openai.txt"
# path: ./rules/openai.yaml
# interval: 86400
# rules:
# - RULE-SET,openai,PROXY-OPENAI
Rule Provider を使う場合も、リモートリストの中身が信頼できるか、更新間隔とローカル追記ルールの優先順位を確認してください。Clash 系は上に書いたルールが先に評価されるため、細かい DOMAIN を上に、広い GEOIP や MATCH を下に置くのが定石です。DOMAIN-KEYWORD,openai は無関係サイトを巻き込みやすいので、長期運用ではサフィックスとログ追記を優先します。
CLI やコンテナから API を叩くときは、プロキシを明示しないと OS のルーティングに任せます。Python 等では HTTPS_PROXY=http://127.0.0.1:7890 を併用するか、TUN モードで仮想 NIC レベルに揃えると、環境変数のばらつきを減らせます。
5 DNS・FakeIP・TLS をセットで見る
ホスト数は Google ほど膨大ではありませんが、DNS の答えが期待とズレると「ブラウザでは開けるのに CLI だけ名前解決が変」という現象は同様に起きます。Mihomo では DoH、FakeIP、fallback-filter の組み合わせが定番です。設定の細部はMeta カーネル DNS の実務記事に譲ります。Clash の DNS セクションと OS の DNS を二重管理しないこと、TUN と DNS ハイジャック併用時にローカル開発用ゾーンを DIRECT に残すことが安定の鍵です。
TLS の観点では、SNI が api.openai.com であっても、途中の企業プロキシによるインスペクションでクライアント証明書検証が失敗するケースがあります。エラー文言が証明書関連なら、まず社内ポリシーと OS の信頼ストアを疑ってください。逆にルールで意図せず DIRECT に落ちていると、RST やタイムアウトとして現れます。API 利用ではキーをリポジトリに含めず、シークレットマネージャや環境変数で渡すのは共通の鉄則です。
6 Web と API の動作確認
ブラウザで ChatGPT を開き、ログインとチャットの送受信が一通りできる状態を基準にします。続けて、同じマシンからターミナルで curl 等により api.openai.com への TLS ハンドシェイクが完了するかを見ます。ここでだけ失敗する場合は、ルールよりも環境変数か、CLI がプロキシを参照していない可能性が高いです。セレクタで別アウトバウンドへ切り替え、再現性を比較してください。ベース URL やパス形式は公式ドキュメントの最新版を正とし、ネットワーク記事の古い例をそのまま流用しないでください。
レート制限と課金
ネットワークが正しくても、トークン上限や組織ポリシーで 429 や課金エラーが返ることがあります。ダッシュボードの利用量とあわせて切り分けます。バッチ処理で大量リクエストを送る場合は、指数バックオフやキューイングをアプリ側に入れ、単一ノードへの依存を減らすと運用が楽になります。
7 トラブルシューティング
- ブラウザだけ成功して CLI が失敗： システムプロキシと環境変数のどちらかが未設定、または TUN がオフ。シェルに
http_proxy／https_proxyを足すか、TUN を有効化して経路を一本化します。 - 403／401／組織ポリシーのメッセージ： ルールではなく API キー、アカウント、管理者設定側の制約の可能性があります。公式ステータスとドキュメントを照合します。
- ストリームが途中で切れる： ノードのパケット損失や、長時間接続の切断を疑い、セレクタで別サーバへ切り替えて比較します。
- 新しいサブドメインで失敗： 接続ログに出た SNI を
DOMAIN-SUFFIXまたはDOMAINで追記し、Rule Provider のリストにも反映できるか検討します。 - ルールを足したら国内サイトが遅くなった：
GEOIP,JP,DIRECTなど直行ルールとの順序を見直し、誤マッチがないか確認します。
8 まとめ
ChatGPT を「ブラウザだけ速くする」のではなく、openai.com／chatgpt.com 系と api.openai.com を含む OpenAI 向けトラフィックをルールと DNS で一貫させると、Web・API・サードパーティツールをまたいだ再現性が上がります。粗い GEOSITE だけに頼ると漏れと過剰マッチの両方が出やすいので、DOMAIN-SUFFIX とログベースの追記、必要なら Rule Provider で保守性を補います。Google の Gemini や Anthropic の Claude を併用する場合も、ベンダーごとに出口を分けておくと切り分けが容易です。
まずは手元の YAML に OpenAI 向けサフィックスと API 用 DOMAIN を追記し、接続ログで漏れがないか確認してください。DNS の細部はDNS 実務記事に譲ります。ルール分流とログの読み方さえ身につけば、同じ考え方を他のクラウド API にも転用できます。
単機能の軽量プロキシより、ルールと DNS を一体で扱える Clash 互換スタックの方が、長めの HTTPS ストリームや複数ドメインにまたがるセッションに強い場面が多いです。生成 AI を業務フローに組み込むほど、その差は試行回数と体験の安定性に直結します。
