Clash初心者向けQ&A 10選：サブスクリプションの取り込み・プロキシモード・システムプロキシ設定
Clashを初めて使うときにつまずきやすい10項目を解説。サブスクリプションの取り込み、RuleとGlobalの選び方、システムプロキシが効かない場合、設定の更新エラーなどを手順付きで紹介します。
1. Clash、クライアント、mihomoの違いは？
まずは3つの役割を整理しましょう。クライアントは操作画面を提供し、コアはネットワーク接続を処理し、サブスクリプションはノードや設定を提供します。クライアントをインストールしただけでは、利用可能なプロキシノードは手に入りません。サブスクリプションを取り込んだ後も、設定を有効にし、ポリシーを選び、アプリの通信を取り込む必要があります。
Clashのオリジナルコアとmihomoは、別々に継続開発されているプロジェクトです。mihomoはClash Metaから発展したもので、Clashの設定方法を多く引き継ぎながら、対応プロトコルや設定機能を拡張しています。旧コアではmihomo向けの設定を読み込めない場合があります。拡張子がどちらも.yamlだからといって、互換性があるとは限りません。
- クライアントを選ぶ：OSとプロセッサのアーキテクチャに合ったインストーラーを選び、クライアント比較でコアの種類を確認します。
- 設定形式を確認する：Clash形式とClash Meta／mihomo形式のどちらを使うか、サービス提供元に確認します。
- エラー内容を確認する：「未対応のプロキシタイプ」と表示されたら、まずコアの対応状況を確認しましょう。同じサブスクリプションを何度もダウンロードするだけでは解決しません。
クライアントによって設定メニューの名称や配置は異なります。ここでは共通の機能を「サブスクリプション」「システムプロキシ」「接続ログ」と呼び、OS固有の操作は具体的な手順を示します。ポート番号は例として7890を使います。実際に利用する前に、クライアントに表示されている待ち受けポートを確認してください。
2. サブスクリプションのURLはどこに入力する？取り込み完了の確認方法
サブスクリプションURLは、クライアントのリモートサブスクリプション取り込み画面に入力します。ブラウザーのプロキシサーバー欄や、ノードのサーバーアドレス欄ではありません。リモートサブスクリプションからは通常YAML設定が返されます。複数の出力形式が用意されている場合は、利用するクライアントに合った形式のURLをコピーしてください。
- サービス提供元のサブスクリプション画面からURL全体をコピーします。クエリパラメーターを残し、コピー時に空白や改行が混ざらないようにしてください。
- クライアントのサブスクリプション管理画面を開き、リモート取り込み機能でURLを入力してダウンロードします。
- ダウンロードが完了したら、その設定を選択するか有効化します。リストに設定カードが表示されても、コアで使用中とは限りません。
- プロキシまたはポリシーグループの画面で、ノードとグループが表示されることを確認します。続けてログを確認し、設定の読み込みエラーがないか調べてください。
ローカルのYAMLファイルを使う場合は、ローカル設定の取り込み機能を利用します。取り込み後にノードが表示されないときは、ダウンロードした内容がログインページ、エラーメッセージ、空ファイルではないか確認してください。ブラウザーで開けるURLがすべてサブスクリプションとは限りません。
3. Rule、Global、Directはどう使い分ける？
普段はRuleを使うのが一般的です。ルールに従って、各接続を直接接続、プロキシグループなどに振り分けます。Globalはプロキシ経路の一時的な確認に、Directはコアに取り込まれた通信を直接接続させるときに使います。モードが制御するのはコアに取り込まれた通信だけで、すべてのアプリの通信を自動的に取り込むわけではありません。
| モード | 動作 | 用途 |
|---|---|---|
| Rule | rulesを上から順に照合し、最初に一致したルールのポリシーを適用 | ドメインやIPなどの条件に応じて、普段の通信を振り分ける |
| Global | コアに取り込まれた接続をGLOBALポリシーで選択 | ルールがアクセスに影響しているか一時的に切り分ける |
| Direct | コアに取り込まれた接続を接続先へ直接接続 | 直接接続時の結果との比較や、プロキシ経路の切り分け |
Globalに切り替えた後も、GLOBALで何が選択されているか確認してください。別のポリシーグループが選ばれている場合もあれば、DIRECTが選ばれている場合もあります。切り替えただけで特定のリモートノードが必ず使われるわけではありません。確認が済んだらRuleに戻し、本来直接接続する通信が長時間リモート経由にならないようにしましょう。
以下はルール部分のみで、単独では設定として使えません。Proxyは例として使っているポリシーグループ名です。現在の設定に存在するグループ名に置き換えるか、先にグループを定義してください。
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- GEOIP,CN,DIRECT
- MATCH,ProxyMATCHは最後に使うフォールバックルールで、通常は末尾に置きます。先に置くと、その後のルールは照合されません。GEOIPルールには対応する地理データファイルも必要です。YAMLの構文が正しいだけでは不十分です。
4. システムプロキシを有効にしても、アプリがプロキシを使わないのはなぜ？
システムプロキシは、OSのプロキシ設定を参照するアプリに接続先を提供する機能であり、通信を強制的に転送するものではありません。独自のプロキシ設定を使うブラウザーや、環境変数だけを参照するコマンドラインツールもあります。ゲームなど、直接接続するアプリもあります。
待ち受けとシステム設定を順に確認する
- コアが動作していることを確認し、HTTPまたはmixed-portのポート番号を調べます。
mixed-portは、同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。 - 同じ端末上のアプリは、
127.0.0.1と実際のポート番号に接続します。サブスクリプションのドメインをシステムプロキシのサーバー欄に入力しないでください。 - Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」で、アドレスとポートを確認できます。
- macOSでは「システム設定」→「ネットワーク」→使用中のネットワークサービス→「詳細」→「プロキシ」で、HTTPおよびHTTPSプロキシの設定を確認できます。
次のコマンドのようにプロキシを明示すると、プログラムがシステム設定を読み取るかどうかに左右されずに確認できます。Windows PowerShellでは、古い環境で同名のエイリアスが干渉しないようcurl.exeを使います。それ以外のOSでは通常curlを使います。
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.comログに127.0.0.1:7890へ接続できないと表示されたら、まずポート番号とコアのプロセスを確認します。プロキシ接続が確立しているのに接続先へのリクエストが失敗する場合は、ノード、ルール、DNSを調べてください。Webページの応答が返っても、そのリクエストがローカルのプロキシ入口を通ったことしか分からず、最終的にリモートノードが使われた証明にはなりません。
5. システムプロキシとTUNモードは同時に有効にする必要がある？
「より広くカバーする」ために、最初から両方を有効にする必要はありません。システムプロキシは、ブラウザーなどプロキシ設定に従うアプリに適しています。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込むため、システムプロキシに従わないアプリに使えますが、権限やルーティング、DNSなどの確認事項が増えます。
- まずブラウザーで確認：システムプロキシで設定、ノード、ルールが正常に動くことを確認してから、TUNが必要か判断します。
- アプリがプロキシ設定に従わない：クライアントがTUNに対応していることを確認し、必要なサービスをインストールするか、指定された権限を付与します。
- 別のVPNを使用中：まず、ルーティングを制御するほかのソフトを一時停止して個別にテストします。デフォルトルートやDNSの制御が競合するのを防げます。
mihomoでは、tun.enableでTUNの有効・無効を設定し、auto-routeは自動ルーティングに関係し、dns-hijackは対象となるDNS通信を取り込みます。これらの項目を有効にすれば、すべての通信を必ず取り込めるという意味ではありません。プラットフォーム、権限、除外ルート、アプリ独自の暗号化DNSなどが結果に影響します。
6. ノードに遅延時間が表示されているのに、Webページを開けないのはなぜ？
遅延テストでは通常、クライアントがノード経由でテストURLにアクセスする時間を計測します。ICMP pingとは異なり、すべての接続先にアクセスできることを示すものでもありません。テスト先に接続できても、動画、ログイン、特定地域向けのサービスが使えるとは限りません。
通信経路を順番に確認する
- ポリシーの選択を確認：現在どのグループに振り分けられていますか？手動選択グループ、自動遅延測定グループ、フォールバックグループでは、経路の選び方が異なります。
- 新しいリクエストで確認：ノードを切り替えた後に再接続します。既存のTCP接続は以前の経路を使い続けることがあり、ページキャッシュも判断を妨げる場合があります。
- 接続先の違いを確認：一般的なHTTPSページと、実際に問題が起きているページをテストし、ノード全体の障害か、接続先サービス側の制限かを切り分けます。
- ログの発生箇所を確認：ドメインの名前解決失敗、ノードへの接続タイムアウト、接続先とのTLS接続失敗は、それぞれ別の問題です。すべてを「ノードが遅い」とまとめないでください。
特定のWebサイトだけ開けない場合は、そのリクエストに適用されたルールを確認します。RuleモードではDIRECTに振り分けられていたり、別のポリシーグループに入っていたりする可能性があります。ノード一覧で選択中の項目だけでなく、今回のリクエストに対応する接続ログを確認してください。
7. サブスクリプションを更新できないとき、まずDNSを変更すべき？
先にエラーを確認し、原因に応じて対処します。更新に失敗するのは、名前解決、TCP接続、TLSハンドシェイク、HTTP応答、YAML解析の各段階で起こり得ます。DNSを直接示すのは名前解決関連のエラーだけです。ステータスコードや設定の構文エラーは、DNSを変更しても解決しません。
| エラーの内容 | まず確認する項目 |
|---|---|
| HTTP 401／403 | サブスクリプションのトークン、アカウントの状態、提供元によるアクセス制限 |
| HTTP 404 | URLが完全か、サブスクリプションのパスが変更されていないか |
| サブスクリプションのドメインを名前解決できない | 端末の名前解決機能と、更新リクエストが使用するネットワーク経路 |
| 接続タイムアウト | 現在のネットワーク、サブスクリプションサイトへの接続可否、クライアントの更新時プロキシ設定 |
| YAMLの解析に失敗 | 応答内容、インデント、形式の互換性、コアの対応状況 |
サブスクリプションの更新をプロキシ経由にするか選べるクライアントもあれば、独自のダウンロード機能を使うクライアントもあります。Webページが開けても、更新機能が同じ経路を使うとは限りません。ダウンロードの動作はクライアントの説明で確認してください。システムプロキシを有効にすれば、すべてのバックグラウンド更新に適用されると決めつけないようにしましょう。
更新を試す前に、最後に利用できた設定を残しておきます。サブスクリプションに接続できないからといって、唯一使える設定を先に削除しないでください。TLSエラーを解消するために証明書の検証を無効にするのも避けましょう。証明書の時刻に関するエラーが出た場合は、まずシステムの日付、タイムゾーン、ネットワーク環境を確認します。
8. DNS、Fake-IP、「DNSリーク」の仕組みを理解する
DNSはドメイン名をIPアドレスに変換します。mihomoのFake-IPモードでは、ドメインに対応するアドレスを割り当て、内部の対応表を使って後続の接続を処理します。一般的な設定では198.18.0.0/16を使用します。この範囲のアドレスが表示されても、すぐにノード障害や名前解決の誤りと判断する必要はありません。
DNSリークでは、DNSクエリが想定外の経路を通っていないかを確認します。検査ページに表示されるリゾルバーの所在地は、ブラウザーのプロキシノードの所在地と一致するとは限りません。リモートDNSサービス、キャッシュ、サービス提供元のネットワーク出口などが表示に影響します。地域名の表示だけでは、DNSリークの有無や安全性を判断できません。
- まず、システムのDNSリクエストがコアに取り込まれているかを確認します。次に、コアが使用する
nameserverと、ドメインごとのnameserver-policyを確認します。 - ブラウザー独自のセキュアDNS／DoHは別の接続を使うことがあります。システムDNSを変更するだけでなく、実際のルーティングも確認してください。
- 一部のLANサービスやアプリはFake-IPに適さない場合があります。必要に応じて
fake-ip-filterを設定し、すべてのドメインを除外するのは避けてください。
初心者は、まず出所が明確で、使用中のコアに合ったDNS設定を利用し、具体的な問題に応じて変更するのがおすすめです。DNS関連の項目は互いに影響するため、複数の解説記事の設定をむやみに組み合わせると、上流DNSのループが発生することがあります。各項目の説明は応用設定とmihomo DNSドキュメントを参照してください。
9. Webサイトに適用されたルールを確認する方法
クライアントの接続画面で対象のリクエストを見つけ、ドメイン、適用ルール、ポリシーの経路を確認します。画面の名称はクライアントによって異なりますが、大切なのは「1つのリクエスト」と「1つのルーティング結果」を結び付けることです。外部IPの確認ページだけで、すべてのアプリの通信経路を推測することはできません。
- 関係のないダウンロードを一時停止し、バックグラウンド通信の影響を減らします。
- 接続ログを開き、ブラウザーで対象のページにもう一度アクセスします。
- ドメインやプロセスで絞り込み、対象の接続に適用されたルールと最終ポリシーを確認します。
- ルールを変更したら設定を再読み込みし、新しい接続を作って再確認します。
一時的にドメインルールを追加する場合は、先に一致する可能性がある広範なルールより前に配置します。以下の例は、example.comとそのサブドメインを直接接続させる構文の説明です。設定全体ではなく、無関係なドメインには影響しません。
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,ProxyProxyは実際に存在するポリシーグループ名に置き換える必要があります。リモートサブスクリプションを更新すると、直接編集した内容が上書きされることがあります。独自設定を継続して使う場合は、クライアントの上書き、マージ、スクリプト機能を利用し、生成後に反映された設定を確認してください。マージの順序はクライアントによって異なるため、エディターに表示された内容だけで最終的なルールを判断しないでください。
10. クライアント終了後にネットワークへ接続できなくなったときの対処法
よくある原因は、ローカルのプロキシプロセスが停止した後も、システムの接続先がその待ち受けアドレスを指したままになっていることです。この場合、アプリは127.0.0.1:7890への接続を続けても応答を得られません。まずネットワークの接続先設定を元に戻してから原因を調べましょう。すぐにクライアントを再インストールする必要はありません。
影響範囲の小さい方法から順に復旧する
- クライアントを開ける場合は、まずシステムプロキシとTUNを無効にしてから、通常の手順で終了します。
- Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、使わなくなった手動プロキシを無効にします。組織が管理するプロキシ設定は、先に管理者へ確認してください。
- macOSでは、現在使っているネットワークサービスの「詳細」→「プロキシ」を開き、使用できなくなったプロキシ設定を解除します。
- ターミナルだけで接続できない場合は、
HTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数と、各ツール独自のプロキシ設定を確認します。 - TUNの異常終了後も接続できない場合は、クライアントを再起動してTUNを通常の手順で無効にします。必要に応じてシステムを再起動し、ネットワークインターフェースとルートを再構築してください。
LinuxまたはmacOSでは、現在のシェルのプロキシ環境変数を確認できます。次のコマンドは読み取りと抽出のみを行い、システム設定は変更しません。変数にアカウント情報が含まれる場合があるため、出力を共有する前に伏せ字にしてください。
env | grep -iE '^(http|https|all|no)_proxy='最初からネットワーク設定のリセットやファイアウォールルールの全削除を実行しないでください。他のVPN、仮想マシン、社内ネットワークに影響する可能性があります。接続が復旧したら、「設定が有効 → コアが待ち受け中 → アプリの通信を取り込み済み → ルールによる経路選択が正しい」の順に再確認すると、通常は問題の箇所を絞り込めます。