GrokがClashで開けない・接続できない時の原因と直し方

Grokだけ開けないときは、まず失敗の範囲を絞る

Clashを起動しているのにGrokのページが開かない、ログイン画面から先へ進まない、質問を送るとタイムアウトする——こうした症状は、すぐに「ノードが壊れた」とは限りません。ブラウザがシステムプロキシを使っていない、Clashのルールが想定と違う出口を選んでいる、DNSの応答が古い、あるいはGrok側で一時的な障害が起きているなど、原因は複数の層に分かれます。最初に、ほかのウェブサイトは開けるか、Grokのトップページとログイン後の画面のどちらで止まるか、同じ端末の別ブラウザでも再現するかを確認してください。

可能なら、失敗した時刻と画面に出たメッセージも記録します。「ページを表示できません」「接続がリセットされました」「応答待ちのまま止まる」では、疑うべき段階が異なります。トップページだけ失敗する場合はDNSやルーティングを、ログイン後だけ止まる場合は認証関連の通信やCookie、追加の接続先を確認する手がかりになります。原因の切り分け中は設定を一度に何か所も変更せず、変更前の状態をメモして一つずつ試すのが安全です。

プロキシモードとブラウザの経路を確認する

ClashのモードがRuleの場合、通信ごとにルールを評価して、選択したプロキシグループ、DIRECT、またはブロック先へ振り分けます。Grokの画面を開いても、関連する通信がDIRECTや意図しないグループに割り当てられていれば、プロキシを起動しただけでは解決しません。最初にClashのホーム画面や設定画面で、現在のモードと選択中のグループを確認してください。メニュー名はClash Verge、Clash Verge Rev、Mihomo Partyなどのクライアントやバージョンによって異なりますが、「Mode」「Proxy」「Rule」などの項目が手がかりになります。

次に、OSのシステムプロキシが有効かを確認します。ブラウザはシステムプロキシを参照していても、別のアプリや拡張機能が独自のプロキシ設定を持つことがあります。Clashの画面上でシステムプロキシを有効にしただけで安心せず、実際にブラウザの通信がClashの接続一覧に現れるかを確かめましょう。ブラウザのプライベートウィンドウで再試行するのも有効です。拡張機能、保存されたCookie、キャッシュが結果に影響するかを通常ウィンドウと比較できます。

Ruleモードの原因を手早く切り分けるには、短時間だけGlobalモードに切り替え、利用可能なノードを一つ選んでGrokを開きます。Globalで成功し、Ruleで失敗するなら、端末やノード全体よりもルールの評価順、ルールセット、選択グループを優先して調べます。Globalでも失敗する場合は、ノード自体の疎通、DNS、システムプロキシ、サービス側の状態などを確認します。テストが終わったら元のモードに戻してください。Globalモードは恒久的な設定ではなく、あくまで原因を分けるための一時的な診断方法です。

ルールと接続ログから誤った振り分けを探す

Ruleモードでだけ失敗する場合は、Grokのページを開いた直後にClashのConnectionsや接続ログを確認します。表示されるホスト名、適用されたルール、選択されたポリシーグループ、通信の状態をセットで読み取るのがポイントです。ひとつのページでも、画面本体、ログイン、画像などの静的ファイル、API通信が別々のホストへ接続することがあります。そのため、最初に見えた一つの通信だけを確認して「Grokの通信はすべて正しい」と判断しないでください。

ルールは通常、上から順に評価され、最初に一致したルールが採用されます。Grok向けのルールを追加する場合は、より広いMATCHルールや意図しないドメインルールより前に配置されているか、ルールが参照するプロキシグループ名が実際の構成に存在するかを確認します。ルール名や接続先のドメインは、使っているプロファイルやサービス側の変更によって異なることがあります。インターネット上の古いルール一覧をそのまま貼り付けるのではなく、自分の接続ログで実際に確認できたホストを根拠にしてください。

失敗した接続がDIRECTになっているなら、ルールの不足や順序が候補です。期待したグループに入っていても失敗するなら、そのグループで選択されているノード、ノードの遅延や切断、またはサービス側の応答を調べます。接続が一瞬で終了するのか、長時間保留された後にタイムアウトするのかも重要です。接続履歴やログを共有するときは、購読URL、認証情報、Cookie、アカウント名などを必ず伏せてください。

ノードとポリシーグループを一つずつ検証する

ルールが想定どおりでも、選択されたノードが不安定ならGrokの通信は完了しません。まずポリシーグループを開き、現在選択されているノード名を確認します。その後、同じモードと同じブラウザのまま、別の利用可能なノードへ一つずつ切り替えて再試行してください。複数のノードを同時に変更したり、グループの種類をまとめて変更したりすると、どの変更で結果が変わったか分からなくなります。切り替えるたびに、ページ表示、ログイン、質問送信のどこまで進んだかを記録すると比較しやすくなります。

遅延テストの数値が小さいことだけで、Grokとの通信が安定しているとは判断できません。測定先への短い接続と、実際のサービスへのログインや応答では、接続先や通信時間が異なります。遅延が良好なノードでも、接続が途中で切れる、応答が長時間返らない、ログイン状態が維持されない場合があります。逆に、測定値が少し高くても、実際のページ表示やAPI応答が安定するノードが見つかることもあります。実際にGrokを操作したときの結果を優先しましょう。

すべてのノードで同じ症状が出る場合は、ノードを次々に追加する前に、同じ時刻にほかのサービスへ接続できるか確認します。別のサービスも不調なら回線やClashコア、端末のネットワーク設定が関係している可能性があります。Grokだけ失敗し、ほかの通信は安定しているなら、ルール、DNS、認証状態、またはサービス側の一時的な問題に絞り込めます。購読やノードを更新した直後から症状が出た場合は、プロファイルの更新でグループ名やルール構成が変わっていないかも確認してください。

DNS・キャッシュ・サービス側の状態を見分ける

DNSの不整合は「サイトが見つからない」「接続先が不安定」「端末によって結果が違う」といった症状につながります。ClashでDNS機能を利用している場合は、クライアントやコアのログに名前解決エラーが記録されていないか確認してください。OSやブラウザに古いDNSキャッシュが残っていると、設定を直した後も以前の接続先を使い続けることがあります。DNS設定を変更したときは、ブラウザを終了して再起動する、ページを開き直すなど、変更が反映される機会を設けてから比較します。

DNSの設定を試すときは、一度に複数のDNSサーバー、ルール、モードを変更しないでください。変更前の値を記録し、一項目ずつ戻せるようにします。特定のネットワークだけで失敗し、別の信頼できる回線では成功するなら、端末の設定だけでなく、その回線のDNSやフィルタリングも候補になります。ただし、公共Wi-Fiや管理されたネットワークの制限を回避しようとするのではなく、ネットワークの利用条件を確認してください。

ルール、ノード、名前解決に目立った問題がない場合は、Grok側の障害や一時的な混雑も考慮します。ほかの利用者にも同じ症状が出ていないか、サービスの公式ステータスや告知を確認し、少し時間を置いてから同じ手順で再試行してください。Clashの接続ログに接続先とポリシーが記録されているのに、応答だけが継続して返らない場合は、設定を大きく変更する前にサービス側の状態を確認する価値があります。繰り返し再読み込みを行うと認証制限が加わることもあるため、短い間隔での連続試行は避けましょう。

TUNとシステムプロキシの違いを整理する

システムプロキシは、OSのプロキシ設定を参照するアプリの通信をClashへ送る方式です。ブラウザなどはこの設定を利用しやすい一方、アプリ独自のネットワーク処理、別のプロキシ設定、システム設定を参照しない通信は、期待どおりに通らないことがあります。ブラウザの通信が接続ログに現れないときは、まずClash側のシステムプロキシ設定とOS側の状態が一致しているかを確認します。ほかのVPNやプロキシを同時に動かしている場合は、競合の有無を確認するため、許可された環境で片方ずつ停止して比較してください。

TUNは仮想ネットワークインターフェースを使い、システムプロキシに対応していないアプリの通信も捕捉しやすくする方式です。ただし、管理者権限、VPNやフィルターとの競合、ルーティングやDNSの設定が関係するため、単純に「TUNをオンにすれば直る」とは限りません。ブラウザの接続がシステムプロキシで正常に確認できているなら、TUNを追加で有効にする必要がない場合もあります。反対に、対象アプリの通信が接続ログに現れず、システムプロキシにも従わないと確認できた場合は、TUNが選択肢になります。

TUNを有効にする際は、最初に元の状態を控え、クライアントが求める権限やOSの許可内容を確認してください。TUNとシステムプロキシを同時に使う設定は、クライアントごとに処理が異なるため、片方ずつ有効にして通信の変化を見ます。接続が悪化したら直前の変更を戻し、ログに新しいエラーが出ていないか確認します。複数のネットワーク拡張を一度に切り替えるより、システムプロキシのみの状態を基準として比較するほうが原因を追いやすくなります。

変更を安全に戻し、原因を記録する

調査が終わったら、診断のために変更したGlobalモード、DNS設定、ノード選択、TUN設定を確認し、普段使う状態へ戻します。Globalモードのままにしておくと、通常のルール分流が適用されず、ほかのアプリの通信まで意図しない経路へ送る可能性があります。設定ファイルを編集した場合は、構文エラーがないことと、アクティブなプロファイルに変更が反映されたことを確認してください。購読から取得したファイルへ直接追記すると、次回の更新で変更が消えることがあるため、編集箇所と保存場所を明確にしておきます。

次回の再発に備え、「発生時刻」「利用したクライアントとコア」「モード」「選択ノード」「Grokのどの操作で失敗したか」「接続ログに表示されたポリシー」を短く記録します。これらがそろえば、設定をむやみに入れ替えずに、同じ条件で再現するかを比べられます。ログを外部へ送る場合は、アカウント情報、購読トークン、接続先の個人情報を削除し、必要な行だけを共有してください。

古いクライアントや個別に組み合わせたプロキシ設定では、項目名の違いや更新状況のばらつきが原因調査を難しくすることがあります。Clash V.COREなら、モードやノードを画面から確認しながら、接続ログを使ってGrokの通信経路を順番に切り分けやすく、手動設定だけに頼る構成より作業の見通しを保ちやすくなります。今回の確認手順を普段の環境でも再現しやすくしたい方は、機能と対応環境を確認のうえ、Clash V.COREのダウンロードページをご覧ください。