Clash初心者向けFAQ10選：サブスクリプションの追加方法、ルール・グローバルモードの選び方、ポートの役割
サブスクリプションの追加、モード選択、ノード切り替え、ポート、自動起動など、初心者がつまずきやすい10の疑問に回答。各項目に関連記事へのリンクを掲載します。
1. Clash、クライアント、mihomoの違いは？
「Clash」は、コアを指す場合もあれば、画面付きのクライアントを指す場合もあります。コアは接続を受け付け、ルールに照らして判定し、プロキシサーバーへ接続します。クライアントはサブスクリプション管理や画面操作、システムプロキシ、コアプロセスの管理を担います。トラブルを調べる際は、「Clashの最新版」とだけ伝えるのではなく、クライアント名とコア名の両方を確認しましょう。
Clash MetaはClashのエコシステムから派生したブランチで、後にmihomoという名称が使われるようになりました。クライアントによって搭載するコアは異なり、対応プロトコルやルールの項目、TUNの設定も一律ではありません。mihomoで読み込める設定でも、旧バージョンのClashコアがすべての項目を認識するとは限りません。
- クライアントのバージョン：通常は「バージョン情報」画面で確認できます。メニューの構成や設定管理機能に関わります。
- コアのバージョン：通常は「コア」または「バージョン情報」画面で確認できます。設定構文やプロトコルの対応状況に関わります。
- サブスクリプションサービス：サーバー情報や設定を提供するサービスです。クライアントとは別のもので、クライアントをインストールしても自動で利用できるわけではありません。
関連記事：まずクライアントのダウンロードからOSに合う製品を選び、プロトコルリファレンスでコアの対応状況を確認しましょう。
2. サブスクリプションを追加する方法と、追加後に反映されない原因は？
サブスクリプションURLは、設定やノード情報を取得するためのアドレスです。Clashの完全なYAMLを返す場合もあれば、ノード一覧だけを返す場合もあります。ノード一覧だけでは完全な設定として動作しないことがあるため、サービス側が現在のクライアントやコアに対応した形式を提供しているか確認してください。
基本的な追加手順
- サブスクリプションサービスのページで、Clashまたはmihomo用のURLをコピーします。アカウント管理ページのURLと間違えないようにしてください。
- クライアントの「設定」または「Profiles」画面を開き、「新規作成」「URLからインポート」などの項目を探します。
- URLを貼り付けてダウンロードし、一覧に設定名が表示され、解析エラーが出ていないことを確認します。
- 設定を選択または有効化し、「プロキシ」画面でプロキシグループとノードが表示されることを確認します。
- 利用可能なノードを選び、必要に応じてシステムプロキシを有効にします。設定を追加しただけでは、アプリの通信がコアに送られるとは限りません。
メニュー名は製品によって異なります。上記は一般的な操作の順序であり、すべてのクライアントで同じメニューをたどれるわけではありません。HTTP 401または403が表示されたら、まずサブスクリプションの認証情報と有効期限を確認してください。ダウンロードは成功してもYAML解析エラーになる場合は、取得した内容がログインページやエラーメッセージ、非対応形式ではないか確認しましょう。
3. ルール・グローバル・直結モードはどう選ぶ？
モードが決めるのは「コアに入った接続をどの出口に振り分けるか」であり、「どのアプリの通信をコアに通すか」ではありません。グローバルモードだけを有効にしても、システムプロキシやTUNを設定していなければ、すべてのアプリが自動的にクライアントを経由するわけではありません。
| モード | 処理方法 | 向いている用途 |
|---|---|---|
| ルール（Rule） | 設定内のルールを上から順に照合し、ポリシーを適用 | 直結とプロキシを使い分ける普段の利用 |
| グローバル（Global） | グローバルポリシーグループで選択した出口を使用 | 出口を一時的に比較し、ルールによる振り分けを調べる |
| 直結（Direct） | 端末から接続先へ直接接続 | 一時的にプロキシを経由せず、通常のネットワーク接続と比較する |
ルールモードでは通常、上から順に照合し、最初に一致したルールが適用されます。以下はルールの一部であり、単独で読み込める完全な設定ではありません。「デフォルトの出口」には、設定内にすでに存在するプロキシまたはプロキシグループ名を指定してください。
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,デフォルトの出口この例では、example.comとそのサブドメインは直結し、それ以外の接続は「デフォルトの出口」に送られます。そのグループでDIRECTが選択されている場合、最後に一致する接続も直結します。そのため、「ルールモードが有効」でも、接続が必ずプロキシサーバーを経由するとは限りません。
関連記事：プロトコルリファレンスでルールの種類、ポリシー名、照合順を確認しましょう。
4. ノードとプロキシグループの違いは？ノードの切り替え方は？
ノードは通常、個別のプロキシサーバーに対応します。プロキシグループはルールから参照できる選択レイヤーです。グループにはノードや別のプロキシグループのほか、DIRECTを含めることもできます。切り替える際は、ホーム画面に表示されたノード名だけでなく、通信が最終的にどのグループに振り分けられているかを確認してください。
select：候補から手動で1つ選択します。接続先の出口を固定したい場合に適しています。url-test：設定されたテスト結果をもとに候補を自動選択します。テスト先や許容値などの設定によって結果は変わります。fallback：候補の順にヘルスチェックを行い、利用可能なものを選びます。最も低い遅延だけを基準にする方式ではありません。
まず「接続」画面を開き、対象ドメインの接続を見つけて、適用されたルールとプロキシチェーンを確認します。その後、該当するプロキシグループでノードを切り替えてください。切り替えが反映されるのは通常、新しく確立する接続です。ダウンロードや動画、長時間接続は以前の出口を使い続ける場合があるため、再接続して確認しましょう。
遅延が80 msと表示されても、それはそのテストにかかった時間を示すだけで、ダウンロード速度には換算できません。実際の転送速度は、帯域幅や混雑状況、接続先のサイト、ローカルネットワークにも左右されます。遅延がタイムアウトと表示されても、テスト先に到達できないだけの場合があるため、実際の通信とあわせて判断してください。
5. ポート7890、7891、9090はそれぞれ何に使う？
これらはよく使われる設定例であり、すべてのクライアントに共通する固定の初期値ではありません。利用前に、クライアントのポート設定または現在有効な設定を確認してください。特にプロキシの接続口と管理用APIを区別し、コントロールポートをブラウザーのプロキシ設定に入力しないようにしましょう。
mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090上記の設定例では、7890はHTTPとSOCKSを兼ねる混合プロキシの接続口、9090は管理画面が使用するコントロールAPIです。allow-lan: falseはLAN内にプロキシを公開しない設定です。古い設定ではHTTPとSOCKSが別々のポートで待ち受ける場合もあります（例：port: 7890、socks-port: 7891）。数字だけでプロトコルを判断しないでください。
コマンドでプロキシの接続口を確認する
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --head https://example.comこのコマンドはローカルの7890番ポートを明示し、接続タイムアウトを10秒に設定します。Windows PowerShellでは、古い環境のコマンドエイリアスによる違いを避けるため、curl.exeを使用できます。接続が拒否された場合は、まずコアが動作しているか、ポート番号が一致しているか確認してください。HTTPレスポンスが返っても、それは応答があったことを示すだけで、すべてのサイトにアクセスできるとは限りません。
関連記事：プロトコルリファレンスで待ち受け設定を確認し、ポートの競合はヘルプセンターを参考に解消しましょう。
6. システムプロキシを有効にしても、ブラウザーやターミナルがプロキシを使わないのはなぜ？
システムプロキシは、アプリが参照するためのプロキシ設定であり、OSがすべての通信を強制的に転送する仕組みではありません。多くのブラウザーはシステムプロキシを利用しますが、コマンドラインツールやゲーム、独自のネットワーク処理を行うアプリは無視することがあります。ブラウザーのプロキシ拡張機能がシステム設定を上書きする場合もあります。
- 前のセクションにある、プロキシを明示指定するコマンドでテストし、「プロキシの接続口が使えない」のか「アプリがプロキシを使っていない」のかを切り分けます。
- ブラウザーのプロキシ拡張機能、個別のプロキシ設定、例外リストを確認し、複数のツールが同時にプロキシ設定を変更しないようにしてください。
- クライアントの「接続」画面で対象の通信が表示されるか確認します。記録がない場合は、ノードを何度も切り替えるのではなく、まず通信の取り込み口を確認してください。
- ターミナルのツールは、ドキュメントに従って環境変数やプロキシ引数を設定します。より多くのアプリの通信を取り込む必要がある場合は、TUNモードを検討してください。
たとえば、macOSやLinuxの現在のシェルでは一時的に次のように設定できます。
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl --head https://example.com
unset http_proxy https_proxyhttps_proxyの値にもhttp://を使用できます。これはHTTPプロキシ経由でHTTPSの接続先へのトンネルを確立する指定です。ここでのexportは現在のシェルと、そこから起動する子プロセスにだけ適用され、システム全体の設定は変更しません。環境変数名への対応状況はツールによって異なります。
関連記事：ヘルプセンターでアプリのプロキシ設定と接続の確認方法を参照してください。
7. TUNモードとは？必ず有効にする必要はある？
TUNは仮想ネットワークインターフェースを通じて通信を取り込み、ルーティングやDNSの設定と組み合わせて、システムプロキシを参照しない接続もコアに送ります。ルールモードとは役割が異なります。TUNは通信をコアに取り込む方法を決め、ルールは取り込んだ後の出口を決めます。
ブラウザーや普段使うツールがシステムプロキシ経由で正常に動作しているなら、「設定を完璧にする」ためだけにTUNを有効にする必要はありません。ゲームや一部のコマンドラインプログラムなど、プロキシ設定を参照しないアプリの通信を取り込む必要がある場合に、クライアントの説明に従って有効にしてください。Windowsのクライアントではサービスのインストールや管理者権限が必要な場合があり、macOSやLinuxでも権限やシステムネットワークの設定が関係します。
有効化の前後に確認すること
- ノードの問題をTUNの問題と取り違えないよう、まずシステムプロキシ経由の通信が使えることを確認します。
- 既存のVPNや仮想ネットワークアダプター、社内ネットワークの要件を確認します。複数のソフトがデフォルトルートを変更すると、競合することがあります。
- 有効化後、対象の通信がクライアントに取り込まれていることを確認し、LAN、DNS、IPv6への接続も正常か確かめます。
- クライアント終了後にネットワークが復旧するか確認します。問題がある場合は、まずTUNを無効にし、残ったルートやサービスの状態を調べてください。
stack、auto-route、dns-hijackの対応状況や初期値は、コアやクライアントによって異なります。インターネット上のTUN設定を一式そのままサブスクリプションに上書きしたり、ネットワークのアクセス制限を回避する目的でTUNを使ったりしないでください。
関連記事：プロトコルリファレンスでTUNの設定項目を確認し、ルーティングの問題はヘルプセンターを参考に調べましょう。
8. サブスクリプションの更新後にカスタムルールが消えるのはなぜ？
リモートサブスクリプションを更新すると、通常はサーバー側の設定を再取得します。ダウンロードしたYAMLを直接編集していると、次回の更新で変更が上書きされることがあります。また、サブスクリプション、プロキシプロバイダー、ルールプロバイダーの更新は別々の処理で、それぞれ異なるデータソースが対象です。
- リモートサブスクリプションは上流のデータソースとして扱い、カスタムルールを保存する唯一の場所にしないでください。
- クライアントにオーバーライド、マージ、スクリプト機能がある場合は、その機能にローカルの変更を設定し、適用範囲を確認してください。
- すべて手動で管理する場合は、ローカル設定として別に保存します。その場合、サーバー情報がリモートサブスクリプションに合わせて自動更新されなくなる点に注意してください。
- 更新後は編集画面の元データだけでなく、最終的に適用された設定も確認してください。
ルールのオーバーライドでは、挿入位置にも注意が必要です。カスタムルールをMATCHの後に追加すると、通信はすでにフォールバックルールに振り分けられているため、後続のルールは適用されません。存在しないプロキシグループを新しいルールから参照すると、設定の読み込みに失敗することがあります。
更新間隔の単位も確認してください。たとえばmihomoのproxy-providersにあるinterval: 3600は3600秒、つまり1時間を意味します。クライアントのサブスクリプション画面では更新間隔が分単位で表示される場合があるため、数字をそのまま転記しないでください。
関連記事：プロトコルリファレンスでプロバイダーとルールの項目を確認し、操作手順はクイックスタートを参考にしてください。
自動起動、起動後のプロキシ設定、自動更新は同じ機能？
いいえ。それぞれ異なる動作を制御します。「自動起動」を有効にすると、通常はログイン後にクライアントが起動しますが、コアの自動起動、システムプロキシの有効化、TUNの復元は個別に確認が必要です。システムサービスをインストールしても、デスクトップ画面がログイン時に必ず開くとは限りません。
| 設定項目 | 確認すること |
|---|---|
| 自動起動 | ログイン後にクライアントが起動しているか |
| 起動時にシステムプロキシを有効化 | システムプロキシのアドレスとポートが、待ち受け中の接続口を指しているか |
| 起動時にTUNを復元 | サービスの権限、仮想インターフェース、ルーティングが正常か |
| サブスクリプションの自動更新 | クライアントに設定した条件で設定を再取得するか |
設定後は、完全に終了してから再ログインするテストを少なくとも一度行ってください。まずコアの状態を確認し、その後に通信をテストします。タスクトレイのアイコンだけで判断しないようにしましょう。ポータブル版クライアントは、保存先のフォルダーを移動すると自動起動に登録されたパスが無効になることがあるため、再設定が必要です。
終了後にブラウザーでプロキシ接続エラーが表示された場合は、OSのプロキシ設定に127.0.0.1:7890が残っていないか確認してください。ローカルの接続口が閉じているのにシステムがそのポートを参照していると、「クライアントを終了したらインターネットに接続できなくなった」という状態になります。
10. インターネットに接続できないときの確認手順は？
「基本ネットワーク → コアの接続口 → 設定とノード → 振り分けルール → アプリ」の順に段階を追って確認すると、DNSやポート、モード、ノードを同時に変更するより原因を特定しやすくなります。一度に変更するのは1項目だけにし、変更前後の結果を記録してください。
- 基本ネットワーク：システムプロキシとTUNを一時的に無効にし、通常アクセスできるサイトに接続できるか確認します。それでも失敗する場合は、Wi-Fiやゲートウェイ、ネットワーク認証を先に確認してください。
- コアの接続口：設定が有効で、コアが動作し、ポート番号が一致していることを確認します。プロキシを明示指定するコマンドでテストし、接続が拒否される場合は、まずローカルで待ち受けているか確認してください。
- サブスクリプションとノード：サブスクリプションが有効であることを確認し、利用可能と分かっている別のノードと比較します。設定を解析できても、サーバーに現在接続できるとは限りません。
- 振り分け結果：接続に適用されたルールとプロキシチェーンを確認します。短時間だけグローバルモードに切り替えて比較し、テスト後は元のモードに戻してください。グローバルモードでは接続できるのにルールモードではできない場合は、まずルールの出口を確認しましょう。
- DNSとアプリ：一部のドメインだけ失敗する場合は、DNSログ、ブラウザーの暗号化DNS、キャッシュ、アプリ独自のプロキシ設定を確認します。すべての問題をDNSが原因だと決めつけないでください。
問い合わせ時に伝える情報
OS、クライアントのバージョン、コアのバージョン、現在のモード、TUNの有効・無効、実際の待ち受けポートに加え、失敗したリクエストの時刻と個人情報を伏せたログを共有してください。すべてのアプリで失敗するのか、ブラウザーやターミナル、特定のサイトだけで失敗するのかを伝えると、原因を絞り込みやすくなります。
関連記事：ヘルプセンターで確認を続けてください。基本設定をやり直す場合は、クイックスタートに沿って、追加、有効化、出口の選択、通信の取り込みを順に確認しましょう。