Clash設定ガイド：サブスクリプション導入から接続確認まで

Subscription

サブスクリプション設定を導入

まず、サブスクリプションサービスから提供されたURLを用意します。通常はhttps://で始まるリンクで、コピー用ボタンから取得するか、サービス提供者の管理画面でClash、Mihomo、または汎用サブスクリプション形式を選んで生成します。サブスクリプションURLは設定への入口となるため、使用前に出所の信頼性を確認し、フォーラムやスクリーンショット、公開文書にそのまま貼り付けないでください。本記事ではノード情報を手動編集しません。基本手順では、クライアントがこの設定にアクセスして解析できれば十分です。

クライアントを開き、Profiles、設定、サブスクリプション管理、またはProfiles管理という名前の画面を探します。デスクトップ版では通常、左側のナビゲーションに入口が表示され、モバイル版では先にメニューを開く場合があります。画面に入ったらサブスクリプションURLの入力欄を見つけ、URLを完全な形で貼り付け、普段使いの設定や個人用サブスクリプションなど識別しやすい名前を付けます。名前は複数の設定を区別するためだけのもので、サブスクリプションの内容は変わりません。入力欄に余分な空白や改行がないことを確認し、保存、追加、または導入をクリックしてください。

保存すると、サブスクリプションは通常、設定一覧に表示されます。ここですぐにシステムプロキシをオンにせず、まず一覧のステータスを確認してください。初めて追加した設定には、更新待ち、未有効化、名前のみなどと表示されることがあります。これはノードがすでに使えることを意味しません。項目の横にある更新ボタンをクリックするか、詳細画面を開いて更新を実行します。クライアントはサブスクリプションURLにアクセスし、設定をダウンロードしてYAMLの内容を解析します。更新中はネットワーク接続を維持し、タイムアウトした場合は少し待ってから一度だけ再試行してください。

更新に成功すると、一覧に更新日時、設定サイズ、ノード数、利用可能状態などが表示されます。表示項目はクライアントによって異なりますが、重要なのは設定ファイルをサブスクリプションURLから取得でき、現在のコアで解析できることです。続いて、この設定の有効化、現在の設定にする、またはアクティベートのボタンをクリックし、実行中の設定にします。この操作を完了して初めて、後続のプロキシグループとモードが更新内容を読み込みます。

更新に失敗した場合は、まずサブスクリプションURLが完全にコピーされているか確認し、現在のネットワークからURLを開けるか確かめます。ブラウザではアクセスできるのにクライアントで解析に失敗する場合、返された内容がClash互換形式でないか、サービスが一時的にエラーページを返している可能性があります。利用可能な元の設定は残し、設定ファイルを何度も削除しないでください。インストールと設定に関する問題の確認手順を参考に、形式、権限、更新日時を点検します。設定を有効化できたら、2つ目の手順でプロキシモードを選択します。

Mode selection

プロキシモードを選択

設定ファイルを有効化したら、クライアントの実行モード、Mode、またはプロキシモード画面を開きます。一般的な選択肢はRule、Global、Directで、日本語またはローカライズされた画面ではルール、グローバル、ダイレクトなどと表示される場合があります。これらは接続をどの経路で処理するかを決めるもので、ノード自体がオンラインかどうかを決めるものではありません。初めて使う場合は、まずRuleモードを選ぶのがおすすめです。多くのサブスクリプション設定にはドメイン、アドレス、フォールバックルールが含まれており、普段の通信を設定どおりにプロキシグループへ振り分けられるためです。

Ruleを選択したら、Proxies、プロキシ、またはプロキシグループ画面に戻ります。ここにはProxy、ノード選択、自動選択、地域別グループなど、1つ以上のプロキシグループが表示されます。まず最上位のプロキシグループを開き、選択可能なノードやポリシーがあることを確認してください。グループが空の場合は、1つ目の手順に戻り、現在の設定が本当に更新されているか確認します。ノードはあるのにすべて利用できない場合は、クライアントの遅延テスト、接続ログ、サブスクリプションサービスの状態を確認し、空のグループをモード設定の誤りと決めつけないでください。

Globalモードは短時間の診断に適しています。ほとんどのリクエストを現在選択しているプロキシポリシーへ直接渡すため、ルールマッチによる変数を減らせます。Ruleモードで特定の宛先を開けない場合は、一時的にGlobalへ切り替え、明確に利用可能なノードを選んでテストします。Globalでは接続できるのにRuleでは接続できない場合、問題は通常、ノードそのものではなくルール、プロキシグループ、またはDNS処理にあります。テスト後はRuleへ戻し、日常の通信がすべて同じポリシーを経由しないようにしてください。

Directモードではプロキシを介さずに接続するため、ローカルネットワークが正常か確認したり、同じアドレスを直接接続とプロキシ経由で比較したりするのに適しています。Directへ切り替える前に現在のモードを覚えておき、テスト後はRuleへ戻してください。モード、ノード、システムプロキシのスイッチを同時に変更すると、結果が変わってもどの設定が原因か判断しにくくなります。モードの詳しい動作、ルールのマッチ順、プロキシグループの関係は、初心者から上級者向けマニュアルのルール振り分け章で確認できます。

Ruleが選択され、プロキシグループに明確なノードまたはポリシーが設定されていることを確認できれば、2つ目の手順は完了です。この時点ではクライアントが処理経路を準備しただけで、システム通信をまだ取り込んでいない場合があります。次はノード接続とシステムプロキシのスイッチを個別に確認します。デスクトップ環境とモバイル環境で操作の違いが最も大きい部分です。

Connection

プロキシ接続を確立

まず、プロキシグループからノードまたは利用可能なポリシーを選択します。画面に遅延テストがある場合は個別のノードをテストできますが、遅延値はテスト先とその時点での結果にすぎず、すべてのウェブサイトにアクセスできることを示すものではありません。ノードを選択したら、ハイライト、チェックマーク、選択中の表示が現れるか確認します。グループが自動選択に設定されている場合は、自動ポリシーが実際にメンバーを選んだことを確認してから次へ進みます。

次にGeneral、一般、システムプロキシ、またはSystem Proxy画面を開きます。WindowsとmacOSのクライアントには通常、システムプロキシのスイッチがあります。オンにすると、システムプロキシ設定に従うブラウザやアプリがClashのローカルポートを使用します。スイッチをオンにしたら、HTTP、SOCKS、または混合ポートも表示されているか確認してください。一般的な設定ではローカルアドレス（例：127.0.0.1）を待ち受けますが、ポート番号は現在のクライアント画面に表示されたものを使用し、他のガイドの数字をそのまま使わないでください。

Androidでは通常、クライアントがシステムVPNの権限を使って通信を取り込みます。起動、接続、VPNを許可などをタップすると、システムのステータスバーに鍵やVPNのマークが表示されることがあります。初回起動時にはシステムの権限確認画面が表示されるため、現在インストールしているクライアントであることを確認して許可を選びます。iOSクライアントもシステムネットワーク拡張の権限を要求するため、接続状態はクライアントとシステム設定の両方で確認します。モバイル端末ではバッテリー最適化、バックグラウンド制限、ネットワーク切り替えが接続の継続性に影響するため、断続的に切断される場合はこれらの環境要因も考慮してください。

TUNモードは、より深いレベルで通信を取り込む方式です。システムプロキシに従わないアプリの通信やUDPを処理したい場合、またはより多くのシステム接続をコアに渡したい場合に適しています。基本設定の段階で最初からTUNを有効にする必要はありません。まずシステムプロキシでブラウザを確認し、サブスクリプション、ノード、モード、ローカルポートが正常であることを確かめてから、必要に応じてTUNを有効にします。有効化時はシステム権限の案内を読み、プラットフォームによっては管理者権限やネットワーク拡張のインストールが必要です。有効化後にネットワーク異常が起きた場合は、まずTUNを無効にして既知の状態へ戻し、その後ルーティングとDNSを調べてください。

ノードを選択してシステムプロキシをオンにしたら、すぐに複数のノードを切り替え続けないでください。数秒待ってクライアントが接続を確立し、ログを生成してから4つ目の手順へ進みます。システムプロキシのスイッチがオンのままにならない場合は、別のVPN、プロキシツール、システム管理ポリシーが設定を上書きしていないか確認します。クライアントは動作中なのにブラウザの接続記録がまったくない場合は、ブラウザが独自のプロキシ設定を使用していないかを優先的に確認してください。

Verification

プロキシの動作を確認

確認は3段階で行います。まずクライアント自体が動作していること、次にアプリのリクエストがローカルポートへ届いていること、最後にルールとノードが想定どおり処理していることを確認します。普段アクセスできる一般的なウェブページを開き、正常に読み込まれるか見ます。ページを開けることは基礎ネットワークが利用できることを示すだけで、リクエストがプロキシを経由した証明にはなりません。クライアントに戻り、接続記録を確認してください。多くのクライアントでは、Connections、接続、ログ、アクティブなリクエストなどの画面にドメイン、ルール結果、プロキシグループが表示されます。

接続記録から、先ほど開いたウェブページのリクエストを探し、表示されているか、結果がProxy、Direct、その他のポリシーのどれになっているか確認します。記録がまったくない場合、アプリのリクエストがClashへ渡っていません。まずシステムプロキシがオンか、ブラウザに個別のプロキシ設定がないか、クライアントの待受アドレスが別のネットワークインターフェースだけにバインドされていないか確認してください。記録がありDirectと表示されても、必ずしも異常ではありません。中国本土でよく使われるサイトやサブスクリプション内の直結ルールは、もともとDirectを選ぶことがあります。その場合は、設定上プロキシを経由するはずのテスト先に変更するか、ルール詳細でマッチした経路を確認します。

接続記録でリクエストがProxyに入っているのにページを読み込めない場合は、まず現在のプロキシグループで選択しているノードを確認し、次にログのエラー種別を調べます。接続タイムアウト、リモート側による切断、TLSハンドシェイク失敗、DNS名前解決失敗では対処方法が異なります。まず別のノードに切り替えて比較できますが、1回につき変更する条件は1つにしてください。すべてのノードで失敗する場合は、システム時刻、ネットワークの切り替え、サブスクリプションの更新日時、クライアントコアのログを確認します。特定のドメインだけ失敗する場合は、そのドメインのルールマッチ、DNS設定、対象サービスの状態を確認してください。

リクエスト経路を確認したら、次にローカルポートを確認します。クライアントの設定画面には通常、HTTP、SOCKS、Mixed Portが表示されます。ブラウザに手動でプロキシを設定する場合は、現在表示されているアドレスとポートを使い、プロトコルの種類を一致させてください。システムプロキシモードでは通常、クライアントがこれらの値を自動設定します。ポートが別のプログラムに使用されていたり、設定画面のポートとログ上の実際の待受ポートが一致していなかったりすると、スイッチがオンに見えてもアプリは接続できません。その場合はクライアントを再起動し、同じプロキシプログラムが複数起動していないか確認します。

最後に独立したネットワーク情報ページで出口情報を確認し、プロキシ有効化前後の結果を比較します。1つのページに表示される地域だけで判断せず、クライアントの接続記録、ルールマッチ、現在のノード状態も合わせて確認してください。より多くのアプリを処理したい場合は、TUNを個別にテストします。TUNの確認では対象アプリを1つずつ開き、接続記録が現れるか観察してください。最初から多数のアプリを起動すると、異常の切り分けが難しくなります。確認が終わったら、現在有効な設定名、モード、プロキシグループ、ポート設定を記録しておくと、サブスクリプション更新やクライアント変更後もすぐに復元できます。

4つの手順を終えても接続できない場合は、最後に動作を確認できた設定へ戻し、単一ノード、Globalによる一時テスト、Directとの比較テストをやり直してください。よくある問題のページにはサブスクリプション解析、ポート、DNS、ルールのトラブル対処への入口があります。設定項目、コアの機能、TUNの仕組みを詳しく知りたい場合は、初心者から上級者向け完全マニュアルへ進んでください。基本手順の途中で高度な項目を一度に変更しすぎないことが大切です。