Clash初心者向けFAQ10選：混合ポート・モード・サブスクリプション・ルールを解説

1. Clashクライアントとコアの違いは？

クライアントは画面表示、サブスクリプションの管理、システムプロキシの切り替え、実行状態の表示を担当します。コアは設定の読み込み、ルールの照合、ドメイン名の解決、接続の確立を担当します。クライアントをインストールしただけでは、利用可能なプロキシノードが使えるとは限りません。接続するには、有効な設定、接続可能なノード、適切なトラフィックの取り込み方法が必要です。

Clash Metaはその後、mihomoという名称で開発が続いています。コアによって対応するプロトコル、DNSフィールド、ルールタイプは異なります。「Clash設定に対応」とされていても、どんな設定でもそのまま動くわけではありません。インポート時に「不明なプロキシタイプ」や「未対応のフィールド」と表示されたら、ノードのパスワードを何度も変更するのではなく、まずコアの種類を確認してください。

確認場所：クライアントの「設定」→「情報」または「コア」画面で、クライアントとコアのバージョンをそれぞれ記録します。
トラブルシューティング：「ログ」を開き、起動時のコア名、設定の読み込み結果、エラーが出たフィールドを確認します。
選び方：まずサービス提供元が指定するプロトコルとコアを確認し、クライアント比較から対応製品を選びます。

2. 混合ポートとは？7890はどこに入力する？

mixed-portは、ローカルでプロキシ接続を待ち受けるポートです。同じポートでHTTPプロキシとSOCKSプロキシの両方を受け付けます。7890はよく使われる設定例であり、固定の標準値でもリモートノードのポートでもありません。実際の値はクライアントの「設定」→「ポート」で確認してください。クライアントによっては「コア設定」にあります。

項目	設定例	設定場所
ローカルプロキシアドレス	`127.0.0.1`	ブラウザーやアプリのプロキシサーバーアドレス
混合ポート	`7890`	アプリで指定するHTTPまたはSOCKSプロキシのポート
リモートノードのポート	設定ファイルで指定	ノード定義の値を使用。ローカルポートで置き換えない
コントロールポート	現在の設定を確認	管理パネルがコアに接続するためのポート。Webプロキシには使用しない

以下はローカル待ち受けの設定例であり、ノードを含む完全な設定ではありません。自分の端末だけで使う場合は、ループバックアドレスにバインドし、LANからのアクセスは無効にしてください。

mixed-port: 7890
allow-lan: false
bind-address: '127.0.0.1'
mode: rule

ログにaddress already in useと表示された場合、通常は別のプロセスがそのポートを使用しています。まず重複して起動しているクライアントを終了し、ポートの使用状況を確認します。7891に変更する場合は、アプリ側の手動プロキシアドレスも同じ値に変更してください。画面のポート番号だけ変えてアプリに古い値を残すと、接続が拒否されます。

3. ルール・グローバル・ダイレクトモードの選び方

これら3つのモードは、トラフィックがコアに届いた後の出力先を決めます。すべてのアプリの通信を自動的にコアへ取り込む機能ではありません。グローバルモードに切り替えても、システムプロキシを無視するターミナルが自動でプロキシを使うわけではありません。

ルールモード（Rule）：設定ファイルのルールに従って、直接接続、拒否、またはプロキシグループを選択します。普段使いでは、まずこのモードを選びましょう。
グローバルモード（Global）：コアに取り込まれた通常の接続を、グローバルの選択先に送ります。「プロキシ」→「GLOBAL」で具体的な接続先を確認してください。モードの切り替えだけでは設定は完了しません。
ダイレクトモード（Direct）：コアに取り込まれた接続を、通常はリモートプロキシノードを経由せずに直接送信します。

設定場所：「プロキシ」または「概要」→「モード」を開き、まず「ルール」を選択してから、対象のプロキシグループで利用可能なノードを選びます。コアによってはDNSやルーティングが別々に動作するため、グローバルモードでも「システム上のすべての通信が同じノードを経由する」とは限りません。

特定のWebサイトを調べる場合は、一時的にグローバルモードに切り替えて比較できます。グローバルモードでは接続できてルールモードでは失敗するなら、適用されたルールとプロキシグループを確認します。どちらのモードでも失敗する場合は、ノード、DNS、トラフィックがコアに取り込まれているかを続けて確認してください。

4. サブスクリプションURL・設定ファイル・ノードの違い

ノードはリモート接続に必要なパラメーターのまとまりで、サーバーアドレス、ポート、プロトコル、認証情報などが含まれます。設定ファイルには、ノード、プロキシグループ、ルール、DNS設定をまとめて記述できます。サブスクリプションURLはこれらの情報を取得するためのアドレスです。取得結果は完全なYAML設定の場合も、ノード一覧だけの場合もあります。

取得元に合わせてインポートする

使用中のクライアントに対応するサブスクリプションURLを取得し、「設定」→「新規作成」→「URLからインポート」を開いて貼り付け、ダウンロードします。
YAMLファイルを入手した場合は、「設定」→「ファイルからインポート」を使います。ファイルの内容をURL入力欄に貼り付けないでください。
ダウンロード後にその設定を選択し、現在の設定として表示されていることを確認してから、「プロキシ」画面に想定したプロキシグループがあるか確認します。

クライアントによっては、ノード単体のリンクをインポートできます。ただし、そのリンクにルールも含まれているとは限りません。ノードだけの場合は、プロキシグループやルールを補うためにクライアントの設定テンプレートが必要になることがあります。「インポートは成功したのにプロキシグループがない」ときは、まずインポートした内容の種類を確認してください。

5. サブスクリプションの更新頻度と手動変更への影響

サブスクリプションの更新は設定の再取得です。クライアントのアップデートでも、ノードの速度測定でもありません。更新頻度はサービス提供元の変更スケジュールによって異なります。まずは24時間ごとに設定し、提供元から別の周期が指定されている場合は、その案内に従って調整してください。更新ボタンを連続で押しても、URLの無効化や形式の非互換は解決しません。

設定場所：「設定」→現在のサブスクリプションのメニュー→「更新」または「編集」→「更新間隔」。単位に注意してください。秒単位なら24時間は86400、分単位なら1440です。クライアントによっては終了中に定期更新が実行されません。これを理由に、サーバー側の更新が停止したと判断しないでください。

手動更新のタイミング：提供元から変更の通知があったとき、ノードが広範囲で使えなくなったとき、または設定内容が明らかに古いとき。
上書きされる可能性がある内容：ダウンロードした設定に直接書き込んだルール、ノード名、DNSパラメーター。
カスタム設定を維持する：変更前にバックアップを保存し、クライアントが対応するオーバーライド、マージ、拡張設定機能を利用してください。

「更新成功」は、今回のダウンロードと読み込みが完了したことを示すだけで、すべてのノードに接続できることを意味しません。ダウンロードに失敗したら、まずログのHTTPステータスと解析情報を確認してください。401や403は権限またはアクセス制限、404はURLの無効化が考えられます。解析エラーの場合は、取得した内容が本当に設定ファイルか確認しましょう。

6. ルールの照合順序が結果に影響する理由

一般的なルールリストは上から順に照合され、最初に一致したルールで指定された出力先が使われます。具体的な例外は上に、最後に適用するフォールバックルールは末尾に置きます。以下では予約済みのサンプルドメインを使って説明します。実際のサブスクリプションにあるプロキシグループ名には依存しません。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

DOMAINは完全一致のドメインを対象にします。DOMAIN-SUFFIXは指定したドメインとサブドメインを対象にします。GEOIP,CNは接続先IPの所在地を地理データベースで判定します。MATCHはフォールバックルールです。上の例はすべて直接接続で、照合順序の説明だけを目的としています。プロキシグループを指定する場合は、出力先を設定内に実在するグループ名に置き換え、名前を完全に一致させてください。

確認場所：「接続」で該当するリクエストを探し、ルール、ルールのペイロード、出力先の経路を確認します。クライアントによっては詳細を展開する必要があります。適用ルールが画面に表示されない場合は、「設定」→「ログレベル」で一時的に詳細なレベルを選び、再現後に元へ戻してください。接続情報を長期間記録し続けないようにしましょう。

ドメインルールを使うには、コアがドメイン情報を取得できる必要があります。アプリがIPアドレスへ直接接続している場合、DNSの取り込み方法が異なる場合、または既存の接続がまだ閉じていない場合は、ルールのテキストだけから想定した結果と異なることがあります。ルールを変更したら、新しい接続を作成して確認してください。

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

システムプロキシは、OSのプロキシ設定にローカルプロキシのアドレスを書き込みます。この設定に従うブラウザーやアプリに適しています。TUNモードは仮想ネットワークインターフェースとルーティングを使ってトラフィックを取り込み、システムプロキシに従わないアプリの一部にも対応できます。ただし、ルーティング、除外設定、権限、プラットフォームごとの実装に左右されます。

デスクトップでの基本的な手順

まずクライアントの「設定」またはトレイメニューで「システムプロキシ」を有効にし、ブラウザーで接続できることを確認します。
対象のアプリが「接続」一覧に表示されない場合は、アプリ独自のプロキシ設定があるか確認します。
より広い範囲のトラフィックを取り込む必要がある場合は、クライアントの案内に従ってサービスをインストールするか権限を付与し、「TUNモード」を有効にします。

Windowsでは、管理者権限やサービスモードが必要になることがあります。macOSでは、関連するシステム権限の許可が求められる場合があります。AndroidやiOSのクライアントは通常、システムのVPNインターフェースを使って通信を取り込むため、デスクトップのシステムプロキシ設定をそのまま適用できません。別のVPN、仮想ネットワークインターフェース用ツール、通信振り分けソフトを同時に使うと、ルーティングが競合することがあります。

初心者は、1回のトラブルシューティングでTUN、DNS、ルールを同時に変更しないでください。一度に変更するのは1項目だけにし、無効時と有効時の違いを記録します。TUNを有効にしてネットワークに問題が起きたら、まずTUNを無効にして復旧し、その後、権限、ルーティングの競合、DNSの取り込みを順に確認してください。

8. ブラウザーは使えるのにターミナルで接続できないのはなぜ？

多くのコマンドラインプログラムは、デスクトップのシステムプロキシ設定を参照しません。http_proxyやhttps_proxyなどの環境変数を使う場合もあれば、独自のプロキシ引数だけを認識する場合もあります。ブラウザーで接続できても、確認できるのはブラウザーが現在使っている経路だけです。ターミナルも同じ経路を使っているとは限りません。

設定場所：クライアントの「設定」→「ポート」で実際の混合ポートを確認し、ターミナルからプロキシを明示したリクエストを試します。127.0.0.1:7890で待ち受けている場合：

# macOS / Linux
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --head https://example.com

# Windows PowerShell
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --head https://example.com

Windowsではcurl.exeを使うと、一部のPowerShell環境でcurlが別のコマンドとして解釈されるのを避けられます。接続先サイトからHTTPレスポンスが返れば、そのリクエストに応答があったことを確認できます。ローカルポートへの接続に失敗した場合は、クライアントが起動しているか、ポート番号が一致しているかを確認してください。

使用中のmacOSまたはLinuxのシェルに環境変数を一時設定する場合は、以下の方法を使えます。HTTPS接続もHTTPプロキシのCONNECTトンネル経由で利用できるため、ここではプロキシアドレスにhttp://を指定します。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# トラブルシューティング後に現在のシェルの設定を解除
unset http_proxy https_proxy

これらの変数が影響するのは、対応するプログラムとそのプロセス環境だけです。変数を設定しても直接接続される場合は、プログラム独自の設定とno_proxyの除外項目を確認してください。グローバルモードをターミナルのプロキシ設定の代わりにしないでください。

9. ノードのレイテンシは低いのにダウンロードが遅いのはなぜ？

クライアントに表示されるレイテンシは、多くの場合、接続確認やHTTPプローブの結果です。具体的な測定方法はクライアントと設定によって異なり、ダウンロード速度を示すものではありません。ICMP pingとは限りません。レイテンシが40 msと表示されるノードでも、継続的な通信では回線の混雑、サーバー帯域、接続先サイトの制限によって速度が低下することがあります。

確認場所：「プロキシ」→対象のプロキシグループで「レイテンシテスト」を実行し、テストURL、時刻、タイムアウト設定を記録します。ノードを切り替えたら古いダウンロードを終了して、新しい接続を開始してください。既存のTCP接続は通常、プロキシグループを切り替えてもすぐには移行しません。

レイテンシの比較：同じテストURLで3回続けて測定し、1回の結果だけで安定性を判断しないようにします。
スループットの比較：同じダウンロード元とファイルを使い、約30秒間の継続速度を確認します。同時に「接続」で選択中の出力先も確認してください。
単位換算：理論上、8 Mbpsは約1 MB/sです。プロトコルのオーバーヘッドは含まれていません。2つの単位をそのまま比較しないでください。

たとえば、50 msという表示から分かるのは、その測定時の結果だけです。ダウンロード速度が50 MB/sに達するとは限りません。特定のサイトだけ遅い場合は、そのサイトの接続と通信振り分けを確認します。すべてのノードで遅い場合は、ローカルネットワーク、別の端末、時間帯を変えて比較してください。ここでの数値は説明用の例であり、ノードの実測値や速度を保証するものではありません。

10. インポート後もネットにつながらないときの確認項目

「設定の読み込み → ローカル待ち受け → トラフィックの取り込み → ルールによる出力先選択 → リモート接続」の順に確認します。まず最初に失敗している箇所を特定すると、サブスクリプション、ポート、DNSを一度に変更するよりも問題を再現しやすくなります。

設定を確認：「設定」で使用する項目が選択されていることを確認し、ログにYAMLの解析エラーがないか調べます。YAMLのインデントにはスペースを使い、同じ階層のフィールドを揃えてください。Tabは使用しません。
待ち受けを確認：「設定」でポート番号を確認し、プロキシを明示したコマンドで一度アクセスします。古いプロセスやポートの競合がないか切り分けてください。
トラフィックの入口を確認：「接続」を開いてから対象サイトに再アクセスします。新しい接続が表示されない場合は、システムプロキシ、アプリ独自のプロキシ設定、またはTUNによる取り込みを確認してください。
ルールを確認：接続が表示されたら詳細を開き、想定したルールに一致しているか、利用可能なプロキシグループが選択されているか確認します。
エラーの種類を確認：名前解決に失敗する場合はまずDNSを確認します。接続がタイムアウトする場合はノードへの到達性、認証に失敗する場合は認証情報やサブスクリプションの状態を確認してください。
復旧方法を確認：クライアントを一時的に終了する前に、システムプロキシを無効にしてください。クライアント内でシステムプロキシを無効にするだけにとどめ、業務ネットワークで必要な企業設定を誤って削除しないようにします。

問い合わせる際は、OS、クライアントとコアのバージョン、発生時刻、失敗するアプリ、機密情報を伏せたログを提示してください。「ブラウザーは使えるがターミナルは失敗する」「プロキシを明示してもローカルポートに接続できない」のように具体的に伝えると、「ネットにつながらない」だけの場合より原因を特定しやすくなります。プラットフォームごとの権限とインストール手順はインストールガイドを、用語や一般的な設定はFAQを参照してください。