Windowsの設定 mihomoコア 段階別ガイド

Clash設定ガイド

クライアントのインストールからルール、TUN、日常のメンテナンスまで、9つのステップで設定を確認します。

初めて接続する場合は、まず入門ガイドに沿って基本の接続手順を進めてから、このページで仕組みや設定項目、トラブルの切り分け方を確認してください。学習の順番に沿って解説しています。すでに接続できている場合は、目次から該当する項目に進めます。クライアントはダウンロードセンターから入手できます。症状から探す場合はヘルプセンターをご覧ください。

1. 基本の仕組みと通信経路

クライアント・コア・サーバーの違い

まず、3つの役割を区別しましょう。Clash Plus、Clash Verge Rev、FlClashなどは、ユーザーが操作するクライアントです。設定の読み込み、プロキシグループの表示、モードの切り替え、バックグラウンドプロセスの管理などを行います。mihomoは、プロキシ接続やルール判定、名前解決を処理するコアです。サーバーは遠隔地にあり、クライアントから転送された通信を受け取ります。クライアントをインストールしても、利用可能なサーバーが手に入るわけではありません。また、クライアントのダウンロード先とサブスクリプションの購入先は別です。

設定項目の名前をすべて覚えるより、アクセス時の通信経路を理解することが大切です。アプリは接続先を名前解決して通信を開始し、システムプロキシ、手動プロキシ、または仮想ネットワークアダプターを経由してコアに接続します。コアは接続先のドメインやIPアドレス、ルールを確認し、直接接続するか、拒否するか、プロキシグループに渡すかを判断します。最後に、プロキシグループが実際の出口を選びます。ページが開かない場合は、どの段階にも原因があり得ます。クライアントのアイコンが点灯しているだけで、通信経路全体が正常だとは判断できません。

サブスクリプション・ノード・プロキシグループの違い

サブスクリプションURLは、設定やノード情報を取得するための入口です。アクセス情報が含まれていることが多いため、パスワードと同様に扱ってください。ノードはサーバーアドレス、ポート、プロトコル、認証情報などで構成される遠隔接続先です。プロキシグループは複数のノードやグループをまとめ、手動選択や接続失敗時の切り替えなどを提供します。同じノードを複数のグループで使うこともできますが、グループ名が実際の接続先の国や地域を示すとは限らず、特定のサイトへの接続を保証するものでもありません。

設定ファイルには、DNS、待ち受けポート、ルールセット、リモートリソースのURLなどが含まれる場合もあります。ノード一覧だけを返すサブスクリプションでは、クライアントのテンプレートやマージ機能で不足分を補うことがあります。一方、設定一式を返すものもあります。この2種類は区別して扱いましょう。読み込みに成功しただけでは、設定が選択済みであること、コアに読み込まれたこと、遠隔サービスのアカウントが有効であることは確認できません。

段階ごとに確認する

ローカルの待ち受けポートは、アプリからコアへ接続する入口であり、遠隔サーバーのポートではありません。たとえばmixed-portは、同じポートでHTTPとSOCKSのプロキシリクエストを受け付けます。Windowsでよく使われるローカルアドレス127.0.0.1は、この端末だけを指します。プロキシを手動で設定するときは、クライアントに実際に表示されているアドレスとポートを入力してください。画面例の数値をそのまま使ったり、サブスクリプションURLをプロキシサーバー欄に入力したりしないでください。

接続状況は4段階で確認します。まずコアが動作しているか、次に通信がコアに届いているか、その後ルールの判定結果、最後に出口からの応答を確認します。接続一覧に記録がない場合は、アプリがシステムプロキシを使っているかを確認してください。記録があり拒否されている場合は、適用されたルールを確認します。想定したプロキシを経由しているのにタイムアウトする場合は、ノード、遠隔サービス、接続先サイトを調べます。この順番で確認すれば、再インストールを繰り返したり、DNSの問題をサブスクリプションの問題と誤認したりするのを防げます。

通信の暗号化とアクセスの安全性も別に考えましょう。クライアントが特定のプロトコルに対応していても、設定の配布元が信頼できるとは限りません。また、遠隔の出口を経由しても、フィッシングサイトからアカウントが自動的に保護されるわけではありません。信頼できる配布元の設定だけを読み込み、ブラウザーで証明書の警告が表示された場合は操作を中止してください。接続の問題を解決するために、出所の分からないルート証明書をインストールしてはいけません。プロジェクトの経緯や役割分担については、Clash、mihomo、Clash Verge Revの関係もご覧ください。

2. クライアントとデバイスの選び方

利用するプラットフォームから候補を絞る

初めてクライアントを選ぶときは、デバイスのプラットフォームとプロセッサのアーキテクチャ、必要な機能を確認してから、画面の使いやすさを比べましょう。Windowsでは、まずClash Plusをお試しください。インストール要件はWindowsのダウンロードページで確認できます。本ガイドのサービスモードやログ、ルールの例に沿って操作したい場合は、Clash Verge Revも選べます。以降はClash Verge Revでよく使われる画面名を例に説明します。他のクライアントでは、同じ意味の設定、プロキシ、オプションの項目を探してください。

WindowsではFlClashやClash Nyanpasuも選べます。複数のクライアントを同時に起動すると、待ち受けポート、システムプロキシ、仮想ネットワークアダプターが干渉する場合があります。クライアントを切り替える前に、旧クライアントのシステムプロキシとTUNを無効にし、プロセスを完全に終了してください。設定のバックアップを残せば十分です。画面を比較するために、すべてのプログラムをスタートアップに登録する必要はありません。トラブルシューティングでは、通信の入口を1つに絞りましょう。

プラットフォーム別のクライアント候補
プラットフォームクライアントと選び方のポイント
WindowsClash Plusが第一候補です。Clash Verge Rev、FlClash、Clash Nyanpasuも利用できます。Clash for Windowsは開発終了済みのアーカイブ版です。
macOSClash Plusが第一候補です。Clash Verge Rev、FlClashも利用できます。ClashX Metaは開発終了済みのアーカイブ版です。
AndroidClash Plusが第一候補です。Clash Meta for Android、FlClash、Surfboardも利用できます。設定形式とプロトコルの対応状況を確認してください。
iOSClash Plusを選び、ダウンロードセンターからApp Storeへ進んでください。公式サイトはclashplus.ioです。
LinuxClash Verge Revがおすすめです。FlClashも選べます。リリース版、パッケージ形式、デスクトップ環境を確認してください。

OS名だけでなく、アーキテクチャも確認する

Windowsの「設定 → システム → バージョン情報」を開き、「システムの種類」を確認してください。x64プロセッサの場合は、通常x64またはAMD64のインストーラーを選びます。この2つはここでは同じアーキテクチャを指し、特定のプロセッサメーカー専用という意味ではありません。ARM64デバイスでは、ダウンロードページに対応ビルドがあることと、使用中のWindows環境がサポートされていることを確認してください。コアの圧縮ファイルを、GUIクライアントのインストーラーと間違えないようにしましょう。

macOSではApple SiliconとIntelを区別してください。Androidではデバイスのアーキテクチャに合わせて汎用パッケージまたは対応パッケージを選びます。Linuxではパッケージ管理方式も確認が必要です。ダウンロードできても、どのシステムにもインストールできるとは限りません。デスクトップクライアントには、コマンドラインのコアとは異なるGUI環境、権限、システムコンポーネントが必要です。サーバーやルーターで使う場合は、独立したmihomoコアの実行方法とサービス管理を調べてください。

メンテナンス状況と必要な機能で選ぶ

Clash for WindowsとClashX Metaは開発が終了しています。過去の操作方法を調べる用途には使えますが、新規ユーザーの標準的な選択肢には適しません。旧クライアントでは、新しい設定項目やプロトコル、システムへの対応が不足している場合があります。読み込みエラーが発生したら、まず設定の要件を確認し、必要に応じてメンテナンス中のクライアントへ移行してください。エラー項目を削除する方法は万能ではありません。削除した設定が、サブスクリプションの動作に必要な場合があります。

コアが似ていても、設定の保存方法、拡張スクリプト、サービスのインストール手順はクライアントごとに異なる場合があります。移行時は、まずサブスクリプションを再読み込みし、必要なルールを1つずつ移してください。プログラムのデータフォルダー全体をそのままコピーするのは避けましょう。特に、クライアントが生成した実行時設定を長期保存用の元ファイルとして使わないでください。そこには一時的なポート、コントロールインターフェースのアドレス、絶対パス、元の環境でしか使えない設定が含まれる場合があります。

最後に、日常の使い方に必要な機能を確認しましょう。主にブラウザーを使うなら、まずシステムプロキシを試します。システムプロキシを使わないアプリも経由させる必要がある場合は、TUNを検討してください。ドメインごとに出口を変える場合は、ルールとプロキシグループの管理が重要です。機能が多いほど初期設定が簡単になるとは限りません。まず最小構成で接続し、必要な機能を1つ追加するたびに動作を確認すれば、問題が起きたときに戻せる状態を保てます。

3. クライアントのインストールと初期確認

インストール前に競合する通信経路を整理する

ダウンロードセンターで、OSとアーキテクチャに合ったインストーラーを選んでください。保存先は見つけやすいローカルフォルダーにし、圧縮ファイルを一時フォルダーから何度も起動するのは避けましょう。インストール前に、ほかのプロキシクライアントを終了し、既存のプロキシポートとTUNの状態を記録してください。組織管理下のデバイスでは、仮想ネットワークアダプターやバックグラウンドサービスのインストールが許可されているか確認しましょう。管理上の制限を回避するために、システムポリシーを変更してはいけません。

インストーラーを実行する際は、発行元と権限要求を確認してください。管理者権限が必要な処理は、インストール先、サービス、ネットワークコンポーネントに関係する内容であるべきです。配布元やファイル形式、画面の警告が想定と異なる場合は、インストールを中止してください。Windowsのセキュリティ警告をすべて誤検知とみなしたり、クライアントのインストールのために保護機能を長期間無効にしたりしないでください。まずダウンロード元、デバイスのアーキテクチャ、システム要件を確認しましょう。

コアの状態を確認してからシステムプロキシを有効にする

初回起動後は設定画面を開き、コアが動作しているか、待ち受けポートが作成されているかを確認してください。サブスクリプションがない状態では、プロキシ画面に選択可能なノードが表示されないことがあります。これは想定どおりの状態で、すぐに再インストールする必要はありません。基本設定とサブスクリプションの読み込みが済むまでは、システムプロキシとTUNを無効にしておきましょう。コアが起動しない場合は、ログで最初に発生した設定の解析エラー、アドレスの競合、権限エラーを確認してください。最後の終了メッセージだけを見て判断しないようにしましょう。

ポートの競合は、旧クライアントが終了していない場合や、同じプログラムを複数起動した場合によく発生します。使用中のプロセスを確認してから対処してください。システムプロセスを手当たり次第に終了してはいけません。以下ではポート7897を例に確認します。実際に使うときは、設定画面に表示されたポートに置き換えてください。コマンドに表示されるプロセス番号は、プログラムを特定するためのものです。そのプロセスに問題があるとは限りません。確認後は、該当ソフトウェアの正規の終了操作でポートを解放してください。

netstat -ano | findstr ":7897"
tasklist /FI "PID eq 1234"

2行目の1234はプロセス番号の例です。実行前に、1行目で確認した実際の番号に置き換えてください。ポートを別の必要なプログラムが使用している場合は、クライアントの設定で未使用のポートに変更し、そのポートを使うツール側も合わせて更新してください。Windowsのシステムプロキシのポートだけを変えて、コアの待ち受けポートを変更しないのは避けましょう。設定が一致しないと、アプリは待ち受けているサービスがないポートにリクエストを送ることになります。

必要な場合にサービスモードをインストールする

Clash Verge Revのサービスモードは、必要な権限を伴うコアの処理をバックグラウンドサービスに任せる機能で、TUNを使う場合によく利用されます。「設定」から「サービスモード」の項目を探してインストールし、システムの案内に従って許可してください。画面のバージョンによって項目名が多少異なる場合があります。インストール後はサービスの状態を確認し、クライアントの指示に従って関連コンポーネントを再起動してください。サービスのインストールとTUNの有効化は別の状態です。

セキュリティソフトや組織の権限設定によって、サービスをインストールできない場合があります。具体的なエラーを記録し、Windowsのサービス管理ツールでサービスが登録されているか、起動できるかを確認してください。スイッチの色だけでインストール成功と判断したり、出所不明の修復コマンドを繰り返し実行したりしないでください。通常のシステムプロキシは使えるのにサービスのインストールに失敗する場合は、システムプロキシを維持したまま、サービスの権限だけを切り分けてください。動作中の通信経路まで壊さずに済みます。

インストール後は、クライアントが正常に起動すること、コアのログに起動失敗が繰り返し記録されないこと、ポートが想定どおりであること、終了と再起動を問題なく行えることを確認します。スタートアップは接続確認後に有効にしてください。「画面の起動」「バックグラウンドサービスの起動」「システムプロキシの自動復元」は、それぞれ別の設定です。設定、プロキシ、ログの画面についてはClash Verge Revの画面ガイドをご覧ください。

4. サブスクリプションの読み込みと設定の反映

読み込み後に有効な設定を選ぶ

まず、利用中のクライアントまたはmihomoに対応したサブスクリプションURLをサービス提供元から入手します。チャットアプリが追加した句読点、空白、改行が入らないよう、URLを正確にコピーしてください。クライアントの「設定」画面にある「設定」または「サブスクリプション」ページを開き、入力欄にURLを貼り付けて「読み込み」をクリックします。ダウンロード完了後に新しい項目が表示されたら、それを明示的に選択または有効化してください。リストに設定カードが表示されただけでは、切り替えが完了したとは限りません。

有効な設定が読み込まれたら、「プロキシ」画面でプロキシグループが表示されるか確認してください。ノードは表示されても、想定したルールやグループがない場合は、サブスクリプションがノード情報だけを返しているのか、設定一式を返しているのかを確認します。クライアントによってはテンプレートからグループやルールを生成できますが、完全なYAMLの読み込みが必要なものもあります。サービス提供元が案内する方法を使い、サブスクリプションURLを不明なオンライン変換サイトに入力しないでください。変換時にURL内の認証情報が漏れるおそれがあります。

ダウンロード失敗と解析失敗を区別する

サブスクリプションをダウンロードできない場合は、まず現在のネットワークからサブスクリプションのドメインにアクセスできるか確認し、次にログでHTTPステータスと接続エラーを調べます。認証エラーは、URLの期限切れやアカウント状態の変更が原因かもしれません。接続タイムアウトは、DNS、ネットワーク制限、サービス提供元の障害などが考えられます。ブラウザーでページを開けても、クライアントがサブスクリプションを取得できるとは限りません。プロキシ経路、証明書環境、リクエストの動作が異なる場合があります。

ダウンロードは完了しても解析に失敗する場合は、取得した内容と設定形式を確認してください。サーバーから想定したYAMLではなく、ログインページやエラーメッセージ、互換性のない項目が返されている可能性があります。エラーが示す項目と行番号を確認し、対応範囲をサブスクリプションの提供元に問い合わせてください。個人情報を含む設定全体を、公開の質問サイトに貼り付けてはいけません。問い合わせる場合も、サーバー情報、認証情報、サブスクリプションURLを除いたエラーの前後だけを共有してください。

元の設定・上書き設定・実行設定を区別する

サブスクリプションを更新すると、リモートの内容が再取得されます。ダウンロード済みファイルを直接編集すると、次回の更新で上書きされる場合があります。実行時に合成された設定を直接編集しても、設定の切り替えやコアの再起動で変更が消えることがあります。長期的なカスタマイズは、クライアントが対応する上書き、マージ、スクリプトの仕組みに保存し、適用順序も確認してください。小さな変更を保存してコアを再読み込みし、最終的な設定に反映されたことを確認します。その後、サブスクリプションを更新しても変更が残るか確認しましょう。

設定の階層と管理する場所
階層確認する内容
リモートのサブスクリプションサービス提供元が配布するノード、プロキシグループ、ルール。更新時に再ダウンロードされます。
ローカルの上書き設定長期的に維持したいポート、DNS、カスタムルール。適用結果はクライアントのマージ方式によって異なります。
実行設定コアが実際に読み込んだ合成結果。有効状態の確認に使い、唯一のバックアップとして扱わないでください。

YAMLはインデントとデータ型に厳密です。インデントにはスペースを使い、タブを混在させないでください。リスト項目のハイフンを残し、特殊文字を含む文字列は正しく引用符で囲みます。同じ名前のキーを複数記述しても「追記」にはなりません。パーサーによってはエラーになったり、どれか1つだけが残ったりします。完全な設定ファイルを2つそのまま連結しないでください。ノード、プロキシグループ、ルール、DNSはそれぞれの構造に沿ってマージし、参照先のグループ名が存在することも確認しましょう。

自動更新の間隔はサービス提供元の案内を参考に設定し、頻繁にしすぎないようにしましょう。更新前に復元可能な設定とローカルの上書きを保存してください。更新後は、グループ内で以前選択していたノードが引き続き存在するか確認します。ノード名が変わると、以前の選択が無効になり、グループが既定の選択に戻ったり出口が変わったりする場合があります。重要な用途では、更新完了の表示だけで判断せず、ルールと出口も改めて確認してください。

サブスクリプションの読み込み後は、有効な設定が選択されていること、コアへの読み込みに成功したこと、プロキシグループが表示されること、少なくとも1つの利用可能な出口を選べることを確認します。ローカルファイルから移行する場合は、信頼できるデバイスから取得したことを確認し、必要な認証情報も保持してください。クラウドストレージやチャットアプリで転送する前に、公開範囲を検討しましょう。ファイルを読み込めても、公開共有してよいとは限りません。ノードのパスワード、コントロールインターフェースのキー、サブスクリプションURLをスクリーンショットに写さないでください。

5. プロキシモードと接続確認

通信の入口と出口の選択を区別する

システムプロキシは「アプリからコアへ通信を送る方法」を決めます。ルール、グローバル、ダイレクトの各モードは「コアに入った通信をどの経路へ流すか」を決めます。この2種類の設定は互いに置き換えられません。グローバルモードにしても、Windowsのすべてのアプリが自動的に通信を預けるわけではありません。システムプロキシを有効にしても、すべてのリクエストが必ず遠隔ノードを経由するとは限りません。変更するのが通信の入口かルーティングかを確認してから接続履歴を見れば、設定の効果を理解しやすくなります。

日常の利用では、まず「ルール」モードを選び、コアに設定されたルールでリクエストを振り分けます。「グローバル」モードでは、コアに入った通信は通常、グローバル用プロキシグループに渡されます。グループ内で適切な出口を選んでください。ダイレクトが選択されていれば、直接接続される場合もあります。「ダイレクト」モードでは、コアに入った通信をそのまま直接送信します。どのモードも、コアに入っていない通信には適用されません。また、遠隔アカウントやノードが有効かどうかを確認する機能もありません。

システムプロキシを有効にしてアプリの動作を確認する

設定とノードの準備ができたら、クライアントで「システムプロキシ」を有効にします。Windowsの「設定 → ネットワークとインターネット → プロキシ」を開き、現在の状態とアドレス、ポートが稼働中のローカル待ち受け先を指しているか確認してください。クライアントによってプロキシ設定の管理方法が異なり、組織のポリシーが上書きする場合もあります。状態が一致しない場合は、まずほかのプロキシソフトを終了しましょう。複数の画面から設定を何度も変更して競合させないでください。

ブラウザーは通常、システムプロキシを利用しますが、拡張機能、個別のプロキシ設定、管理ポリシーによって動作が変わる場合があります。既存の接続を終了してテストページを開き直し、クライアントの接続画面も確認してください。ページを再読み込みするだけでは、古い接続やローカルキャッシュが使われる可能性があり、新しい設定の反映を確認できません。テストでは判別しやすい新しいリクエストを発生させ、ドメイン、プロキシ経路、接続状態を確認しましょう。ウェブページの隅に表示される通知だけを唯一の根拠にしないでください。

コマンドラインのツールは、Windowsのシステムプロキシを自動的に使うとは限りません。ローカルHTTPプロキシへの接続だけを確認する場合は、プロキシアドレスを明示できます。以下では混合ポート7897を例にしています。実行前に、現在使用中のポートに置き換えてください。このコマンドは接続先からの応答を確認するものです。すべてのネットワークで特定の公開サイトに接続できることや、すべてのアプリがプロキシを経由していることを保証するものではありません。

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

HTTPレスポンスが返れば、そのリクエストが接続先との間を往復できたことは確認できます。ただし、どのプロキシ経路を通ったかは、クライアント側でも確認が必要です。ローカルポートへの接続に失敗する場合は、コアと待ち受け状態を確認してください。ローカルで受け付けた後に遠隔側でタイムアウトする場合は、出口を調べます。証明書エラーが表示された場合は、デバイスの時刻と信頼できる証明書の環境を確認し、証明書検証を無視するオプションを追加しないでください。複数のノードに切り替えてページの再読み込みを繰り返すより、エラーが発生した段階に応じて対処するほうが効果的です。

速度テストとグローバルモードの使い方

ノードの速度テストでは、クライアントに設定されたテスト先へリクエストを送信します。結果はテスト先、ネットワーク経路、プロトコルの実装に左右されます。テストに成功しても、ほかのサイトへ接続できるとは限りません。失敗しても、ノードがまったく使えないとは限りません。実際の問題を調べるときは、接続したいサイトを開いて、名前解決の失敗、誤ったルール判定、接続先からの拒否がないか確認してください。ノードを比較する場合は条件をそろえ、異なる時間に行った1回だけの測定値で長期的な品質を判断しないでください。

クライアントを終了する前に、特に設定が自動で復元されると確認できていない場合は、システムプロキシを無効にしてください。異常終了後にブラウザーがインターネットへ接続できない場合は、Windowsのプロキシ設定が停止済みのローカルポートを指していないか確認します。ネットワークを復旧してからクライアントを再起動してください。プロキシ設定の残留を直すために、すべてのネットワークアダプターをすぐにリセットする必要はありません。システムプロキシで主な用途を満たせるなら、まずはその方法を維持し、次の章で出口の選択を確認しましょう。

6. ルール設定とカスタマイズ

ルールの判定順を理解する

ルールモードでは通常、上から順に照合し、最初に一致したルールのポリシーが適用されます。より具体的なルールを広範なルールより前に置き、最後に全体のフォールバックとなるMATCHを配置してください。ルールを追加したら、リクエストに必要な情報が含まれているか確認します。ドメインルールは判別可能なドメイン名、アドレス範囲ルールは接続先IP、プロセスルールはプラットフォームの権限とコアのプロセス情報取得機能に依存します。アプリ名だけを見て一致すると判断することはできません。

よく使われるDOMAINは完全一致するドメイン名、DOMAIN-SUFFIXはドメインとそのサブドメイン、IP-CIDRはIPアドレス範囲に一致します。組み込みポリシーのDIRECTは直接接続、REJECTは通信の拒否を意味します。そのほかのポリシー名は、既存のプロキシグループやノードを参照するのが一般的です。大文字・小文字やスペースも含め、名前は完全に一致させてください。存在しないグループを参照すると、読み込みに失敗したり、想定外の経路になったりすることがあります。

まず検証しやすいルールを1つ試す

以下は、指定したドメイン、ループバックアドレス、LAN内アドレスを直接接続するルールの例です。ノードやプロキシグループを含む完全な設定ではなく、リモートのサブスクリプションとそのまま置き換えることもできません。ローカルのルール上書きを使う場合は、必要な項目を既存のルール一覧の適切な位置に追加し、末尾のポリシーは残してください。LAN内アドレスをすべて直接接続するべきかどうかは、デバイスが接続しているネットワークと実際のセキュリティ境界を考慮して判断します。

rules:
  - DOMAIN,example.com,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

no-resolveは、アドレスルールの判定だけを目的とした名前解決を行わないようにする指定です。DNS全体を無効にするものではありません。リクエストが先にあるドメインルールに一致した場合、後続のアドレスルールは判定されません。トラブルシューティングでは、まず接続の詳細を開いて、実際に一致したルールとその並び順を確認してください。「優先度を上げる」ためにすべてのアドレスルールを先頭へ移動してはいけません。既存のドメイン別ルーティングが変わるおそれがあります。

ルールセットでルールを管理する

ルールが増えてきたら、rule-providersでリモートまたはローカルのルールセットを管理し、RULE-SETで参照できます。ルールセットのbehavior、形式、内容は対応させてください。ドメインの一覧を、変換せずに従来形式のルール一覧として使うことはできません。リソースを取得できない場合は、ダウンロード先、キャッシュファイル、ログを確認してください。サブスクリプションを更新できても、リモートのルールリソースがすべて更新されたとは限りません。

ルールソースを選ぶときは、一度に大量のソースを追加するより、メンテナンス範囲と更新方法を確認してください。複数のルールセットが同じ接続先に適用される場合、最終的な動作は参照順で決まります。業務アプリ、決済サイト、LAN内デバイスに例外を設定する場合は、理由と確認日を記録しておきましょう。後からルールの目的が分からなくなるのを防げます。元の設定を更新した後は、カスタムルールが想定した位置にマージされているかも確認してください。

ルールの問題を確認する順序
症状最初に確認する項目
接続先が誤った出口を通る現在のモード、適用されたルール、ルールの順序、プロキシグループの選択。
ルールに一致しない実際のリクエストのドメイン名またはIP、接続の再利用、プロセス情報を取得できるか。
変更後に読み込みに失敗するYAMLのインデント、ポリシー名、ルールセットの参照、ログに最初に記録された解析エラー。

振り分けを確認するときは、既存の接続を終了してからリクエストを再送してください。すでに確立した接続は、ルールを変更しても通常すぐには別の出口に切り替わりません。ブラウザーやデスクトップアプリは複数のドメインへ同時にリクエストすることがあり、ページのメインドメインに対するルールだけでは、画像、認証、APIの通信をカバーできない場合があります。まず接続履歴で不足しているリクエストを確認し、必要なルールだけ追加してください。範囲の広すぎるキーワードルールで、無関係な通信まで一緒に振り分けるのは避けましょう。

ルーティングとDNSは分けて考えてください。ルールは出口を決めますが、ドメインの名前解決はローカル、コア、遠隔のいずれかで行われる場合があります。アドレスルールも名前解決の結果に影響されることがあります。名前解決に問題がある場合は、ルールを次々に追加して隠そうとしないでください。まずDNSの応答と接続先を確認し、そのうえで名前解決の設定を見直します。問題を再現するリクエストを記録しておけば、TUNやFake-IPを設定するときの比較基準になります。

7. TUNモードとDNSの確認

仮想ネットワークアダプターによる通信の制御が必要か確認する

TUNモードは、仮想ネットワークアダプターとルーティングを使って通信を制御します。システムプロキシに従わないアプリへの対応に向いていますが、制御範囲はOS、ルーティング、除外設定、クライアントの実装によって異なります。あらゆる問題を解決するための強化スイッチではありません。ブラウザーは正常で特定のアプリだけが失敗する場合は、まずアプリが実際に使うネットワークインターフェースとプロトコルを確認してから、TUNが必要か判断してください。問題がノードの認証やルールの誤りにある場合、通信の入口を変えても出口の問題は解決しません。

有効にする前に、ほかのVPN、仮想ネットワークアダプター型プロキシ、同様の通信制御ツールを終了し、現在のシステムプロキシの状態を記録してください。Clash Verge Revでは、サービスモードがインストールされ、正常に動作していることを確認してからTUNを有効にします。初回のテストでは、リクエストの経路を分かりやすくするため、システムプロキシを一時的に無効にできます。クライアントが特定の組み合わせを要求する場合は、その案内に従ってください。有効にした後は、通常のウェブサイト、LAN内のリソース、必要な業務アプリを確認しましょう。1つのページだけを試して長期間使い続けるのは避けてください。

よく使われるTUNの設定項目

以下はmihomo設定のTUNセクションの例です。項目の構造を示すもので、実行可能な完全設定ではありません。クライアントの画面から同じ内容が生成される場合は、画面設定か手書き設定のどちらか一方で管理し、上書きの競合を避けましょう。対応する項目は実際のコアによって異なります。読み込みエラーが発生したら、該当バージョンのドキュメントを確認してください。エラー項目をすべて削除して、動作が分からない通信制御を無理に有効化しないでください。

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

enableはTUNを有効にするかどうか、stackはネットワークスタックの実装、auto-routeはルートの自動設定、auto-detect-interfaceは送信インターフェースの検出を制御します。dns-hijackの例は、対象となる通常のDNS通信を受け取るための設定です。HTTPSなどの暗号化された通信でアプリが独自に行う名前解決をすべて対象にするものではなく、コアのDNS設定全体を置き換えるものでもありません。

DNSの経路を個別に確認する

Fake-IPモードでは、予約済みアドレスをドメインに割り当て、後続の接続でコアが元のドメイン名を復元してルーティングに使います。このアドレスは、接続先サーバーの実際のグローバルIPではありません。名前解決の結果がFake-IPのアドレス範囲内でも、すぐにDNS汚染と判断しないでください。コアのログ、接続の詳細、最終的な応答を確認します。アプリが実際のIPアドレスを必要とする場合や互換性の問題がある場合は、対象を絞ってfake-ip-filterを設定してください。

DNSモードを変更しても、システムやアプリのキャッシュに以前の結果が残る場合があります。影響を受けるアプリを終了し、必要に応じてシステムのDNSキャッシュを削除してから接続し直してください。以下のWindowsコマンドはシステムの名前解決キャッシュを更新するもので、ブラウザー内部のキャッシュをすべて削除したり、遠隔サービスの問題を解決したりするものではありません。実行が成功しただけでネットワーク障害が解消したと判断せず、新しいリクエストの状態を確認してください。

ipconfig /flushdns

会社や学校のネットワーク、仮想マシン、複数のネットワークアダプターを使う環境では、ルーティングの境界に特に注意してください。デフォルトインターフェースの変更やWi-Fiと有線LANの切り替えによって、自動検出の結果が想定と異なる場合があります。LAN内のプリンター、共有フォルダー、社内ドメインへの経路を維持する必要がある場合もあります。このような問題が起きたら、まずTUNを無効にして復旧するか確認し、その後ルーティングと名前解決を調べてください。ネットワークアダプターの削除やシステム全体のネットワークリセットをいきなり行うのは避けましょう。

WindowsのUWPアプリには、ループバック接続に関する独自の制限もあります。ローカルのシステムプロキシを使う際、サンドボックスの制限によってループバックアドレスに接続できない場合があります。通常のデスクトップブラウザーとは異なる問題です。UWPアプリのループバック制限と例外設定を参考に、対象のアプリだけを確認してください。すべてのアプリの権限をまとめて変更しないでください。名前解決の仕組みや互換性について詳しくは、Fake-IPとredir-hostの違いをご覧ください。まずマッピングの仕組みを理解してから、除外リストを調整しましょう。

8. 日常のメンテナンスとトラブルシューティング

復元可能な設定を保存する

安定して使えるようになったら、管理対象をクライアント、コア、サブスクリプション、ローカルの上書き設定に分けましょう。クライアントを更新すると画面や同梱コアが変わる場合があります。サブスクリプションの更新ではノードやルールが変わり、上書き設定の変更は最終的な実行設定に影響します。一度に変更するのは1種類だけにし、変更前後の状態を記録してください。問題が発生した際に、どの更新が接続を変えたのか推測せず、確認済みの手順まで戻せます。

バックアップには、サブスクリプションURLの安全な保管場所、ローカルのカスタムルール、上書きスクリプト、必要な設定を含めてください。ログや一時キャッシュをすべてバックアップする必要はありません。実行設定には機密情報や端末固有のパスが含まれる場合があり、新しいデバイスへ移してもそのまま使えるとは限りません。暗号化されたストレージやアクセスを制限した場所に保存し、同期ソフトからほかのメンバーに公開されないか確認してください。バックアップファイル自体にもアクセス制限が必要です。

ログを段階ごとに読み解く

接続が切れたら、発生時刻、接続中のネットワーク、影響を受けたアプリ、直近の変更を記録します。まずコアが動作しているか確認し、次にシステムプロキシやTUNが想定どおり有効か確認してください。特定のサイトだけが使えない場合は、すぐにシステム全体を再起動せず、別のアプリや接続先で比較します。すべてのアプリで失敗する場合は、ローカルの待ち受け、ネットワークインターフェース、DNS、サービスの状態を順に確認し、問題の範囲を絞りましょう。

設定の解析エラーは項目とインデント、ローカルポートのバインド失敗は使用中のプロセス、名前解決エラーはDNSを確認します。遠隔とのハンドシェイクや認証に失敗する場合は、プロトコル設定とサービス提供元の状態を調べてください。タイムアウトだけでは、原因を特定できません。何らかの処理が制限時間内に完了しなかったことを示すだけです。サブスクリプションの取得、接続先への通信、ルールリソースの更新、ノードのテストのどの段階で発生したかを周辺のログから確認し、無関係な方法で修復しないようにしましょう。

再現のために一時的にログの詳細度を上げるのは有効ですが、大量のデバッグログを長期間残さないでください。詳細ログには、アクセスしたドメイン、接続先アドレス、選択されたポリシーが記録される場合があります。共有前に機密情報を削除してください。問い合わせるときは、OSの種類、クライアント名、使用中の機能、発生時刻、最小限の再現手順を伝えれば十分です。サブスクリプションURL、ノードの認証情報、コントロールインターフェースの設定全体は共有しないでください。スクリーンショットにアドレスバー、サイドバー、通知の個人情報が写っていないかも確認しましょう。

実行しやすい順序で元に戻す

ルール変更後に接続できなくなった場合は、最後に追加したルールをまとめて取り消して再読み込みします。サブスクリプション更新後に失敗した場合は、グループの選択状態と追加された設定項目を確認し、それから以前のバックアップへの復元を検討します。TUNの有効化後に失敗した場合は、まずTUNを無効にしてシステムプロキシの経路で接続できるか確認してください。クライアントの異常終了後にネットワークが使えない場合は、Windowsにローカルプロキシの設定が残っていないか調べます。安全機能を手当たり次第に無効にするのではなく、以前に動作確認した状態へ戻してください。

メンテナンス時の確認リスト
操作完了後の確認
サブスクリプションの更新有効な設定、ノードの選択、ルールセットの読み込み、実際の接続先へのアクセス。
クライアントの更新コアの起動、サービスの状態、待ち受けポート、既存の上書き設定の反映状況。
ネットワークの切り替え送信インターフェース、DNS、LANへのアクセス、TUNのルーティング。
デバイスの移行再インストール、設定の再読み込み、カスタム設定の個別復元。一時的な状態をそのままコピーしない。

スタートアップは、動作が安定してから有効にしましょう。デバイスを再起動して一通り確認し、サービス、画面、プロキシ設定の起動順が想定どおりか確かめます。システムプロキシがコアの待ち受けより先に復元されると、起動直後に一時的な接続エラーが起きる場合があります。スリープからの復帰やネットワークの切り替えも個別に確認してください。ネットワークインターフェースやルートが変わることがあります。復帰後に限って問題が起きる場合は、再インストールを繰り返すより、その時点のログを残すほうが役立ちます。

ノードを頻繁に切り替えることを、日常のメンテナンスにしないでください。まずルールと出口が正しいかを確認し、そのうえで別の利用可能なノードを試します。1回の速度測定だけで候補をすべて削除しないでください。詳しく調べる場合は、ヘルプセンターの項目から該当する症状を探し、機密情報を除いたエラーの前後を添えてください。メンテナンスの目的は不確かな変更を減らし、最後に動作確認できた状態を説明・復元できるようにすることです。

9. 応用設定と学習の進め方

最終的な実行設定を読む

前半の8章を終えたら、応用設定の第一歩は項目を増やすことではなく、クライアントからコアに渡される最終設定を理解することです。元のサブスクリプション、ローカルの上書き設定、実行結果を見比べ、待ち受けポート、プロキシグループ、ルール、DNSがそれぞれどこで定義されたか確認します。小さな変更を1つ加えて合成結果の位置を調べ、実際の動作も検証してください。項目を誰が生成しているか説明できない場合は、重要な用途をその設定に依存させないようにしましょう。

次に、プロキシグループの動作を学びます。手動選択グループは出口を明示して選ぶのに適し、自動テストやフォールバックグループはテスト条件に応じて選択します。テスト先、間隔、許容値、遅延検出の設定が結果に影響します。名前に「自動」とあっても、すべての用途に最適という意味ではありません。まず重要度の低い通信で試してから、適用範囲を広げてください。手動で戻せる選択肢を1つ残しておくと、自動選択による変化を切り分けやすくなります。

リソースと名前解決の設定を分けて考える

3つ目の段階で、proxy-providersとrule-providersを学びます。前者はプロキシのリソース、後者はルールのリソースを管理し、参照関係と更新方法も異なります。リソースを分けると設定の重複を減らせますが、パス、キャッシュ、リモートからのダウンロードへの依存が増えます。各リソースの取得に失敗した場合の動作を確認し、初回起動時にキャッシュがなくても読み込みを完了できるか検証してください。ローカルにキャッシュがある状態だけで、設定の信頼性を判断しないようにしましょう。

4つ目の段階では、DNSを詳しく学びます。OS、ブラウザー、コア、遠隔サーバーのどの段階で名前解決するかを整理し、アプリ独自の暗号化DNSが使われていないか確認してください。次に、ドメインに応じたDNSの選択、直接接続先の名前解決、プロキシサーバーのアドレス解決などを学びます。設定項目が相互に依存し、循環参照になる場合があります。たとえばプロキシサーバーへの接続に先立ってそのアドレスの名前解決が必要なのに、名前解決にもプロキシ接続が必要になる状態です。

循環が発生した場合は、まず検証済みの名前解決経路に戻し、その後設定を1つずつ追加してください。公開DNSサーバーのアドレスを理由なく大量に並べても、互換性が高まるわけではありません。社内ドメインの名前解決には、組織が提供するDNS環境が必要な場合があります。公開DNSサービスが社内のレコードを把握しているとは限りません。ウェブサイトが開けても業務リソースが使えなくなることを防ぐため、ルールによる出口、DNSの選択、LANへのアクセスをまとめて確認しましょう。

コントロールインターフェース・スクリプト・LAN共有を確認する

コントロールインターフェースは、クライアントや管理ツールからコアを操作するための接続口です。一般のアプリが使うプロキシポートではありません。external-controllerを設定する場合は、まずローカルからのみアクセスできる状態にし、認証方式と待ち受け範囲を理解してから公開範囲の拡大を検討してください。管理の利便性のために、インターネットへ直接公開してはいけません。また、コントロールインターフェースのポートをHTTPプロキシのポートとしてブラウザーに設定しないでください。設定を変更できるインターフェースは、通常のウェブページではなく管理用の入口として扱う必要があります。

LAN共有では、allow-lan、バインドアドレス、Windowsファイアウォールの設定も関係します。スイッチを有効にするだけでは、ほかのデバイスから使えるとは限らず、アクセス範囲が意図せず広がるおそれもあります。共有する場合は、まず信頼できるネットワーク、接続元のデバイス、ポートを限定し、別のデバイスから動作を確認してください。公共Wi-Fi、ゲストネットワーク、組織のネットワークでは、待ち受けを安易に公開しないでください。テストが済んだら、公開範囲を必要最小限に戻し、入口を開いたままにしないようにしましょう。

拡張スクリプトや設定の上書きは、繰り返し作業を減らすのに役立ちます。ただし、スクリプトは実行可能な処理です。配布元と変更範囲を確認してください。対象項目だけを変更し、プロキシグループの削除、DNSの書き換え、コントロールインターフェースの待ち受け範囲の拡大が起きないことを確かめましょう。サブスクリプションを変更した後も再検証が必要です。スクリプトが特定のグループ名を前提としている場合、名前が変わってもスクリプトが実行されるだけでは、正しい設定が生成されたとは限りません。スクリプトなしの基本設定を比較用に保存してください。

最後に学習の流れを確認しましょう。入門ガイドで最短の接続手順を復習し、このガイドで動作の仕組みを理解します。ログと接続画面で仮説を検証し、長期的に必要な変更は管理しやすい上書き設定に記録してください。一般的なデスクトップユーザーが、すぐに独立したコアの運用に移行する必要はありません。サーバーやルーター、自動管理が必要になった段階で、サービス管理、ファイル権限、ネットワークの境界を学べば十分です。設定が複雑になるほど、シンプルで検証済みの、復元可能な経路を残すことが重要です。

Clashをダウンロード