デスクトップ版:システムプロキシ
クライアントのメインスイッチとシステムプロキシスイッチを有効にし、現在の設定が先ほど追加したものか確認します。OSのプロキシ設定に別のアドレスが残っている場合は、他のネットワークツールを終了してからClashに再設定させてください。
10 MIN · BASIC SETUP
サブスクリプションの追加、プロキシモードの選択、接続、結果確認を順番に進めます。初回利用に必要な操作だけに絞っているため、クライアントをインストール済みで、サブスクリプションまたはYAML設定を読み込むユーザーに適しています。
準備
操作を始める前に、端末へ利用可能なClash GUIクライアントがインストールされていることを確認し、サブスクリプションURLまたはローカルのYAMLファイルを用意します。サブスクリプションURLは通常、ネットワークサービスの提供元が発行する完全なURLです。YAMLファイルはそのまま読み込める設定ファイルです。どちらか一方を選べばよく、同時に追加する必要はありません。クライアントをまだインストールしていない場合は、インストールパッケージからOSに合うクライアントを選んでください。
クライアントを開いたら、まずメイン画面が正常に表示されるか確認します。デスクトップ版では通常、サイドバーに「設定」「サブスクリプション」または「Profiles」があります。Android版ではホーム画面や右上のメニューに設定入口があることが多く、macOSのメニューバークライアントではステータスバーのアイコンから機能を開く場合があります。クライアントによって名称や位置は異なりますが、操作の流れは同じです。まず設定をクライアントに保存し、現在の設定として適用してから、モードを選択して接続します。
端末で別のプロキシ、VPN、ネットワークフィルターを実行している場合は、今回の設定を始める前に終了することをおすすめします。複数のアプリがシステムプロキシ、VPNルート、DNSを同時に変更すると、クライアントでは接続済みでも通信が現在の設定を通らないことがあります。初回設定ではネットワークを制御するツールを1つだけ実行し、基本接続を確認してから他のソフトを1つずつ戻すと、競合の原因を特定しやすくなります。
設定入口
クライアントの「サブスクリプション」「設定」または「Profiles」ページを開き、新しいサブスクリプションを追加します。完全なURLを入力欄に貼り付け、先頭、パラメータ、末尾の文字までコピーされていることを確認してください。URLが長くても、重複しているように見える記号を手動で削除したり、チャットアプリで省略表示された部分を完全なURLとして扱ったりしないでください。サブスクリプションに「日常用」など識別しやすいローカル名を付け、追加、ダウンロード、更新のいずれかを実行します。
クライアントはサブスクリプションの内容を取得し、ローカル設定へ変換します。成功すると、設定一覧に名前、更新日時、選択可能な状態などが表示されます。次にその設定をクリックするか、「現在の設定にする」「有効化」などの操作を行い、クライアントに実際に読み込ませます。サブスクリプションを一覧に保存しただけでは有効になりません。メイン画面に古い設定名が表示されている場合、後続のモードやプロキシグループも古い内容を使い続けます。
設定を選択したら、プロキシまたはプロキシグループのページを開き、プロキシグループとノードが表示されていることを確認します。一般的なグループ名には「プロキシ」「自動選択」「フォールバック」「直連」などがありますが、実際の名称は設定の提供元によって異なります。これらが表示されていれば、少なくともサブスクリプションはクライアントで解析されています。一覧が完全に空、解析エラーだけが表示される、更新直後に古い設定へ戻るといった場合は、システムプロキシを有効にせず、まず追加の問題を解決してください。
ローカルのYAMLファイルを使う場合は、サブスクリプション入力欄ではなく「ファイルを読み込む」を選択します。読み込み後は同じようにファイルを現在の設定として適用し、プロキシグループが表示されるか確認してください。初回接続前にYAMLを広範囲に変更しないでください。まず元の設定で接続を1回試すと、「元の設定が使えない」のか「手動変更でエラーが生じた」のかを切り分けられます。proxies、proxy-groups、rules、dnsなどの項目を確認する場合は、設定リファレンスで順に調べてください。
現在の設定名が表示され、プロキシグループとノード一覧を開けるなら、プロキシモードの選択へ進めます。
通信経路
クライアントのホーム画面または「モード」設定に戻ると、通常はルール、グローバル、直連の3つのモードが表示されます。初回利用では「ルール」モードがおすすめです。ルールモードでは、設定ファイルのルール一覧を上から順に照合し、通信を直連、プロキシ、ブロックの各ポリシーへ振り分けます。ローカルネットワークや普段使う直連サービスの経路を保ちながら、プロキシが必要なリクエストを指定したプロキシグループへ送れるため、日常利用で最も一般的な選択です。
「グローバル」モードでは、制御可能な通信の大部分を1つのプロキシポリシーへ送ります。ノード自体が接続できるかを短時間で確認する用途には向いていますが、すべての障害をルールの問題と判断するのには適しません。「直連」モードでは通信がプロキシを経由せず、一時的に元のネットワークへ戻すときに使います。切り分けではルールとグローバルを比較してください。グローバルではアクセスできるのにルールではできない場合、ルールの順序、対象ポリシー、DNSの照合に原因がある可能性があります。両方で失敗する場合は、ノード、システムプロキシ、VPN権限、ネットワーク環境を確認します。
| モード | 通信の処理方法 | このチュートリアルでの用途 |
|---|---|---|
| ルール | YAMLのルール順に従い、直連、プロキシ、ブロックのポリシーを選択 | 日常利用での第一選択 |
| グローバル | 大部分の通信を指定したプロキシポリシーへ統一して送信 | ノードと接続経路の一時的なテスト |
| 直連 | リクエストをプロキシノード経由にしない | 元のネットワークへ戻して比較 |
ルールモードを選択したら、「プロキシ」「Proxies」またはプロキシグループのページを開きます。設定には自動選択グループ、手動選択グループ、複数階層の参照グループが同時に存在する場合があります。まず主要なプロキシ出口を担うグループを見つけ、状態が正常なノードまたは自動選択を指定します。グループ内に別のプロキシグループがある場合は、さらに下の階層へ進んで最終出口を確認してください。外側のグループだけを選び、内側のグループにノードを指定していないと、接続が古い選択のままになることがあります。
クライアントに表示される遅延テストは、特定の検査リクエストに応答があったかを示すだけで、すべてのWebサイトへアクセスできることを単独で証明するものではありません。遅延結果が表示されても実際のリクエストに失敗する場合は、プロトコルのハンドシェイク、接続先の制限、DNS、システム時刻などが原因の可能性があります。初回設定ではクライアントのテストを完了できるノードを1つ選び、4番目の手順で実際のアクセスと接続ログを確認してください。速度テストを繰り返して接続確認を省略しないでください。
プロキシグループに選択肢がない場合は、前の手順に戻り、設定が正常に読み込まれているか確認します。ノードは存在するもののすべてエラーになる場合は、サブスクリプションを1回更新し、端末の日付、時刻、タイムゾーンが正しいことを確認してください。複雑なプロキシグループのネスト、ルールプロバイダー、オーバーライドのマージは今回の基本手順には影響しません。分割ルーティングをカスタマイズするときに、設定リファレンスを参照してください。
モードがルールに設定され、主要なプロキシグループでノードまたは自動選択が指定されていれば、システム接続を確立できます。
システムによる通信制御
デスクトップ版では「システムプロキシ」「System Proxy」などのスイッチを探して有効にします。クライアントがシステムプロキシのアドレスをOS設定へ書き込み、ブラウザやシステムプロキシに従うアプリがClashのローカル待受ポートへリクエストを送るようになります。有効化後はクライアントをバックグラウンドで実行したままにしてください。クライアントを終了するとローカルポートの待受が停止しますが、OSにプロキシ設定だけが残り、Webページを開けなくなることがあります。
AndroidとiOSのクライアントは通常、システムVPNインターフェースで通信を制御します。接続ボタンを押すとVPN権限の確認が表示されるため、許可した後、ステータスバーにVPNマークが出るか確認し、クライアントへ戻って接続状態を確認します。初回の許可を取り消した場合、クライアントが代わりに承認することはできません。もう一度接続を押してリクエストを許可してください。端末によってはバックグラウンド動作も制限されるため、バッテリー設定とバックグラウンド設定でクライアントの接続維持を許可します。
ブラウザや一般的なデスクトップアプリだけでプロキシを使う場合、通常はシステムプロキシで十分です。システムプロキシを読み取らないアプリや独自のネットワークスタックを使うアプリでは、TUNモードを検討します。TUNの有効化には管理者権限、補助サービス、ネットワーク拡張の許可が必要な場合があり、初回起動時にクライアントから案内が表示されます。まずシステムプロキシで基本接続を確認してからTUNを有効にすると、権限、ドライバー、サブスクリプションの問題を混同せずに済みます。
クライアントのメインスイッチとシステムプロキシスイッチを有効にし、現在の設定が先ほど追加したものか確認します。OSのプロキシ設定に別のアドレスが残っている場合は、他のネットワークツールを終了してからClashに再設定させてください。
接続を押してシステムのVPNリクエストを許可し、クライアントをバックグラウンドで実行したままにします。同じ種類のVPN接続を1つしか許可しないシステムでは、既存のVPNを切断してからClashクライアントへ再接続してください。
アプリがシステムプロキシに従わない場合や、より完全な通信制御が必要な場合だけ有効にします。権限の確認が表示されたら、クライアントの案内に従って許可し、変更後に一度再接続してください。
接続ボタンが点灯していても、リクエストが正しいノードを経由しているとは限りません。ローカルポートの競合も確認してください。Clashの設定ではHTTP、SOCKS、mixedの待受ポートがよく使われます。同じポートを別のプログラムが使用していると、クライアントログに待受失敗やアドレス使用中のメッセージが表示されます。その場合は使用中のプログラムを終了するか、アプリ間の参照関係を確認したうえでポートを変更します。ポート項目の役割と変更方法は、設定リファレンスの共通項目の章で確認できます。
接続が完了したら、すぐに設定を追加変更しないでください。現在のクライアント、設定、ルールモード、ノードを維持したまま次の手順へ進み、段階的に確認します。直連経路、プロキシ経路、クライアントの接続ログを個別に確認することで、問題がシステムによる通信制御の前にあるのか、ルールとノードの間にあるのかをすばやく判断できます。
システムプロキシまたはVPNが有効で、クライアントが実行中、かつログにポート待受エラーがなければ、通信を確認できます。
結果を確認
まず普段から直接アクセスできるWebサイトを開き、基本ネットワークが正常であることを確認します。続いて、プロキシポリシーへ振り分けられるはずの対象へアクセスします。ブラウザでページが開くかだけでなく、クライアントの「接続」「Connections」またはログページも同時に確認してください。有効なリクエストには通常、対象ドメイン、適用ルール、使用したプロキシグループ、最終ノードが表示されます。これらの情報は、ページの表示だけを見るより設定が意図どおり動作しているかを判断しやすくします。
ルールモードでは、直連サイトはDIRECTまたは設定内の対応する直連グループに一致します。プロキシが必要な対象はプロキシルールに一致し、先ほど選択したプロキシグループとノードが表示されます。すべてのリクエストが直連になる場合は、モードが誤って直連になっていないか、ルール設定が本当に現在のサブスクリプションへ切り替わっているか確認してください。すべてのリクエストが同じプロキシへ入る場合は、グローバルモードのままになっていないか、ルール末尾のフォールバックポリシーが前の照合結果を上書きしていないか確認します。
ブラウザではアクセスできるのに、特定のアプリだけ接続できない場合は、そのアプリがシステムプロキシを読み取るか確認します。デスクトップ版ではサブスクリプションとノードを変更せずにTUNをテストできます。モバイル版では、クライアントのアプリ別設定で対象アプリが除外されていないか確認してください。ドメインは開けないのに対応するIPアドレスへ直接アクセスできる場合、DNSが原因である可能性が高くなります。DNSモード、Fake-IPの除外項目、LANドメインの処理は高度な設定です。実際の用途に合わせて設定リファレンスで調整してください。
システムプロキシを無効にするかVPNを切断し、一般的なWebサイトをテストします。元のネットワーク自体に問題がある場合は、まずネットワーク接続を復旧してください。
再接続してアクセスを開始し、クライアントの接続一覧に新しい記録が表示されるか確認します。記録がない場合、通信がまだクライアントへ入っていない可能性があります。
対象リクエストに適用されたルールとプロキシグループを確認します。経路が意図と異なる場合は、モードとルールの順序を確認してください。
ルールが正しいのにリクエストが失敗する場合は、同じプロキシグループ内の別ノードへ切り替えて再テストし、ログのハンドシェイク、タイムアウト、名前解決に関するメッセージを確認します。
確認中は、毎回1つの明確なリクエストだけを送信し、接続記録を適宜整理または絞り込むことをおすすめします。バックグラウンドアプリは更新、同期、プッシュ通知の通信を継続するため、大量の記録にテスト対象が埋もれることがあります。クライアントのドメインフィルターを使うか、対象ドメインを控えてから該当項目のルールとポリシーを確認してください。これにより、他のアプリの接続を現在のテスト結果と誤認しにくくなります。
「ルールモードでは失敗するがグローバルモードでは成功する」場合、クライアントを再インストールする必要はありません。まずルールモードで対象に適用されたポリシーを確認します。直連や誤ったプロキシグループに振り分けられているなら、原因はルールまたはポリシーの選択です。「両方のモードで失敗するが、クライアントには接続記録がある」場合は、最終ノード、プロトコル接続、DNSを優先して確認します。「クライアントに接続記録がまったくない」場合は、3番目の手順に戻り、システムプロキシ、VPN、TUN、アプリ側のプロキシ設定を確認してください。
その後のメンテナンス
基本接続が完了したら、現在使用している設定名、モード、主要なプロキシグループの選択を記録します。後でサブスクリプションを更新したりルールを変更したりして異常が出た場合、この確認済みの状態と比較できます。サブスクリプションは通常、手動更新または定期更新に対応しています。更新後は現在の設定が選択されたままか確認し、プロキシグループの選択が設定内容によってリセットされていないか簡単に確認してください。
ポート設定、DNS、Fake-IP、TUN、プロキシグループのネスト、ルール構文、オーバーライドのマージを扱う場合は、設定リファレンスを続けて読んでください。YAMLの構造に沿って項目と例を説明しているため、基本接続が正常になってから項目ごとに変更するのに適しています。サブスクリプションの更新失敗、システムプロキシの残存、接続後のネットワーク切断、DNSリークなどの具体的な障害は、よくある質問で症状から探せます。
現在動作している設定を基準として残してください。その後は毎回1種類の設定だけを変更し、「接続記録—ルール—プロキシグループ—ノード」の順に確認を繰り返します。