Clashの設定方法
サブスクリプションの追加と接続確認

ステップ1：サブスクリプションを追加して設定を有効化

まずクライアントを開き、「サブスクリプション」または「設定」の画面を探します。必要なのはサービス提供元が発行したサブスクリプションURLです。アカウント管理画面のログインURLや、ブラウザーで開く購入ページではありません。サブスクリプションには通常、ノードやプロキシグループ、ルールが含まれますが、内容は提供元によって異なります。クライアントは設定を読み込んで使用するソフトウェアであり、インストールしただけで利用可能なノードが自動的に作られるわけではありません。

提供元のサブスクリプション画面でClashまたはmihomo互換の形式を選び、URL全体をコピーします。クライアントに戻り、「新規作成」「インポート」またはプラス記号の項目からURLでのインポートを選択し、サブスクリプションURL欄に貼り付けます。名前は「日常用」など、用途を区別しやすいものにします。名前は一覧で見分けるためのもので、接続先は変わりません。URLの前後に空白や改行がないことを確認してからインポートしてください。

ダウンロードと解析が終わるまで待ちます。成功すると、設定一覧に新しいカードや項目が表示されます。自動で有効になるクライアントもあれば、カードやラジオボタンを選択したり、「この設定を使用」を押したりする必要があるものもあります。設定が選択済みであることを確認し、「プロキシ」画面にプロキシグループが表示されるか確認してください。インポート成功の表示だけを見て、設定の選択を忘れるのは初回によくあるミスです。

サブスクリプションURLとローカル設定ファイル

.yamlまたは.ymlファイルを受け取った場合は、「ファイルからインポート」を選び、ファイル選択画面から開いてください。ファイルの内容をURL欄に貼り付ける方法ではありません。インポート後は設定の有効化も必要です。通常、ローカルファイルはリモートサブスクリプションのように自動更新されません。リモート設定の自動更新はファイルの内容やクライアントの実装によるため、両者を同じものとして扱わないでください。

インポート時に形式エラーが表示されたら、取得した内容が本当に設定ファイルか確認します。URLによってはログインページや有効期限切れの案内、特定のクライアント専用形式が返されることがあります。ダウンロードに失敗する場合は、現在のネットワークからサブスクリプションサーバーに接続できるか、URLの有効期限が切れていないか確認してください。ノードがまだクライアントに読み込まれていない可能性があるため、ダウンロード失敗だけでノードが使えないと判断しないでください。

初回の設定では、サブスクリプションの内容を変更せず、ルールやDNSもすぐには編集しないでください。問題が起きたときに、サブスクリプション自体の異常か、ローカルでの変更が原因かを切り分けやすくなります。設定ファイル、サブスクリプション、プロキシグループの関係は用語クイックガイドで確認できます。まず設定が有効になり、プロキシ画面に項目が表示されていることを確認したら、次に進みましょう。

ステップ2：プロキシモードとノードを選択

クライアントの「プロキシ」または「アウトバウンド」画面を開き、「ルール／グローバル／ダイレクト」のモードを探します。初めて使う場合は「ルール」がおすすめです。ルールモードでは、現在の設定に基づいて接続ごとに振り分け先を決めます。すべての通信が同じノードを通るわけではなく、モードを選んだだけで想定どおりに振り分けられるわけでもありません。実際の結果は設定内のルールによって決まります。

モードを切り替えたら、サブスクリプションに含まれる主要なプロキシグループを展開します。グループ名は「ノード選択」「プロキシ」などさまざまで、統一されていません。グループ内にノードが並んでいる場合は、まず手動で1つ選びます。「自動選択」や別のプロキシグループが表示されている場合は、さらに展開して実際の接続先を確認してください。選択状態はチェックマーク、枠線、ハイライトなどで示されます。選択後に表示が変わったことも確認しましょう。

クライアントに遅延テスト機能があれば、一度実行して明らかにタイムアウトする候補を除外できます。ただし、測定値が示すのは指定されたテスト先と方法での応答状況だけです。ダウンロード速度を表すものではなく、すべてのサイトにアクセスできる保証にもなりません。候補ノードを1つ選び、後続の接続確認を行ってください。ノード、モード、ネットワークを続けて切り替えると、どの変更が影響したのか判断しにくくなります。

ルールモードではプロキシグループを先に確認する

設定によっては、よく使うサイトやメディアサービス、その他の通信が別々のグループに振り分けられます。グループを1つ変更しても、テスト中のサイトには影響しないことがあります。ルールが専用のプロキシグループを参照している場合、メインのプロキシグループで選んだ接続先は、そのアクセスに関係しない可能性があります。今はルールを1行ずつ編集する必要はありません。各グループの選択状態を確認し、対象のグループがDIRECTや利用できないノードを選んだままになっていないか見てください。

グローバルモードと比較する場合は、切り替え後にグローバル用プロキシグループを確認してください。ルールモードのノードが引き継がれるとは限りません。テスト後はルールモードに戻します。モードの変更が影響するのは、すでにコアに渡された接続だけです。プロキシの接続口を使っていないアプリの通信が、自動的にクライアントへ入ることはありません。次に適切な接続口を有効にします。カスタムルールの優先順位やプロトコルの互換性については、プロトコルガイドを参照してください。

ステップ3：システムプロキシまたはモバイル接続を有効化

設定が有効になり、接続先も選択できましたが、アプリの通信をクライアントに渡す設定がまだ必要です。まずホーム画面やステータス画面でコアが起動中か確認します。クライアントに独立した起動ボタンがある場合は、先に起動してからプロキシを有効にしてください。設定の読み込み失敗、ポート競合、コアの終了が発生している場合は、そのエラーを解決してから操作します。システムプロキシを何度もオンにしても解決しません。エラーの文面をもとによくある質問で対処方法を探してください。

デスクトップではまずシステムプロキシを有効にする

Windows、macOS、LinuxのGUIクライアントで「システムプロキシ」を探して有効にします。ホーム画面に切り替えがあるクライアントもあれば、設定画面やトレイメニューにあるものもあります。有効にすると、システムプロキシ設定に従うブラウザーやアプリがクライアント経由での接続を試みます。まず通常のブラウザーで新しいページを開いてテストしてください。最初からゲーム、コマンドラインツール、独自のプロキシ設定を持つアプリで判断するのは避けましょう。

ネットワーク設定や補助サービスの変更許可を求められた場合は、起動したクライアントからの要求であることを確認してから許可します。クライアントが起動していないときに、手動でクライアントのシステムプロキシアドレスを設定したままにしないでください。アプリが存在しない待ち受けポートに接続することになります。テスト中は、複数のプロキシツールがシステム設定を取り合わないよう、システム設定を操作するツールを1つに絞ってください。

AndroidとiOSでは、通常アプリ内の「接続」や起動スイッチを操作します。初回はシステムVPN構成の許可を求められます。許可したらクライアントに戻り、接続済みと表示されることと、システムのVPN状態表示を確認してください。ここでのVPN許可はシステムが通信を取り込むための入口であり、ノードのプロトコルが従来型VPNに変わるという意味ではありません。同じ種類の接続口を使う別のアプリがある場合は、先に接続を切ってから試してください。

必要な場合に限りTUNを有効にする

ブラウザーは使えるのに、システムプロキシ設定に従わないアプリがある場合は、TUNの利用を検討できます。仮想ネットワークインターフェースを通じて、ルーティング条件に合う通信を取り込みます。通常は管理者権限やクライアントサービスが必要です。設定でサービスがインストール済みで正常に動作していることを確認してから、クライアントの案内に沿ってTUNを有効にしてください。サービスの設定方法はOSによって異なるため、他のプラットフォームのメニュー手順をそのまま使う必要はありません。

TUNは初回設定で必須ではなく、すべてのアプリやネットワーク環境の通信を取り込める保証もありません。ルーティングやDNSとの連携も関係します。有効化後にインターネットへ接続できなくなったり、LAN内のデバイスにアクセスできなくなったりした場合は、まずTUNを無効にし、動作確認済みのシステムプロキシの状態に戻してから互換性を確認してください。初回の切り分けでは、仮想ネットワークアダプター、DNS、アウトバウンドモードを同時に変更せず、いつでも戻せる基準の状態を保つことが重要です。

この手順が終わると、ステータス画面ではコアの起動、設定の有効化、プロキシ接続口の有効化がそろっているはずです。スイッチの色だけでは成功と判断できません。次の手順で実際のリクエストがクライアントに届いているか、どのプロキシグループを通ったか確認します。

ステップ4：実際のアクセスとルール適用を確認

まず、サブスクリプションのルール上プロキシ経由になる想定のサイトを開き、新しいタブで再読み込みします。ブラウザーのキャッシュに残った古い内容だけを見て判断しないためです。次にクライアントへ戻り、「接続」または「アクティブな接続」の画面を開いて、アクセスしたドメインを探します。接続がすぐに終了する場合は、ページを更新しながら一覧を確認するか、最近の接続記録を表示してください。

該当する接続を開き、適用されたルール、振り分け先のプロキシグループ、最終的に選択されたアウトバウンドノードの3点を確認します。ルールモードで一部の接続がDIRECTと表示されても、必ずしも異常ではありません。接続先が本来ダイレクト接続になるものか確認してください。同様に、システムにVPNと表示されたり、クライアントに「起動中」と表示されたりしても、コンポーネントが動作していることを示すだけです。個々のリクエストの経路確認にはなりません。

次に、設定上ダイレクト接続になる想定のアドレスを開き、2つの接続結果を比較します。どちらも想定どおりなら、今回のテストでは通信の取り込み、ルール、接続先が一通り機能しています。出口IPの確認は補足情報として利用できますが、確認サイトへの接続経路しか示しません。すべてのアプリが同じ出口を使っていると判断する根拠にはなりません。重要な操作を行う場合は、対象アプリの接続記録も個別に確認してください。

現象に応じて該当する手順を確認する

ウェブページを開けず、クライアントにも該当するリクエストがまったく表示されない場合は、システムプロキシが有効か、ブラウザーに独自のプロキシ設定がないか、現在使用中のクライアントを確認しているかを調べます。コマンドラインツールがシステムプロキシを参照しないのはよくあることです。サブスクリプションをすぐに変更せず、ツールが対応するプロキシオプションを使うか、TUNの利用を別途検討してください。

接続がクライアントに届いているのに、ログにタイムアウトやハンドシェイクエラーが記録される場合は、同じプロキシグループ内の別のノードに切り替え、同じ接続先を再テストします。ルールモードでは失敗するのにグローバルモードでは正常な場合は、各モードで実際に選ばれた接続先と適用されたプロキシグループを比較してください。ルールや選択先を調べる手がかりにはなりますが、この現象だけで特定のルールが誤っているとは断定できません。

エラーがドメイン名の解決を示している場合は、エラーが出たドメイン名と現在の通信取り込み方法を記録してから、トラブル対処ガイドに沿ってDNSを確認します。ネット上で見つけたDNS設定をそのまま一式上書きしないでください。コアやモードによって設定項目が異なり、サブスクリプション本来の設定を損なう可能性があります。Fake-IP、DNSの解決ルール、コアごとの差異は用語クイックガイドとプロトコルガイドで確認できます。まずは基本的な接続を復旧させましょう。

動作確認後の設定保存と更新

アクセスが正常にできたら、現在の設定名、モード、主要なプロキシグループの選択内容、システムプロキシとTUNのどちらを使っているかを記録しておきます。その後は設定を1つずつ変更し、同じ接続先を再テストしてください。問い合わせ用のスクリーンショットには、エラー文、OS、クライアント名を残し、サブスクリプションURLと認証情報は隠します。赤いエラー表示だけの画像より、こうした情報があるほうが原因を特定しやすくなります。

リモートサブスクリプションを更新する場合は、ステップ1の設定一覧に戻り、「更新」または再読み込みの項目を使います。完了を待って、設定が引き続き選択されていることと、プロキシグループの選択が保持されていることを確認してください。自動更新のタイミングはクライアントとサブスクリプションの設定によって異なります。更新が長期間ないからといって、ノードが永久に変わらないわけではありません。画面上でリモート設定を直接編集した場合は、次回の更新で変更が上書きされる可能性にも注意してください。

最後に、通常の切断手順を一度テストします。システムプロキシまたはモバイル接続を先に無効にしてからクライアントを終了し、通常のネットワーク接続に戻ったことを確認してください。OS起動時に自動起動したい場合は、設定が安定してから有効にし、次回ログイン時にコアとプロキシ接続口の両方が起動していることを確認します。これでサブスクリプションの追加、モード選択、通信の取り込み、実際の動作確認まで一通り完了です。ルールの調整は必要に応じて行ってください。