開始前の準備:クライアント、サブスクリプションURL、システム権限
操作を始める前に、現在のOSに合ったClashのGUIクライアントと、サービス提供元が発行したClashのサブスクリプションURLを用意します。クライアントは設定の読み込み、ローカルプロキシポートの起動、ルールの実行を担当します。サブスクリプションURLはノード、プロキシグループ、ルールを提供します。両者は別物です。クライアントをインストールしても利用できる設定がなければ、プロキシ画面に選択可能なノードは通常表示されません。
まずダウンロードセンターを開き、Windows、macOS、Linuxからインストールパッケージを選びます。Windowsでは通常、環境に合ったアーキテクチャのインストーラーをダウンロードし、ウィザードに従ってインストールします。macOSではApple SiliconとIntelプロセッサーを区別してください。Linuxではディストリビューションに合うパッケージ形式を選びます。初回起動時にネットワーク、VPN設定、ファイアウォールの権限を求められることがあります。これらはローカルプロキシや仮想ネットワークインターフェースの構築に必要なため、使用するクライアントの機能に応じて許可します。
サブスクリプションURLは通常、サービス提供元の管理画面で発行され、https://で始まる長いリンクです。アカウント識別用のパラメータが含まれる場合があるため、完全なURLを公開チャット、スクリーンショット、ログ投稿などに貼り付けないでください。本記事ではノードやサブスクリプションサービスを提供していません。また、「無料ノード」を安定した設定の入手先として推奨することもありません。公開URLは失効しやすく、設定内容が変更されていないか確認するのも困難です。
インストール後はクライアントを起動しますが、すぐにシステムプロキシを有効にする必要はありません。初回起動では、プログラムが正常にメイン画面を開き、「設定」「サブスクリプション」「Profiles」などの入口を見つけられることを確認します。その後、先に設定を追加し、ポリシーを選び、最後にシステムプロキシを有効にします。この順序なら、ルールが読み込まれる前にシステム通信が未準備のローカルポートへ送られる事態を避けられます。
サブスクリプションを追加:クライアントに設定ファイルを読み込ませる
サイドバーの「設定」「サブスクリプション」「Profiles」「Configs」などのページを開きます。多くのデスクトップクライアントでは、ページ上部にURL入力欄があり、その横に「追加」「ダウンロード」「登録」またはプラスボタンがあります。サブスクリプションURL全体を入力欄に貼り付け、追加を実行します。クライアントがリモート設定を取得し、受け取ったYAML設定をローカルの設定ディレクトリに保存します。
追加に成功すると、画面に新しい設定の記録が表示されます。通常は設定名、更新日時、更新ボタンなどが表示されます。記録が表示されたからといって、すぐにページを離れないでください。その記録をクリックするか、右側のメニューから現在の設定として有効化します。クライアントによっては「有効化」「選択」「アクティブ設定にする」などの名称です。記録の横に選択マーク、色付きの枠、Activeといった表示があれば、設定はすでに有効です。
「プロキシ」ページに切り替えて結果を確認します。通常は、「ノード選択」「自動選択」「フェイルオーバー」など、サービス提供元が独自に名付けたプロキシグループがいくつか表示されます。各グループには少なくともDIRECT、自動ポリシー、具体的なノードのいずれかを選べる状態になっているはずです。グループ名に統一された形式はありません。画面が空白ではなく、ポリシーとノードの階層が表示されていれば、設定はコアに読み込まれています。
追加をクリックした後に形式エラーが表示された場合は、手元のURLがClash YAMLのサブスクリプションなのか、別のクライアント向けの汎用サブスクリプションなのかを確認します。ブラウザーでURLを開けても、形式に互換性があるとは限りません。返された内容がエンコードされた文字列だけで、proxies、proxy-groups、rulesなどのフィールドを含むYAMLでなければ、現在のクライアントでは直接読み込めない可能性があります。形式の判別、設定ファイルの構造、サブスクリプション変換にはより多くの注意点があります。このような場合は使い方マニュアルの設定に関する章を参照してください。
サブスクリプションを追加した後は、「更新」と「編集」の違いも理解しておきましょう。更新はリモートURLから設定を再ダウンロードする操作で、サービス提供元がノードやルールを追加・変更した場合に実行します。ローカルファイルを直接編集しても現在のコピーだけが変わり、次回更新時にリモートの内容で上書きされることがあります。初回利用では、カスタムルールの追加を急がず、まず元の設定で接続を1回確認してください。基本的な経路が正常だと確認してから、ルールの上書き、スクリプト拡張、設定の統合に進みます。
プロキシモードを選択:初回はルールモードを使う
設定の読み込みが完了したら、「プロキシ」ページまたはメイン画面のモード選択エリアを開きます。一般的な選択肢はルールモード、グローバルモード、ダイレクトモードで、画面上ではRule、Global、Directと表示されます。初回はルールモードがおすすめです。設定ファイルのルールを上から順に照合し、結果に応じて接続をDIRECT、PROXY、REJECT、またはプロキシグループへ渡します。
ルールモードでは通信を種類ごとに振り分けられます。たとえば、ローカルネットワークや設定で指定された直接接続ドメインはDIRECT、プロキシが必要なドメインはPROXYグループ、明示的に拒否するリクエストはREJECTへ送られます。通常はプロキシグループでノードを選ぶだけで、ウェブサイトごとの接続方法を個別に決める必要はありません。ルールの優先順位、ドメイン照合、IP照合、最後のMATCHによるフォールバックは応用的な内容なので、使い方マニュアルのルール分岐の章で確認してください。
グローバルモードでは、ほとんどの接続を現在選択しているプロキシノードへ送ります。ルールによって特定のウェブサイトが直接接続になっているかを短時間で判断するには便利ですが、トラブル対処の唯一の手段には向きません。ダイレクトモードではプロキシを経由せず、元のネットワークへ一時的に戻したり、問題がプロキシ経路にあるか確認したりする際に使います。確認が終わったら、実際の用途に合わせてルールモードへ戻してください。
Ruleを選んだら、プロキシグループを設定します。最上位の「ノード選択」または同様のグループ名をクリックし、まず具体的なノードを1つ選びます。設定に「自動選択」ポリシーがあれば、それを選んでコアに候補ノードを自動判定させることもできます。画面の遅延テストは、クライアントからテスト先までの応答状況を示すだけで、すべてのウェブサイトにアクセスできることを証明するものではありません。ここでは明らかに応答しないノードを除外する目的で利用します。
設定によっては、複数階層のプロキシグループが含まれます。最上位グループが「自動選択」「地域グループ」などの子グループを参照し、その子グループが具体的なノードを参照する構成です。上位のポリシーを変更した後は、参照先の子グループを開いて最終的なノードも確認します。上位で自動ポリシーを選んでいる場合、下位ノードを手動で切り替えても現在の接続にすぐ反映されないことがあります。上位で地域グループを選んでいる場合は、その地域グループ内の選択肢が実際の出口になります。
DOMAIN-SUFFIX,example.net,PROXY
GEOIP,CN,DIRECT
MATCH,PROXY
接続を確立:システムプロキシを有効にしてクライアントを起動したままにする
クライアントのホーム画面または設定画面に戻り、「システムプロキシ」「System Proxy」のスイッチをオンにします。これによりOSのHTTP・HTTPSプロキシ設定が、Clashが待ち受けているローカルアドレスへ向けられます。一般的には127.0.0.1とローカルポートの組み合わせです。ポート番号はクライアントの設定で決まるため、別のガイドに固定の番号が書かれていても、現在の設定を手動で同じ番号に変更しないでください。
システムプロキシを有効にすると、ブラウザーやOSのプロキシ設定を読み取る多くのデスクトップアプリがClashへリクエストを送ります。クライアントは起動したままにしてください。プロセスを終了するとローカルの待ち受けポートも消え、システムプロキシがすぐに元へ戻らなければ、アプリでウェブページがすべて開けなくなることがあります。クライアントを終了する前にシステムプロキシを無効にするか、終了時にシステム設定を自動復元できるクライアントか確認してください。
Windowsで通常のデスクトップブラウザーは接続できるのに、Microsoft Storeアプリや一部のシステムコンポーネントに接続記録がない場合は、UWPのループバック制限を確認します。多くのクライアントでは、設定またはサービスモードの画面にループバックを補助する入口があります。これはWindowsアプリコンテナーのネットワーク権限に関わる操作で、すべてのPCで必要になるわけではありません。対象アプリが現在のプロキシを実際に読み取らない場合だけ対応し、詳しい仕組みは使い方マニュアルのシステムプロキシとTUNの章を参照してください。
macOSで初めてシステムネットワークのプロキシを変更すると、システムパスワードの入力を求められることがあります。TUNを有効にする際は、ネットワーク拡張の許可が必要になる場合もあります。Linuxのデスクトップ環境では、システムプロキシの対応が完全に統一されていません。ブラウザーはデスクトップ設定を読み取れても、コマンドラインプログラムは読み取らないことがあります。そのため、この手順ではまずブラウザーでシステムプロキシを確認し、ターミナルのプログラムは次の手順で個別に確認します。
TUNモードは初回接続に必須ではありません。仮想ネットワークインターフェースを通じて、システムプロキシを読み取らない通信も広く取り込めますが、管理者権限、ルーティング、DNS、他のVPNソフトとの連携が必要になります。まずはシステムプロキシだけを有効にし、サブスクリプション、ノード、ルールが機能することを確認してください。ゲーム、コマンドラインツール、特殊なアプリが接続できない場合に限り、TUNを有効にするのがおすすめです。問題が起きたときの確認範囲を小さくできます。
システムプロキシをオンにした直後に自動でオフになる場合や、クライアントがポートの使用中を通知する場合は、まず他のプロキシソフトを終了し、別のClashプロセスがバックグラウンドで動いていないか確認します。複数のプログラムに同じシステムプロキシ設定を同時に変更させたり、同じポートを待ち受けさせたりしないでください。競合を解消してクライアントを再起動し、設定の有効化、Ruleモード、ノード選択、システムプロキシの順にもう一度確認します。
有効性を確認:ブラウザーと接続記録を一緒に確認
ブラウザーで、普段から安定して読み込めるHTTPSページを開きます。「ページが開いた」だけではプロキシが有効だと判断しないでください。ルールによってそのページがDIRECTになっている可能性があるためです。続いてClashクライアントに戻り、「接続」「Connections」ページを開いて、ブラウザーで発生した新しいセッションが表示されるか確認します。セッション記録には通常、対象ドメイン、プロトコル、適用されたルール、最終ポリシーが表示されます。
対象ドメインを見つけたら、ルールが何に一致したか、最終的にどのポリシーが使われたかを確認します。DIRECTなら、リクエストはルールエンジンを通過したうえで、設定により直接接続されています。PROXYまたは具体的なプロキシグループとノードなら、プロキシ経路に入っています。REJECTなら、ルールによって明示的に拒否されています。この確認はページを更新するだけより正確です。「Clashに入っていない」のか「Clashに入った後でルールにより直接接続になった」のかを区別できます。
続いて「ログ」「Logs」ページを開きます。正常な接続では、対象アドレス、ルールの一致、ポリシーの選択を確認できます。接続タイムアウトが続く場合は、同じプロキシグループ内の別ノードを試します。ドメイン解決エラーが出る場合は、DNS設定、TUNの状態、他のネットワークツールがDNSを同時に処理していないかを確認します。ブラウザーのリクエストがログにまったくない場合は、システムプロキシのスイッチ、ブラウザーのプロキシ拡張機能、アプリ自身のプロキシ設定に原因がある可能性が高いです。
ブラウザーの拡張機能がシステムプロキシを上書きすることがあります。プロキシ切り替え拡張機能をインストールしている場合は、いったん無効にするか、システム設定を使用するよう変更して、新しいページを開いて再テストします。ブラウザー内の既存接続が再利用されることがあるため、テスト時は新しいプライベートウィンドウを開くか、ブラウザーを完全に終了してから再起動してください。Connectionsページで新しく作成されたセッションを見つけやすくなります。
ターミナルのプログラムは個別に確認する必要があります。多くのコマンドラインツールはデスクトップのシステムプロキシを読み取らず、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY環境変数を参照するか、コマンド引数でプロキシアドレスを明示する必要があります。まずクライアントの設定画面でHTTPまたはmixedポートを確認し、明示的な引数でリクエストを実行します。
curl -x http://127.0.0.1:7890 https://example.com
上の7890はコマンド構造を示す例です。実際には、現在のクライアントに表示されているローカルHTTPまたはmixedポートへ置き換えてください。コマンドを実行したらConnectionsページに戻り、該当するセッションを探します。明示的なプロキシでは接続できるのに、-xなしのコマンドに記録がない場合、Clash自体は正常に動作しており、ターミナル側のプロキシ環境変数が未設定ということです。
最後に復元テストを行います。システムプロキシを無効にしてページを更新し、新しいリクエストがConnectionsに入らなくなるか確認します。その後、システムプロキシを再び有効にし、セッションが戻ることを確認します。この切り替えで、システム設定が実際に変更されたか検証できます。完了後はRuleモードを維持し、用途に応じてクライアントをOS起動時に自動起動するか決めます。終了時の動作を理解しないまま、複数のネットワークツールを同時に自動起動しないでください。
10分経っても接続できない場合:経路に沿って確認
トラブル対処では、すべてのスイッチを無作為に切り替えないでください。Clashの基本経路は、サブスクリプションをダウンロードできる、設定をコアが読み込める、プロキシグループに利用可能なポリシーがある、ローカルポートが待ち受けている、対象アプリがそのポートへ通信を送る、という5段階に分けられます。この順序で確認すれば、問題がどの層で止まっているかを素早く判断できます。
- 設定層:設定ページに戻って一度更新し、現在の設定が明確に選択されていることを確認します。更新に失敗する場合は、ノードの切り替えを続けるのではなく、サブスクリプションURL、ネットワーク接続、設定形式を先に確認します。
- ポリシー層:プロキシページを開き、モードがRuleで、最上位のプロキシグループが利用できない選択肢のままになっていないことを確認します。具体的なノードを別のものに変更したら、新しいブラウザー接続を作成してください。長時間開いたままのページで結果を判断しないでください。
- ポート層:クライアントのログにポート競合やコアの起動失敗がないか確認します。ポートが競合している場合は、他のプロキシプログラムと重複起動しているクライアントを終了してから、再起動します。
- システム層:System Proxyがオンになっていることを確認します。Windowsではシステムのプロキシ設定、macOSでは現在のネットワークサービスのプロキシ項目を確認します。Linuxでは、デスクトップ環境と対象アプリが同じ設定を読み取っているか確認してください。
- アプリ層:ブラウザーではプロキシ拡張機能、ターミナルでは環境変数、ゲームや特殊なアプリではTUNが必要かを確認します。1つのアプリの結果から、すべてのアプリが同じプロキシ方式を使っていると判断しないでください。
特定のウェブサイトだけで問題が起き、他のプロキシ接続が正常な場合は、そのサイトのセッションに表示されるルール、ポリシー、エラーを確認します。ルールの誤りは設定層、ノードにアクセスできない問題は出口層、DNSエラーは名前解決層の問題です。すべてのサイトで接続記録がまったくない場合は、ルールファイルを変更する前にシステムプロキシとアプリの設定を確認してください。
それでも原因を特定できない場合は、起動可能な元の設定を保存し、クライアント名、OS、現在のモード、TUNの有効・無効、ログに表示された具体的なエラー、Connectionsにセッションが表示されるかを記録します。その後ゼロから学ぶ使い方マニュアルで、システムプロキシ、TUN、DNS、ルール分岐、ログの各章を確認してください。詳細な設定はマニュアルにまとめ、本ページでは初回接続に必要な最短手順に絞っています。