Clashのサブスクリプション導入と接続確認

開始前の確認

操作を始める前に、インストール済みのClash GUIクライアントと、サービス提供元から発行されたサブスクリプションURLまたは直接導入できるYAML設定ファイルを用意します。サブスクリプションURLは通常、https://で始まるリンクです。YAMLファイルは.yamlまたは.yml形式が一般的です。どちらか一方があれば十分です。サービス管理画面のログインURL、プランページのURL、QRコードの画像をサブスクリプション本文として貼り付けないでください。

クライアントがまだインストールされていない場合は、まずクライアントのダウンロードページから対応するプラットフォームを選びます。WindowsとmacOSは通常、インストール後すぐにGUIを開けます。AndroidとiOSでは初回接続時にシステムVPN権限の確認が表示されるため、許可が必要です。Linuxのデスクトップ環境ではアプリメニューから起動する場合があります。サーバー環境ではコアとコマンドライン設定の利用が適していますが、本記事の簡易ガイドでは扱いません。

初回設定では、起動中の他のプロキシ、VPN、ネットワークフィルタリングツールを一時的に終了することをおすすめします。複数のプログラムが同時にシステムプロキシを変更したり、同じポートを使用したりすると、クライアントは起動済みなのにブラウザーが現在の設定を経由しないことがあります。以前のプログラムを終了してからClashクライアントを開くと、ポート競合やルーティングの競合を減らせます。職場や学校のネットワークで固定プロキシが必要な場合は、後で戻せるよう元の設定を先に記録してください。

システム時刻が正確であることも確認します。サブスクリプションサービスや一部の暗号化接続では正しい時刻情報が必要です。日付やタイムゾーンのずれが大きいと、サブスクリプションの更新失敗、接続ハンドシェイクの失敗、証明書エラーなどが起こります。確認が終わったらクライアント画面を開いたままにし、次は設定画面から導入を始めます。

プロキシモードを選択する

初回はルールモードを選択する

設定を読み込んだら、プロキシ、Proxiesまたはモード画面を開きます。まず全体モードのセレクターを探します。通常はルール、グローバル、直接接続の3つがあり、英語ではRule、Global、Directに相当します。初回設定ではルールモードがおすすめです。このモードでは、各通信を設定ファイルのルールに上から順に照合し、プロキシポリシー、直接接続、ブロックのいずれかを決めます。日常のWeb通信やローカルネットワークをすべて同じ経路にする必要はありません。

グローバルモードでは、ほとんどの通信を同じポリシーまたはノードへ渡します。指定したノードで特定サイトにアクセスできるか一時的に確認する用途には向きますが、設定に慣れていない段階の既定モードにはおすすめしません。直接接続モードはプロキシポリシーを経由せず、問題がプロキシ経路にあるかを素早く切り分けるときに使えます。3つのモードが変えるのは通信の処理方法であり、サブスクリプションやノードを削除するものではありません。確認が終わったらいつでもルールモードに戻せます。

ポリシーグループに利用可能なノードを指定する

ルールモードを決めたら、ポリシーグループを確認します。各ポリシーグループは、ルールが最終的に参照する選択項目で、具体的なノードや別の自動選択グループを含む場合があります。まず、ノード選択、プロキシ選択、Proxyに近い名前の主要グループを展開します。自動選択や遅延選択の項目があれば、まず自動ポリシーを選びます。具体的なノードしかない場合は、サービス提供元が利用可能としているノードを1つ選択します。

一部のクライアントでは、ノードの横に遅延テストボタンがあります。テスト結果が示すのは、クライアントからテスト先までの応答状況であり、すべてのWebサイトでの実速度を保証するものではありません。初回接続で最低値を何度も追い求める必要はありません。結果が返り、ノードが利用不可でなければ先へ進めます。すべてのノードがタイムアウトする場合は、まずサブスクリプションを更新し、端末から通常のWebページへアクセスできるか確認します。この段階でDNS、ポート、ルールを同時に変更すると、原因を特定しにくくなります。

設定には、動画配信、メッセージング、AIサービス、ソフトウェアのダウンロードなど、独立したポリシーグループが含まれる場合もあります。初回は既定値のままにし、主要なプロキシグループだけを設定してください。これらのサブグループは主要グループを参照していることが多いため、主要グループを選ぶだけで関連ルールにも利用可能な出口が適用されます。ポリシーグループ、ノード、ルールの用語の違いは用語集で確認できます。

モードが上書きされていないか確認する

クライアントによってはモードを記憶でき、設定によっては上書き機能で実行パラメーターを固定できます。ルールモードを選んだら別の画面へ移動して戻り、表示がRuleまたはルールのままか確認します。毎回別のモードへ戻る場合は、設定画面の上書き、設定の混入、起動設定を確認してください。内容が分からないモード上書きを一時的に無効にして、ルールモードを選び直します。主要なポリシーグループが利用可能なノードを指していることを確認したら、次にシステム接続を開始します。

動作を確認する

まずクライアントがリクエストを受信しているか確認する

ブラウザーでよく使うWebページを開いて更新し、同時にクライアントの接続、Connections、ログ画面を確認します。通常は、ブラウザーが発行したドメイン、宛先、適用ルール、選択されたポリシーが一覧に表示されます。新しい接続が継続的に表示されれば、ブラウザーの通信はClashに到達しています。一覧がまったく変わらない場合は、システムプロキシが有効か、ブラウザーが独自のプロキシ設定を使っていないか、クライアントがバックグラウンドで動作しているかを確認します。

接続一覧のルール情報は重要です。たとえばローカルサイトにDIRECTと表示される場合、ルールに従って直接接続されています。プロキシが必要なサイトでは、主要なプロキシグループまたは具体的なノードが表示されるはずです。すべてのリクエストが同じ経路になる場合は、モードを誤ってグローバルまたは直接接続にしていないか確認します。Webページが開くかどうかだけで設定の正しさを判断しないでください。もともと直接接続できるサイトでは、プロキシ経路が機能している証明になりません。

出口結果を確認する

続いて、信頼できるネットワーク出口確認ページへアクセスし、表示された出口地域やネットワーク情報を記録します。直接接続モードに切り替えて一度更新し、ルールモードに戻してもう一度更新して結果を比較します。ルールモードでプロキシが必要な確認リクエストが選択したノードを使い、直接接続モードではローカルネットワークの出口に戻るなら、システムプロキシ、コア、ポリシーグループが一連の経路として機能しています。比較後はルールモードに戻してください。

出口結果が変わらなくても、クライアントの接続一覧にリクエストが表示されている場合は、そのリクエストに適用されたルールを確認します。確認サイトがルールによって直接接続に指定されている可能性があり、プロキシが無効とは限りません。プロキシポリシーで処理されることが明確な別の宛先もテストし、接続詳細でポリシーチェーンを確認してください。ルールが特定のポリシーに一致する理由や、上から順に照合される仕組みについてはルール構文リファレンスを参照してください。

直接接続とプロキシ経路を個別にテストする

完全な確認では、2種類のリクエストをテストします。1つは直接接続が想定されるサイト、もう1つはプロキシ経由が想定されるサイトです。直接接続のサイトは正常に読み込まれ、接続記録にDIRECTまたは対応する直接接続グループが表示されます。プロキシ対象のサイトには、プロキシポリシーグループと実際のノードが表示されます。両方が想定どおりであれば、ルールモードで接続できているだけでなく、分流の方向も正しいと判断できます。

もう一度サブスクリプションの更新をテストします。設定画面に戻って更新を実行し、更新日時が変わり、現在の設定が選択されたままであることを確認します。更新後にプロキシ画面を開き、主要なポリシーグループの選択が保持されているか確認します。サブスクリプションによっては更新時にポリシー内容が再構築され、選択していたノードが削除されると既定の項目へ戻る場合があります。その場合は利用可能なノードを選び直せばよく、クライアントを再インストールする必要はありません。

再現可能な正常状態を保存する

確認が終わったら、現在の4つの重要情報を覚えておきます。アクティブな設定名、実行モード、主要なポリシーグループの選択、システムプロキシまたはTUNの状態です。今後アクセスできないときは、まずこの4項目を照らし合わせます。設定の切り替え、モードの変更、ノードの無効化、システムによる取り込みの停止などを素早く見つけられます。YAMLを変更する場合は、正常に読み込める設定を先に1つ保存し、構文エラーが起きたときに戻せるようにしてください。