Clashを初めて使う人がよく尋ねる10の疑問：ノード・モード・ポートを一度に解説

1. Clashのノードはどこから入手するのか

結論：Clashクライアントは設定の読み込み、トラフィックの振り分け、プロキシ接続の確立を担いますが、ノード自体を生成するものではありません。ノードは通常、サービス提供者が発行するサブスクリプションURLから取得します。ユーザーがYAML設定に手動で記述することもできます。

利用できる設定には通常、プロキシノード、プロキシグループ、ルール、DNS設定が含まれます。ノード一覧だけでプロキシグループがない場合、サーバーは表示されても「自動選択」や「フォールバック」などで切り替えられないことがあります。ルールだけでノードがない場合も、プロキシルールの出口がありません。

サブスクリプションURLと通常のWebリンクの違い

サブスクリプションURLは通常、サービス提供者が発行します。コピーしたら、クライアントの設定インポート欄に貼り付けます。
サブスクリプションURLはClash YAMLを返す場合もあれば、Base64形式のノード一覧を返す場合もあります。後者は、クライアントが対応形式をサポートしているか、信頼できるサービスで変換する必要があります。
ブラウザでURLを開けても、Clashが認識できる形式とは限りません。ログインページ、プランページ、HTMLのエラーページが表示される場合、それは有効な設定データではありません。
サブスクリプションURLには通常、本人確認用のパラメーターが含まれます。アカウント情報と同じように扱い、スクリーンショット、フォーラム、公開コードリポジトリに掲載しないでください。

インポート後は、設定一覧で追加した設定を選択する必要があります。Clash Verge Rev 2.xの一般的な画面では、「サブスクリプション」→「新規作成」→URLを貼り付け→「保存」と進み、その後サブスクリプション一覧に戻って該当する設定をクリックします。クライアントによって「サブスクリプション」がProfiles、設定、プロファイルなどの表記になっている場合もありますが、手順は「追加、更新、選択」の3段階です。

2. サブスクリプションのインポートに成功しても使えない理由

結論：「インポート成功」はクライアントが設定を取得したことを示すだけで、ノードが選択済みであることや、システムの通信がClashに渡っていることを意味しません。初心者が見落としやすいのは、後者の2点です。

次の4項目を順番に確認

設定が有効になっている：設定一覧で現在の項目が選択状態になっていることを確認します。履歴に表示されているだけでは不十分です。
プロキシグループが選択されている：「プロキシ」またはProxiesページを開き、主要なプロキシグループが空欄でないことを確認します。利用可能なノード、または自動テストグループを選択してください。
実行モードが直結になっていない：切り分け中はまずルールモードを使い、Directや直結モードを誤って選ばないようにします。
通信の入口が有効になっている：通常のブラウザではシステムプロキシを有効にします。システムプロキシに従わないアプリではTUNが必要になる場合があります。

実行ログも確認できます。Webサイトにアクセスしても新しいログがまったく出ない場合、リクエストがClashに入っていません。システムプロキシ、ブラウザ個別のプロキシ、TUN、ポート設定を確認してください。ログにリクエストがあるもののtimeout、connection refused、DNSエラーが表示される場合に、ノード、ネットワーク、DNSを詳しく調べます。

3. ルールモード、グローバルモード、直結モードの選び方

結論：普段はルールモードを優先します。グローバルモードは振り分けの問題を一時的に切り分けるときに便利です。直結モードはプロキシ転送を停止するときに使いますが、通常は通信自体がClashのコアを通る状態です。

モード	処理方法	適した場面	よくある誤解
ルールモード	ルールを上から順に照合し、直結、プロキシ、拒否を決める	普段のWeb閲覧、ソフトウェア更新、ローカルサービスを併用する場合	ルールが古いと、一部のドメインが誤ったポリシーに振り分けられる
グローバルモード	大半のリクエストを選択したプロキシポリシーにまとめて渡す	問題の原因がルールによる振り分けか判断する場合	OS上のすべての通信が自動的にClashへ入るわけではない
直結モード	ローカルネットワークから対象へ直接アクセスする	プロキシの出口を一時停止し、ネットワークの状態を比較する場合	システムプロキシは有効なままになっている可能性がある

ルールモードの基本は「上から順に、最初に一致したルールを適用」です。たとえばドメインが先に DOMAIN-SUFFIX ルールへ一致すると、後続の MATCH は処理されません。設定末尾によくある MATCH は、前のルールに一致しなかった接続を受け止めるフォールバックルールです。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Proxy

あるWebサイトがグローバルモードでは使えるのにルールモードでは使えない場合、通常はノードに問題はありません。確認すべきなのは、どのルールに一致したかです。接続履歴を開き、対象ドメインが最終的に DIRECT、特定のプロキシグループ、REJECT のどれに振り分けられたかを確認し、設定を更新するか該当ルールを調整します。

4. 7890ポートとは何か。既定値のままにする必要はあるか

結論：7890は多くのClash設定で使われるローカルプロキシポートですが、すべてのクライアントで固定された必須値ではありません。mixed-portとして設定される場合もあれば、HTTPプロキシ専用の場合もあります。実際の値は、現在のクライアントの実行設定とYAML設定を基準にしてください。

設定項目	よく使われるポート	用途
`mixed-port`	7890	同じポートでHTTPとSOCKS5のプロキシリクエストを受け付ける
`port`	7890	HTTPプロキシの入口
`socks-port`	7891	SOCKS5プロキシの入口
`external-controller`	9090	グラフィカルインターフェースが状態の取得やポリシー切り替えに使うコントロールインターフェース

9090はブラウザに入力するプロキシポートではありません。ブラウザのプロキシを 127.0.0.1:9090 に誤設定すると、通常は接続に失敗します。混合ポートを使う場合、プロキシアドレスは一般に 127.0.0.1:7890 です。クライアントに別のポートが表示されている場合は、画面上で現在有効な値を使ってください。

ポートが使用中のときの対処

ログにaddress already in use、bind failed、「ポートが使用中」などと表示されたら、まず他のプロキシツールを終了してClashを再起動します。それでも競合する場合は、「設定」→「パラメーター設定」または「設定」→「ポート設定」で混合ポートを7892、7893など未使用の番号に変更し、システムプロキシを再度有効にします。ブラウザにプロキシを手動設定している場合は、ブラウザ側のポートも変更してください。

ポート変更後は、スイッチの状態だけを見ないでください。ログでローカルの待ち受けが開始されていることを確認するか、クライアントのホーム画面でHTTP、SOCKS、Mixedの入口に表示された実際のポートを確認します。システムプロキシの自動設定は通常、新しいポートに追従しますが、手動設定は自動では変わりません。

5. システムプロキシを有効にしてもWebサイトが開けない理由

結論：まずリクエストがClashに入っているかを確認し、次に入った後のどの段階で止まっているかを調べます。システムプロキシのスイッチがオンになっただけでは不十分です。ノードの停止、ルールによる直結、DNSの失敗、ブラウザによるシステム設定の上書きなどが「有効なのにつながらない」原因になります。

5分でできる切り分け手順

クライアントのログまたは接続ページを開き、現在のフィルターを解除します。
ブラウザで対象サイトにアクセスし、該当するドメインが表示されるか確認します。
ログが出ない場合は、ブラウザに個別インストールしたプロキシ拡張機能を無効にし、プロキシアドレスが 127.0.0.1 で、ポートがクライアントと一致していることを確認します。
ログがあるのに DIRECT に一致する場合は、一時的にグローバルモードへ切り替えて比較します。グローバルモードで使えるなら、ルールを確認すべきです。
ログにtimeoutと表示されたら、遅延が正常な別のノードに切り替え、ローカルネットワークから通常のWebサイトへアクセスできるか確認します。
ログにDNS error、no such host、名前解決のタイムアウトが表示されたら、ポートを何度も切り替えるのではなく、DNS設定を確認します。

Windowsでは、システムプロキシが他のソフトウェアに書き換えられていないかも確認します。一般的な確認先は「設定」→「ネットワークとインターネット」→「プロキシ」です。Clashがシステムプロキシを自動管理している場合、手動プロキシのアドレスは通常、ローカルのループバックアドレスになります。クライアントを終了する前にシステムプロキシを無効にし、OSが停止した7890ポートへリクエストを送り続けないようにしてください。

macOSでは「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」で状態を確認できます。複数のプロトコルを手動で同時に有効にし、さらにクライアントにも管理させる必要は通常ありません。重複設定はポートの不一致を招くため、クライアントの「システムプロキシに設定」機能で一元管理するのが基本です。

6. ノードの遅延はどの程度なら正常か。数値が小さいほど必ず速いのか

結論：遅延はテストリクエストの往復にかかる時間で、ダウンロード速度と同じではありません。普段のWeb閲覧では50〜150ミリ秒なら反応が速く、150〜300ミリ秒でも利用できます。500ミリ秒を継続的に超える、またはtimeoutになる場合は、優先的にノードを変更するとよいでしょう。

これらは固定の品質基準ではありません。地域、通信事業者、Wi-Fiの電波状態、テスト先によって結果は大きく変わります。同じノードでも、あるテストURLでは92ミリ秒、別のURLでは180ミリ秒になることがあります。夜間の混雑時には110ミリ秒から260ミリ秒へ上がることもあります。2〜3回連続でテストし、実際のWeb閲覧、動画再生、ファイルダウンロードの結果も合わせて判断してください。

遅延は低いのに速度が遅い主な原因

ノードからテスト先までの経路は短くても、実際の対象サイトまでの回線が混雑している。
サーバー側の利用可能な帯域が限られており、接続はすぐ確立しても継続転送速度が高くない。
ローカルのWi-Fiでパケットロスが発生し、遅延は一時的に正常でも接続が不安定になっている。
プロキシグループに表示されているのが前回のキャッシュ結果で、ノードの現在の状態が変わっている。
UDP、動画の分割データ、大容量ファイルの転送では、通常のHTTP遅延テストとは異なる経路が使われる。

自動選択グループは通常、定期的なURLテストで遅延の低いノードを選びます。一方、フォールバックグループは現在のノードが利用可能かどうかを重視します。前者は日常の選択、後者は接続の継続性を保ちたい場合に適しています。テスト間隔を短くしすぎないでください。300〜600秒に1回の確認で十分なことが多く、数秒おきに実行すると余計なリクエストが発生します。

7. システムプロキシとTUNモードの違い

結論：システムプロキシは、アプリがOSのプロキシ設定を読み取ることを前提とします。TUNモードは仮想ネットワークインターフェースを通じて、より多くのIP通信を取り込みます。ブラウザや多くのデスクトップソフトはシステムプロキシを利用できますが、ゲーム、コマンドラインプログラム、一部のストアアプリ、独自のネットワークスタックを使うソフトではTUNが必要になる場合があります。

項目	システムプロキシ	TUNモード
取り込み方法	アプリがHTTPまたはSOCKSプロキシ設定を読み取る	仮想ネットワークインターフェースがシステムのネットワーク通信を受け取る
必要な権限	通常は一般ユーザー権限	通常は管理者権限またはサービスモードが必要
適したプログラム	ブラウザ、システムプロキシに従うソフト	システムプロキシを読み取らないプログラム、一部のUDPアプリ
切り分けの難しさ	低い	ルーティング、DNS、仮想ネットワークインターフェース、ファイアウォールを同時に確認する必要がある

初めて使う場合は、まずシステムプロキシを安定させてからTUNを検討します。Mihomo 1.19.xの設定仕様を採用するクライアントでは、TUNの一般的な設定に enable、stack、auto-route、auto-detect-interface、DNSハイジャックなどがあります。グラフィカルクライアントでは通常、「設定」→「システム設定」→「サービスモード」でバックグラウンドサービスをインストールし、その後「設定」→「ネットワーク」またはホーム画面からTUNを有効にします。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixed は互換性を重視した一般的な選択です。特定のシステムで接続問題が起きる場合は、クライアントの説明に従ってsystemまたはgVisorを試してください。既存の設定を把握しないまま、サブスクリプション内のTUNやDNSの項目を丸ごと上書きしないでください。サブスクリプション側に環境に合ったパラメーターが用意されている可能性があります。

8. ブラウザは使えるのに、ゲーム・ターミナル・ストアアプリがプロキシを使わない理由

結論：これらのプログラムはシステムプロキシを読み取らないか、UDP、自前のDNS、QUICなど別の通信方式を使っている可能性があります。ブラウザが使えるなら、ノードと基本的なプロキシ入口はおそらく正常です。次に確認すべきは、対象プログラムの通信がClashに入っているかどうかです。

コマンドラインツールには独自のプロキシ変数があることがよくあります。現在のターミナルセッションだけでローカルHTTPプロキシを使う場合は、ツールの対応状況に応じて HTTP_PROXY と HTTPS_PROXY を設定します。SOCKS5に対応するプログラムでは、127.0.0.1:7890 またはクライアントに表示されるSOCKSポートを指定できます。変数名とプロキシプロトコルはプログラムのドキュメントに合わせてください。すべてのツールがシステム設定を読み取るとは限りません。

HTTP_PROXY=http://127.0.0.1:7890
HTTPS_PROXY=http://127.0.0.1:7890

ゲームや一部のストアアプリはUDPを使うことがあり、通常のHTTPシステムプロキシではこの通信を直接処理できません。その場合は、ノードが該当する通信に対応していることを確認してからTUNを有効にし、接続一覧で対象IP、プロトコル、適用されたポリシーを確認します。TUNを有効にしても記録がない場合は、仮想ネットワークインターフェース、ルーティングの除外項目、アプリが別のネットワークインターフェースを使っていないかを確認してください。

「グローバルモード」は、すでにClashへ入った接続の出口を決めるだけで、すべてのプログラムを強制的にコアへ送るものではありません。したがって、ルールモードからグローバルモードに変えても、システムプロキシやTUNの代わりにはなりません。初心者が混同しやすいのはこの2つの層です。通信の入口は「Clashに入るか」を決め、プロキシモードは「入った後にどこへ出るか」を決めます。

9. サブスクリプションの更新失敗、404、タイムアウトへの対処

結論：404はURL自体またはアカウント状態に関係することが多く、タイムアウトはネットワーク経路、サーバーの応答、プロキシ経由の更新設定が原因になりやすいです。エラーの種類に応じて対処し、まだ使える現在の設定をすぐに削除しないでください。

404、401、403が表示される場合

404：サブスクリプションのパスが存在しない、URLが変更された、またはサーバーが共通のエラーページを返しています。サービス提供者の管理画面から最新のURLをコピーし直してください。
401：認証パラメーターが無効または不足しています。アカウントに再ログインしてサブスクリプションを取得してください。
403：サーバーが現在のリクエストを拒否しています。アカウント状態、リクエスト頻度、アクセス元などが関係している可能性があります。

timeoutまたはconnection resetが表示される場合

まずブラウザでサブスクリプションのドメインに接続できるか確認します。ただし、完全なサブスクリプションURLは公開しないでください。現在のネットワークからサブスクリプションサーバーへ直接接続できない場合は、クライアントで「プロキシ経由で更新」「プロキシを使ってサブスクリプションを更新」などの設定を探します。サーバーが直接接続のみを許可している場合は、その設定を無効にしてください。2つの方式を短時間に何度も切り替えて再試行すると、サーバーのレート制限にかかる可能性があります。

自動更新の間隔は短くしすぎないでください。ノード情報は毎分変わるものではないため、一般的には1440分に1回で十分です。早めに同期したい場合は360分に設定します。5分間隔では不要なリクエストが増え、一時的なネットワークの揺らぎで状態が何度も上書きされる可能性もあります。更新に失敗したら、直前に成功した設定を残したまま手動で再試行してください。

更新後に設定が突然空になった場合は、まず直前のローカル記録へ戻し、返された内容がHTMLのログインページ、エラーJSON、または非対応形式ではないか確認します。クライアントにYAML parse errorと表示されたら、エラー行を確認してください。インデント、コロンの後の空白、重複したキー名、閉じられていない引用符などが解析失敗の原因になります。

10. 最初の1週間を安定して使う設定と、問題発生時の復旧方法

結論：設定はシンプルに保ち、まずルールモード、主要なプロキシグループ1つ、システムプロキシだけを使います。ブラウザで安定して通信できることを確認してから、自動速度測定、TUN、カスタムDNS、スクリプトを追加してください。機能を1つ追加するたびに、実際のアクセスで動作を確認します。

初心者に適した基本状態

現在の設定を明確に選択し、直近で利用できたローカル記録を1つ残しておく。
実行モードはルールモードにし、主要なプロキシグループでは検証済みのノードを手動で1つ選択する。
混合ポートはクライアントが自動管理する値を使う。例：7890。
システムプロキシはクライアントのスイッチで管理し、ブラウザに拡張機能を重ねて設定しない。
自動更新間隔は360〜1440分に設定する。
ログレベルは普段の利用ではinformationにし、debugは切り分けるときだけ一時的に使う。
TUN、スクリプトによる上書き、カスタムDNSは必要な場合に1つずつ有効にする。

設定を崩したときの復旧手順

TUN、スクリプト、手動で記述した上書き設定を無効にし、元のサブスクリプション設定だけを残す。
ルールモードへ戻し、テストで利用可能と確認したノードを選択する。
ローカルの混合ポートを確認し、ポート競合がないことを確かめる。
システムプロキシをいったん無効にしてから再度有効にし、OSのプロキシアドレスを更新する。
ブラウザで対象サイトへアクセスしながら、接続ログを確認する。
基本的なアクセスが復旧したら、カスタム設定を1つずつ戻し、各手順で変化を記録する。

Clashを完全に終了するとすべてのWebサイトが開けなくなる場合、システムプロキシの設定が残っている可能性があります。クライアントを再起動してシステムプロキシを無効にするか、OSのネットワーク設定で手動プロキシを解除してください。Clashを有効にすると中国本土の一般的なWebサイトまで遅くなる場合は、ルールがすべてのリクエストをプロキシグループへ送っていないか、グローバルモードになっていないか確認します。

最初の1週間ですべての設定項目を理解する必要はありません。まず4つの層を区別しましょう。サブスクリプションが設定を提供し、ノードが接続先の出口を担い、システムプロキシまたはTUNが通信を取り込み、ルールが出口を選択します。「有効にしたのにつながらない」問題の多くは、この4層に沿って順番に確認すれば特定できます。