サブスクリプションを追加して設定を有効化
始める前に、使用するクライアントに対応したサブスクリプションリンク、またはローカルのYAML設定ファイルを用意してください。クライアントは設定の読み込みとリクエストの転送を担います。インストールしただけでは、利用可能な出口が用意されたことにはなりません。サブスクリプションは、利用権限のあるサービスまたは自分で構築したサービスから取得してください。このガイドではサブスクリプションURLを提供しません。リンクにアクセス認証情報が含まれる場合があるため、公開コメントに投稿したり、完全なリンクが写ったスクリーンショットを公開ページにアップロードしたりしないでください。
クライアントを開き、「設定」「サブスクリプション」または「Profiles」画面に移動して、「新規作成」「追加」「リンクからインポート」などの項目を探します。リモートリンクを選び、URL全体を貼り付けて、見分けやすい名前を付けてから保存またはインポートしてください。先に保存してからダウンロードする画面では、設定カードの更新ボタンもクリックします。読み込みが終わったら、更新日時、設定名、解析成功のメッセージなどが表示されているか確認してください。表示方法はクライアントによって異なります。
貼り付ける際は、URLの前後に空白や改行、チャットアプリが追加した句読点が入らないようにしてください。ブラウザーでリンクを開けても、応答があったことを示すだけで、返された内容がClashの設定形式であるとは限りません。解析に失敗した場合は、まずサブスクリプションの提供元に、どのクライアント形式を選べばよいか確認してください。形式エラーへの対処としてローカルポートやDNSを何度も変更しないでください。設定本文の解析とは別の問題です。
ローカルファイルを使う場合は、「ファイルからインポート」を選び、ファイル選択画面で該当する.yamlまたは.ymlファイルを指定します。インポート前に元ファイルを保管してください。クライアントによっては設定本文を直接貼り付けることもできますが、YAML全体をサブスクリプションリンクとして入力しないでください。ノード情報のみのファイルと、ルール、DNS、プロキシグループを含む完全な設定ファイルでは用途が異なります。そのまま使えるかどうかは、クライアントが設定を補完するかによります。
インポート後、新しい設定の「有効化」「使用」または選択ボタンをクリックします。設定カードが表示されているだけでは、現在の設定として適用されたとは限りません。「プロキシ」画面に戻り、設定内のプロキシグループやノードが表示されていることを確認してください。空欄のままなら、設定画面に戻り、選択状態とエラーメッセージを確認します。複数の設定を保存できるクライアントでは、以前のテスト用設定が選択されたままになっていないかも確認してください。
初回は手動で一度更新すれば十分です。利用可能であることを確認した後、サービス提供元の推奨に従って自動更新の間隔を設定してください。更新頻度が高すぎると、リクエスト制限がかかる場合があります。リモート更新によってダウンロードした設定への直接編集が上書きされることがあるため、初期設定の段階でサブスクリプション更新と大幅な手動編集を併用しないでください。追加が完了し、設定が有効になったことを確認したら、次にリクエストの出口を選ぶルールを決めます。
ルールモードとプロキシグループを選択
クライアントのホーム画面、設定画面、またはトレイメニューにあるモード選択を開き、初回は「ルール」を選びます。英語表示では通常「Rule」です。ルールモードでは、現在の設定にあるマッチ順に従って、リクエストの処理方法を選択します。たとえば、直接接続する、特定のプロキシグループに渡す、接続を拒否するなどです。ここで選ぶのは通信の振り分け方法であり、システムプロキシを有効にする設定ではありません。ルールモードを選んでも、アプリの通信がまだクライアントに届いていない場合があります。
よく使われるモードには「グローバル」と「ダイレクト」もあります。グローバルモードでは通常、コアに届いた通常のリクエストをグローバルプロキシグループで処理します。短時間の比較テストには使えますが、すべてのアプリの通信が取り込まれるわけではありません。ダイレクトモードでは、コアに届いたリクエストを直接接続します。普段はサブスクリプション提供元のルールモードを使い、まずは振り分けの動作を変えないようにしてください。問題の原因が設定なのか通信の取り込みなのか、切り分けにくくなります。
ルールモードを選んだら、「プロキシ」画面を開き、現在の設定に含まれる選択用グループを探します。「ノード選択」「プロキシ」など名前はさまざまで、名称だけで全体を制御するスイッチだと判断できません。設定の説明を確認し、ルールが実際に参照しているグループを特定してから、その中で利用可能な出口を選択してください。あるグループを選んでも、すべてのルールがそのグループを通るとは限りません。別のルールが異なるグループを参照していることもあります。
選択したグループに「自動選択」など別のグループが表示される場合は、下位グループの選択内容とテスト状態も確認してください。手動選択グループは通常、指定した項目を維持します。自動選択グループは、設定されたヘルスチェックの結果に応じて出口を決めます。初回のトラブルシューティングでは、グループの入れ子による不確定要素を減らすため、明確なノードを一時的に選択してください。ルールから参照されていないグループだけを切り替えても、アクセス結果が変わらないことがあります。
クライアントの接続テストや遅延テストを実行し、タイムアウトや接続失敗などの状態を確認します。テスト結果はテスト先、プロトコル、現在のネットワーク環境によって変わり、特定のリクエスト一回分を示すにすぎません。すべてのWebサイトにアクセスできる保証にはなりません。テストに成功しても、実際にWebページを開いて確認してください。タイムアウトした場合もログと併せて判断し、サブスクリプション全体が無効だと決めつけないでください。
この段階では、現在有効な設定、使用中のモード、対象プロキシグループで選択している出口を説明できる状態が目安です。プロトコル、コアとの互換性、モバイル端末での選び方については、プロトコルとコアのガイドを参照してください。初回の接続では、設定に含まれるDNSとルールを維持し、次のステップでシステムの通信をクライアントに取り込む方法を設定します。
システムプロキシまたはVPN接続を有効化
デスクトップでは、まずクライアントのホーム画面またはステータス欄でコアが起動していることを確認します。アプリの起動時にコアも自動起動するクライアントもあれば、先に起動ボタンを押す必要があるものもあります。設定の読み込みに失敗したという表示が出た場合は、前の段階に戻ってエラーを解消してください。アプリのウィンドウが開いていても、リクエストを転送するコアが正常に動作しているとは限りません。状態を確認したら「システムプロキシ」を有効にし、システムプロキシに従うアプリからローカルの待ち受けポートへリクエストを送ります。
システムプロキシを有効にした後、OSのネットワークプロキシ設定を開き、アドレスとポートが現在のクライアントを指しているか確認できます。ポート番号はクライアントに表示される値を使い、ほかのガイドにある数字をそのまま入力しないでください。混合ポートはHTTPとSOCKSの両方のリクエストを受け付けますが、クライアントによっては別々のポートを用意しています。初回設定で待ち受けアドレスを変更する必要はありません。ローカルのブラウザーから接続するために、LANアクセスを許可するのも避けてください。
WindowsやmacOSで別のプロキシツールも動作している場合は、先にそちらのシステムプロキシを無効にしてから、現在のクライアントを有効にしてください。複数のプログラムが同じシステム設定を書き換えると、画面上は有効でも実際のポートが別のプログラムを指すことがあります。ブラウザーに独立したプロキシ拡張機能がある場合は、システム設定に従うよう切り替え、拡張機能がシステムプロキシを上書きしないようにしてください。
Androidでは通常、ホーム画面の起動ボタンからローカルVPN接続を確立します。初回起動時にシステムからVPN接続の要求が表示されるため、対象アプリを確認してから許可してください。接続後は、通常システムにVPNのステータスアイコンが表示され、クライアントにも実行中の状態が表示されます。ほかのVPNに接続中の場合は、先に切断してください。端末によっては、常時接続VPNや接続のロック設定が新しい接続による通信の取り込みを妨げることがあります。
iOSクライアントで初めて接続するときは、案内に従ってVPN構成の追加を許可し、システムで求められる端末認証を完了してください。その後クライアントに戻り、接続が確立していることを確認します。システム設定に複数のVPN構成が保存されている場合は、どの構成が起動中か確認してください。構成の追加許可は準備にすぎません。接続中かどうかはクライアントとシステムのVPN状態で判断し、許可を押したことだけを理由に確認を省略しないでください。
デスクトップのTUNは別の通信取り込み方式で、通常はサービスコンポーネント、管理者権限、またはシステムの許可が必要です。対象範囲もシステムプロキシとは異なります。初回接続では、まずシステムプロキシでブラウザーの動作を確認してください。対象アプリがシステムプロキシに従わない場合や、より広い範囲の通信を取り込む必要がある場合に、TUNを検討します。Androidクライアントでは仮想ネットワークインターフェースを内部で使用していることがあるため、デスクトップと同じ名前のスイッチを探す必要はありません。
通信の取り込みとルール適用を確認
クライアントを起動したまま、ブラウザーで新しいタブを開き、現在のルールでプロキシ経由になるはずの、アクセス権限があるWebページにアクセスします。ページ自体の読み込みが遅いのか、接続に問題があるのかを見分けやすくするため、まずは内容がシンプルなページを使ってください。初回の確認では、開きっぱなしのページを更新するだけにしないでください。ブラウザーのキャッシュ、接続の再利用、サイト側のキャッシュによって、現在の設定とは無関係に見えることがあります。
アクセスと同時に、クライアントの「接続」「アクティビティ」または「ログ」画面を開き、アクセスしたドメインを探します。接続記録には通常、接続先アドレス、適用ルール、プロキシチェーンが表示されます。ログには接続エラーや名前解決エラーが記録されることがあります。画面によって表示内容は異なりますが、少なくともリクエストがコアに届いていることを確認してください。Webページが開いても、クライアントに該当リクエストがまったく表示されない場合、プロキシが有効とはまだ判断できません。元の直接接続経路でアクセスしている可能性もあります。
該当するリクエストを見つけたら、処理方法が想定どおりか確認します。DIRECTに一致している場合、そのリクエストは設定上、直接接続する指定です。「プロキシが起動していない」ことを直接示すものではありません。プロキシグループを通る場合は、プロキシチェーンで最終的にどの出口が選ばれたかも確認してください。Webページが複数のドメインを使う場合、1回のアクセスで複数の接続が発生します。一つの静的リソースの記録だけで、ページ全体の接続経路を判断しないでください。
次に、設定上は直接接続するはずのWebページにアクセスし、ルールの適用状況を確認します。プロキシ経由と直接接続の両方を確認すれば、すべての通信を同じ出口に送る状態を、ルールによる振り分けが正常な状態と誤認せずに済みます。外部の出口IPアドレス確認ページは補助として使えますが、示されるのはそのリクエストの出口だけです。すべてのアプリ、ドメイン、IPv6通信が同じ経路を使うとは限りません。
リクエストがクライアントに届いていない場合は、まずシステムプロキシまたはVPN接続が有効か確認します。次に、ブラウザーが独自のプロキシを使用していないか、システムのポートがクライアントと一致しているか確認してください。リクエストがコアに届いているのに接続に失敗する場合は、プロキシグループの選択を確認し、同じ設定内の別の利用可能な出口に切り替えて比較します。ログにドメイン名前解決エラーが明記されている場合は、設定のDNSを確認してください。手がかりがないまま設定全体を置き換えないでください。
変更は一度に一つにし、同じアクセス方法で再テストしてください。「設定が有効 → プロキシグループを選択済み → コアが正常に動作 → 通信の取り込みが有効 → ルールと名前解決の記録」の順に確認するのがおすすめです。エラー情報を共有するときは、エラーの種類と必要なフィールド名を残し、サブスクリプションURL、ノード認証情報、関係のないアクセス記録は伏せてください。詳しい確認手順は接続済みなのにWebページが開かないときのチェックリストを参照してください。
動作確認ができたら、自動更新、自動選択、必要なTUN設定を一つずつ有効にし、変更のたびに再確認してください。最後に通常の切断も試します。デスクトップではシステムプロキシを無効にしてからクライアントを終了し、モバイルではクライアントの停止ボタンを使ってVPNが切断されたことを確認してください。クライアント終了後も、システムが停止済みのローカルポートにリクエストを送り続ける事態を防げます。
初期設定の完了時には、サブスクリプションを読み込める、プロキシグループの選択が明確、システム通信がクライアントに届く、実際のアクセスが想定した出口を通る、という4点を確認できる状態にします。サブスクリプションや端末を変更したときは、サブスクリプションの追加から確認し直してください。プロトコルの対応状況やコアの設定差を調べる場合は、プロトコルガイドを参照できます。初回接続のために、すべての詳細設定をあらかじめ変更する必要はありません。