ChatGPT と Grok が重い・不安定？2026 年、Clash のルール分流とノード選びで整える

なぜ AI チャットは通常のブラウジングより「ネットに敏感」なのか

従来のサイトは短い HTTP リクエストが中心ですが、AI チャットは常時近いパイプラインです。1 セッションでストリーミング、静的リソース、履歴同期、アップロード先ストレージ、機能フラグやテレメトリ用ホスト名が同時に動きます。一部だけ経路がずれると、明確なエラーではなくもっさり感として現れます：文字が途切れる、スピナーが止まらない、クライアントが静かに再試行する、など。

• ストリーミングはジッターを増幅します。軽い損失やバッファ膨張が「ページ全体の失敗」ではなく「表示のぎこちなさ」になります。
• 並列依存が多く、1 ドメインの誤分類で UI だけ先に詰まります。
• セッションの一貫性：ログイン中に出口 IP が頻繁に変わると、リスク判定が厳しくなり「急に CAPTCHA が増えた」ように感じられます。

Clash はルールベースなので、国内向けは高速な DIRECT、OpenAI / xAI 系は安定したプロキシグループへ寄せ、遅延測定とフォールバックでノード選択を洗練できます。

見落としがちなのは同時接続です。入力中も提案のプリフェッチや同期が走り、いずれかのレグが遅いと「半分だけ反応している」状態になります。だからこそホスト名単位のチューニングが効きます。

「モデル障害」ではなく経路の問題を示すサイン

課金プラン変更や再インストールの前にパターンを整理しましょう。ルールによる経路分岐の穴、DNS の食い違い、ping は良いのにストリームが不安定なノードが典型原因です。

Clash のConnectionsやログが真相です。DIRECT のまま残るべきフローがないか、逆に LAN が遠回りしていないかを確認します。

ポリシーのフラップにも注意：数秒ごとに出口が変わるとセッションがリセットされ「謎の切断」に見えます。許容値の調整や手動固定が先かもしれません。

まず DNS：遅い ChatGPT の半分は名前解決

ブラウザのリゾルバと Clash 内部が違うと、同じ名前でもエッジや国が変わります。fake-ip ではアプリ間で一時的に認識がズレることもあります。

• 方針を揃える：DoH/プロバイダ既定などを選び、ISP DNS・ルータ DNS・ブラウザ単独 DoH を無秩序に切り替えない。
• LAN とキャプティブポータルは DIRECT：RFC1918 やルータ管理画面は確実に直結側へ。
• 入口を比較：Web は動くがデスクトップアプリだけダメなら DNS 経路を疑う。

ブラウザ DoH と Clash のリゾルバ

ブラウザだけ DoH を有効にすると、システム他部と解決結果が分岐します。デバッグ中は一時的に揃え、ベースラインが安定してからプライバシー機能を戻すのが安全です。

Rule モードで OpenAI / xAI を意図的に固定

常時 Global はハンマーです。Rule で Web・デスクトップ・モバイルが触るホストを実測ベースでカバーしましょう。

ルール順序が重要です。粗い GEOIP より狭い AI 用ルールを上に。リモートルールセットは更新間隔を現実的に。

巨大なコミュニティリストを無批判に足さない。広告ブロック用途のリストが SaaS を壊す典型です。

モード	AI チャット体験	トレードオフ
Rule	既定の最適解：必要なトラフィックだけ遠回り。	ログを見て微調整が必要。
Global	短時間の切り分けに有効。	負荷とバッファが増えがち。
Direct	プロキシ起因かを切り分け。	恒久的な回避策ではない。

ポリシーグループ：url-test とフォールバック

測定値の ms だけで選ばない。定期的に再テストし、短周期で出口がコロコロ変わらないグループが会話向きです。

• プロバイダ推奨の安定した HTTPS プローブを使う。
• トレランスで「同点の行き来」を抑える。
• フォールバックで地域全体の劣化に備える。

Auto グループのプローブ内容を確認。ダウンロード最適化のプローブが会話レイテンシと一致するとは限りません。

2026 年のノード選び：速さの意味

スループット自慢より安定 RTT・低損失・一貫した出口が重要です。

• 地理はヒント：実測トレースと自宅 ISP の国際ピアリングで検証。
• データセンター IP は普通。ログインだけ急に厳しくなったら別のクリーンなノードを試す。認証中は IP ホッピングを避ける。
• 多段チェーンは TLS とストリームのジッターを増やす。

測定は緑でもカクつくときは、帯域を食うタブや同期を止めて再試行。自宅アップロード側のバッファ膨張も疑う。

ピーク帯の最終区間遅延も忘れずに。有線化や長文推論中の手動ロックも有効です。

さらに三角測量の習慣を。同じルールセットをスマホのテザリングで試し、症状が「端末について回る」ならローカル設定やノード側、「家にだけ残る」ならルータやプロバイダ最終区間を疑うと切り分けが速いです。感情論でノードを総入れ替えする前に、再現手順を三回繰り返してログに相関が出るかを見てください。

デスクトップ／モバイル：システムプロキシと TUN

ブラウザは追従しやすいですがネイティブアプリはバイパスしがち。TUN で取りこぼしを減らします。

1. システムプロキシ ON、Rule で AI ドメインをカバー。
2. アプリ独自のプロキシ設定やピン留めの有無を確認。
3. TUN は企業 VPN や ZTNA と競合し得る。

iOS / Android

サンドボックスにより、フルデバイス TUN でないクライアントは効きが弱いことがあります。症状はデスクトップと同型（Safari は動くがアプリはダメ）になりがちです。

CAPTCHA とリスクチェックについて

プラットフォームのシグナルは常に更新されます。Clash は正当な保護を無効化しません。ログイン中のノード跳び回りを避け、認証と API の経路を揃え、過剰ブロックを一時停止するのが現実的な助けになります。

Connections を読むコツ

最初から全列を理解する必要はありません。ホスト名・ポリシー・実際の outbound の三点に絞る。停止時に新規フローが出るか、静かになるかを十秒観察します。

成功時と失敗時のホスト差分を残すと、欠けたルールや途中で変わったチェーンが見えます。

IPv6・MTU・ホテル Wi‑Fi

IPv4/IPv6 で方針が割れると「画像は来るがストリームが不安定」になり得ます。IPv6 を一時オフで差が出るなら、恒久的無効化ではなくプロファイル側で整えるべきです。

MTU 問題は短文では成功し長文で切れるパターンが典型。ノードを総入れ替えする前にサイズ相関を確認します。

サブスクリプション側の天井

YAML だけでは混雑した上流や枯渇した帯域は救えません。地域全体が赤い時間帯は輻輳のサインです。リージョン変更・端末数削減・オフピーク利用が現実的です。

古いサブスクは幽霊ノードを抱え、自動選択を混乱させます。手動更新と再テストを忘れずに。

FAQ

ストリームが途中で止まる

DNS・LAN のバッファ・グループフラップを併せて疑う。ログでポリシー変更直後の再接続が繰り返されていないか。

ChatGPT だけ遅い

ルール欠落か DNS 分裂。ホスト名単位で確認。

同じノードで Grok と挙動が違う

バックエンドと CDN が異なる。ログドリブンでルールを足す。

音声やリアルタイムが弱い

ジッタに弱い。UDP 対応と通話中のノード固定を。

会社 VPN と併用で不安定

承認された分割設定を。TUN を無秩序に積まない。

「AI 高速化」拡張機能

不透明な中継になり得る。不具合後に入れた拡張を疑う。

2026 チェックリスト

メンテされたクライアントから始める

一度に一変数だけ変えて因果を保ちましょう。

Clash を無料ダウンロードし、ChatGPT・Grok 向けルーティング調整の土台にする