Clash完全ガイド｜サブスクリプション・ルール・TUN設定

第1章 · 基本概念と接続の流れ

クライアント・コア・設定の役割

Clashエコシステムのクライアントは、通常GUIとプロキシコアで構成されています。GUIは設定のインポート、プロキシグループの表示、システムプロキシやログの管理を担当し、コアはローカルポートでの待ち受け、ルール判定、接続の確立を担います。mihomoは、このエコシステムで広く使われているコアの一つです。画面や名称が似ていても、搭載コアや対応フィールド、権限の仕組みまで同じとは限りません。設定を移行する前に、移行先クライアントの説明を確認しましょう。

設定ファイルはコアが動作するための指示書で、一般にYAML形式で保存されます。ローカルの待ち受けポート、利用可能なプロキシ、プロキシグループ、ルーティングルール、DNSの動作などを記述します。サブスクリプションは通常、リモート設定を取得するためのURLであり、クライアントそのものでも、オンにすればすぐ使えるサービスでもありません。有効な設定を取得して有効化し、アプリの通信がコアに届いて初めて、ルールやプロキシの選択が機能します。

ノード・プロキシグループ・ルールの関係

ノードは具体的な接続先と接続パラメーターを表し、プロキシグループはノードや別のプロキシグループをまとめる仕組みです。手動選択や定期的なテストによる自動選択などがあります。ルールは接続をどの出口へ送るかを決めます。特定のサイトで問題が起きたら、設定全体を何度も切り替えるより、まず接続ログで適用されたルールと転送先グループを確認し、次にグループ内で選択中のノードを調べると原因を絞り込みやすくなります。

ブラウザーからのアクセスは、一連の処理として考えるとわかりやすくなります。アプリがシステムプロキシまたは独自の設定を読み取り、リクエストをローカルの待ち受けポートへ送ります。コアは取得できるドメイン名やアドレスとルールに基づいて出口を決め、選ばれたノードが接続先と通信します。どの段階でも失敗する可能性があります。ブラウザーにタイムアウトと表示されても、わかるのは通信が完了しなかったことだけです。その表示だけで、サブスクリプションの無効化、DNSの異常、サーバー停止のいずれかに断定はできません。

項目	役割	確認場所
設定プロファイル	実行設定一式を保存する	設定一覧で現在有効な項目
プロキシグループ	出口をまとめて選択する	プロキシまたはノードの画面
接続ログ	適用ルールと実際の出口を確認する	接続画面、コアのログ

システムプロキシとTUNは別の仕組み

システムプロキシは、アプリが参照するOSの設定であり、すべてのプログラムに適用されるわけではありません。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、追加の権限やDNS・ルート設定が関わります。初回はシステムプロキシでブラウザーの接続を確認しましょう。システムプロキシを通らないアプリがあると確認できてからTUNを検討すれば、基本設定が動かない段階で複数のネットワーク動作を同時に調べずに済みます。

ローカルポートも区別が必要です。混合ポートはHTTPとSOCKSのプロキシリクエストを受け付けますが、コントロールインターフェースはクライアントがコアを管理するためのものです。両者は互換性がありません。ブラウザーのプロキシ先にコントロールインターフェースのアドレスを入力すると、通常は接続エラーになります。普段はクライアントによるシステムプロキシの自動設定を使い、別の端末のポート番号をそのまま使わないでください。手動で入力する場合は、現在の実行設定に表示された値を確認します。

最後に、2種類の「更新」を区別しましょう。クライアントの更新はプログラムやコアを置き換え、サブスクリプションの更新はリモート設定を取得します。クライアントを更新しても期限切れのサブスクリプションが必ず復旧するわけではなく、サブスクリプションを更新してもプログラムのバージョンは上がりません。問題を記録するときはこの2つを分け、障害発生前に最後に接続できた条件も残してください。以降の章でトラブルを調べる際の重要な基準になります。

第2章 · OSに合わせたクライアント選び

まずデバイスを確認し、次に画面や機能を比較

クライアント選びでは、まずOS、CPUアーキテクチャ、通信を取り込みたいアプリを確認し、その後で画面や操作の好みを比較します。初めてインストールする場合は、まずダウンロードページのClash Plusをお試しください。設定管理の方法、デスクトップとの連携、コア設定の場所を比べたい場合は、クライアント比較をご覧ください。画面例にある特定のスイッチを探すために、複数のネットワーク制御ツールを同時にインストール・起動するのは避けましょう。

Windowsでは「設定 → システム → バージョン情報」でシステムの種類を確認し、CPUアーキテクチャを調べます。macOSでは「このMacについて」でチップまたはプロセッサ名を確認してください。Apple Silicon用とIntel用のインストーラーは、ファイルサイズだけでは見分けられません。ダウンロードページに表示された対応アーキテクチャから選び、デバイスが対象外の場合は、まずサポート状況を確認しましょう。他のプラットフォーム向けのパッケージをリネームして実行するのは避けてください。

プラットフォーム	おすすめと代替候補	選ぶ際のポイント
Windows	Clash Plus；Clash Verge Rev、FlClash、Clash Nyanpasu	アーキテクチャ、サービスの動作、プロキシの復元
macOS	Clash Plus；Clash Verge Rev、FlClash	チップのアーキテクチャ、システム権限
Android	Clash Plus；Clash Meta for Android、FlClash、Surfboard	設定形式、バックグラウンド動作
iOS	Clash Plus	ストアからの入手、VPNの許可
Linux	Clash Verge Rev；FlClash	ディストリビューションのパッケージ形式、デスクトップ環境

見た目より設定の互換性を重視

同じプラットフォームでも、クライアントによって設定の扱いは異なります。サブスクリプションとは別に上書き設定を重ねるもの、ローカルファイルを直接編集するもの、特定の形式だけを受け付けるものがあります。特にSurfboardは、同じダウンロードページに掲載されているからといって、任意のClash YAMLをそのまま読み込めるとは限りません。ネットワークの問題と誤認しないよう、まずクライアントが対応する設定形式を確認し、設定の提供元から適切な形式のデータを入手してください。

デスクトップで設定を頻繁に切り替える場合は、プロキシグループの表示、上書き設定の入口、ログのエクスポート、終了時のプロキシ復元動作などを比べましょう。モバイルでは、接続状態の表示、バックグラウンド制限、アプリごとの通信取り込み方法が特に重要です。機能が多ければよいとは限りません。インポート、接続確認、検証、終了後の復元を安定して行えるクライアントを、以降の設定テストに使う環境として選びましょう。

iPhoneではダウンロードページからClash PlusのApp Storeページへ進めます。製品の説明は公式サイト clashplus.ioでも確認できます。入手後は、まず設定一覧と接続の操作場所を確認してから、システムへのVPN構成追加を許可してください。iOSのバックグラウンド動作やネットワーク権限はOSが管理するため、サービスのインストール、システムトレイ、ローカルポートなどデスクトップ向けの手順をそのままスマートフォンに適用することはできません。

アーカイブ済みクライアントと単体コア

Clash for WindowsとClashX Metaは、本サイトではメンテナンス終了済みのアーカイブクライアントとして掲載しています。既存環境との互換性を調べる用途には使えますが、新規インストールにはおすすめしません。古いガイドに表示される画面があっても、現在も同じ手順でインストールすべきという意味ではありません。新しいデバイスでは、まずメンテナンス中のクライアントを選び、ガイドの概念を現在のメニューに当てはめると、権限や設定の互換性に関する問題を減らせます。

mihomo単体コアは、プロセス、設定ディレクトリ、ネットワークルールを自分で管理したいユーザー向けです。デスクトップGUIの代わりとなる完全なインストーラーではなく、起動しただけでOS連携機能がすべて利用できるわけでもありません。サーバーやルーターなどでは、起動サービスやアクセス制御も整える必要があります。一般的なデスクトップ利用ではGUIクライアントを使うと、プロセス監視やシステムルートの詳細より、設定そのものに集中できます。

クライアントを移行するときは、まず旧クライアントのシステムプロキシとTUNを無効にして終了し、その後で新しいクライアントを起動します。意味を理解している設定、ルール、上書き設定だけを移行し、内容が不明な実行ディレクトリはコピーしないでください。移行後はポート、プロキシグループの選択、DNSの動作を再確認します。同じサブスクリプションでも、クライアントごとに異なるデフォルト設定が適用され、接続結果が完全には一致しない場合があります。

第3章 · インストール・権限・初回起動

インストール前に現在のネットワーク設定を整理

インストールを始める前に、使用中のプロキシクライアントを終了し、通常のネットワークでブラウザーにアクセスできるか確認してください。以前に手動プロキシを設定していた場合は、アドレスとポートを記録し、無効にする必要があるか判断します。インストール後に問題が起きても、元からあったネットワークの問題か、新しい設定による変化かを切り分けやすくなります。職場や学校が管理するデバイスでは管理規則に従い、組織の設定を回避してシステムサービスをインストールしないでください。

クライアントのダウンロードページから、OSとアーキテクチャに合ったファイルを選びます。Windowsではインストールウィザードに従ってセットアップし、スタートメニューから起動してください。macOSでディスクイメージを入手した場合は、開いて案内に従い、アプリを「アプリケーション」フォルダへ移動してから起動します。展開先の一時フォルダやディスクイメージから使い続けると、アップデート、補助サービスのパス、ログイン時の起動設定に不整合が生じることがあります。

権限の要求を必要な機能と照らし合わせる

初回起動時は、まずメイン画面、設定一覧、ログの場所を確認し、すべての権限をすぐ許可しないようにしましょう。通常の設定インポートと、システムレベルで通信を取り込む機能では必要な権限が異なります。TUNやサービスモードでは管理者の確認が必要な場合がありますが、通知権限は主に状態表示に関わります。許可する前に、OSの確認画面に表示されたアプリ名と操作内容を確認してください。見覚えのないプログラムから要求された場合はキャンセルし、インストール元と実行中の操作を確認しましょう。

macOSでアプリを開けない、またはシステム拡張に関する警告が表示された場合は、まずファイルの入手元を確認し、システム設定の「プライバシーとセキュリティ」などで具体的な理由を確認して、OSが案内する方法で対処してください。デバイス全体のセキュリティ機能を無効にすることを、通常のインストール手順にしないでください。キーチェーンやネットワーク拡張の許可は、通常のサブスクリプションのインポートとは別の操作です。警告が繰り返し表示される場合は、アプリが元のインストール場所にあるか、補助コンポーネントが正しくインストールされているか確認しましょう。

Androidでは、インストール後にクライアントへ設定をインポートして接続をタップし、OSに表示されるVPN接続の確認を読みます。長時間の利用中にOSがアプリを頻繁に停止する場合は、バッテリーやバックグラウンド管理でアプリの制限を確認してください。最初から省電力設定をすべて変更する必要はありません。OSによっては通常のVPNサービスを同時に1つしか動かせないため、別のVPNアプリを起動すると現在の接続が切れることがあります。これは必ずしもクライアント自体の障害ではありません。

iOSでも、VPN構成の追加をOSに許可する必要があります。許可したらクライアントに戻り、設定が選択されていることを確認してから接続してください。Linuxでは、まずディストリビューションに対応するパッケージ形式を確認し、デスクトップのソフトウェアインストーラーまたはディストリビューションのパッケージ管理ツールでインストールして、不足している依存関係の内容を確認します。デスクトップアプリの起動失敗とコアの設定エラーは分けて対処しましょう。前者はアプリの起動エラーを確認し、後者は設定とログを調べます。

初回起動後の確認手順を決める

サブスクリプションがない状態で、メイン画面に未接続や空のプロキシグループが表示されるのは通常の動作です。まず設定、プロキシ、接続、ログの4画面を見つけ、プログラムが設定を保存できることを確認します。次にローカルの待ち受けポートを確認し、システムプロキシとTUNが有効か記録してください。初回テストではシステムプロキシだけを有効にし、他の通信取り込み機能はオフのままにすると、次章でサブスクリプションを検証する際に原因を追いやすくなります。

Windowsでは、PowerShellから指定したポートの待ち受け状況を確認できます。次の数字は確認対象のポート例にすぎないため、クライアントの実際の設定に合わせて変更してください。プロセスが見つかったら、タスクマネージャーでプログラムを特定してから正常に終了します。見覚えのないシステムプロセスを直接終了しないでください。ポートが待ち受けていないことは、ネットワークが必ず使えないという意味ではなく、検索範囲に該当する待ち受け項目が見つからなかったということです。

Get-NetTCPConnection -LocalPort 7890 -State Listen

最後に終了後の復元をテストします。システムプロキシとTUNをオフにしてクライアントを終了し、通常の直接接続が想定どおり使えるか確認してください。終了後もブラウザーにプロキシサーバーが利用できないと表示される場合は、ローカルを指すプロキシ設定がOSに残っていないか調べます。まずネットワークの入口を元に戻してからクライアントを再起動しましょう。接続トラブルの後で慌ててスイッチを探すより、インストール時に復元手順まで確認しておくほうが確実です。

第4章 · サブスクリプションの導入と設定の適用

サブスクリプションURLと実際の設定を見分ける

サブスクリプションURLは通常、設定サービスの提供元が発行します。個人を識別できる情報が含まれる場合があるため、機密情報として管理してください。URL全体を公開スクリーンショット、オンライン変換サイト、問い合わせに貼り付けないでください。本サイトでは設定の使い方を解説しており、継続利用できる公開サブスクリプションは提供していません。「Clash 無料ノード」などで検索する場合も、配布元、有効期間、データ上のリスクを確認し、一時的に入手した設定を安定した日常利用の基盤にしないようにしましょう。

URLを入手したら、クライアントの「設定」「サブスクリプション」またはProfile画面を開き、新しいリモート設定を追加します。URL欄にアドレスを貼り付け、用途がわかる名前を付けてから、インポートまたはダウンロードを実行してください。名前には「日常用」などを使い、アクセス識別情報は含めないようにします。完了後は、ダウンロード待ちの空の項目だけでなく、設定項目、更新日時、利用可能なプロキシグループのいずれかが表示されていることを確認します。

ダウンロード後に有効化する

インポートに成功しても、実行中の設定に切り替わったとは限りません。設定一覧で取り込んだ項目を選び、「有効化」「使用」などのボタン、または選択マークを操作します。その後プロキシ画面で、グループ名や選択肢が変わったか確認してください。クライアントによってはコアが自動で再読み込みされ、別途確認が必要な場合もあります。画面に古いプロキシグループが表示される場合は、すぐに再インストールしたり同じサブスクリプションを何度も追加したりせず、設定画面で有効状態を確認しましょう。

ローカルYAMLのインポートは、既存ファイルを使う場合やオフラインで編集する場合に適しています。「ファイルからインポート」を選び、圧縮ファイル、Webページを保存したファイル、スクリーンショットではなく、設定ファイルそのものを選んでください。リモート設定は通常、更新を取得できますが、ローカルファイルは主にユーザー自身が管理します。ディスク上の元ファイルを編集した内容がクライアントに反映されるかは、参照方式かコピー方式かによって異なります。小さな変更と再読み込みで確認しましょう。

インポート時に形式エラーが表示されたら、まずエラーの位置と応答内容を確認します。サブスクリプションURLがログイン画面、アクセス制限の案内、サービス期限切れのページを返す場合があります。これらはYAMLではないため、ブラウザーで開けてもコアでは使えません。貼り付け時に空白、改行、日本語の句読点が混ざっていないかも確認してください。サブスクリプション管理ページのURLを実際の設定URLとして使わないようにしましょう。両者は異なることがよくあります。

YAMLの構造と記述ルール

YAMLではインデントで階層を表し、通常はタブではなくスペースを使います。同じ階層のフィールドは位置を揃え、リスト項目のハイフンも一貫した位置に置いてください。以下は基本設定の一部を示す例で、利用可能なプロキシは含まれていません。このままではサブスクリプション全体として接続できません。トップレベルのフィールドを見分けるための例です。mode、ログレベル、待ち受け設定は同じ階層にあり、プロキシノードの内部にインデントしてはいけません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

サブスクリプションを更新する前に、クライアントが設定をどのように保存するか確認してください。リモート設定を直接編集すると、次回の更新で変更が上書きされることがあります。長期的に残したいローカル変更は、クライアントが対応する上書きまたはマージ機能に追加します。最初は複雑な上書きを加えず、元のサブスクリプションが正常に読み込まれ接続できることを確認してから、カスタム設定を一つずつ追加しましょう。編集画面だけを見て反映済みと判断せず、最終的に有効な設定を毎回確認してください。

自動更新の間隔を短くしすぎないようにし、通常は提供元の推奨に従って設定します。頻繁に更新してもサービスの停止は解消せず、アクセス制限を受ける可能性もあります。更新に失敗した場合は、最後に使えた設定をすぐに削除せず、内容を保持したまま取得処理だけを個別にテストしてください。タイムアウト、空の応答、形式エラーを切り分けるには、サブスクリプションの解析エラー・セルフチェックリストを参考に、段階を追って確認しましょう。

同じサブスクリプションが旧クライアントでは使えて新クライアントでエラーになる場合は、設定全体を公開して質問するのではなく、まず対応フィールドと設定形式を比較してください。設定をエクスポートして、ノードアドレス、認証情報、サブスクリプション識別情報を隠します。エラー周辺の構造とメッセージだけを残せば、インデント、未対応フィールド、形式の互換性を判断するのに十分な場合がほとんどです。

第5章 · プロキシモードと接続の検証

入口と出口を分けて確認

クライアントの「ルール」「グローバル」「ダイレクト」は、主にコアに届いた通信の出口を選びます。システムプロキシとTUNは、アプリの通信がコアに届くかどうかを決めます。モードをグローバルにしても、すべてのアプリが自動的に取り込まれるわけではありません。検証時は、まずクライアントの接続画面を開き、ブラウザーからテスト対象へアクセスして、新しい接続が表示されるか確認します。接続ログが確認できてから、モードやノードの選択を調べましょう。

モード	選択方法	確認すること
Rule	ルールの順にポリシーを選択	日常の振り分けとルールの確認
Global	グローバル用のプロキシグループを使用	出口が利用可能か確認
Direct	直接接続で通信	通常のネットワーク経路と比較

日常利用では、まずルールモードから始めるのが一般的です。プロキシ画面で主要な選択グループを見つけ、利用可能とわかっているノードを手動で選んでから、システムプロキシを有効にします。テスト中はブラウザーとURLを固定し、接続できるかを確認した後、接続の詳細で適用ルールと実際の出口を調べます。ノードのテストに成功しても、あるテストリクエストが完了したことを示すだけです。あらゆるサイト、プロトコル、長時間接続が正常に動く保証にはなりません。

グローバルモードで範囲を限定して比較

ルールモードで特定の接続に失敗した場合は、一時的にグローバルモードへ切り替え、グローバルグループで実際に選択されているノードを確認できます。同じ入口とノードでグローバルなら接続でき、ルールモードでは失敗する場合は、適用ルールと対象のプロキシグループを重点的に確認します。両方のモードで失敗するなら、ノード、名前解決、上流ネットワークを調べましょう。比較が終わったらルールモードに戻し、以降のテストが一時設定のままにならないようにしてください。

ダイレクトモードにしても、OSの状態が完全に元へ戻るわけではありません。アプリからローカルプロキシポートを経由してコアに通信が届く場合があり、DNSや通信の観測方法もクライアントの影響を受けることがあります。クライアントを完全に終了した状態のネットワークを確認するには、システムプロキシとTUNをオフにしてから終了し、別途テストしてください。「コア経由の直接接続」と「クライアントを完全に終了した状態」を別のテスト条件として扱えば、問題の範囲を誤って判断せずに済みます。

接続ログがない場合は段階的に調査

ブラウザーでアクセスしても新しい接続ログが出ない場合は、システムプロキシが実際に有効か、プロキシのアドレスが現在の待ち受けポートを指しているか確認します。ブラウザー拡張、独自のプロキシ設定、アプリ内のネットワーク設定がシステム設定より優先される場合があります。別のクライアントがシステムプロキシを変更した可能性もあります。不要なプロキシ拡張を一時的に無効にし、クライアントを一つだけ起動してリクエストを再実行し、接続画面に変化があるか確認しましょう。

ログはあるのに接続できない場合は詳細を開き、対象ドメイン、ポート、ポリシーの経路、エラー内容を確認します。タイムアウト、接続拒否、名前解決失敗は、それぞれ問題の層が異なるため、すべてを「ノードを変更」で済ませないでください。同じ対象を2つの設定済み出口で比較し、次に同じ出口から2つの対象を比較します。一度に変える条件を一つにすれば、接続先サービスの制限、特定ノードの問題、ローカル設定の問題を区別しやすくなります。

コマンドラインのプログラムは、デスクトップのシステムプロキシを参照するとは限りません。ローカルHTTPプロキシを個別に検証する場合は、次のリクエストを使えます。アドレスとポートは実際の実行設定に合わせてください。例のドメインはテスト方法を示すためのもので、現在のネットワークから必ずアクセスできるとは限りません。レスポンスが返っても、指定した入口で今回のリクエストが処理されたことを示すだけです。ブラウザーや他のアプリの接続ログ確認に代わるものではありません。

curl --proxy http://127.0.0.1:7890 --head https://example.com/

モードやノードを切り替えても、既存の接続は以前の出口を使い続ける場合があります。新しい設定を確認するにはリクエストを新たに送信してください。必要であれば該当する接続だけを閉じるか、テスト用アプリを再起動すればよく、OSのネットワーク設定をすべてリセットする必要はありません。ブラウザーのキャッシュ、接続の再利用、オフラインのページ内容も誤判断の原因になります。すでに開いているページが表示され続けるかではなく、新しく確立した接続とその時刻に注目しましょう。

この章を終えるときは、使用中のクライアント、有効な設定、選択したグループとノード、通信の入口、接続できた対象を簡潔に記録してください。次章でルールを変更したら、同じ条件で再テストします。速度の問題が特定の状況だけで起きる場合は、接続速度を段階的に切り分ける方法も参考にしてください。DNS、モード、サブスクリプション一式を同時に変更するのは避けましょう。

第6章 · ルールによる振り分けと設定順序

上から順に評価し、最初に一致したルールを適用

ルールモードでは、接続を上から順にルールと照合し、通常は最初に一致したルールのポリシーが適用されます。より具体的な例外は広い範囲のルールより前に、フォールバック用のルールは最後に配置します。ルールを追加しても効果がない場合は、まず上のルールが先に一致していないかを確認し、次に対象名とプロキシグループを調べてください。同じルールをリストの末尾に何度コピーしても、先行ルールに捕捉済みの接続には影響しません。

ドメインルールはサービス名による振り分けに、アドレス範囲のルールは明確なIPネットワークの処理に適しています。ドメインサフィックスルールは指定したドメインとそのサブドメインに一致します。安易にキーワードルールへ置き換えると、対象範囲が広がる場合があるため注意してください。アプリからコアにドメイン名が渡されるかどうかも、ドメインルールの適用に影響します。接続画面にIPアドレスしか表示されない場合は、DNSの動作も踏まえて判断し、すぐにルール構文の誤りと決めつけないようにしましょう。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

次のルールは、設定の一部をマージする例であり、完全なプロキシ定義ではありません。DIRECTは組み込みの直接接続ポリシーです。PROXYは、実際の設定にあるプロキシまたはプロキシグループ名と完全に一致させる必要があります。その名前がなければ、既存のグループ名に変更してください。最後のMATCHは、それまでのルールに一致しなかった接続を受け持つため、他のルールより前に置いてはいけません。コピーする前に自分のグループ名を確認し、例の記述が整っているからといって設定全体を置き換えないでください。

アドレスルールと名前解決の範囲

アドレス範囲ルールのプレフィックス長はネットワークの範囲を表し、ポート番号ではありません。例のプライベートアドレス範囲は、LANを直接接続する考え方を示すものです。家庭や職場のネットワークが同じ範囲を使っているとは限らないため、ゲートウェイとデバイスのアドレスを確認してください。範囲の広いパブリックIPアドレスを安易にダイレクト接続の一覧へ追加しないでください。広すぎる条件が意図した通信より先に一致し、一部のサイトが断続的に使えなくなることがあります。

no-resolveは、ルールの一致判定のためにドメインの名前解決を新たに行わない設定です。DNS全体を無効にするものではありません。接続に宛先IPがすでに含まれている場合は、引き続きアドレス範囲を判定できます。指定するかどうかは、ルールの目的と名前解決の方針によって決まります。名前解決後のアドレスで振り分けたい場合は、追加の名前解決が及ぼす影響を理解してください。もともとIPアドレスでアクセスする通信だけを処理したい場合は、不要な名前解決を減らせます。

リモートルールセットとローカル上書き

ルールが増えたら、コアが対応するルールプロバイダーで、リモートまたはローカルのルールセットを管理できます。ルールセットの内容形式は、宣言した種類と一致させる必要があります。たとえばドメイン一覧と完全なルール一覧は互換ではありません。ファイルをダウンロードできても、解析できるとは限りません。参照名、キャッシュの場所、更新日時も確認してください。リモート取得に失敗して古いキャッシュが使われているのに、新しいルールが読み込まれたと誤認するのを防げます。

GUIクライアントでは、サブスクリプションのルール、ローカル上書き、マージスクリプトを組み合わせて最終設定を生成する場合があります。エディター上の順序が、コアが実際に読み込む順序とは限りません。変更後は最終設定または実行設定のプレビューを開き、対象の項目を検索して位置とポリシー名を確認します。その後、接続画面で実際に適用されたルールを確認してください。「編集、プレビュー、再読み込み、検証」の流れを守るほうが、保存成功の表示だけを見るより確実です。

アプリへのログインとWebページのアクセスで出口が異なる場合は、まず実際の接続先を確認してください。一つの操作で認証、リソース、APIなど複数のドメインへ通信することがあり、アドレスバーに表示されたメインドメインだけにルールを追加しても解決しない場合があります。接続ログで必要な接続先を一つずつ確認し、対象範囲を絞ったルールを優先してください。一度の失敗を直すためにすべての通信をグローバルへ切り替えると、ルールの不足が隠れるだけで、原因の説明や解決にはなりません。

ルールのメンテナンスでは、項目数を増やすより動作を説明できることが大切です。カスタム例外には目的と削除する条件を記録し、不要になったら整理します。サブスクリプションに同じルールが含まれる場合は、上書きを重ねる必要があるか検討してください。この章を終えたら、接続先、適用ルール、ポリシーの経路から出口を説明できる状態を目指しましょう。ページが開くかどうかだけで振り分け結果を推測する必要はありません。

第7章 · TUN・DNS・ルーティングによる通信の取り込み

TUNを有効にする理由を明確に

TUNは仮想ネットワークインターフェースを使って通信を取り込み、システムプロキシに従わないアプリに使われます。速度を上げるボタンではなく、無効なノードや誤ったサブスクリプションを修正する機能でもありません。まず第5章のシステムプロキシで接続できることを確認し、対象のアプリが本当にコアへ通信を送っていないか判断しましょう。ブラウザーのプロキシ拡張の設定ミスであれば、入口を修正すればよく、仮想NIC、システムルート、DNSの取り込みを追加する必要はありません。

有効にする前に、現在のネットワークインターフェース、他のVPNの状態、クライアントを終了する方法を記録してください。デスクトップでは補助サービスのインストールや権限の昇格が必要な場合があり、モバイルではOSのVPNインターフェースが管理します。まずはクライアントに用意されたTUNスイッチと既定の設定を使いましょう。GUIで通信の取り込みを有効にしながら、サーバー向けガイドを参考にシステムルートを手動追加すると、ルールが重複したり元に戻しにくくなったりするおそれがあります。

fake-ipとローカル名前解決を理解する

fake-ipモードでは、ドメイン名に対応するアドレスを返し、コアがドメインと接続の対応を管理することで、その後の振り分けを行いやすくします。これらのアドレスは接続先サーバーの実際のパブリックIPではないため、Webサイトの所在地やノードの経路を判断する用途には使えません。実際のアドレス、ローカルデバイスの検出、特定の検証動作に依存するアプリには例外が必要な場合があります。分流をすべて無効にするのではなく、クライアントとコアが対応するフィルター機能を使って調整してください。

LANプリンター、ファイル共有、社内ドメインは、特に注意してテストしてください。ローカルDNS、特定のネットワーク範囲へのルート、ブロードキャストによる検出に依存する場合があり、パブリックなドメインルールだけでは解決できません。TUNを有効にしたら、ゲートウェイ、LAN上のデバイス、よく使う社内サービスを確認してから外部の接続先をテストします。内部リソースだけに問題がある場合は、ダイレクト接続のルートと名前解決の経路を調べ、すぐにすべてのプロキシノードを原因と考えないでください。

競合の見つけ方と安全な復元

別のVPN、仮想マシンのネットワーク、コンテナブリッジ、セキュリティソフトもルーティングを変更することがあります。すべてのアプリが同時に切断された場合は、まずTUNをオフにして元のネットワークが復旧するか確認し、その後で競合する要因を一つずつ調べましょう。複数のNICがある環境では、自動検出された出力インターフェースが意図と異なることがあります。特に有線と無線を同時に有効にしている場合は注意してください。手動で指定するときは、他のデバイスの例をコピーせず、現在の端末に実在する名前を使います。

ブラウザーは使えても特定のアプリで失敗する場合は、アプリのプロトコルと接続先ポート、ノードがその通信方式に対応しているかを確認します。UDP通信が動作するかどうかは、ノードの能力、コアの設定、上流ネットワークにも依存します。TUNを有効にしても、対応していない機能が補われるわけではありません。接続詳細でリクエストが取り込まれたか、どのプロトコルが使われたか、どの段階でエラーになったかを調べてから、通信の取り込み範囲を調整するか、別の出口を試すか判断してください。

テストの最後に復元手順を一度確認します。TUNをオフにし、仮想インターフェースと自動ルートの状態がクライアントの想定どおりか確認してから、システムプロキシの基準状態に戻してください。スリープからの復帰、Wi-Fiの切り替え、LANケーブルの抜き差しの後も、出力インターフェースと名前解決が正常か再確認します。日常的な状況で安定してからTUNを常用しましょう。安定しない場合は、より単純な通信経路のほうが管理しやすくなります。

第8章 · 更新・バックアップ・トラブル対応

復元可能な設定の基準を保存

安定して動作したら、現在のクライアント、有効な設定、主要なプロキシグループの選択、システムプロキシとTUNの状態を記録し、必要なローカル上書きを保存します。バックアップはサブスクリプションURLのコピーだけではありません。自分で作成したルールと、そのマージ方法も含めてください。リモートサブスクリプションは再取得できても、ローカルの変更には別のコピーがない場合があります。クライアントを再インストールする必要があるときは、プログラムファイルを処理する前に設定をエクスポートしましょう。

バックアップにはノードの認証情報、サブスクリプション識別情報、コントロールインターフェースの設定などが含まれることがあります。管理された保存場所に保管し、公開リポジトリや公開クラウドストレージへアップロードしないでください。スクリーンショットやログから接続先やデバイスのパスが漏れる場合もあるため、共有前に該当箇所を隠します。トラブル対応に必要なのは設定の構造、エラー、発生順序であり、アカウント情報全体ではありません。必要最小限の情報に絞ると、問題も説明しやすくなります。

更新は3つの操作に分ける

クライアントのアップグレード、コアの更新、サブスクリプションの再取得は、別々に実行して個別に検証してください。まず現在の正常な状態を記録し、操作を一つだけ行った後、設定が読み込めるか、よく使う接続先にアクセスできるかを確認します。それから次の操作へ進みましょう。プログラム、コア、サブスクリプション、DNSを一度にすべて変更すると、問題が改善しても本当の原因がわからず、次に同じ問題が起きたときに復元しにくくなります。

アップグレード前に変更内容を読み、特に設定フィールド、サービスモード、デフォルト動作の変更を確認してください。バージョン番号だけで現在の環境に適しているか判断したり、最新版を追うためにクライアントのコアファイルを安易に置き換えたりしないでください。GUIクライアントによってはコアとの連携が必要です。手動でコアを置き換えると、コントロールインターフェースや設定生成に互換性の問題が出る場合があります。クライアントが正式に提供する更新方法を優先し、復元に必要なローカル設定を残してください。

範囲を絞って障害を切り分ける

問題が起きたら、まず影響範囲を確認します。すべてのアプリか一つだけか、すべての接続先か特定のドメインだけか、現在のネットワークだけか、ネットワークを切り替えても同じかを調べます。その後、第5章で作った基準に戻り、設定と出口を固定して比較してください。接続先が一つだけ失敗する場合は、ルール、接続先サービス、出口の制限を重点的に確認します。すべてのリクエストでログが出ない場合は入口とプロセスを、ログに名前解決エラーが集中する場合はDNSを調べましょう。

症状	最初に確認すること	記録しておく情報
設定を読み込めない	形式、フィールド、ポリシーの参照	エラー行と解析メッセージ
接続ログがない	入口、ポート、プロキシの競合	システムプロキシと実行状態
一部の接続先だけ失敗	適用ルール、出口、名前解決	接続先とポリシーの経路
終了後にアクセスできない	残存プロキシとルート	終了前後の設定変更

詳細なログが必要な場合は、一時的にログレベルを上げ、最小限の操作を一度だけ再現して正確な時刻を記録し、作業後に通常のレベルへ戻します。デバッグログを長期間有効にすると、保存や検索の負担が増え、アクセス情報がより多く残る可能性もあります。数時間分のログをそのまま担当者へ渡さず、障害の前後に関係する部分を選び、期待した動作、実際の動作、すでに実施した比較テストを説明してください。

速度低下と接続不能は分けて調査します。ダウンロードの状況、Wi-Fiの電波、デバイスの負荷、通信事業者の経路、接続先の混雑など、さまざまな要因が体感速度に影響します。一度のノードテストで継続的な通信速度は判断できません。同じテスト対象、近い条件、固定した出口を使い、ノードやネットワークを変えたときの差を比較してください。一度の自動測定の順位だけを見て頻繁に切り替えると、長時間の接続が途切れるおそれがあります。

復元の手順と継続的な整理

重大な問題が起きたら、まずTUNとシステムプロキシをオフにして基本のネットワークを復元し、最後に使えた設定を読み込みます。サブスクリプションの更新が原因であれば、保存しておいたローカルコピーと比較してください。カスタム上書きが原因なら、そのレイヤーだけ一時的に無効にし、クライアント全体を削除しないでください。プログラムファイルまたはユーザーディレクトリが破損していると確認できた場合に限って再インストールを検討し、削除前に必要な設定を保存しましょう。

使わなくなったサブスクリプション、無効なルール、重複した自動起動項目を定期的に整理し、古いクライアントが常駐していないか確認します。複数の設定の用途、切り替え方法、更新方針に疑問がある場合は、Profileと複数設定の管理ノートをご覧ください。日々パラメーターを調整することではなく、変更を記録し、問題の証拠を残し、明確な手順で復元できる状態にすることがメンテナンスの目的です。

第9章 · 安定した設定から応用管理へ

設定一式をコピーする前にプロキシグループを学ぶ

応用設定は、動作を確認済みの設定から始めます。まずプロキシグループ同士の参照方法を理解し、次に自動選択やフェイルオーバーを学びましょう。不明なルール、スクリプト、リモートリソースが大量に含まれる設定一式を、いきなりコピーするのは避けてください。機能を追加するたびに、何を解決するのか、どんな条件に依存するのか、どう検証し、どう取り消すのかを説明できるようにします。説明できなければ、設定の複雑さだけが増えて、後のトラブル対応が難しくなります。

手動選択グループは出口を明示的に制御したい場合に適しています。自動テストグループは指定したテスト先を使って候補ノードを比較し、フェイルオーバーグループは独自の方式で利用可能な項目を選びます。テスト先は確認したい接続状況を代表するものにしてください。ただし、すべてのサービスを代表できるアドレスはありません。ノードのテストが成功しても、動画、ゲーム、業務サービスが使えない場合は実際の通信を確認し、テスト結果だけで総合的な正常性を判断しないようにしましょう。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    use:
      - daily
    url: https://example.com/
    interval: 600

この例は、dailyという名前のプロキシプロバイダーに依存しているため、完全な設定内でその定義が必要です。プロキシグループの部分だけをコピーしても、ノードは表示されません。テスト用アドレスも、実際の到達性と用途に合わせてください。PROXYはAUTOを参照します。通信がAUTOへ渡されるのは、選択時に限られます。画面に自動選択グループが表示されていても、すべての接続が自動的にそのグループを使うわけではありません。

プロバイダーと上書き設定の管理範囲を理解する

プロキシプロバイダーを使うと、ノードの取得元とローカルのポリシーを分けて管理できます。ルールプロバイダーでは、ルールの内容をメイン設定から分離できます。どちらもリモート取得、キャッシュ、形式の互換性に関わるため、用途がわかる名前を付けて個別に管理してください。リソースのダウンロードに失敗した場合は、まず利用可能なキャッシュがローカルにあるか確認してから、起動に影響があるか判断します。まだ確立していない同じプロキシ経路にすべてのリソースを依存させると、起動時の依存関係が循環するおそれがあります。

上書き設定は個人のポリシーを保存するのに便利ですが、マージの動作はクライアントによって異なります。リストを置き換える場合もあれば追加する場合もあり、マージ後にスクリプトが内容を変更することもあります。どのクライアントでも同じ順序になるとは限りません。複雑な設定を変更する前に、識別しやすいグループやルールを一つ追加して、最終設定内の位置と内容を確認する小さなテストを行いましょう。最初から検証しにくい大規模な処理を書くのは避けてください。

コントロールインターフェースとLANアクセス

外部コントロールインターフェースはコアを管理するためのもので、通常のプロキシ入口とは権限上の意味が異なります。リモート管理が不要な場合は、ローカル端末からのみアクセスできる状態にし、すべてのネットワークインターフェースで安易に待ち受けないようにしてください。LANからの管理が必要な場合は、認証、OSのファイアウォール、接続元の制限を設定し、管理画面とインターフェースのセキュリティ境界を確認します。画面が開かないからといって、すべてのアクセス制御を無効にしたり、インターフェースをインターネットに公開したりしないでください。

LAN向けプロキシを有効にする場合も、待ち受けアドレス、ポート、接続するデバイス、ファイアウォールをあわせて確認します。allow-lanを変更するだけで他のデバイスが接続できるとは限らず、すべてのネットワークに公開すべきという意味でもありません。信頼できるネットワークでまず1台のデバイスを使ってテストし、プロキシの入口とコントロールインターフェースの違いを確認しましょう。そのネットワークを離れるときや公衆Wi-Fiへ切り替える前に、不要になった共有機能を無効にしてください。

再現可能なテスト方法を確立

応用設定のテストでは、元の設定とコピー、変更内容の記録を必ず残し、通常のWebページ、振り分けが必要な接続先、LANサービス、終了後の復元を含む固定テストを用意します。DNS、ルール、TUNのいずれかを変更したら、毎回このテストを行い、適用ルールとエラーの変化を記録してください。結果が想定どおりの場合だけ変更を残します。ページがたまに開くことだけを、設定が正しい唯一の判断基準にしないでください。

これ以上パラメーターを追加する必要はありません。新しいデバイスで基本の手順を再現する場合は、クイックスタートガイドに戻ってください。クライアントを変更する場合は、ダウンロードページとクライアント比較をご覧ください。個別の状況については技術ノートを参照してください。安定した動作を土台に、明確な目的のある変更だけを応用設定として加えることで、設定を長期にわたって理解しやすく、管理しやすい状態に保てます。

Clashの使い方・設定完全ガイド