Clash 初心者Q&A10選:モードの違い・ポート・サブスクリプション・よくあるエラー

モードの選択ミスで、プロキシ効果が半減する

クライアントを入れたばかりの初心者は、ほぼ全員「どのモードを選ぶべきか」でつまずく。モードの選択ミスは直接エラーにはならないが、プロキシ効果が落ちて速度が遅くなったり一部サイトが開けなくなったりし、後から原因を探すほうがむしろ手間になる。

1. ルールモードとグローバルモードは何が違うのか?

ルールモードでは、クライアントがリクエストの宛先アドレスを受け取ると、まず設定内のルールセットと照合する。「直接接続」条件に該当する通信(日本国内の銀行サイト、ローカルLANアドレスなど)は端末のネットワークからそのまま出て行き、「プロキシ」条件に該当したものだけノードへ転送される。グローバルモードはこの照合ステップを飛ばし、宛先が国内か海外かにかかわらず全通信をプロキシノードに流す。日常使用ではルールモードを推奨する。日本国内サービスは端末側の回線を通るぶん遅延が低く、ノードの通信量も消費しない。ルールセットの判定漏れで本来プロキシを通すべきサイトが直接接続と誤判定された場合のみ、一時的にグローバルモードに切り替えて確認するとよい。

2. TUNモードとは何か、通常モードでは足りないのか?

通常モード(システムプロキシ/HTTPプロキシ)は、アプリが自らプロキシ設定を行った通信のみを引き受ける。ブラウザや大半のチャットアプリはこれでカバーできるが、システムの低レイヤーのネットワークインターフェースに直接アクセスするアプリ(一部のゲームクライアントやバックグラウンドサービス)はこのプロキシ層を回避してしまう。TUNモードはシステム上に仮想ネットワークアダプタを作り、端末の全通信をいったんこの仮想アダプタで受け取ってからプロキシコアに渡すため、カバー範囲がより完全になる一方、追加の権限許可(Androidでは VPN 権限のポップアップ)が必要になる。通常はプロキシモードで問題なく、特定のアプリがどうしてもプロキシを通らない場合にTUNモードを検討すればよい。

ポート・サブスクリプション・更新周期

この一群の疑問は基本的な内容に見えるが、後々トラブルを調査する際に最も見落とされがちな基礎情報でもある。先に理解しておくことで、試行錯誤の時間をかなり節約できる。

3. 画面に表示される7890番ポートは何のためのものか?

7890は、クライアントが標準で開放しているローカルの混合プロキシポート(HTTPとSOCKS5の両プロトコルに対応)で、ブラウザ拡張機能やコマンドラインツール、プロキシ機能を内蔵していないソフトウェアなどは、プロキシアドレスを手動で 127.0.0.1:7890 と設定することで接続できる。クライアント画面でシステムプロキシのスイッチをオンにすれば、システムレベルの通信は既に自動で組み込まれているため、このポートは手動でプロキシ設定が必要な場面向けであり、通常は気にする必要はない。

4. サブスクリプションリンクの更新頻度はどのくらいが適切か?

サブスクリプションの内容はサービス提供者側が管理しており、更新頻度は提供者によって異なる。一般的な運用としては、クライアント設定内で自動更新の周期(例えば12時間や24時間ごとに取得)を設定しておき、ノード情報が変わった際に自動的に同期されるようにするため、手動操作は不要になる。急いで変更内容を確認したい場合は、クライアント内の「サブスクリプション更新」や「リフレッシュ」ボタンから手動で即時実行することもでき、自動周期を待つより直接的だ。

5. サブスクリプションリンクをインポート後にノードリストが空になった場合、リンクが無効になったのか?

すぐにリンク無効と決めつける前に、よくある原因が3つある。1つはリンクをコピーした際に末尾に余分な空白が入ったり文字が欠けたりしているケース。2つ目はリンク自体が汎用共有形式であり、Clashが直接認識できる設定リンクではなく、クライアント側でフォーマット変換が必要なケース。3つ目はサービス提供者側で実際にサブスクリプションが一時停止または期限切れになっているケースだ。まずブラウザでリンクを開いて設定用のテキストが正常に返ってくるか確認するとよい。テキストが返ってくればリンク自体は問題ないので、貼り直してもう一度インポートすればほとんどのケースは解決する。

ノードと遅延の見方

6. ノードリストの遅延数値は、小さいほど良いのか?

その通りで、遅延数値は通常ミリ秒単位で表示され、クライアントがそのノードに速度測定リクエストを送信してから応答を受け取るまでの時間を示す。数値が小さいほど接続確立が速いことを意味する。ただし遅延はあくまで「接続の速さ」を反映するものであり、実際のダウンロード・再生速度とは必ずしも一致しない。遅延200msでも帯域が十分な回線であれば、遅延80msだが回線が混雑しているノードより実際の体感は良くなる場合もある。日常的なノード選びでは、まず遅延で明らかに高いものを一次的にふるい落とし、残った候補から実際の使用感で二次的に絞り込むとよい。

7. ノードが全てタイムアウトまたは測定失敗になった場合はどうするか?

まず端末自体のネットワークが正常か(日本国内の一般的なWebページが問題なく開けるか)を確認する。ネットワークが正常であれば、サブスクリプション内のノードが一括で期限切れになっているか、サービス提供者側の回線が一時的に不安定になっている可能性が高い。まず手動でサブスクリプションを更新して最新のノードリストを取得し、更新後も依然として全てタイムアウトする場合は、クライアント側の設定ミスではなくサービス提供者側の問題だとほぼ判断できる。

プロキシに接続できないときは、まずこの手順を確認

確認する順序をあらかじめ決めておくことで、「あちこち手当たり次第に触る」という無駄な試行を避けられる。以下の順番で一通り確認すれば、大抵の場合は問題箇所を特定できる。

8. プロキシスイッチをオンにしても全く反応しない場合、まず何を確認すべきか?

最初にクライアントのメイン画面にある接続状態アイコンが「接続済み」表示になっているか確認する。接続が成立していなければ、以降の確認はすべて意味を持たない。次に現在選択しているノードグループの中に少なくとも1つ使用可能な状態のノードがあるか確認する(全てグレーや赤表示になっていないか)。3つ目にシステム設定でプロキシ権限(またはVPN権限)がこのクライアントに実際に付与されているかを確認する。システム更新後に権限がリセットされることがあるため、再度許可し直す必要がある場合もある。この3ステップを確認してもなお接続できない場合は、ノードやサブスクリプション自体の問題を検討する。

9. 特定のアプリだけ開けないが、ブラウザは正常に動作する場合、原因は何か?

そのアプリがシステムのプロキシ設定を経由しない低レイヤーの通信方式を使っている可能性が高く、通常のプロキシモードではカバーできていない。まずTUNモード(クライアント内で同等の「拡張モード」オプションがある場合はそちら)を有効にして全通信を仮想ネットワークアダプタ経由にし、そのアプリが正常になるか確認する。TUNモードを有効にしても直らない場合は、ルールセットの中でこのアプリ関連のドメインが誤って直接接続カテゴリに分類されていないか確認する。

10. 通信が本当にプロキシを経由しているか、思い込みではないと確認する方法は?

最も直接的な方法は、ブラウザでアクセス元IPを表示するページを開くことだ。プロキシを無効にした状態で表示されるIPと地域を記録し、その後プロキシ接続をオンにしてページをリロードし、IPと地域が変化しているかを比較する。変化していれば、通信が確かにプロキシノードを経由していることになる。クライアント画面にリアルタイムの通信量グラフがある場合は、ページを閲覧しながらグラフに対応する変動があるかを併せて確認すると、より確実に判断できる。

この10の疑問は、インストールから日常使用まで最もつまずきやすい箇所をカバーしている。まずこの順番で一通り自己チェックすることをお勧めする。大半の接続異常はこの一巡で原因が見つかるはずだ。ノードの速度測定やプロキシが有効になっているかの確認方法をさらに体系的に理解したい場合は、初回接続の流れを専門に解説した記事も併せて参照してほしい。