Clash / Mihomo 設定メモ

Clashをゼロから使いこなす使用ガイド

基本概念から始め、クライアントの選択、インストール、サブスクリプションの読み込み、プロキシモード、ルール分岐、TUN、DNS、日常メンテナンスまで順に進めます。初回接続をすぐに完了したい場合は、まずクイックスタートガイドを確認してください。設定がなぜ有効になるのか、トラブルをどの層から確認すべきかを理解したい場合は、本ページの各章を順に読み進めてください。

順番どおりに学べる構成 Windows · macOS · Android · iOS · Linux ルール · DNS · TUN · メンテナンス

第1章

基本概念：接続がどこを通るかを把握する

クライアント、コア、設定ファイルの役割分担

Clashのエコシステムは通常、3つの要素で構成されます。GUIクライアントはボタン操作、設定管理、システム権限を担当し、Mihomoなどのコアはポートの待ち受け、ルールの解析、プロキシ接続の確立、通信の転送を担当します。設定ファイルにはノード、プロキシグループ、ルール、DNS、TUNのパラメータを記述します。画面上で「システムプロキシ」や「TUNモード」をオンにすると、実際にはクライアントがシステムのネットワーク設定を変更し、対応するパラメータをコアに渡して実行させています。この関係を理解しておけば、トラブル解決で画面上の接続スイッチだけを確認することがなくなります。画面に「実行中」と表示されても、コアのプロセスが起動していることを示すだけで、サブスクリプションの有効性、適切なポリシーの選択、DNSの正常性、対象アプリがプロキシ経路に入っていることまでは保証しません。

GUIクライアントとコアは、同じバージョンという概念ではありません。クライアントの更新は通常、画面、プラットフォーム対応、設定管理機能を改善します。一方、コアの更新はプロトコル、ルールの挙動、DNS、ネットワークスタックに重点があります。クライアントによってはコアの更新機能を内蔵し、別のクライアントではインストールパッケージと一緒にコアを配布します。日常利用で毎回の更新を追いかける必要はありませんが、設定項目を認識できない、プロトコルのハンドシェイクに失敗する、新しいOSとの互換性に問題があるといった場合は、クライアントとコアを別々に確認し、両者を1つの「Clashのバージョン」として扱わないでください。

通信の入口、ポリシー判定、出口

典型的な接続は4段階に分けられます。第1段階では、ブラウザーやアプリがシステムプロキシのポートへリクエストを渡すか、TUN仮想インターフェースによって取り込まれます。第2段階では、コアが対象ドメイン、IP、プロセス、ネットワーク種別を解析します。第3段階では、ルールを上から順に照合し、リクエストをプロキシグループへ送ります。第4段階では、プロキシグループが具体的なプロキシノード、DIRECT、REJECTのいずれかを選びます。どこか1段階が途切れるだけでも、表面上はウェブページを開けない状態になります。システムプロキシが有効でない場合は入口の問題、ルール順序が誤っている場合は判定の問題、ノードが利用できない場合は出口の問題です。DNSの応答異常は、判定より前に発生している可能性があります。

よく使われる待ち受けポートには、HTTP、SOCKS5、mixed-portがあります。HTTPポートはHTTPプロキシに対応したアプリに適し、SOCKS5ポートはSOCKS対応のツールに適しています。mixed-portは1つのポートで両方のリクエストを受け付けます。多くのGUIクライアントがこれらのポートを管理するため、一般ユーザーが自分で変更する必要はありません。ポートが別のプログラムに占有されている、LAN内の端末から接続したい、コマンドラインツールでプロキシを手動指定したい場合に、現在の待ち受けアドレスとポートを確認します。待ち受け先が127.0.0.1の場合は本体からのみアクセスできます。LANアクセスを許可すると接続可能な範囲が広がるため、ファイアウォールとアクセス制御も同時に確認してください。

設定、サブスクリプション、実行状態は別のもの

サブスクリプションはリモートで管理される設定ソース、設定ファイルはクライアントがダウンロードしてローカルに保存した具体的な内容、実行状態はコアが特定の設定を読み込んだ結果です。サブスクリプションURLへ正常にアクセスできても、返された内容が現在のコアの構文に合うとは限りません。設定を解析できても、含まれるノードが無効になっている場合があります。ノードで接続を確立できても、ルールによって対象リクエストがDIRECTへ送られることがあります。確認は「サブスクリプションの更新成功—設定の読み込み成功—プロキシグループに選択肢があるか—リクエストが想定ルールに一致したか—出口が利用可能か」の順に行ってください。層ごとに確認する方が、メインスイッチを何度も切り替えるより早く解決できます。

層 担当する内容 よくある症状 優先して確認する項目
クライアント 画面、権限、システム設定 スイッチを有効にできない、起動直後に終了する インストール元、システム権限、ログ
コア 待ち受け、照合、転送 ポートが存在しない、設定の読み込みに失敗する コアのログ、ポート占有、構文
設定 ノード、プロキシグループ、ルール、DNS 選択できるノードがない、ルールの挙動が異常 サブスクリプションの更新日時、設定内容
システムネットワーク 通信がプロキシへ入る経路 ブラウザーは使えるが他のアプリは使えない システムプロキシ、TUN、アプリのプロキシ設定

この章を終えたら、まず「接続の問題は単一のスイッチの問題ではない」という判断原則を覚えておいてください。以降の設定はすべて、「入口、判定、出口」という経路に戻して理解します。Windows、macOS、Android、iOS、Linuxのいずれを使っていても、画面上の名称が異なるだけで、トラブル解決の順序は共通にできます。

第2章

クライアントの選び方：プラットフォーム、権限、メンテナンス方法で決める

コアを直接動かすより、まずはGUIクライアントを選ぶ

一般的なデスクトップやモバイル端末では、GUIクライアントを優先してください。設定の保存、システムプロキシ、スタートアップ、ログ表示、コアの起動・停止、権限要求をまとめて処理でき、問題が起きたときも現在の状態を確認しやすくなります。本サイトでは各プラットフォーム向けにClash Plusを第一候補としており、サブスクリプションの読み込み、プロキシ切り替え、基本的な通信の取り込みを統一された画面で行いたいユーザーに適しています。WindowsとmacOSではClash Verge Rev、FlClashも選択できます。WindowsではClash Nyanpasuも利用でき、現在メンテナンスが終了しているClash for Windowsはアーカイブ用の選択肢として残しています。macOSには、すでにメンテナンスが終了しているClashX Metaもあります。クライアントの一覧、各プラットフォームの入口、現在のインストールパッケージはダウンロードページで確認してください。

Androidでは、Clash Plus、Clash Meta for Android、FlClash、Surfboardから選べます。モバイルでは、画面の見た目だけでなく、システムVPN権限、バックグラウンド実行の制限、省電力設定を確認する必要があります。iOSではClash PlusのApp Store版を使用し、VPN設定を通じて通信を取り込みます。Linuxのデスクトップ環境ではClash Verge RevまたはFlClashを利用できます。サーバー、ルーター、コンテナ、デスクトップ環境のない端末では、Mihomoコアを直接配置し、設定ファイルで管理する方法が適しています。

選ぶときに確認したい3つの条件

1つ目はシステムアーキテクチャです。Windowsではx64が一般的ですが、一部の端末はARM64です。Appleチップ搭載MacではApple SiliconまたはARM向けパッケージ、古いIntel Macではx64パッケージを選びます。Linuxではディストリビューションの形式に加えてCPUアーキテクチャも確認し、AMD64、ARM64、ARMv7、MIPSのパッケージを混用しないでください。アーキテクチャが不明な場合は、ファイル名で推測せず、先にシステム情報で確認します。インストールパッケージをダウンロードできても起動できない場合、アーキテクチャの不一致は最初に確認すべき項目の1つです。

2つ目は、通信を取り込みたいアプリの範囲です。ブラウザーやシステムプロキシに従うプログラムだけをプロキシ経由にするなら、通常のシステムプロキシで十分です。ゲーム、コマンドラインツール、ストアアプリ、仮想マシン、システムプロキシ設定を参照しないソフトウェアでは、TUNが必要になる場合があります。3つ目はメンテナンス方法です。デスクトップユーザーは通常、画面からサブスクリプションを更新し、プロキシを選択できることを求めます。サーバーユーザーは設定ファイル、サービスプロセス、リモートログ、自動再起動を重視します。機能が最も多いクライアントが必ずしも安定するとは限りません。現在の要件を満たし、更新経路が明確で、ログを読みやすいことの方が重要です。

利用シーン 推奨する選択肢 重点的に確認する項目
Windows / macOSの日常的なデスクトップ利用 Clash Plusを優先し、Clash Verge Rev、FlClashも比較 アーキテクチャ、システムプロキシ、TUN権限
Androidスマートフォンまたはタブレット Clash Plus、Clash Meta for Android、FlClash、Surfboard VPN許可、バックグラウンド制限、省電力設定
iPhone / iPad Clash Plus App Store版 VPN設定、オンデマンド接続、システムネットワーク
Linuxデスクトップ Clash Verge RevまたはFlClash ディストリビューション形式、デスクトップ権限、アーキテクチャ
サーバーとルーター Mihomoコア 設定パス、サービス管理、ルーティング、ファイアウォール

複数のクライアントでシステム通信を同時に取り込まない

同じ端末に比較用として複数のクライアントをインストールすることはできますが、システムプロキシやTUNを同時に有効にしないでください。2つのコアが待ち受けポートを奪い合ったり、2つのクライアントがシステムプロキシ設定を交互に書き換えたりすると、画面上は有効に見えても、実際のポートが別のプロセスを指すことがあります。クライアントを切り替える前に、古いクライアントのシステムプロキシとTUNを無効にし、プロセスが終了したことを確認してから新しいクライアントを起動してください。新しいクライアントがポート占有を通知した場合は、ランダムにポートを変更し続けるのではなく、占有しているプロセスを特定します。ブラウザー、環境変数、他のツールが古いポートを参照している可能性があるためです。

アーカイブ済みのクライアントは、古い設定との互換性維持や一時的な移行には適していますが、新規インストールの標準としてはおすすめできません。メンテナンス終了後も既存のインストールがすぐに使えなくなるわけではありませんが、OSの更新、プロトコルの変更、コアの項目更新によって互換性の問題が徐々に発生する可能性があります。移行時は、まずローカルの追加ルール、プロキシ選択、ポート設定を記録し、新しいクライアントでサブスクリプションを読み込みます。古いコア、キャッシュ、システム連携の状態まで持ち込まないよう、プログラムフォルダー全体を直接コピーしないでください。

第3章

インストールと初期設定：戻せる基本状態を先に作る

インストール前に競合状態を整理する

インストール前に、実行中の他のプロキシクライアントを終了し、システムプロキシ、TUN、VPN設定を無効にします。Windowsではシステムのネットワーク設定で手動プロキシが古いポートを指していないか確認します。macOSでは現在のネットワークサービスのプロキシ項目を確認し、モバイル端末ではステータスバーに表示されるVPNが他のアプリによって維持されていないか確認します。古いクライアントを残しておくこと自体に問題はありませんが、初期設定では1つのプログラムだけに通信を管理させるのが安全です。インストール後にネットワークへ接続できなくなった場合も、問題が新しいクライアントにあるのか、2つのプログラムの重複にあるのかを切り分けやすくなります。

ダウンロード時はOSとアーキテクチャに合うファイルを選びます。Windowsのインストールパッケージは通常、インストールウィザードによってユーザーフォルダーまたはプログラムフォルダーへ配置されます。macOSではアプリを「アプリケーション」へ移動し、初回起動時にシステムのプライバシーとセキュリティ設定で確認を求められることがあります。Linuxのdebまたはrpmパッケージはディストリビューションに合わせ、ポータブル版やコアの圧縮ファイルは保存先と実行権限を自分で設定します。Androidではインストール後にVPN権限を要求し、iOSでもApp Storeからインストールした後、初回接続時にVPN設定を作成します。これらの権限は端末内の通信入口を作るために必要です。拒否してもクライアントは起動できますが、ネットワークを実際に取り込むことはできません。

初回起動は最小限の設定だけ行う

初回起動ですぐにポート、DNS、TUNスタック、多数の上書き項目を変更することはおすすめしません。まずはデフォルトの待ち受けアドレスとポートを維持し、クライアントがコアを起動できること、ログ、設定一覧、プロキシポリシー、接続履歴の入口を確認します。次に有効なサブスクリプションを1つ読み込み、利用可能なプロキシを選んでからシステムプロキシを有効にします。その状態でブラウザーから一般的なウェブページへアクセスし、接続履歴に新しいリクエストが現れるか確認します。接続一覧がまったく変化しない場合は、通信がまだクライアントに入っていません。ノードを変更する前にシステムプロキシを確認してください。

Windowsでクライアントにサービスモードやネットワークコンポーネントのインストールが必要な場合は、画面の指示に従って権限を許可します。サービスモードは通常、高い権限でTUN、ルーティング、システム設定を管理するために使われ、インストール後にクライアントの再起動が必要になることがあります。macOSのネットワーク拡張や補助サービスも、同様にシステムの確認が必要です。Linuxのデスクトップ環境では、トレイ、システムプロキシへの書き込み、TUN権限がデスクトップセッションとシステムサービスに依存します。ターミナルからGUIクライアントだけを起動する場合は、ターミナルを閉じたときにプロセスも終了しないか注意してください。

確認できるサインでインストール結果を検証する

インストール成功は、ウィンドウが表示されたかどうかだけでは判断できません。少なくとも4つのサインを確認します。コアのログに起動エラーが繰り返し出ていないこと、ローカルの待ち受けポートが作成されていること、サブスクリプション設定を読み込めること、システムプロキシを有効にした後に接続履歴でブラウザーのリクエストを確認できることです。ログにアドレスの占有が表示された場合、Windowsではnetstat、macOSまたはLinuxではlsofを使ってポートの所有プロセスを確認できます。以下のコマンドは本体の待ち受け状態を特定するだけで、ネットワーク設定は変更しません。

Windows:
netstat -ano | findstr LISTENING

macOS / Linux:
lsof -nP -iTCP -sTCP:LISTEN

ポートを古いクライアントが使用している場合は、該当プロセスを終了し、古いクライアントが変更したシステムプロキシを元に戻します。ポートが待ち受けていないのにクライアントが実行中と表示される場合は、コアのログを開き、設定解析エラー、権限不足、コアファイルの欠落を確認します。最初からファイアウォールやセキュリティ設定を無効にしないでください。まず明確なログを根拠に切り分けます。ローカルのループバックポートを作成できない問題と、リモート接続がブロックされる問題は別であり、対処法も異なります。

モバイル端末では、システムのバックグラウンド制限も確認します。Androidで画面消灯後に切断される場合、電池の最適化、バックグラウンド活動の制限、システムによるプロセス終了がよくある原因です。クライアントのバックグラウンド実行を許可し、VPNが常駐していることを確認してください。iOSではWi-Fiとモバイル通信を切り替えた際にネットワークが再構築され、短時間の再接続が発生することがあります。長時間復旧しない場合は、VPN設定を何度も削除するのではなく、クライアントで現在の設定とプロキシを確認してください。

初期設定が完了した状態

  • クライアントとコアの両方が安定して起動し、ログに同じエラーが繰り返し出ない。
  • 設定を1つ読み込み、プロキシグループとノード一覧を確認できる。
  • システムプロキシを有効にすると、ブラウザーのリクエストが接続履歴に表示される。
  • クライアントまたはシステムプロキシを停止すると、システムネットワークが元の状態へ戻る。
  • 複雑な上書き、スクリプト、カスタムDNSをまだ有効にしておらず、後から項目ごとに検証できる。

この最小限の利用可能な状態を保つことは重要です。後からルールの上書き、TUN、DNSを有効にした後にネットワーク異常が起きても、「デフォルト設定＋システムプロキシ」の状態へ項目ごとに戻せます。複数のモジュールを一度に変更すると手順は減りますが、問題の原因を特定できず、最終的に再インストールへ進みがちです。しかし再インストールしても、システムプロキシ、サービス、ローカル設定が自動的に消えるとは限りません。

第4章

サブスクリプションと設定：更新元、読み込み結果、ローカル変更を管理する

サブスクリプションを読み込んだ後の最初の確認

サブスクリプションは通常、URL、クリップボード、ローカルファイルから読み込みます。追加後に一度手動更新し、クライアントに更新日時が表示されること、プロキシ画面にノードとプロキシグループが現れることを確認します。サブスクリプション名が表示されただけでは、内容のダウンロード成功を意味しません。URLの期限切れ、ネットワーク到達不能、応答形式の誤り、変換結果の非互換によって、空の設定項目だけが残ることがあります。更新に失敗した場合は、クライアントのログでHTTPステータス、解析メッセージ、保存先を先に確認し、更新ボタンを連続して押さないでください。

サブスクリプションURLにはアクセス認証情報が含まれることが多いため、アカウントのパスワードと同じように扱い、公開スクリーンショット、質問掲示板、ログの添付ファイルに載せないでください。端末を変更するときは、ブラウザー履歴やチャット履歴から長期間コピーするのではなく、信頼できる経路でURLを再取得します。設定のエクスポートでは、取得元も区別してください。完全なエクスポートにはサブスクリプションURLやノードパラメータが含まれることがあります。ローカルルールや上書きだけのエクスポートは、個人設定の移行に適しています。

リモート設定とローカル上書きの境界

サブスクリプションをダウンロードした後のYAMLを直接編集する方法は、通常、長期運用には向きません。次回更新時にリモート内容でローカルファイルが上書きされ、手動で追加したルール、DNS、プロキシグループが消える可能性があります。上書き、マージ、拡張スクリプトに対応するクライアントでは、個人ルールを独立した上書きレイヤーに置きます。対応していない場合は、サブスクリプション設定をローカル設定としてコピーできますが、リモートの変更が自動同期されなくなる点を理解してください。メンテナンス前に、クライアントが「上書き更新」「マージ更新」「実行用設定の生成」のどれを採用しているか確認しないと、画面上で変更しても再起動後に元へ戻ることがあります。

標準YAMLはインデントで階層を表し、タブとスペースを混在させてはいけません。リスト項目はハイフンで始まり、文字列にコロン、シャープ、特殊文字が含まれる場合は引用符で囲むのが安全です。設定の読み込みエラーは後続の行を指すことが多いものの、実際の原因は直前のインデントや閉じていない引用符にある場合があります。変更後は小さな範囲でテストし、毎回1つのモジュールだけを変更して、読み込み可能な前のファイルを残してください。以下は構造を理解するための最小例です。サーバーアドレスはドキュメント用に予約されたもので、実際の接続には使えません。

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

proxies:
  - name: "サンプルノード"
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: "demo-user"
    password: "your-password"

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - "サンプルノード"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手動選択
  - MATCH,DIRECT

設定内の名称は一致していなければなりません。ルールが「手動選択」を指す場合、プロキシグループにも同名の項目が必要です。プロキシグループが「サンプルノード」を参照する場合、ノード名もスペースや大文字・小文字を含めて完全に一致させます。よくある読み込みエラーはプロトコルパラメータではなく、ノード名を変更した後にプロキシグループを同期し忘れたこと、またはルールをコピーした際に設定に存在しないグループ名が残っていることが原因です。日本語名も使用できますが、ツール間で変換する場合は、短く安定した名称の方が管理しやすくなります。

サブスクリプション更新失敗を層ごとに処理する

まず、そのサブスクリプション設定を使わなくても端末からサブスクリプションURLへアクセスできるか確認します。古い設定が無効になった後、サブスクリプションの更新も失敗することがあります。その場合は一時的にプロキシを無効にして直接更新するか、利用可能な別の設定へ切り替えてから更新します。返ってきたものが設定内容ではなくウェブページ、ログインページ、エラーメッセージの場合は、URLをYAMLとして保存しようとせず、サブスクリプションの提供元で認証を処理してください。ダウンロードには成功しても解析に失敗する場合は、別のクライアント向け形式でないか、現在のコアが未対応の項目を含んでいないか確認します。

サブスクリプション変換は、ノードを修復するツールではなく、設定を生成する工程として扱ってください。変換によってプロキシグループ、ルール、項目を組み替えることはできますが、無効なノードを復旧したり、サブスクリプション自体の権限を変更したりはできません。変換を使う場合は、テンプレートの出所、対象形式、更新方法を記録し、数か月後にルールの由来を説明できるようにします。アクセス認証情報を含む場合は、処理経路と保存場所を確認し、できるだけ自分で管理できる環境で完了してください。

設定管理の目的は、ファイルをできるだけ多く保存することではありません。現在どの設定を実行しているのか、どこから更新されたのか、どの内容をローカルで追加したのかを説明できることが重要です。ローカル設定には「デスクトップ日常用」「システムプロキシのみのテスト」「TUNトラブル解決」など用途を明記し、長期間使っていない重複コピーは削除しましょう。設定が増えすぎると、ルール自体より古いファイルを誤って選ぶことの方が発見しにくくなります。

第5章

プロキシモード：ルール、グローバル、DIRECTの選び方

日常のデフォルトはルールモード

ルールモードでは、設定内のルールを1つずつ確認し、リクエストをプロキシグループへ送るか、直接接続するか、拒否するかを決めます。サイトやアプリごとに異なる出口を使え、ローカルサービス、LANアドレス、プロキシ不要の通信をDIRECTにできるため、長期利用に適しています。ルールモードが想定どおり動くかは、ルールセットの内容、順序、DNSの結果、プロキシグループの選択に左右されます。すべてのネットワーク環境を自動判定するブラックボックスではありません。アドレスが誤った出口へ送られた場合は、接続詳細で一致したルールを確認し、クライアント全体を長期間グローバルモードに変更するのではなく原因を特定してください。

接続履歴には通常、対象ドメインまたはIP、適用ルール、プロキシチェーン、最終ノードが表示されます。特定のウェブサイトを調べるときは、まず接続一覧をクリアまたは絞り込み、その後にリクエストを再実行して新しい接続を確認します。ブラウザーはメインドメイン、静的リソース、ログインAPI、サードパーティサービスへ同時にアクセスすることがあります。ページの異常がメインドメインだけに起因するとは限りません。失敗した接続と適用ルールを特定して初めて、ルール不足、プロキシグループの選択ミス、ノード自体の利用不能を判断できます。

グローバルモードはルールの問題を切り分けるために使う

グローバルモードでは通常、取り込み可能な通信の大部分を指定したプロキシまたはノードへ送ります。出口の短時間テストに適しています。ルールモードでウェブサイトを開けず、グローバルモードで復旧する場合、ノードには接続能力があり、問題はルール判定、DNS、プロキシグループの経路にある可能性が高くなります。グローバルモードでも失敗する場合は、ノード、プロトコル、システム時刻、ネットワーク環境を優先して確認します。グローバルモードは診断用の手段であり、統一された出口が必要な一時的な場面にも使えますが、既存の分岐設計を迂回するため、LAN、ローカルサービス、プロキシ不要の通信に影響することがあります。

グローバルモードへ切り替えた後は、グローバル用プロキシグループで何が選ばれているかを確認します。設定によっては「GLOBAL」グループが選択リストになっており、ノードを手動で指定する必要があります。モードを切り替えただけで有効な出口を選ばないと、ルールモードと同じ結果になることがあります。テスト後はルールモードへ戻し、対象アプリを再度開いてください。プログラムによっては確立済みの長時間接続を再利用するため、モードを切り替えても古い接続の経路はすぐに変わりません。ブラウザーでは対象タブを閉じるか、接続が再構築されるまで待ちます。

DIRECTモードはローカルネットワークを確認するために使う

DIRECTモードでは、取り込み対象のリクエストをプロキシノードを経由させずに直接アクセスさせます。現在のネットワークで基本通信、DNS、対象サービスへ到達できるか判断するのに適しており、クライアントを起動したままプロキシを一時停止して接続を観察する場合にも使えます。DIRECTモードはシステムプロキシを無効にすることとは異なります。通信は依然としてコアへ入り、最終動作だけがDIRECTになります。クライアントを完全に終了する場合は、システムプロキシまたはTUNを無効にし、システムのネットワーク設定が復元されたことを確認してください。

DIRECTモードでも一般的なウェブサイトへ接続できない場合、ローカルネットワーク、DNS、システムルーティング、ファイアウォール、残っている別のVPNが原因かもしれません。この状態でプロキシノードを変更し続けても意味はありません。反対に、DIRECTは正常でグローバルが失敗するなら、通常はノードまたはプロキシプロトコルの問題です。DIRECTとグローバルは正常でルールだけ失敗するなら、ルールとプロキシグループを重点的に確認します。この3モードの比較で範囲を素早く絞れますが、各テストは同じ対象、同じネットワーク、新しい接続で行い、キャッシュの影響を避けてください。

モード 主な用途 適した時間帯・場面 トラブル解決時の判断
Rule ルールに従って出口を振り分ける 日常利用 適用ルールとプロキシチェーンを合わせて判断する
Global 指定したプロキシへ一括送信する 短時間のテストまたは統一された出口 ルールの問題を切り分けられる
Direct ローカルネットワークから直接接続する 基本ネットワークを確認する ノードとプロキシプロトコルの問題を切り分けられる

プロキシグループが最終出口を決める

モードは、プロキシ判定へ入る方法だけを決めます。具体的にどの出口を使うかはプロキシグループが決めます。一般的なプロキシグループには、手動選択、自動速度測定、フォールバック、負荷分散があります。手動選択は最も分かりやすく、重要な用途に適しています。自動速度測定はテストURLと間隔に基づいて結果の良いノードを選びますが、測定遅延は実際のアクセス速度と同じではありません。フォールバックは現在のノードが使えないときに予備へ切り替えるため、継続性を重視する設定に適しています。プロキシグループの名称はクライアントによって異なる場合があるため、設定内のtypeを基準にしてください。

自動選択は実際の検証の代わりにはなりません。テストURLへ到達できても、そのノードがテストリクエストを完了できたことを示すだけです。対象サイトでは異なる経路、プロトコル、地域ポリシーが使われることがあります。ノードの遅延は正常に見えるのにウェブページが遅い場合は、実際の接続確立時間、ダウンロード中の挙動、パケットロスを確認し、少数のノードを手動で比較します。測定間隔を極端に短くするとバックグラウンドリクエストが増え、ノード間を頻繁に切り替える原因にもなります。日常設定では適切な間隔を使い、重要なプロキシグループには手動選択の余地を残すのが適切です。

第6章

ルール分岐：照合順序、ルール種別、上書き方法

ルールは上から順に照合し、最初に一致した時点で停止する

Clashのルールで最も重要な挙動は順序です。リクエストはルール一覧の先頭から確認され、最初に一致したルールが指定するポリシーを採用します。以降のルールは確認されません。具体的なドメインルールは、広いドメインサフィックス、GeoIP、最終フォールバックより前に置くのが一般的です。広範囲のルールが先に一致すると、後ろにある正確なルールが正しく記述されていても実行されません。「カスタムルールが効かない」場合は、まず接続履歴で実際にどのルールに一致したか確認し、ルール一覧の位置を見直してください。

よく使われるルールには、DOMAINによる完全一致ドメイン、DOMAIN-SUFFIXによるドメインサフィックス、DOMAIN-KEYWORDによるドメインキーワード、IP-CIDRによるIPv4ネットワーク、IP-CIDR6によるIPv6ネットワーク、GEOIPによる地理的IP分類、PROCESS-NAMEによるプロセス名、最後のMATCHがあります。ドメインが見えている場合はドメインルールが直接的です。IPルールは名前解決の結果に依存し、プロセスルールはプラットフォームと通信の取り込み方法に依存します。すべてのシステムやクライアントで、プロセス識別能力が同じとは限りません。

正確な条件から広いフォールバックへ組み立てる

新しいルールを追加するときは、対象が具体的なホスト、ドメインサフィックス全体、IP範囲、アプリのプロセスのどれかを明確にします。正確なドメインで解決できる場合は、広すぎるキーワードを直接使わないでください。同じ文字列を含む別ドメインまで誤って対象になる可能性があります。ドメインサフィックスルールはメインドメインとサブドメインを対象にでき、構造が安定したサービスに適しています。IPネットワークルールはドメイン情報がないサービスや、アドレス単位で明確に分岐したいサービスに適していますが、CDNやネットワーク地域によってアドレスが変わるため、継続的なメンテナンスが必要です。

rules:
  - DOMAIN,api.example.com,作業用プロキシ
  - DOMAIN-SUFFIX,example.net,手動選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,手動選択

no-resolveは、このIPルールを照合するときに判定のための追加のドメイン解決を行わないようコアへ伝えます。プライベートネットワークなど、アドレス条件が明確な場合に適しています。追加するかどうかはルールの種類と実際の要件で決め、すべてのルールへ機械的に付けないでください。MATCHは最終フォールバックとして通常末尾に置きます。それまでに一致しなかったリクエストが指定したポリシーへ入ります。MATCHを途中に置くと、後続のルールは永遠に実行されません。

ルールセットとGeoデータは追跡可能にする

大規模な設定では通常、rule-providersでルールセットを参照し、メイン設定に数千ものルールを詰め込みません。ルールセットは独立して更新できる一方、取得元、挙動、更新日時という3つの変数が増えます。利用前に、どのカテゴリを対象にするか、どの形式か、どのプロキシが参照するか、更新に失敗したときキャッシュを使い続けるかを確認します。対象範囲が大きく重なるルールセットを同時に重ねないでください。同じドメインがどれに一致するかが並び順に依存し、後から説明しにくくなります。

GeoIPと地理的なサイト分類はローカルのデータファイルに依存します。データが古いと、新しく割り当てられたアドレスや新しいドメインを正しく分類できないことがあります。データのダウンロードに失敗しても、クライアントが古いキャッシュを使い続ける場合があります。Clash GeoIPを更新するときは、クライアントにデータ更新の入口があるか確認し、ログでダウンロードと読み込みが成功したことを確認します。更新後に分岐の挙動が突然変わった場合は、対象サイトの表示内容や企業所在地からIP分類を推測するのではなく、更新前後の適用ルールを比較してください。

ローカル上書きは正しい挿入位置に置く

クライアントが提供する「前置ルール」「後置ルール」「マージルール」の意味は異なる場合があります。前置ルールは通常、リモートルールより前に挿入され、個人ルールを優先させたい場合に適しています。後置ルールがリモートのMATCHより後ろにある場合、実際には有効になりません。上書き機能を使うときは、最終的に生成された実行設定またはログのルール順序を確認し、カスタム内容が本当にMATCHより前に入っていることを確認してください。編集欄にルールが見えているだけでは、コア読み込み後の順序が同じとは限りません。

ルールのデバッグは1つの対象から始めます。接続の絞り込みを解除し、対象ドメインへアクセスして、ドメイン、解決されたIP、適用ルール、プロキシグループ、最終ノードを記録します。その後は1つのルールだけを変更し、設定を再読み込みして新しい接続を作ります。ブラウザーのDNSキャッシュ、接続の再利用、サービスワーカーが古い経路を保持することがあります。必要に応じて対象ページを閉じるか、アプリを再起動してください。より詳しい構文と上書き例はClashカスタムルール構文の詳しい解説で確認できます。

ルールが効かないときの確認リスト

  1. ルール構文をコアが正常に読み込めているか。
  2. ルールが参照するプロキシグループが存在し、名称が完全に一致しているか。
  3. より広いルールが先に一致していないか。
  4. カスタムルールが最終MATCHより前に挿入されているか。
  5. 対象リクエストが変更前に確立された接続を再利用していないか。
  6. ドメインリクエストがルールに入る前に、別のコンポーネントによって書き換えまたは解決されていないか。

第7章

TUNとDNS：より多くの通信を取り込み、名前解決を揃える

システムプロキシとTUNでは取り込み範囲が異なる

システムプロキシは、主にOSのプロキシ設定を参照するアプリへ影響します。ブラウザーや一部のデスクトップソフトは対応が良好ですが、ゲーム、コマンドラインツール、ストアアプリ、仮想マシン、独自のネットワークスタックを使うソフトウェアは迂回することがあります。TUNは仮想ネットワークインターフェースを作成し、システムルーティングを通じてより多くのIP通信をコアへ渡すため、対象範囲が広くなります。これは「より速いシステムプロキシ」ではなく別の入口方式です。ルーティング、DNS、権限、LAN、他のVPNとの互換性に関する問題も発生します。

初めてTUNを有効にする前に、システムプロキシモードが正常に動作することを確認してください。これにより、サブスクリプション、ノード、基本ルールが概ね有効だと判断でき、TUNが失敗したときに権限、仮想インターフェース、ルーティング、DNSへ範囲を絞れます。最初からTUN、カスタムDNS、IPv6、複数の上書きを同時に有効にすると、切断後に原因を特定しにくくなります。まずシステムプロキシを無効にし、デフォルトのTUNパラメータだけでテストしてください。リクエストが接続履歴に現れることを確認した後、DNSとバイパスルールを項目ごとに調整します。

権限、ルーティング、ネットワークスタックのパラメータ

TUNは仮想インターフェースを作成し、システムルートを変更するため、デスクトップOSでは通常、管理者権限、補助サービス、ネットワーク拡張が必要です。Windowsではサービスモード、ドライバーの状態、他のVPNを確認します。macOSではネットワーク拡張の許可を確認し、LinuxではTUNデバイスと適切なcapabilityまたは管理者権限が必要です。権限不足の場合、ログにはインターフェース作成、ルート設定、デバイスアクセスの失敗が表示されます。この状態でノードを何度変更しても結果は変わらないため、まずシステム権限を処理してください。

一般的なTUNスタック名にはsystem、gVisor、mixedがありますが、使用可能な値はコアとクライアントによって異なります。systemはOSのネットワークスタックへの依存が大きく、gVisorはユーザー空間でより多くのネットワーク処理を行い、mixedはプロトコルに応じて組み合わせます。明確な問題がない場合は、クライアントのデフォルト値を維持してください。特定のアプリだけ接続できない、UDPに異常がある、スリープ復帰後に通信できない場合は、元の値を記録してからスタックを切り替えて比較します。毎回1項目だけを変更し、コアを再起動して仮想インターフェースを作り直してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: false
  dns-hijack:
    - any:53

auto-routeはルートを自動的に書き込み、auto-detect-interfaceは現在のデフォルトネットワークインターフェースを識別します。有線、Wi-Fi、仮想マシンのインターフェース、他のVPNへ同時に接続している場合、自動検出が誤った出口を選ぶことがあります。TUNを有効にするとすべての接続がタイムアウトする場合は、他のネットワークツールを終了してTUNを再度有効にし、デフォルトインターフェースの変化を確認します。strict-routeはルーティングの制約を強め、通信の迂回を減らす可能性がありますが、LAN、仮想マシン、特殊なルートへ影響しやすくなります。初回設定でむやみに有効にしないでください。

DNSモードがドメインをルールへ渡す方法を決める

DNSはドメインをIPへ変換するだけではありません。ルールがドメインを確認できるか、接続がどの出口を通るか、名前解決の経路に不一致が起きるかにも影響します。Clash DNSの代表的な拡張モードにはredir-hostとfake-ipがあります。redir-hostは実際の名前解決結果を返す方式に近く、fake-ipはまず予約アドレスを返してマッピングし、接続時にコアがドメインを復元するため、ルール照合までドメイン情報を保持しやすくなります。一部のLANサービス、デバイス検出、ゲーム、実IPに依存するプログラムでは、fake-ip-filterへの追加が必要になる場合があります。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"

例にあるパブリックDNSは構文を示すためのものです。実際の選択は、利用地域のネットワーク、設定ルール、プライバシー要件を踏まえて決めてください。設定がプロキシ経路とDIRECT経路でDNSを分けられる場合、プロキシ対象サーバーの名前解決が、まだ確立していないプロキシへ逆に依存しないようにします。Clash DNSのリークが疑われる場合、1つの検査サイトの結果だけを見ないでください。まず、システムDNSのリクエストがTUNまたはDNSハイジャックで取り込まれているか確認し、次にコアのログ、現在の待ち受けポート、実際にどのDNSへ送信されたかを確認します。ブラウザー内蔵の暗号化DNSがシステム経路を迂回することもあるため、確認対象に含めてください。

TUNの障害はネットワーク復旧を優先して処理する

TUNを有効にして完全にオフラインになった場合は、まずTUNを無効にしてルートが復旧するか確認します。無効にしても接続できない場合は、クライアントを終了し、システムに仮想インターフェース、プロキシ設定、他のVPNが残っていないか確認します。その後クライアントを再起動し、システムプロキシだけで基本接続を検証します。基本接続が正常になったら、TUNログでインターフェース作成、デフォルトルート、DNS待ち受け、権限エラーを確認します。LAN機器へアクセスできない場合は、プライベートネットワークがDIRECTになっているか、strict-routeが遮断していないか、LANアドレスがfake-ipの対象になっていないか確認してください。

スリープからの復帰、Wi-Fiの切り替え、有線からテザリングへの切り替え後に接続できなくなる場合、デフォルトインターフェースやルートが変わっていることがよくあります。まずクライアントによる自動再構築を待ち、復旧しなければTUNを一度無効にしてから再度有効にします。頻繁に起きる場合は、クライアントがネットワーク変化時の再読み込みに対応しているか確認し、auto-detect-interfaceも確認します。コンテナ、仮想マシン、リモート接続ツールを同時に実行している場合は、それらが作成するネットワーク範囲を記録し、TUNルートが上書きしないようにします。TUNが安定しているかどうかはスイッチが点灯するかではなく、ネットワーク切り替え、スリープ復帰、LANアクセスで説明可能な結果が得られるかで判断します。

第8章

日常メンテナンスとトラブル解決：設定の有効性から確認する

無理のないメンテナンス習慣を作る

日常のメンテナンスで毎日設定を変更する必要はありません。信頼できる方法は、サブスクリプションとルールデータを定期的に更新し、更新後に最小限の検証を行うことです。設定を読み込めるか、よく使うプロキシグループにノードがあるか、ルールモードで一般的なウェブページを開けるか、接続履歴が想定どおりかを確認します。クライアントやコアを更新する前に、現在の設定、TUNの状態、ポート、ローカル上書きを記録します。更新後はまず基本接続を検証し、それから複雑な項目を戻します。安定性が必要な環境では新機能の更新を少し遅らせても構いませんが、OS更新やプロトコル互換性の問題がある場合は現在のメンテナンス状況を確認してください。

バックアップではキャッシュではなく、ローカルで追加した内容を重視します。サブスクリプションの取得方法、ローカル上書きルール、DNSの変更、プロキシグループの変更、サービス設定を保存してください。ノード一覧がすべてサブスクリプションから生成される場合、複数のスナップショットを長期保存する必要はありません。本当に残すべきなのは、サブスクリプションから再取得できない個人設定です。バックアップファイルには用途と日付を記載し、サブスクリプションURL、ノード認証情報、LAN情報を公開しないようにします。

接続済みなのにインターネットへつながらない場合の固定手順

第1段階では、設定が正常に読み込まれ、プロキシグループに利用可能な選択肢があるか確認します。第2段階ではDIRECTへ切り替えてローカルネットワークを確認し、次にグローバルへ切り替えて明確なノードを選び、ルールの影響を除外します。第3段階では、システムプロキシまたはTUNが実際に通信を取り込んでいるか確認します。接続履歴に新しいリクエストがなければ入口の問題です。リクエストがあり、すぐ失敗するならルール、プロキシチェーン、エラー種別を確認します。第4段階ではDNSを確認し、ドメインアクセスとIPへ直接アクセスした場合の挙動を比較します。第5段階ではポート競合、TUN権限、他のVPN、ファイアウォール、システム時刻を確認します。

「接続済み」はノードのハンドシェイクまたはクライアントの実行状態を指すことが多く、すべての対象へ到達できることを意味しません。1つのウェブサイトだけ失敗する場合は、そのサイトが使う複数のドメインと適用ルールを確認します。すべてのサイトが失敗する場合は、出口とシステムネットワークを確認します。ブラウザーは使えるのにコマンドラインが使えない場合は、コマンドラインツールがシステムプロキシを参照するか確認するか、現在のターミナルにプロキシ環境変数を設定します。一時的なテストにはローカルのmixed-portを使えます。ポートはクライアントに表示される実際の値を確認してください。

Windows PowerShell:
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"

macOS / Linux:
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"

環境変数は現在のターミナルと、そこから起動したプロセスにだけ有効です。ターミナルを閉じると通常は無効になります。クライアントのポートが7890でない場合は、実際の値に置き換えてください。テスト後は、一時的な変数をグローバルなshell設定へ誤って書き込まないでください。特にクライアントを常駐させない端末では、クライアント終了後もコマンドラインが存在しないポートを参照し続ける原因になります。より詳しい手順はClashで接続済みなのにネットへつながらない場合の確認リストを参照してください。

遅延、タイムアウト、速度の問題は分けて考える

Clashのノード遅延テストは通常、小さなHTTPリクエストを送信します。結果はテストURL、DNS、ハンドシェイク方式、現在のネットワークに左右されます。遅延が低いからといってダウンロード速度が高いとは限らず、対象サービスが利用できるとも限りません。タイムアウトは、ノードへ到達できない、テストURLがブロックされている、プロトコルのハンドシェイクに失敗する、ローカルネットワークでパケットロスが起きているなどの原因で発生します。ノードを比較するときは、同じテストURLを近い時間帯に使い、実際のウェブ閲覧やダウンロードも合わせて判断してください。1回の並び順だけで結論を出さないようにします。

速度が突然低下した場合は、まず単一の対象だけが影響を受けているか確認し、DIRECT、異なるノードのグローバル、ルールモードを比較します。通信が想定したプロキシへ送られているか、ノードが自動的に頻繁に切り替わっていないか、バックグラウンドでサブスクリプションやルールを更新していないかを確認します。無線ネットワークの不安定さ、省電力設定、モバイル回線の切り替え、他のダウンロードも結果へ影響します。夜間だけ、または特定の経路だけで起きる場合は、ネットワーク経路の変化かもしれません。クライアントの再インストールを繰り返しても、通常は解決しません。

ログは問題の前後に必要な部分だけ集める

トラブル解決時はログレベルを一時的にinfoまたはdebugへ変更し、問題を1回再現したら、時刻、対象、モード、エラー行をすぐ記録します。debugログは情報量が多いため、長時間有効にするのには適していません。加工せずに公開することも避けてください。共有前に、サブスクリプションURL、ノードサーバー、認証情報、ローカルユーザー名、ファイルパスを削除します。有効なログには、問題発生前後の起動、DNS、ルール照合、接続エラーが含まれている必要があります。最後の「timeout」1行だけを切り取っても十分な情報にはなりません。

HTTPS証明書エラーが出た場合は、まずシステム時刻、ブラウザーのポリシー、システムの証明書チェーン、ネットワーク内の中間装置を確認し、その後でプロキシ経路との関係を判断します。通常のClash転送では、すべてのウェブサイトに復号用証明書をインストールする必要はありません。ソフトウェアが通信分析、スクリプト書き換え、その他の中間処理を有効にしている場合は、個別に確認が必要です。プロキシ経由でHTTPS証明書エラーが出た場合の対処法に沿って層ごとに確認し、証明書警告を無視して問題を回避しないでください。

症状 最初に確認する場所 次に行うこと
接続履歴が空 システムプロキシ、TUN、アプリ自身のプロキシ 通信の入口と待ち受けポートを確認する
すべてのリクエストがタイムアウト ノード、システム時刻、ネットワーク出口 DIRECTとグローバルモードを比較する
ドメインだけ失敗 DNSの待ち受けと名前解決経路 ブラウザーの暗号化DNSとハイジャックを確認する
ルールモードが異常 適用ルールとプロキシグループ グローバルモードでノードを検証してから順序を調整する
スリープ後に通信できない TUNインターフェースとデフォルトルート TUNを再構築し、インターフェースの識別を確認する

第9章

高度な設定への道筋：安定した設定から保守可能な設定へ

まず個人の要件を検証可能な条件に書き換える

高度な設定とは、ルールやスイッチを増やすことではありません。要件を検証できる動作へ変換することです。たとえば「仕事用ドメインは常に固定プロキシを通す」「LANと開発環境はDIRECTを維持する」「モバイル回線の切り替え後もTUNが自動復旧する」「ルールセットの更新に失敗してもキャッシュを使う」といった条件です。各目標には、対応する設定、観察方法、戻し方を用意してください。どの上書きが何を解決するのか説明できない場合は、長期設定へ追加しないことをおすすめします。

基準設定と実験設定を分けることをおすすめします。基準設定には、安定したサブスクリプション、明確なプロキシグループ、必要なルール、検証済みのDNS/TUNパラメータだけを含めます。実験設定では、新しいルールセット、別のネットワークスタック、プロキシグループの挙動をテストします。実験が成功したら、変更した1項目だけを基準設定へ移します。これにより、設定解析の失敗やルーティング異常が起きても、大量の過去変更から原因を推測せず、すぐ利用可能な状態へ戻せます。

proxy-providersで動的なノードを管理する

ノードの取得元をメイン設定から分離して管理する場合は、proxy-providersでリモートまたはローカルのノードプロバイダーを定義し、プロキシグループから参照できます。これにより、プロキシグループとルールを安定させたまま、ノード一覧を計画的に更新できます。プロバイダーには、種類、パス、更新間隔、ヘルスチェックを明確に設定します。キャッシュパスは複数のプロバイダーで同じファイルを共有しないようにし、ヘルスチェックURLには長期的に安定し、応答が軽く、実際のネットワーク条件に合う対象を選びます。

proxy-providers:
  primary:
    type: http
    url: "https://example.com/subscription"
    path: "./providers/primary.yaml"
    interval: 21600
    health-check:
      enable: true
      interval: 900
      url: "https://www.gstatic.com/generate_204"

proxy-groups:
  - name: "自動選択"
    type: url-test
    use:
      - primary
    url: "https://www.gstatic.com/generate_204"
    interval: 600

例のアドレスは構造を説明するためだけのものです。実際のサブスクリプションURLは信頼できる提供元から取得し、安全に保存してください。更新間隔は短ければよいわけではありません。短すぎるとリモートへのリクエストとローカルの再読み込みが増え、ノードが頻繁に変わって長時間接続を中断することがあります。ヘルスチェックも完全な利用可能性を保証せず、テスト対象へ接続できることを示すだけです。重要な用途では手動プロキシグループを残し、必要に応じて自動選択を候補として使うにとどめ、唯一の出口にしないでください。

rule-providersでルールの役割を分ける

ルールが増えたら、LAN、仕事、メディア、開発、DIRECT、ブロックなど用途別にルールセットを分けられます。メイン設定には参照順序と最終ポリシーだけを残し、各ルールセットの役割を明確にします。サイトごとに細かいファイルを作りすぎると、多数の小ファイルが管理コストになります。「更新元が同じ」「ポリシーの対象が同じ」「メンテナンス周期が近い」ルールをまとめる方が実用的です。

リモートルールセットを更新する前にキャッシュを残し、形式とbehaviorの種類が一致していることを確認します。domain、ipcidr、classicalのルールセットでは内容構造が異なり、種類を誤ると解析失敗や照合異常が起きます。ルールセットの読み込みに成功しても、接続履歴で代表的な対象をいくつか検証してください。ダウンロード成功だけでは、ルール順序が正しいことも、対象が想定したポリシーへ入ったことも証明できません。

コアの配置ではサービスと権限管理も整える

サーバーやルーターでMihomoを直接実行する場合、GUIクライアントが代わりに行っていた作業を自分で整える必要があります。設定パス、作業ディレクトリ、ログ、プロセス監視、起動順序、更新、権限などです。まずフォアグラウンドのコマンドで設定を読み込み、構文エラーがないことを確認してから、システムサービスの管理へ移します。最初からプロセスをバックグラウンドで静かに実行すると、起動失敗の原因を確認しにくくなります。設定で参照する相対パスは作業ディレクトリを基準とします。サービスマネージャーのディレクトリが手動テスト時と異なると、ルールセットやデータベースファイルを見つけられないことがあります。

mihomo -t -f ./config.yaml
mihomo -d ./runtime -f ./config.yaml

1つ目のコマンドで設定を確認し、2つ目で実行ディレクトリを指定してファイルを読み込みます。実際の実行ファイル名とパスは、ダウンロードした内容に合わせてください。サービスアカウントには、設定の読み取り、キャッシュへの書き込み、必要なネットワークインターフェースの作成に必要な権限を与えます。ただし簡単だからといって、設定ディレクトリ全体に不要な書き込み権限を与えないでください。設定を変更したら、先に検査を実行してからサービスを再読み込みします。リモート端末がそのプロキシを管理接続に使っている場合は、更新前にローカルコンソールまたは復旧経路も用意してください。

すべての機能を一度に完成させず、段階的に拡張する

高度な設定への道筋は4段階に分けられます。第1段階ではルールモードを安定させ、接続履歴から1つのリクエストを説明できるようにします。第2段階ではローカル上書きとルールセットを整理し、サブスクリプション更新で個人設定が上書きされないようにします。第3段階ではTUN、DNS、ネットワーク切り替えを有効にして安定させます。第4段階でprovider、サーバー配置、自動更新、監視を検討します。各段階で一定期間運用し、日常の通信、スリープ復帰、LAN、よく使うアプリに異常がないことを確認してから次へ進んでください。

学習中は、未検証の設定断片を大量に保存するより、症状と結論を優先して記録します。同じ項目でも、コア、クライアント、OSによってデフォルト値が異なる場合があります。コピーする前に、現在の実行設定を確認してください。Windowsのシステムプロキシ、サブスクリプション、UWPループバックの問題はWindowsでClashをインストールする完全ガイドを参照できます。初回設定の手順を整理し直す場合は、Clash初回インストール設定チェックリストへ戻ってください。

以降の変更では、同じ手順を使い続けられます。目的を明確にし、基準設定をバックアップし、1項目だけ変更し、再読み込み後にログと接続履歴を確認し、DIRECT、グローバル、ルールモードで比較します。クライアントを変更または再インストールする場合は、Clashクライアントのダウンロードページでプラットフォームとアーキテクチャを確認してください。初回接続だけをすぐ復旧したい場合は、クイックスタートガイドに従って最小限の状態を作り直します。このガイドの目的は設定を複雑にすることではなく、すべてのスイッチに明確な位置を与え、あらゆるトラブルに決まった出発点を用意することです。