Clash設定ガイド

01 · サブスクリプションを追加して設定を有効化

クライアントを開き、「設定」「サブスクリプション」または「Profiles」ページへ移動して、「新規作成」「追加」「URLからインポート」などを選びます。種類を選ぶダイアログが表示された場合は、リモートサブスクリプションまたはリモート設定を選び、プロキシを個別に新規作成しないでください。見分けやすいローカル名を設定し、プロバイダーから提供されたURLを入力欄にすべて貼り付けます。名前は端末上の表示に使われるだけで、接続先の出口には影響しません。

貼り付けたら、URLの先頭と末尾を確認します。チャットアプリからコピーすると、説明文や改行、末尾の句読点が混ざることがあります。URL以外は取り除きますが、疑問符以降のパラメーターは削除・変更しないでください。サブスクリプションURLには認証情報が含まれる場合があります。URL全体を公開の掲示板に投稿したり、URLが写ったスクリーンショットをそのまま送ったりしないでください。問い合わせる際はエラーメッセージを残し、URL内の機密情報を隠しましょう。

「保存」「インポート」「ダウンロード」などをクリックし、クライアントの処理が完了するまで待ちます。正常に処理されると、設定一覧に新しい項目が追加され、名前、更新日時、ダウンロード状況などが表示されます。続いて、その項目の「使用」「有効化」を選ぶか、選択マークを付けて現在の設定にします。保存後に自動で切り替わらないクライアントもあります。一覧に追加されたことだけでは、実行中のコアが設定を読み込んだとは限りません。

プロキシグループが表示されることを確認

「プロキシ」または「Proxies」ページに移動し、選択可能なプロキシグループとそのメンバーが表示されているか確認します。プロキシ名は設定の提供元が決めるため、必ずしも「PROXY」とは限りません。「DIRECT」「REJECT」などの組み込み項目しか表示されない場合は、設定ページに戻って現在の選択項目を確認し、インポート時のメッセージも確認してください。リモートのプロキシプロバイダーは別途ダウンロードが必要な場合があり、メイン設定のインポートが成功しても、すべてのリモートリソースが読み込まれたとは限りません。

ローカルファイルを使う場合は、同じページで「ファイルをインポート」を選び、実際の .yaml または .yml ファイルを指定してから有効化します。拡張子をYAMLに変えただけでは、ファイルが設定として有効になるわけではありません。Webページ、ログイン案内、エラーページは設定ファイルにはなりません。ファイルには実際のプロキシ情報、またはプロキシを読み込む proxy-providers の定義が必要です。ポートとルールだけの断片では、通常プロキシ接続を確立できません。

インポートに失敗したら、まずエラーの種類を確認します。接続タイムアウトはリクエストが正常に完了しなかったことを示します。認証エラーの場合はサブスクリプションの利用権限を確認し、解析エラーの場合は、プロバイダーが現在のコアに対応した設定形式を提供しているか確認してください。個人用サブスクリプションを、信頼できないオンライン変換サイトに貼り付けないでください。URLの形式や変換の注意点は用語集のサブスクリプションと設定ファイルの説明を、具体的な対処方法はヘルプセンターをご覧ください。

02 · ルールモードと出口を選択

先ほどの設定を有効にしたまま、「プロキシ」または「モード」ページを開き、「ルール / グローバル / ダイレクト」の選択肢を探します。初回設定では「ルール」を選択します。これはコアの設定値 mode: rule に対応します。設定内のルールに従って、接続を直接接続するか、ポリシーグループに渡すか、拒否するかが決まります。モードは通信の振り分けを決めるだけで、他のアプリの通信をクライアントに取り込む機能ではありません。

次に、設定内で出口の選択に使われているポリシーグループを探します。「プロキシ選択」「ノード選択」など、別の名前で表示される場合があります。グループを開き、メンバーから利用可能なプロキシを選びます。メンバーが別のポリシーグループの場合は、そのグループで現在選択されている出口も確認してください。初回の動作確認では手動で出口を選ぶと、テスト結果と出口を対応させやすくなります。他の通信振り分けグループは同時に変更しないでください。

設定によっては、自動テストグループが初期選択されています。そのまま使っても構いませんが、テスト結果はクライアントから指定されたテスト先までの状態を示すだけで、目的のWebサイトにアクセスできる保証にはなりません。クライアントに接続テスト機能があれば一度実行し、タイムアウトや明確なエラーがないか確認します。テスト後も実際にWebサイトへアクセスして確認してください。テストの数値だけで、すべてのアプリの通信が取り込まれたと判断しないでください。

モードと通信の取り込み設定を区別する

「グローバル」にしても、もともとクライアントを経由しないアプリの通信が自動的にコアへ入るわけではありません。ブラウザーがシステムプロキシを使っていない場合、グローバルモードに切り替えるだけでは通信を取り込めないことがあります。同様に、「ダイレクト」を選んでも、システムプロキシ設定や仮想ネットワークインターフェースが解除されるわけではありません。通信の取り込みを完全に止めるには、モードだけでなく該当するスイッチをオフにしてください。

ルールモードで特定の宛先が想定と異なる経路を通る場合は、すぐにルールを削除せず、まず状況を記録します。後述する接続ページに一致したルールが表示されるため、原因がルールの選択か通信の取り込みかを判断できます。ここではルールモードが選択され、出口グループが明確に設定されていることだけ確認して、接続の手順へ進みます。ルールの優先順位、ポリシーグループの入れ子、MATCH の詳しい動作は全ドキュメントの設定編をご覧ください。

03 · システムプロキシまたはVPN接続を有効化

クライアントのホーム画面または概要画面に戻り、設定の読み込み後にコアが起動していることを確認します。「コアを起動」と「システムプロキシ」が別々のスイッチなら、先にコアを起動し、その後システムプロキシを有効にします。接続ボタンが1つだけの場合は、クライアントの案内に従って操作し、ログに起動エラーがないことを確認してください。この段階では、複数のネットワーク制御ツールを同時に有効にしたり、トラブル対処のためにシステムファイアウォールを無効にしたりしないでください。

デスクトップ：まずシステムプロキシを確認

Windows、macOS、デスクトップ環境のあるLinux向けクライアントには、通常「システムプロキシ」スイッチがあります。有効にすると、OSのプロキシ設定に従うアプリからのリクエストがローカルの待ち受けポートに送られます。クライアントの設定で実際のアドレスとポートを確認してください。たとえば 127.0.0.1:7890 はよくある設定例です。実際の値は使用中のクライアントに表示されたものを使い、ガイドと数字を合わせるためにポートを変更しないでください。

ポートが使用中と表示された場合は、他のプロキシクライアントを終了してからコアを再起動します。起動ログに address already in use と表示される場合、システムプロキシが有効に見えても、ローカルのプロキシサービスが使えるとは限りません。待ち受けが正常に開始したことを確認してから、ブラウザーを新しいウィンドウで開いてテストします。アプリによっては既存の接続が維持されるため、必要に応じてページを更新するだけでなく、アプリを完全に終了して再起動してください。

Linuxでは、デスクトップのプロキシ設定がアプリに反映されるかどうかは、デスクトップ環境やアプリの実装によって異なります。ターミナルのプログラムも、必ずしもシステムプロキシを参照するとは限りません。初回確認では、プロキシ設定に対応したブラウザーを使い、すべてのターミナルツールの動作を一度に判断しないでください。サーバー、ルーター、systemdサービスへの導入は、ここで扱うGUIの設定手順とは異なります。詳しくはLinuxのインストール・デプロイ編をご覧ください。

モバイル：システムVPNの許可

AndroidやiOSでは、クライアントの起動または接続ボタンをタップすると、通常、VPN接続の作成やVPN設定の追加をシステムから求められます。インストール済みで現在使用しているクライアントからの要求であることを確認し、システムの案内に従って許可してください。クライアントに戻って接続状態を確認します。許可を取り消すと、設定を選択済みでもネットワークの取り込みは開始されません。ステータスバーの表示で分かるのはトンネルが有効かどうかであり、リモートの出口が使えるかどうかではありません。

すでに別のVPNが動作している場合は、いったん切断してから現在のクライアントを起動し、システムVPNの取り合いを避けてください。初回のテストではクライアントを前面に表示したままアクセスを確認します。前面では正常に動作し、バックグラウンドに切り替えたときだけ切断される場合に、バッテリー管理とバックグラウンド動作の権限を確認しましょう。こうしたバックグラウンド制限をサブスクリプションの無効と誤解し、何度もインポートし直さないでください。

TUNを有効にするタイミング

デスクトップでは、まずシステムプロキシを使って再現可能なテスト結果を得ます。システムプロキシ設定に従わないアプリや特定の種類の通信を取り込む必要がある場合に、TUNを検討してください。TUNは通常、仮想ネットワークインターフェース、ルート、DNSの処理に関わり、管理者権限やクライアントサービスが必要になることがあります。クライアントのサービスインストール案内に従い、スイッチの色だけでインストール完了と判断しないでください。

TUNを初めて有効にする際は、元のシステムプロキシの状態を記録し、両者の併用方法についてクライアントの説明に従ってください。TUN、DNS、ルート、モードを一度に変更しないでください。有効化後に通常のネットワーク接続が途切れたら、まずTUNをオフにし、動作確認済みのシステムプロキシの設定に戻します。デスクトップのTUNとモバイル端末のVPN許可は画面上の名称が似ていますが、仕組みは異なります。詳しくはネットワーク取り込み方式の用語解説をご覧ください。

04 · アクセスと接続履歴を確認

アプリ側とクライアント側の両方を確認します。まず通信の取り込みをオフにした状態で、普段使っているサイトにアクセスできることを確認してください。通常のネットワーク接続に問題がある場合は、Wi-Fi、モバイルデータ通信、ネットワークへのログインを先に確認します。次にプロキシ接続を有効に戻し、確認したいページを開きます。キャッシュ済みのページだけで判断しないよう、新しいリクエストを使ってテストしてください。

ページが読み込まれたら、すぐにクライアントの「接続」または「Connections」ページに戻り、アクセスしたドメインを探します。新しいリクエストの記録はすぐ消えることがあるため、必要ならページを再読み込みし、ログも確認してください。対象が表示されたか、どのルールに一致したか、最終的にどのポリシーや出口へ渡されたかの3点を確認します。ルールモードでは、サイトによってDIRECTに振り分けられるのは正常な動作であり、クライアント全体が機能していないことを意味しません。

状況に応じて確認範囲を絞る

対象の接続記録がまったくない場合は、まずアプリがシステムプロキシを使っているか、コアが実際に待ち受けているか、モバイル端末でVPN接続が維持されているかを確認します。リクエストがクライアントに届いていない可能性があるため、この段階で出口を変更するのは後にしてください。記録が表示されても経路が想定と違う場合は、クライアントを再インストールするのではなく、現在のモード、一致したルール、ポリシーグループの選択を確認します。

想定したポリシーに一致しているのに、タイムアウト、接続拒否、ハンドシェイクエラーが発生する場合は、選択した出口が使えるか、サブスクリプションの権限が有効か、端末の時刻が正しいかを確認します。一度に変更する出口は1つにし、同じ接続先で再試行して前後の結果を記録してください。特定のWebサイトだけに問題がある場合は、サイト側の状況も考えられます。1つのサイトの成功・失敗だけで、すべてのネットワーク接続の状態を判断しないでください。

任意：ローカルプロキシを指定してテスト

デスクトップでは、次のコマンドを使ってローカルプロキシサービスとアプリ側のプロキシ設定を切り分けられます。ローカルHTTPプロキシを明示的に使うため、ブラウザーがシステム設定を参照するかどうかに左右されません。実行前に、ポートをクライアントで使用しているHTTPまたはmixedの待ち受けポートに置き換えてください。SOCKSだけを有効にしている場合は、このHTTPプロキシの引数を使わないでください。

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/

Windows PowerShellでは、古い環境で同名のエイリアスが引数の解釈を変えないよう、コマンドの先頭を curl.exe にすることをおすすめします。HTTPレスポンスヘッダーが返れば、指定したローカルプロキシ経由のリクエストで、宛先から応答を受け取れたことが分かります。ただし、リモート出口を経由したかどうかはクライアントの接続履歴で確認してください。ルールによっては対象が直接接続されることもあります。ローカルアドレスに接続できない場合は、DNSを変更する前に待ち受けポートを確認してください。

コマンドは成功するのにブラウザーでは失敗する場合は、ブラウザー独自のプロキシ拡張機能や個別のプロキシ設定、既存の接続を確認します。ブラウザーでは成功するのに他のアプリで失敗する場合は、そのアプリがシステムプロキシに対応しているかを確認し、必要に応じてTUNを検討してください。外部IPアドレスの確認は補助的な手段です。ルール振り分けでは、確認先によって出口が異なる場合があるため、IPアドレスが変わらないことだけではプロキシの無効を証明できません。

再現できる動作状態を記録

テストページにアクセスでき、接続履歴も想定どおりなら、現在のモードと通信の取り込み方法を維持します。使用中の設定名、実際の待ち受けポート、選択したポリシーグループを記録しておくと、その後のトラブル対処がしやすくなります。終了する際は、先にシステムプロキシまたはVPN接続をオフにしてからクライアントを終了してください。システムプロキシのアドレスを手動設定した端末では、停止したポートを参照する設定が残っていないことも確認します。

サブスクリプションの内容が変わったら、設定ページから更新します。更新後は現在の設定が有効なままか確認し、この節の手順でもう一度動作確認してください。基本テストが終わる前に複雑なルールを追加しないでください。更新の失敗、UWPアプリがプロキシを使わない問題、一部のアプリだけインターネットに接続できない問題は、ヘルプセンターで症状別に確認できます。設定を継続的に管理する場合は、全ドキュメントもご覧ください。