サブスクリプションの完全性を確認
サブスクリプションをコピーするときは、プロトコルの先頭から末尾まで全ての文字を含めてください。ページ上で省略表示された文字だけをコピーしたり、URLの前後に空白、日本語の句読点、説明文を加えたりしないでください。サービス提供元が「汎用サブスクリプション」と「Clashサブスクリプション」を併記している場合は、Clashまたはmihomo対応と明記されたURLを優先します。
決められた順序で、利用可能な設定のインポート、ルールモードの選択、プロキシノードへの接続、通信が想定どおり処理されていることの確認を行います。初回利用に必要な操作だけを扱い、プロトコルとコアの選び方は別のリファレンスページで解説します。
操作を始める前に、使用中のシステムに対応したClashのGUIクライアントと、有効期限内のサブスクリプションURLを用意します。サブスクリプションは通常サービス提供元が発行し、ノード、プロキシグループ、DNS、分流ルールが含まれています。クライアントは設定を読み込んで実行するもので、接続可能なノードを自動で生成するわけではありません。
サブスクリプションをコピーするときは、プロトコルの先頭から末尾まで全ての文字を含めてください。ページ上で省略表示された文字だけをコピーしたり、URLの前後に空白、日本語の句読点、説明文を加えたりしないでください。サービス提供元が「汎用サブスクリプション」と「Clashサブスクリプション」を併記している場合は、Clashまたはmihomo対応と明記されたURLを優先します。
初めてシステムプロキシ、VPN設定、TUN機能を有効にするとき、OSから管理者権限やネットワーク接続の許可を求められることがあります。システムの確認画面が表示されたらアプリ名を確認し、必要な場合だけ許可してください。まずブラウザーの通信だけを確認したい場合は、先にシステムプロキシを使えば十分で、最初から全ての詳細設定を変更する必要はありません。
設定中はサブスクリプションサーバーへのアクセスやノードのテストが必要です。そのため、Clashを有効にしていない状態でもデバイスが正常にインターネットへ接続できることを先に確認してください。ローカルネットワーク自体が切断されていると、サブスクリプションの更新も遅延テストも失敗し、基本的なネットワーク障害をクライアントの不具合と誤認しやすくなります。
設定の取得元
インストール済みのClashクライアントを開き、まず「設定」「サブスクリプション」または「Profiles」画面を探します。この画面には通常、ローカル設定の一覧とサブスクリプションURLの入力欄があります。サービス提供元から受け取った完全なサブスクリプションリンクを貼り付け、先頭と末尾に余分な空白がないことを確認してから、「インポート」「ダウンロード」または「更新」をクリックします。クライアントが名前を求める場合は、「日常用設定」のような識別しやすい短い名前を付けます。名前によってサブスクリプションの内容が変わることはありません。
送信後、すぐにプロキシ画面へ移動しないでください。まずダウンロードと解析が完了するまで待ち、設定一覧に新しい項目が表示されるか確認します。通常は項目の横に最終更新時刻が表示され、一部のクライアントでは自動更新間隔も確認できます。インポートした設定を選択して、現在の設定として有効にします。その後「プロキシ」または「Proxies」画面を開き、プロキシグループとノード一覧が表示されるか確認します。「ノード選択」「自動選択」やサービス提供元独自のプロキシグループが表示されれば、設定の読み込みは完了しています。
貼り付け直後に形式エラーが表示された場合は、まずサブスクリプションの提供元に戻ってURLをコピーし直し、リンクの文字を手動で編集しないでください。ブラウザーでサブスクリプションURLを直接開くと、YAMLファイルがダウンロードされる場合と、エンコードされたテキストが表示される場合があります。どちらも正常な形式になり得ます。重要なのはクライアントが認識できるかどうかです。ブラウザーでログインページ、期限切れの通知、空のレスポンスが表示された場合は、クライアントで何度も更新するのではなく、先にサービス提供元のページでサブスクリプションを更新してください。
一部のクライアントには「URLからインポート」と「ファイルからインポート」の両方があります。通常のサブスクリプションにはURLからのインポートを使います。以後の更新ではクライアントが同じURLへ再アクセスします。ファイルからのインポートは、端末に保存済みのYAML設定に適していますが、リモート側の変更は自動反映されません。初回利用時は、ノードやルールの変更後にそのまま更新できるURL方式をおすすめします。
通信の経路
設定が読み込まれたことを確認したら、「設定」「一般」またはクライアントのホーム画面を開き、「出力モード」「プロキシモード」または「Mode」を探します。一般的な選択肢は、ルール、グローバル、直接接続です。初回接続では「ルール」をおすすめします。ルールモードは設定内のルールを上から順に確認し、ドメイン、IPアドレス、アプリ、地域情報に基づいてプロキシ経由か直接接続かを判断します。プロキシが必要なリクエストをプロキシグループへ送りながら、直接接続に適した通信は元の経路を維持できます。
グローバルモードは、ルールに一致する大半の通信を現在のプロキシ設定へ一括して送るモードです。分流ルールが原因かどうかを一時的に切り分ける用途には適していますが、設定内容を理解しないまま長期的な既定値として使うのはおすすめしません。直接接続モードはプロキシを経由せず、プロキシを一時停止したり比較テストを行ったりするときに使います。直接接続に切り替えるとアクセスが復旧し、ルールモードでは失敗する場合は、クライアントを再インストールするのではなく、ルールの一致、プロキシグループの選択、DNS設定を確認してください。
ルールモードを選択したら、まずFake-IP、DNS上書き、ルールプロバイダー、スクリプトなどの上級項目を変更しないでください。多くのサブスクリプションにはそのまま使える標準設定が含まれており、複数の項目を同時に変更すると原因の特定が難しくなります。初回操作の目的は、確認可能な接続を1つ確立することです。接続が安定してから、アプリとの互換性に応じてDNSモード、TUNルーティング、カスタムルールを検討してください。
モードの選択は通信の照合方法を決めるだけで、ノードへの接続が完了したことを意味しません。モードを選んだらプロキシ画面に移動し、主要なプロキシグループに実際に利用可能なノードまたは自動選択グループを指定します。プロキシグループ名がサービス提供元によって変更されている場合は、一覧の上部にあり、現在選択可能な主要グループを優先して探してください。ルールが最終的にどのグループを参照するかはサブスクリプションの内容によって決まり、グループ名が例と完全に一致するとは限りません。
設定内のルールに基づいて、プロキシ経由か直接接続かを決定します。普段の利用は通常ここから始めるとよく、後から特定のリクエストがどのルールに一致したかも確認しやすくなります。
主要な通信を選択したプロキシ設定へ一括して送ります。ルールモードとの比較に使えますが、既存の細かな分流ロジックはスキップされます。
通信を現在のネットワーク出口から直接送ります。元のネットワーク経路へ戻したり、問題がプロキシ経路に関係しているかを確認したりするときに適しています。
Fake-IP、ルールセット、GEOIP、MATCHなどの名称に慣れていない場合は、用語クイックリファレンスを参照してください。各プロトコルの接続特性、リソース使用量、コアとの互換性については、プロトコルとコアのリファレンスにまとめています。初回接続を完了するために、これらを先に理解する必要はありません。
ノードとシステム設定
「プロキシ」「ポリシー」または「Proxies」画面を開き、主要なプロキシグループを表示します。ノードを手動で選ぶ場合は、まずクライアントの遅延テスト機能を使うとよいでしょう。テスト結果は、現在の端末からテスト先までノードを経由した際の応答状況を示すもので、利用可能性と相対的な遅延の目安に過ぎず、実際のダウンロード速度を保証するものではありません。テストが完了し、結果が比較的安定したノードを選べば十分で、一覧の最小値を何度も追い求める必要はありません。
設定に url-test 自動選択グループがある場合は、そのグループを直接選択します。コアが設定されたテスト先と間隔に基づいて、より良好なノードを選びます。fallback グループがある場合は、通常、設定順に利用可能性を確認し、前のノードが使えないときに切り替えます。初回利用ではプロキシグループを書き換える必要はなく、現在の主要なプロキシ設定がノードまたは自動選択グループを最終的に参照していることを確認してください。
ノードを選択したら、一般設定に戻り、「システムプロキシ」「Set as system proxy」または同様の意味のスイッチを有効にします。この操作により、システムプロキシに対応したブラウザーやアプリがClashのローカル待受ポートを使用するようになります。クライアントはバックグラウンドで起動したままにし、すぐにプロセスを終了しないでください。システムプロキシはアプリにリクエストをローカルポートへ送るよう伝えるだけで、実際の転送は起動中のClashコアが行います。
WindowsとmacOSでは、多くのブラウザーがシステムプロキシ設定を読み取るため、このスイッチを有効にすれば次の確認へ進めます。一部のアプリは独自のプロキシ設定を持つか、システムプロキシを全く参照しないため、その通信はクライアントの接続パネルに表示されないことがあります。AndroidとiOSのクライアントは通常、システムVPNインターフェースで通信を取り込み、初回有効化時にシステムの許可画面が表示されます。アプリ名と接続要求を確認して許可してください。Linuxのデスクトップ環境がシステムプロキシを自動的に読み取るかどうかは、ディストリビューション、デスクトップコンポーネント、アプリの設定によって異なります。必要に応じてアプリ内にローカルプロキシアドレスを入力してください。
TUNモードは、システムプロキシに従わない通信をより多く取り込むための機能ですが、仮想ネットワークインターフェース、ルーティング、システム権限が関係します。初回接続では、まずシステムプロキシでブラウザーの動作を確認してください。ブラウザーは利用できるのに特定のアプリだけプロキシを経由しない場合に限り、TUNの有効化を検討します。これにより、ノード、サブスクリプション、基本的なプロキシ経路が正常であることを先に確認でき、権限、ルーティング、DNSの問題を同時に切り分けずに済みます。
結果の確認
Clashクライアントを起動したまま、システムプロキシまたはシステムVPNが有効になっていることを確認します。新しいブラウザーウィンドウを開き、普段使っているIP確認ページへアクセスして、表示された外部IPアドレスと地域を記録します。その後、システムプロキシを一時的に無効にして同じページを再読み込みし、結果を比較します。有効時と無効時で出口アドレスが異なり、有効時にWebページが正常に読み込まれれば、ブラウザーの通信はClashを経由しています。
IP確認ページだけでは、ルールが想定どおり動作しているか判断できません。クライアントの「接続」「Connections」または「ログ」画面も開いてください。その画面を表示したままブラウザーで新しいWebサイトを開きます。通常、接続一覧に新しいドメイン、宛先アドレス、適用ルール、使用中のプロキシ設定が表示されます。検索に対応している場合は、アクセスしたドメインを入力し、最終的にプロキシ、直接接続、その他の設定のどれが使われたか確認できます。
ルールモードでは、全てのリクエストがプロキシとして表示されるわけではありません。ローカルサービス、LANアドレス、特定サイトへの通信が直接接続になる設定もあり、これは正常です。確認すべき点は、プロキシが必要な宛先が想定したプロキシ設定に入り、クライアントに該当する接続が記録され、ページが安定して読み込めることです。「全ての通信が同じノードを通る」ことをルールモード成功の基準にしないでください。
外部アドレスが変わらない一方で接続パネルにブラウザーのリクエストが表示される場合は、まずそのリクエストに適用されたルールを確認します。DIRECT に一致している場合、設定によって直接接続が選ばれています。比較のため一時的にグローバルモードへ切り替えてください。グローバルモードでアドレスが変われば、ノードとローカルプロキシ経路は正常で、以後はサブスクリプションのルールを確認すべきです。比較後は忘れずにルールモードへ戻してください。
外部アドレスが変わらず、接続パネルにも新しいリクエストが全く表示されない場合は、通常ブラウザーがClashのローカルプロキシを使用していません。システムプロキシのスイッチを再確認し、ブラウザーを終了して再起動した後、ブラウザー拡張機能やアプリ内プロキシがシステム設定を上書きしていないか確認してください。企業ネットワーク、別のVPNソフト、セキュリティツールがプロキシ設定を書き換える場合もあります。切り分け時は、ネットワークを制御するツールを一度に1つだけ有効にしてください。
ブラウザーのリクエストが異なるネットワーク出口から送信されています。続けて、適用された具体的なルールを確認できます。
リクエストがClashコアに到達しています。プロキシ設定とルールの項目から最終的な経路を確認できます。
システムプロキシのスイッチによってブラウザーの経路が正常に変わり、基本設定が完了しています。
基本トラブルシューティング
問題が起きたときに、クライアント、サブスクリプション、DNS、システムネットワークを同時に変更しないでください。確認順序を固定すると、原因を特定しやすくなります。まずプロキシを無効にしてローカルネットワークが正常か確認し、次にサブスクリプションを更新して設定が読み取れるか確認します。その後、複数のノードをテストし、最後にシステムプロキシが実際に有効か確認してください。前の段階を通過していない場合、後の確認結果はほとんど参考になりません。
| 症状 | 優先して確認する項目 | 次に行うこと |
|---|---|---|
| サブスクリプションをインポートできない | リンクが完全か、期限切れでないか、Clashに対応した内容が返されているか | サブスクリプションをコピーし直し、サービス提供元の状態を確認 |
| ノードテストが全てタイムアウトする | 基本ネットワーク、サブスクリプションの更新時刻、ファイアウォール、システム時刻 | 別のネットワークでテストし、プロトコルが現在のクライアントに対応していることを確認 |
| ブラウザーの接続記録がない | システムプロキシ、ブラウザー独自のプロキシ、他のネットワークツール | ブラウザーを再起動し、プロキシの入口を1つだけ残す |
| 記録はあるがWebページを開けない | 適用ルール、現在のプロキシ設定、ノードの利用可能性、DNS | グローバルモードで一時的に比較し、その後ルールモードへ戻す |
| ブラウザーは使えるがアプリでは有効にならない | アプリがシステムプロキシを読み取るか | アプリのプロキシ設定を確認し、必要に応じてTUNモードを検討 |
切り分け中はクライアントのログを残して構いませんが、警告を一行ずつ全て障害と判断する必要はありません。ネットワークの切り替え、接続の終了、ルールの更新でも通常の状態記録が生成されます。注目すべきなのは、失敗した時刻と一致するエラー、繰り返し発生する接続タイムアウト、DNS解決失敗、設定解析エラーです。サブスクリプション障害、ノードのタイムアウト、システムプロキシの問題については、よくある質問も確認してください。