操作前：クライアントをインストールし、元の設定を残す
まずクライアントのダウンロードページから、端末のOSとプロセッサーアーキテクチャに合ったインストーラーを選び、インストールしてメイン画面を開きます。クライアントは設定管理、画面表示、システム連携を担い、コアはプロキシ接続、ルール、DNS処理を担います。インストールが完了しても、利用可能なノードが用意されたわけではありません。続けて、利用権限があり、信頼できる提供元から入手した、現在のコアと互換性のある設定が必要です。
初回設定の前に、プロキシを有効にしていない状態で、普段直接アクセスできるWebサイトを開き、ローカルWi-Fi、モバイルデータ通信、または有線ネットワークが正常か確認します。端末でネットワーク認証ページへのログインが必要な場合は、先に認証を完了してください。システムに設定されている元のプロキシを記録し、既存の設定がある場合はクライアントのエクスポートまたはバックアップ機能で別に保存します。他のプロキシツールは先に正常切断し、複数のプログラムがシステムプロキシを書き換えたり、VPN接続を奪い合ったりしないようにします。
サブスクリプションを準備する際は、提供元が完全なClash互換YAML、ノード一覧、単一ノードの共有リンクのどれを提供しているか確認してください。これらは同じ読み込み項目を使うとは限りません。サブスクリプションURLにはアカウント識別情報が含まれる場合があるため、公開スクリーンショット、問い合わせ、オンライン変換ツールに貼り付けないでください。この記事では初回接続に必要な操作だけを扱います。DNS、ルール構文、設定の結合については設定リファレンス大全を参照してください。
ステップ1：サブスクリプションを読み込み、現在の設定にする
クライアントの「設定」「サブスクリプション」または「Profiles」画面を開き、「新規作成」「追加」「インポート」などの項目を探します。リモートサブスクリプションを使う場合は、URLから追加する方法を選び、完全なリンクをアドレス欄に貼り付けます。名前を入力できる場合は、「日常用設定」など識別しやすい名前を付けます。送信前に、先頭や末尾に空白、改行、チャットアプリが付けた句読点がないか確認し、保存または読み込みを実行して、ダウンロードと解析が完了するまで待ちます。
成功すると、設定一覧に新しい項目が表示され、更新日時や更新操作が付くことがあります。項目が表示されても、有効になったとは限りません。その項目をクリックするか、横にある「使用」「有効化」「現在の設定にする」などの操作を行い、画面でこの設定が現在選択中だと明確に表示されるまで進めます。その後プロキシ画面を開き、設定内のプロキシグループと選択肢が表示されることを確認して次へ進みます。ダウンロード完了の表示だけでは、コアがすべての項目を受け入れた証拠にはなりません。
ローカルYAMLはファイル読み込みから追加する
ローカルに設定ファイルがある場合は、同じ画面で「ファイルからインポート」を選び、システムのファイル選択画面から実際のYAMLファイルを開きます。YAML本文をサブスクリプションURL欄に貼り付けたり、拡張子だけを変更して通常のテキストを互換設定として扱ったりしないでください。クライアントがファイルをコピーせず直接参照する方式の場合は、ファイルを安定したフォルダに保存し、読み込み後に元ファイルを移動・削除しないようにします。
完全な設定には通常、ノードまたはノードプロバイダー、プロキシグループ、ルールなどが含まれますが、すべてのサブスクリプションがノードをメインファイルに直接記述しているとは限りません。リモートプロバイダーを使う場合は、関連リソースの更新を待つ必要もあります。そのため、設定の読み込み後にプロキシグループが空の場合は、まず他のリソースに依存しているか、その読み込みに失敗していないか確認してください。すぐに不明な項目を手動で追加するのは避けます。
読み込みに失敗したら、まずダウンロードと解析を切り分ける
タイムアウトや接続失敗が表示された場合は、現在のネットワーク環境でリンクを取得できるか、サブスクリプションがまだ有効かを確認します。YAML解析エラーや不明な項目が表示された場合は、エラーに含まれる項目名と行番号を記録してください。サーバーが返すログインページ、エラーページ、単純なノード一覧を、クライアントが設定として読み込んでエラーになることもあります。ブラウザーでURLを開けても、返された内容が利用可能な設定とは限りません。認証情報を含むリンクを公開サイトでテストするのも避けてください。
この段階では元のファイルを残し、クライアントのデータを急いで消去しないでください。提供元にサブスクリプション形式と対象コアを確認するか、サブスクリプションURL、完全なYAML、共有リンクの違いを参照して正しい入口を選びます。初回読み込み直後は、更新頻度の高い自動更新も有効にしないでください。設定が利用できることを確認してから更新周期を設定し、ローカル変更は独立した上書きに分けて管理します。次回更新で変更が上書きされるのを防ぐためです。
ステップ2：ルールモードとプロキシ出口を選択する
先ほど読み込んだ設定を選択したまま、ホーム、プロキシ、設定画面にある「モード」を探します。初回は「ルール」または「Rule」を選ぶのがおすすめです。このモードでは、設定内のルールに従って、接続を直接接続、プロキシグループ、拒否のいずれで処理するかをコアが決定します。振り分けルールを含む完全な設定に適しています。読み込んだ内容がノードだけで、ルールやプロキシグループを含まない場合は、モードを切り替えれば自動で振り分けが生成されると考えず、先に互換性のある設定を用意してください。
その他によく使われるモードは「グローバル」と「直接接続」です。グローバルモードは通常、コアに入った通信をグローバルポリシーで処理しますが、クライアントを迂回しているアプリまで自動的に取り込むことはありません。直接接続モードは、取り込み済みの接続を主に対象へ直接アクセスさせます。切り分けには役立ちますが、正しいルール設定の代わりにはなりません。モードの選択と通信の取り込みは別の段階です。グローバルを選んでも、システム上のすべてのプログラムがプロキシを使うわけではありません。
プロキシグループで実際に使う出口を確認する
ルールモードを選んだら、「プロキシ」または「プロキシグループ」画面を開きます。設定内のグループ名を確認し、通常のプロキシ通信を担当するグループを探します。「プロキシ選択」「Proxy」のほか、提供元独自の名前が使われている場合もあります。展開して、利用権限のある有効なノードを選択してください。グループ内に別のプロキシグループが含まれる場合は、現在の選択項目をさらに確認し、最終的にどのノード、自動選択グループ、直接接続ポリシーが使われるかを明確にします。
先頭に表示されているからという理由だけで項目を選ばないでください。特に DIRECT は直接接続を意味し、選択すると通常はリモートプロキシノードを経由しません。そのグループに一致する接続をプロキシ経由にしたい場合は、最終出口が直接接続になっていないことを確認します。自動選択グループは設定された検出ロジックで候補を選べますが、候補ノードが有効で、検出先に到達でき、クライアントが関連設定を正しく読み込んでいることが前提です。
画面に接続テストがある場合は、候補ノードを一度テストして、明らかに到達できない項目を除外します。テスト成功は、その時点で特定の検出リクエストが完了したことを示すだけで、すべてのWebサイト、プロトコル、アプリが正常に動作するとは限りません。テスト失敗も検出先が原因の可能性があります。初回設定では確認済みの出口を1つに固定し、自動でノードを切り替えながらルールを調べることは避けて、結果を比較しやすくします。
まず画面で設定し、項目の編集を急がない
この段階で「最適化」のためにDNS、TUN、ルール一覧を同時に変更する必要はありません。クライアントによっては画面設定やローカル上書きが、サブスクリプション内の同名項目を上書きします。そのため、ファイルに mode: rule と書かれていても、画面には別のモードが表示される場合があります。まずクライアントで最終的に有効なモードを確認してください。項目と画面の表示が長期間一致しない場合は、上書きと結合の説明を参照します。ルールモードとプロキシ出口を確認してから、次のシステム接続へ進みます。
ステップ3：接続して通信の取り込みを有効にする
まずクライアントのホームに戻り、コアが正常に起動できることを確認します。画面は開けても起動失敗が続く場合は、ログでポートの競合、設定の読み込み、権限エラーを確認してください。この状態でシステムプロキシを有効にすると、アプリが動作していないローカル入口を参照する可能性があります。コアが正常に動作し、設定が読み込まれてから、アプリの通信を渡します。
デスクトップ：まずシステムプロキシでブラウザーを確認する
Windows、macOS、または対応する連携機能を備えたLinuxのデスクトップクライアントで、「システムプロキシ」スイッチを探して有効にします。通常は、システムプロキシをローカルの待受アドレスとポートへ向けます。その後、OSのプロキシ設定で実際の値を確認し、アドレスとポートがクライアントの設定と一致しているか確認してください。クライアントがシステム設定へ自動反映できない場合は、表示されている実際の待受値を手動で設定し、他のチュートリアルにある固定ポートをそのまま使わないでください。
たとえば、クライアントが実際に混合ポート 7890 を使っている場合に限り、ローカルアプリのHTTPプロキシを 127.0.0.1:7890 に設定できます。ここでの数字は説明用の例であり、端末の現在の状態を検出したものではありません。クライアントがポートを変更した場合は、システムやアプリ側の設定も合わせて変更します。初回にローカルで使うだけなら、LANアクセスを有効にする必要はありません。確認のために待受入口を他の端末へ公開するのも避けてください。
システムプロキシは、設定に従うアプリの確認に適しています。一部のブラウザー拡張機能は独自のプロキシ設定を持ち、コマンドラインツール、ゲーム、アプリの中にはシステムプロキシを読み取らないものもあります。そのため、ブラウザーはアクセスできるのに特定のプログラムだけ失敗する場合は、まずそのプログラムの接続方式を確認し、ノード全体の障害と判断しないでください。Linuxでは、デスクトップ環境やアプリによってプロキシ設定の読み取り方が異なる場合もあります。
モバイル：接続ボタンでシステムの許可を完了する
AndroidまたはiOSのクライアントで、設定とプロキシグループを確認してからホーム画面の接続ボタンをタップします。初回は通常、OSが表示するVPN許可の確認画面が開きます。リクエスト元が、インストールしてこれから使うクライアントであることを確認し、案内に従って許可してください。クライアントに戻り、接続状態の切り替えが完了するまで待ちます。システムにVPNアイコンが表示されても、トンネルインターフェースが有効になったことを示すだけで、リモートノードへの到達性やすべてのルールが想定どおりであることを直接証明するものではありません。
接続できない場合は、他のVPNが接続枠を使用していないか、クライアントにアプリ単位の除外設定がないかを確認します。Android端末でロック画面やバックグラウンド移行後だけ切断される場合は、バックグラウンド動作とバッテリー制限を確認してください。初回からすべてのシステム権限を無制限に許可する必要はありません。iOSではまずシステムの許可手続きが完了していることを確認し、その後クライアントでエラー表示を確認します。同じサブスクリプションを何度も読み込むのは避けてください。
この段階が終わったらクライアントを動作させたまま、設定、ノード、接続方式を一時的に切り替えないでください。続いて新しい実際のリクエストで結果を確認し、同じ設定に基づいて観察できるようにします。
ステップ4：リクエスト、ルール、アクセス結果を確認する
ブラウザーを開き、新しいページで、アクセス権があり、プロキシルールに一致する想定のHTTPSサイトへアクセスします。すでに開いている古いタブだけを確認するのは避けてください。キャッシュ、接続の再利用、既存セッションによって画面は正常に見えても、新しい接続が発生していない場合があります。その後クライアントの「接続」または「ログ」画面に戻り、直前のリクエストに対応する対象ドメインと時刻を探します。表示項目はクライアントによって異なるため、実際に確認できる情報を基準にしてください。
確認は3段階で行います。リクエストがコアに入ったか、どのルールまたはプロキシグループに一致したか、接続が実際に完了したかを確認します。対象の記録が見つかったら、まず出口がステップ2で選んだものと一致しているか確認してください。直接接続ルールに一致している場合、Webサイトが開いてもプロキシノードが正常だとは証明できません。該当する記録がまったくない場合は、まずログのフィルター条件と記録範囲を確認し、その後アプリがシステムプロキシを迂回していないか、VPNの取り込み対象から除外されていないかを確認します。
プロキシ接続と直接接続を分けて確認する
次に、直接接続する想定のサイトへアクセスし、ルール上の処理結果を確認します。両方のリクエストが想定どおりなら、1つの出口IPだけを見るよりも、ルールの振り分けが正しいことを判断しやすくなります。出口IPの確認は補助的な情報です。ルールモードでは、照会サイトごとに異なるポリシーが適用される可能性があるため、1回の照会だけで全アプリの出口を判断できません。クライアントのログが簡易的な場合は、対象とノードを固定し、1つの設定だけを変更する前後で順に比較します。
Webページは開けるのに特定のアプリが使えない場合は、ステップ3に戻り、そのアプリのプロキシ設定、ブラウザー拡張機能、アプリ単位の除外項目を確認します。ログに解析エラーがある場合は、対象ドメインの名前解決に失敗したのか、ノードサーバーのアドレスを解決できないのかを切り分けてください。両者は発生箇所が異なるため、すべてをノードのタイムアウトと判断してはいけません。DNSの取り込みや漏洩確認は、システムの暗号化DNS、ブラウザーのセキュアDNS、TUNルーティングの影響も受けます。詳しい確認はDNS設定の章を参照し、今回は問題を再現できる記録を残してください。
失敗したら一度に変更する変数は1つだけにする
接続を有効にした後、すべてのWebページが開けなくなった場合は、まずシステムプロキシを無効にするか、クライアントのVPNを切断して、元から直接接続できたサイトをテストします。停止後に正常へ戻るなら、次はローカル待受、現在の設定、リモート経路を重点的に確認します。停止しても失敗する場合は、ローカルのネットワーク接続、ネットワーク認証、元のシステム設定を先に確認します。通信が復旧したら、サブスクリプションの有効性、ノードパラメーター、接続ログを順に確認し、クライアントの再インストールを最初の手段にしないでください。
特定のノードだけ失敗する場合は、同じ対象と同じモードを維持したまま、確認済みの別ノードに切り替えて比較します。特定のWebサイトだけ失敗する場合は、ノードを固定し、そのサイトに適用されたルールとエラー種別を確認します。「対象、時刻、使用ポリシー、エラー概要」だけを記録し、完全なサブスクリプションURLや認証情報は公開しないでください。さらに詳しい段階的な切り分けはノードタイムアウトの確認手順を参照してください。コアの読み込みに失敗した場合は設定の検証とトラブルシューティングを確認します。
利用可能な基準状態と終了方法を残す
プロキシ接続と直接接続の両方が想定どおりになったら、現在利用できる設定とローカル設定のバックアップを保存してから、自動更新、スタートアップ起動、複雑なルール変更を検討します。機能は毎回1つずつ追加し、問題が起きたらこの基準状態へ戻します。使用を停止する場合は、クライアントでシステムプロキシを無効にし、VPNを切断するかTUNを停止してから、プログラムを終了します。異常終了後にネットワークへ接続できない場合は、システムが停止したローカルポートを参照し続けていないか確認し、操作前に記録したプロキシ設定へ戻してください。