Clash初心者が最初の1週間でよく抱く10の疑問：サブスクリプションのインポートからシステムプロキシまで解説

1. クライアントの選び方：Clash、Clash Meta、mihomoの関係

質問1：どのClashクライアントをダウンロードすべきか

結論から言えば、まずはOSに合った、現在もメンテナンスされているGUIクライアントを選び、利用するサブスクリプションのプロトコルをカーネルがサポートしているか確認します。WindowsとmacOSの初心者には、設定、システムプロキシ、TUNモードを管理できるデスクトップクライアントがおすすめです。Androidでは、設定のインポートとアプリごとの分流に対応したクライアントを選びます。初回から複数のクライアントを入れる必要はありません。同じ端末で2つのプロキシプログラムを動かすと、かえってポート競合が起きやすくなります。

「Clash」は元のClashカーネルを指す場合もあれば、Clash形式の設定に対応したクライアント全般を指す場合もあります。元のプロジェクトはすでに更新を停止しており、現在よく使われる新しいクライアントの多くはmihomoカーネルを採用しています。mihomoは以前Clash Metaという名称で呼ばれており、設定構造はClash YAMLを引き継ぎながら、プロトコル、ルールセット、DNS、透過プロキシの機能を拡張しています。「Metaカーネル」や「mihomoカーネル」と表示されている場合は、同じ技術系統における時期の異なる名称と考えて差し支えありません。

基本的なWebプロキシだけ使う：GUIクライアント、ルールモード、システムプロキシで大半の操作に対応できます。
ゲームランチャー、コマンドライン、ストアアプリを使う：TUNモードに対応したクライアントを選びます。
既存のYAMLをインポートする：サブスクリプションURLだけでなく、ローカル設定ファイルにも対応しているか確認します。
デバイスのアーキテクチャが異なる：Windowsではx64とarm64が一般的です。Apple Silicon搭載Macはarm64、Intel Macはx64を選びます。

2. サブスクリプションURLの入手先と正しいインポート方法

質問2：クライアントのインストール後もノードが表示されないのはなぜか

Clashクライアント自体は通常、設定の読み込み、ルールの実行、接続の転送を担うもので、利用可能なノードを自動生成するものではありません。ノード情報は、ユーザー自身のサービス設定、組織内の設定、またはネットワークサービス提供元が発行するサブスクリプションURLから取得します。サブスクリプションURLは通常、HTTPSで始まる専用URLで、アクセス用トークンが含まれる場合があります。アカウント情報と同じように扱い、スクリーンショット、フォーラム、公開コードリポジトリなどに載せないでください。

一般的なインポート手順は「設定」→「新しい設定」→「URLからインポート」です。クライアントによっては「Profiles」→「New Profile」→「URL」と表示されます。サブスクリプションURLを貼り付けたら、まずダウンロードを実行し、新しい設定を現在の設定に指定します。設定が一覧に表示されただけでは有効になったとは限りません。設定の横に「現在使用中」「選択済み」などの表示や選択マークがあることも確認してください。

完全なサブスクリプションURLをコピーし、先頭がhttps://になっているか確認します。
クライアントの「設定」または「Profiles」ページを開きます。
「URLからインポート」を選び、URLを貼り付けてダウンロードします。
ダウンロードした設定を選択し、プロキシグループとノード一覧が表示されるまで待ちます。
「プロキシ」ページを開き、対象のポリシーグループでノードを選択します。
ホームに戻り、「システムプロキシ」を有効にしてからブラウザーで接続をテストします。

質問3：サブスクリプションのインポートや更新に失敗した場合の対処法

まず、「URLをダウンロードできない」場合と「ダウンロード後に解析できない」場合を切り分けます。前者では、タイムアウト、HTTP 401、403、404などが表示されることが一般的です。後者では、YAML解析エラー、フィールド型エラー、設定の検証失敗などが表示されます。401と403は、トークンの期限切れ、アカウント状態の変化、サーバー側の制限を意味することが多く、404はURLが変更された可能性があります。解析エラーの場合は、サブスクリプションがClashまたはmihomoで認識できる設定形式を出力しているか確認してください。

画面に表示されるメッセージ	よくある原因	対処の順番
Request timeout	現在のネットワークからサブスクリプションサーバーに接続できない	別のネットワークで試し、システム時刻とDNSを確認する
401 / 403	サブスクリプションのトークンまたはアカウント状態に異常がある	サブスクリプションURLを再取得し、トークンを手動で変更しない
YAML parse error	返された内容が有効なYAMLではない	サブスクリプションの出力形式を確認し、エラー行を確認する
設定は存在するがノードが空になっている	サブスクリプションの内容が空、または設定形式が一致していない	元のレスポンスとクライアントカーネルの互換性を確認する

初回インポート時は、自動更新、設定の上書き、スクリプト処理を同時に有効にしないでください。まず元の設定を読み込めることを確認し、その後に機能を1つずつ追加します。ブラウザーでサブスクリプションURLを直接開いた際にログインページやHTMLのエラーページが表示される場合、クライアントもそれをYAMLとして解析できません。URLが有効なのにクライアントでエラーが出る場合は、「設定」→「ログ」でログレベルを一時的にdebugへ変更し、1回再現して具体的にどの段階で失敗したか確認します。調査が終わったらinfoに戻してください。

3. ルール、グローバル、ダイレクトのどれを選ぶべきか

質問4：Rule、Global、Directの違いは何か

Rule ルールモードは、設定内のルールに従ってドメイン、IP、プロセス、ルールセットを順番に照合し、接続を指定されたポリシーグループへ渡します。日常利用に適しており、多くのサブスクリプション設定でデフォルトになっています。中国本土のサイトは直接接続し、プロキシが必要な宛先はプロキシポリシーへ送り、LANアドレスは通常ダイレクト接続にします。

Global グローバルモードは、大半の接続をGLOBALという名前のポリシーグループへ渡します。特定のノードが接続を確立できるか一時的に確認する場合に便利です。ただし、すべての通信が必ずローカルネットワークの外へ出るわけではなく、LAN、予約済みアドレス、クライアント自身の接続はカーネルのルールに従って処理される場合があります。長期間グローバルモードを使うと、サブスクリプションが設計した分流ロジックを迂回してしまいます。

Direct ダイレクトモードは、プロキシノードを経由せず接続先へ直接アクセスします。障害の原因がプロキシ経路にあるか確認したり、転送を一時的に停止したりする場合に適しています。Directはクライアントの終了を意味しません。システムプロキシがローカルポートを指している場合、通信はいったんクライアントに届き、その後クライアントが直接接続します。

通常は「モード」→「ルール」を選択します。
「プロキシ」→対象のポリシーグループを開き、遅延テストで利用できるノードを選びます。
特定のサイトに問題がある場合は、一時的にグローバルモードへ切り替えて比較します。
グローバルでは使えるのにルールモードで失敗する場合は、ルールの判定結果とポリシーグループの選択を重点的に確認します。
グローバルでも失敗する場合は、ノード、ネットワーク、ポート、DNSを重点的に確認します。

接続がどのルールに一致したかを確認する方法

「接続」または「Connections」ページを開き、対象サイトに再度アクセスしてからドメインで絞り込みます。通常、記録には対象ホスト、対象ポート、アップロード・ダウンロード量、適用されたルール、実際のポリシーチェーンが表示されます。たとえばDOMAIN-SUFFIXがProxyに一致し、現在のProxyが特定のノードを選択していれば、分流経路を確認できます。MATCH → DIRECTと表示される場合は、最後のフォールバックルールによってダイレクト接続に渡されたことを示します。

4. システムプロキシを有効にしてもブラウザーが接続できない理由

質問5：システムプロキシのスイッチは何をしているのか

システムプロキシのスイッチは通常、OSのHTTPおよびHTTPSプロキシアドレスを127.0.0.1とローカルポートに設定するだけです。たとえば設定がmixed-port: 7890の場合、システムプロキシは127.0.0.1:7890を指します。この設定に従うかどうかはアプリ自身が決めます。主要なブラウザーは通常システムプロキシを読み取りますが、一部のゲーム、ターミナルプログラム、ストアアプリ、独自のネットワークスタックを持つソフトウェアは無視する場合があります。

次の順番で確認し、ノードを何度も切り替えることで本当の原因を隠さないようにします。

クライアントのホームで、単に画面が起動しているだけでなく、カーネルが実行中であることを確認します。
「設定」→「ポート設定」を開き、Mixed Portの実際の値を確認します。
システムプロキシのアドレスがそのポートと一致しているか確認します。例：127.0.0.1:7890。
「接続」ページを開いたままブラウザーを更新し、新しい接続が表示されるか確認します。
接続はあるのにアクセスできない場合は、適用されたルール、ノード、DNSを確認します。
接続がまったくない場合は、ブラウザーのプロキシ拡張機能、システムプロキシの上書き、アプリ自身の設定を確認します。

ブラウザーにプロキシ拡張機能を同時に入れている場合、拡張機能がシステムプロキシを上書きすることがあります。調査中は拡張機能を「システムプロキシを使用」に切り替えるか、一時的に無効にしてください。コマンドラインツールが環境変数を読み取る場合もあります。Windows PowerShellではHTTP_PROXYとHTTPS_PROXYを確認し、macOSまたはLinuxのターミナルではenv | grep -i proxyを実行できます。古い変数が別のポートを指したままだと、ブラウザーは正常なのにターミナルだけ失敗する現象が起きます。

質問6：TUNモードを有効にする必要があるのはいつか

TUNモードは仮想ネットワークインターフェースを通じて、より多くのシステム通信を受け取ります。システムプロキシを無視するアプリ、UDP通信、一部のゲームランチャー、通信をまとめて制御したいコマンドラインプログラムに適しています。これは「速度を上げる」スイッチではありません。ブラウザーと一般的なデスクトップアプリだけを使うなら、通常はシステムプロキシのほうが管理しやすくなります。対象アプリがシステムプロキシを読み取らないと確認できた場合に、TUNを有効にするのが適切です。

一般的な手順は「設定」→「ネットワーク設定」→「TUNモード」です。初回の有効化では管理者権限を求められ、仮想ネットワークコンポーネントのインストールが必要になる場合があります。有効化後は、クライアントでTUNが正常に動作していることを確認し、システム内に別のVPN、仮想NICツール、古いクライアントがあり、ルーティングを奪い合っていないか確認してください。Windowsで有効化に失敗する場合は、まずクライアントを完全に終了し、管理者権限で一度起動してサービスのインストールを完了します。その後も管理者権限が必要かどうかは、クライアントのサービス実装によって異なります。

5. ノードのタイムアウト、ポート競合、DNSの調べ方

質問7：遅延テストでTimeoutが表示されたら、ノードは必ず使えないのか

必ずしもそうとは限りません。遅延テストは通常、設定で指定されたテストURLへリクエストを送り、固定のタイムアウト時間を設定します。テスト先に到達できない、ノードがその宛先へのアクセスを許可していない、DNS解決に失敗した、ローカルネットワークでパケットロスがある、といった原因でもTimeoutになります。少なくとも、設定を更新する、異なる地域のノードを2つ切り替えて試す、HTTPSに対応していることが明確なサイトへブラウザーでアクセスする、という3つの方法で確認してください。

遅延の数値はダウンロード速度でもありません。1回のテストで80 msになった場合、それはその時点でテストリクエストが約80ミリ秒で完了したことを示すだけで、継続的な通信速度までは判断できません。3回連続で85 ms、92 ms、410 msとなるなら、経路の揺らぎが大きいと考えられます。動画や通常のWeb閲覧では、400 msへ頻繁に跳ねる低遅延ノードより、140 msで安定したノードのほうが使いやすい場合があります。

すべてのノードが同時にタイムアウトする：サブスクリプションの状態、ローカルネットワーク、DNS、クライアントログを確認します。
1つのノードだけタイムアウトする：同じグループの別ノードに切り替え、しばらくしてから再テストします。
遅延テストは正常なのにWebサイトを開けない：適用されたルール、ブラウザーのプロキシ、対象サイトの制限を確認します。
TCPのページは正常なのにゲームが使えない：クライアントがUDPを制御しているか、TUN設定が有効か確認します。

質問8：「ポート7890は使用中」と表示された場合の対処法

これは、別のプロセスが同じポートをすでにリッスンしていることを示します。よくある原因は、古いクライアントがバックグラウンドで動作している、同じクライアントを2つ起動している、別のネットワークツールも7890を使用している、といったものです。すぐにポートを繰り返し変更するのではなく、まず占有しているプロセスを特定してください。Windowsではコマンドプロンプトで次のコマンドを実行します。

netstat -ano | findstr :7890
tasklist /fi "PID eq プロセス番号"

macOSとLinuxでは次のコマンドを使用できます。

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iUDP:7890

古いインスタンスだと確認できたら、そのプロセスを正常に終了してから現在のクライアントを再起動します。ポートが本当に別の必要なプログラムに使われている場合は、「設定」→「ポート設定」でMixed Portを7891などの未使用ポートに変更します。変更後はシステムプロキシも更新し、新しいポートを指すようにしてください。YAMLを手動で管理する場合、対応する設定は次のように記述できます。

mixed-port: 7891
allow-lan: false
mode: rule
log-level: info

allow-lan: falseは、LAN上のデバイスにプロキシ入口を提供しないことを意味します。スマートフォンをPC経由でプロキシ接続する必要がある場合は、LANアクセスを有効にしたうえで、OSのファイアウォールと信頼できるネットワーク範囲も設定してください。リッスンポートだけを変更するのは不十分です。

質問9：Webサイトは開くのに、名前解決が遅い、またはDNSエラーが出る場合の対処法

ClashまたはmihomoのDNSモジュールは、ルール照合と接続確立の間でドメイン解決を調整します。代表的な拡張モードにはfake-ipとredir-hostがあります。fake-ipはまず予約アドレスのマッピングを返し、カーネルが元のドメインを復元します。ルール照合の効率が高く、TUNによる制御にも適しています。一部のLAN機器、業務用ソフトウェア、実IPを必要とするプログラムではfake-ip-filterへの追加が必要になる場合があります。

原因を確認できていない段階で、大量のDNSサーバーを重ねて設定しないでください。まずは安定した2つの名前解決経路を使い、ログにタイムアウトが出るか確認します。基本構成は次のとおりですが、実際の設定は現在のクライアントとサブスクリプションの要件に従ってください。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"

設定を変更したら、「設定」→「再読み込み」を実行し、アプリ自身のキャッシュを消去してから再テストします。Windowsではipconfig /flushdnsを実行してシステムDNSキャッシュを消去できます。macOSでは対象アプリを終了して再起動してください。クライアントログにDNS timeoutが出続ける場合は、fallbackの数を増やす前に、現在のネットワークから入力したDNSサーバーへ接続できるかを確認します。

6. 設定更新、自動選択、障害からの復旧

質問10：最初の1週間が終わるまでに残しておくべき設定

まずは最小限の再現可能な状態を維持します。つまり、有効なサブスクリプション、現在の設定1つ、ルールモード、利用できることを確認したノード1つ、正しいローカルポート、そしてシステムプロキシまたはTUNのどちらか一方を明確に選んだ状態です。複数の自動選択スクリプト、リモートルールの上書き、実験的なDNSオプションを同時に有効にしないでください。基本経路が安定してから、自動更新、遅延テスト、ルールセットの機能を追加します。

サブスクリプションの自動更新間隔は短くしすぎないでください。ノード情報は通常、毎分更新する必要はなく、6時間、12時間、24時間程度に設定すると変化を観察しやすくなります。クライアントがスリープから復帰してネットワークに再接続した際は、設定を一度手動で更新してもよいでしょう。更新に失敗しても、現在使える設定をすぐ削除しないでください。古い設定で接続を維持できる場合があります。まずログのHTTPステータスコードを確認し、その後にサブスクリプションURLを再取得するか判断します。

記録しておきたい6項目

クライアント名、バージョン、システムアーキテクチャ。例：Windows 11 x64。
カーネル名とバージョン。例：mihomo 1.19.x。
現在のモード：Rule、Global、Direct。
通信の入口：システムプロキシ、TUN、またはアプリ内の手動プロキシ。
Mixed Portの実際の値。例：7890または7891。
障害が発生した時刻、ログのエラー行、適用されたポリシーグループ。

この6項目があれば、「接続できない」だけの場合より問題を特定しやすくなります。たとえば、Windows 11 x64、mihomo 1.19.x、ルールモード、システムプロキシ、mixed-port 7890、ブラウザーの接続がProxyに一致したもののログにconnection timeoutが出ている、と記録します。これだけで原因をノード経路に絞り込め、クライアントを何度も再インストールする必要がなくなります。

5分で行う固定のトラブルシューティング手順

カーネルを確認：実行状態であり、ログに設定の読み込み失敗がないことを確認します。
入口を確認：システムプロキシのポート、またはTUNの制御状態を確認します。
接続を確認：対象アプリを更新し、Connectionsに記録が表示されるか確認します。
ルールを確認：記録に表示されたルール、ポリシーグループ、最終ノードを確認します。
出口を確認：別のノードに切り替え、グローバルモードとルールモードの結果を比較します。

DirectではアクセスできるのにRuleで失敗し、Connectionsで誤ったポリシーグループにリクエストが入っている場合は、ルールまたはポリシーグループの選択を修正します。Directとプロキシの両方で失敗するなら、ローカルネットワークとDNSに戻って確認します。ブラウザーには接続記録があるのに対象アプリにはまったく記録がない場合は、そのアプリがシステムプロキシを読み取るか確認し、TUNを使うか判断します。入口、ルール、出口の順に層を分けて調べるほうが、設定を削除して再インストールするより有効な手がかりを残せます。