Clash使い方ガイド：インストール・サブスクリプション・ルール設定・TUNまで

1. 基本概念と通信経路

クライアント、コア、サービスを区別する

Clashのエコシステムでは、クライアントが操作画面を提供し、コアが設定を解析して通信を処理し、ルールを適用します。実際の通信出口を提供するのはリモートサービスです。この3つは別の役割です。クライアントをインストールしても、利用可能なノードが自動で作成されるわけではありません。サブスクリプションもクライアントのアカウントではありません。問題が起きたら、画面、コアの設定、リモートサービスのどこに原因があるかを見極めると、すべてをインストール失敗と決めつけずに済みます。

多くのクライアントはmihomoコアを使用しますが、実際に使える機能は同梱されたコアのビルド、システム権限、クライアントの実装によって異なります。ファイルを読み込めても、すべての項目が有効になったとは限りません。反対に、コアが機能に対応していても、クライアント側に設定項目がない場合があります。本ガイドのYAML例はmihomoで一般的な構文をもとにしています。適用前に、使用中のクライアントで設定を反映する方法を確認してください。

アクセスを4つの段階に分けて考える

ブラウザーでWebサイトにアクセスすると、通常はドメイン名を解決し、接続を確立して暗号化ハンドシェイクを行い、最後にアプリケーションデータをやり取りします。プロキシは複数の段階に関わることがあります。システムプロキシはアプリにローカルポートへリクエストを渡すよう指示し、ルールが通信先の方針を決め、リモートノードが接続先のサイトに接続します。どこか1つでも失敗するとWebページが開かないため、ブラウザーに表示された最後のエラーだけでは原因を特定できないことがあります。

ローカルの待ち受けアドレスにはループバックアドレスがよく使われます。これは、同じ端末からの接続だけを受け付けるアドレスです。ポートはアプリがコアに接続する入口であり、リモートノードのサーバーアドレスやサービスポートとは異なります。ローカルポートを変更したら、ブラウザーやターミナルに手動で設定したプロキシアドレスも変更してください。リモートノードの設定値は通常サブスクリプションから提供されます。ローカルポートの競合を理由に変更すると、別々の問題が混同されるため避けましょう。

プロキシグループは通信先を選ぶ仕組みであり、ノードそのものではありません。手動選択グループではメンバーを指定でき、自動テストグループでは設定されたテスト条件に応じてメンバーが選ばれ、フェイルオーバーグループでは利用可能なメンバーの順序が重視されます。ルールの転送先にはプロキシグループのほか、DIRECTなどの組み込みアクションも指定できます。グループ名だけで動作を判断せず、グループの種類、メンバー、現在の選択状態を確認してください。

通信制御、ルール振り分け、名前解決の役割を理解する

システムプロキシ、TUN、ルールモードはそれぞれ異なる問題に対応します。システムプロキシとTUNは主に通信をコアへ渡す方法を決め、ルールモードはコアに渡された通信の振り分け先を決めます。DNS設定はドメイン名の解決方法と、解決情報をルール判定に使う方法に関わります。これらは組み合わせて使うもので、互いに置き換えられるものではありません。TUNを有効にしてもルールモードは使えます。また、システムプロキシを無効にしても、すべての通信が必ずコアを通らなくなるとは限りません。

設定内のDNSと、端末が接続中のネットワークから提供されるDNSが同時に使われる場合もあります。アプリ独自の暗号化DNS、ブラウザー内蔵の名前解決、LAN内のドメイン名が関わると、通信経路はさらに複雑になります。すぐに名前解決の方式を変更する必要はありませんが、アクセス結果に問題があるときはDNSを個別に確認してください。IPアドレスへの直接アクセスとドメイン名でのアクセスで結果が異なる場合、名前解決の経路を調べる手がかりになります。

最初の検証では一般的なWebページを1つ選び、クライアントの接続ログも確認します。ログには接続先のドメイン名またはアドレス、適用された方針、接続状態が表示されるはずです。ログに記録がなければ、まず通信を受け付ける入口を確認します。記録はあるのに接続できない場合は、ノード、名前解決、リモート側のエラーを調べてください。まず問題の境界を見つけ、範囲を絞り込む方法は以降の章でも使えます。何度も再インストールするより、原因の手がかりを残しやすくなります。

2. プラットフォームと用途からクライアントを選ぶ

操作方法を決めてから機能を比較する

普段使いのGUIクライアントなら、まずClash Plusを候補にし、使用するOSや必要な機能に応じてほかのクライアントと比較しましょう。選ぶ際は機能の数より、サブスクリプションの更新、プロキシグループの選択、接続ログ、権限に関する案内が分かりやすいかを重視してください。インストール前にダウンロードセンターで使用中のプラットフォーム向けの配布先を確認し、システムのアーキテクチャとインストール形式を確かめましょう。先に複数のアプリをダウンロードし、似た画面の間で設定を移し替える必要はありません。

デスクトップでは、Clash Verge Rev、FlClash、Clash Nyanpasuを異なる画面や使い方の比較対象にできます。各クライアントの設定が項目ごとにそのまま移せるとは限りません。サブスクリプションの拡張機能、サービスモード、コアの更新、ログの確認方法などに違いがあります。端末を長期間運用するなら、初回起動時の画面だけでなく、設定の保存場所と復元方法が分かることも重要です。

プラットフォーム	選択肢	事前に確認する点
Windows	Clash Plus。Clash Verge Rev、FlClash、Clash Nyanpasuも比較できます	CPUアーキテクチャ、サービス権限、システムプロキシの復元
macOS	Clash Plus。Clash Verge Rev、FlClashも比較できます	Apple SiliconかIntelか、ネットワーク拡張の許可
Android	Clash Plus。Clash Meta for Android、FlClash、Surfboardも比較できます	VPNの許可、バックグラウンド制限、サブスクリプションの形式
iOS	Clash Plus	アプリストアでの入手可否、VPNの許可、システムのネットワーク制限
Linux	Clash Verge Rev、FlClash。サーバー用途ではmihomoも検討	パッケージ形式、デスクトップ環境、サービスの管理方法

名称よりアーキテクチャとシステム連携を確認

CPUアーキテクチャはメーカー名だけで判断せず、システム情報で確認してください。macOS用のインストーラーはApple SiliconとIntelで異なります。Windows端末もアーキテクチャが異なる場合があります。Androidでは汎用パッケージと特定アーキテクチャ向けパッケージで対応範囲が異なります。ダウンロードページに掲載された選択肢から選び、ファイル名の規則をもとに、存在しないインストーラーのURLを推測しないでください。

Linuxでは、ディストリビューションごとのパッケージ管理方法も確認が必要です。Debian系向けのパッケージをRPM系ディストリビューションにそのままインストールすることはできません。GUIクライアントはデスクトップ環境向けです。CLIのコアを使う場合は、設定ディレクトリ、サービスの起動、ログの確認を自分で管理します。GUIのないサーバーでは、プロキシを使うためにデスクトップ環境一式を追加する必要はありません。コアとサービスマネージャーを使う方が構成を把握しやすい場合があります。

モバイル端末では、通常システムのVPNインターフェースを使って通信を制御します。同時にこの入口を使用できる関連サービスは1つだけという制限が一般的です。別のセキュリティアプリ、仕事用プロファイル、通信最適化アプリが競合する場合があります。デスクトップでも仮想ネットワークアダプターやルーティングが競合することがあります。企業VPNや特別なLAN接続が必要なら、すべてのネットワークツールを同時に使えると想定せず、通信を制御する範囲を明確に指定できるかを優先して選びましょう。

サブスクリプションの互換性とメンテナンス状況を確認する

サブスクリプションの読み込みに対応していても、実際に受け付けられる形式は異なる場合があります。Clashの完全なYAML、ノード一覧だけのファイル、別クライアントの設定は同じ入力形式ではありません。特にSurfboardを選ぶ場合は、提供元が対応する形式を提供しているか確認してください。ファイルの拡張子だけで互換性を判断することはできません。設定を変換するとルール、プロキシグループ、プロトコルのパラメーターが欠落する場合があります。変換に成功しても、実際の通信経路を確認してください。

Clash for WindowsとClashX Metaは、メンテナンスが終了したアーカイブ版です。既存環境がこれらに依存している場合は移行時の参考にできますが、新しい端末では現在もメンテナンスされている選択肢を優先してください。古いアプリが起動しても、新しいサブスクリプションのプロトコルや設定項目を理解できるとは限りません。未知の項目、読み込まれないノード、コアのエラーが発生したら、サブスクリプションが無効だと決めつける前に機能の違いを確認しましょう。

iOSでClash Plusを使う場合は、ダウンロードセンターからApp Storeに進み、公式サイト clashplus.io の製品情報も確認できます。同じ名前のクライアントを複数のプラットフォームで使う場合も、デスクトップとモバイルで権限が同じだとは限りません。クライアントを選んだら、名称、システムアーキテクチャ、設定の入手元、主な用途を記録しておきましょう。トラブル対処に役立つ環境情報になります。

3. インストール、権限、基本環境の確認

初回起動時は変更を最小限にする

インストール前に、実行中の類似プロキシツールを終了し、現在のシステムプロキシ設定とVPNの状態を記録します。複数のアプリが同時にシステムプロキシを変更すると、後から起動したアプリが設定を上書きする場合があります。終了する順番によって復元結果も変わります。仕事用の設定がある端末は、先にバックアップしてください。旧アプリのアンインストールから移行を始めるのは避けましょう。新しいアプリで設定を読み込み、安定して動くことを確認してから旧環境を整理すれば、元に戻しやすくなります。

クライアントを起動したら、メイン画面、設定画面、ログ画面が正常に表示されることを確認します。最初は自動起動、TUN、複雑な上書き設定を有効にしないでください。サブスクリプションやノードがまだないのは正常な状態であり、インストール異常ではありません。起動直後にアプリが終了する場合は、同じファイルを何度もダウンロードするのではなく、OSとの互換性、アーキテクチャ、インストール先のアクセス権、セキュリティソフトの検出ログを確認しましょう。

権限の要求と実際の用途を確認する

デスクトップクライアントは、システムサービス、仮想ネットワークアダプター、ネットワーク拡張機能のために追加の許可を求めることがあります。用途を理解したうえで許可してください。GUIアプリ全体を常に管理者権限で実行するのは、一般的な解決策ではありません。システムプロキシは通常、現在のユーザーセッションに関係します。TUNはサービスコンポーネントやルーティングの変更を伴う場合があります。権限不足が疑われる場合は、クライアントの機能別のインストール手順を確認し、サービスが未インストールなのか、起動していないのかを切り分けましょう。

macOSではシステムの案内に従ってネットワーク関連の許可を行い、システム設定で状態を確認します。AndroidとiOSでは、通信制御を初めて有効にするとVPNの許可が表示されます。拒否しても画面は開きますが、通信が想定どおりコアに渡らないことがあります。会社や組織の管理下にある端末では、ポリシーによって権限が制限される場合があります。その場合は管理者の指示に従い、再インストールを繰り返して制限を回避しないでください。

インストール後は、設定ディレクトリとログの場所を確認し、クライアントがポータブルディレクトリ、ユーザーデータディレクトリ、独立したサービス用ディレクトリのどれを使うか把握します。画面で表示される設定ファイルと、コアに渡されて実行されるファイルは同じとは限りません。まず保存場所を記録し、ファイルの内容をすぐに手動編集する必要はありません。生成ファイルを直接変更すると、次回の保存や起動時にクライアントが上書きすることがあります。

ローカルポートと待ち受け範囲

ローカルポートはアプリがコアへ接続する入口です。ほかのプログラムがポートを使用していると、ログにバインド失敗やアドレス使用中などのエラーが表示されます。その場合は使用中のプログラムを終了するか、クライアントが対応している場所で待ち受けポートを変更し、手動で設定したプロキシアドレスも合わせて変更してください。ローカルの競合を避けるために、サブスクリプション内のリモートサービスポートを変更してはいけません。別の接続区間に影響します。

# ローカルの接続口を理解するための例。インターネットに接続できる完全な設定ではありません
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

例のmixed-portは、一般的なHTTPとSOCKSのプロキシリクエストを受け付けます。実際のポートはクライアントに表示される稼働中の値を使ってください。LANからのアクセスを無効にしておくと、最初のトラブル対処の範囲を端末内に絞れます。ほかの端末から使う場合は、待ち受けアドレス、ファイアウォール、アクセス制御も検討してください。LANアクセスを有効にするだけで、安全な共有環境が整うわけではありません。

基本確認のゴールは、特定のサイトにアクセスできることだけではありません。アプリが起動し、コアが継続的にエラーを出さず、待ち受け口を把握でき、終了後にネットワーク設定が復元されることも確認しましょう。その後でサブスクリプションを読み込めば、問題の範囲を絞りやすくなります。コマンドラインでLinuxに導入する場合はデスクトップクライアントとsystemdによる2つの導入方法を参照してください。デスクトップの自動起動とシステムサービスを同じ設定として扱わないようにしましょう。

4. サブスクリプションの読み込み、更新、設定の保持

まず読み込むデータの種類を確認する

サブスクリプションは通常、サービス提供元が管理する設定URLです。クライアントはURLからノード、プロキシグループ、ルールなどを取得します。個人を識別できる情報がURLに含まれる場合があるため、機密情報として扱ってください。公開スクリーンショット、問い合わせ内容、共有ドキュメントに載せないようにしましょう。読み込み前に、提供元が指定するクライアントの種類と形式を確認します。ブラウザーでURLを開けても、現在のコアに適した内容が返されるとは限りません。

クライアントのサブスクリプション、設定、または設定ファイルの画面を開き、リモート設定を追加してURLを貼り付け、保存します。更新が終わったら、その設定を現在使用するものに指定し、プロキシグループとノードが表示されるか確認してください。クライアントによっては、ダウンロードと有効化が別の操作です。ダウンロードだけではコアが古い設定のまま動作することがあります。設定に名前を付けられる場合は、入手元や用途を区別できる名前にします。URL全体を名前に含めるのは避けましょう。

初回読み込み後は、成功メッセージだけでなく、更新ログとコアの実行ログも確認してください。ダウンロード成功は応答を取得できたこと、解析成功はデータ構造を読み取れたこと、コアの読み込み成功は実行設定に反映されたことを示します。対応していないプロトコルのノードは、一部しか表示されない場合があります。ノード数の変化と警告を照らし合わせ、表示されないノードを提供元が削除したと決めつけないようにしましょう。

更新に失敗したら、リクエスト、内容、読み込みの順に確認

リクエストに失敗した場合は、URLを末尾のパラメーターまで完全にコピーしたか、余分な空白がないか確認します。続いて、エラーが名前解決の失敗、接続タイムアウト、アクセス拒否、リダイレクトの異常のどれに該当するかを見ます。ネットワークに接続できてもサブスクリプションを取得できない場合、更新リクエストの通信経路が原因かもしれません。更新通信を既存のプロキシ経由にするかどうかはクライアントによって異なります。現在のプロキシグループに自動で従うと決めつけず、該当する設定を確認してください。

内容を取得できても読み込めない場合は、返されたものがYAML、別形式、Webページのエラーメッセージのどれかを確認します。アカウントの状態ページ、ログインページ、CAPTCHA画面はプロキシ設定として読み込めません。サーバーが一時的に異常な内容を返した場合は、そのエラーページを保存して手動編集しないでください。元の利用可能な設定を残して提供元の復旧を待つ方が安全です。ローカルデータを消去せずに済み、使えるノードやルールも保持できます。

読み込み時にエラーが出たら、まずエラーが示す項目や行番号を確認してください。YAMLはインデントで階層を表すため、タブの使用、コロンの抜け、リストの階層ミスで解析に失敗することがあります。解析できるYAMLでも、存在しないプロキシグループをルールから参照するなど、意味上の問題が残る場合があります。テキスト形式の誤りと、コアによる検証エラーを区別しましょう。前者は構造、後者は項目の対応状況と参照名を確認します。

リモート設定と個人の変更を分けて管理する

サブスクリプションから生成されたファイルを直接編集すると、次回更新時に変更が失われることがあります。長く使う設定は、クライアントが用意する上書き、マージ、パッチ、ローカル拡張の機能に追加してください。機能名やマージ順序はクライアントによって異なります。まずログレベルの変更など小さな変更を加え、設定が保持されるか試します。その後、サブスクリプションを更新してコアを再起動し、実行設定に変更が残ることを確認してください。

配列のマージには特に注意が必要です。上書き機能によってはルール一覧全体を置き換え、ルールを1件追加するだけでは済まないことがあります。同名のプロキシグループを置き換える場合もあります。適用前にプレビューや出力した最終設定を確認し、元のノード、プロキシグループ、フォールバックルールが残っているか確かめてください。同じ項目を画面のスイッチ、ローカルファイル、リモートパッチの3か所で管理すると、実際に有効な値を説明しにくくなります。

更新後に通信が遅くなっても、すぐにクライアント一式を入れ替える必要はありません。更新前後で使用中のノード、プロキシグループの選択、適用されたルールが変わっていないか確認してください。ノード名が変更されると、以前の手動選択が無効になり、別のメンバーに切り替わることがあります。簡単な操作手順は入門ガイドのサブスクリプション設定を参照してください。この章では、更新を確認でき、元に戻せるメンテナンス作業にすることを重視します。定期更新を設定するだけでは十分ではありません。

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

ルール、グローバル、DIRECTの違い

普段の利用ではルールモードから始めましょう。コアに渡された通信はルール一覧に従って振り分けられます。直接接続が必要なサービスを残しつつ、特定のリクエストだけをプロキシに渡せます。グローバルモードでは、通常コアに渡された接続がグローバルポリシーに送られるため、短時間の比較テストに向いています。DIRECTモードはプロキシを経由しない状態を確認するのに使います。モード名が示すのはコア内での選択方法であり、すべてのアプリの通信が制御対象になるとは限りません。

よくある誤解は、グローバルモードに切り替えると端末上のすべての通信がプロキシを通るというものです。システムプロキシを参照しないアプリは、そもそもコアに接続を渡さない可能性があり、モードを切り替えても結果は変わりません。トラブル対処では、まず接続ログにリクエストがあるか、次にどのルールが適用されたか、最後に出口が利用可能かを確認します。通信を制御する範囲と振り分け方法を、同じスイッチとして扱わないでください。

最短の接続確認手順を作る

まずTUNを無効にしてシステムプロキシを有効にし、ノードを1つ選んでテスト用のWebページにアクセスします。同時に接続パネルを開き、接続先ドメインで絞り込んで、適用されたルールと出口を確認してください。ブラウザーでページを開けたことは最初の確認材料です。接続ログでリクエストがコアに渡ったことを確認でき、ログからは失敗した段階をさらに調べられます。出口IP確認ページを使う場合も、そのページへのリクエストが想定した経路を通ったか確認しましょう。

コマンドラインツールはデスクトップのシステムプロキシを参照しない場合があります。比較するには、ローカルの接続先をコマンドで明示できます。以下のコマンドは、クライアントのmixed-portが7890であることを前提としています。実際に使う際は画面に表示されたポート番号に置き換えてください。テスト先は公開されているサンプルサイトであり、すべての接続先に同じようにアクセスできるとは限りません。リクエストが1回成功すれば、経路が概ね機能していることを確認できますが、すべてのプロトコル、アプリ、サイトが正常とは限りません。

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

2つ目のコマンドでは、接続先のホスト名をSOCKSプロキシ側で解決します。ローカル端末で先に名前解決する経路と比較するのに役立ちます。結果が異なる場合は、クライアントのDNS、ノードのプロトコル、ログをあわせて確認してください。結果だけから特定の漏えいが起きていると断定することはできません。後から同じ条件で再確認できるよう、実行コマンド、時刻、モード、ノードを記録しておきましょう。

レイテンシテストはダウンロード速度を保証しない

クライアントに表示されるテスト値は、指定されたリクエストの往復時間などを示します。具体的な意味はテスト先や実装によって異なります。数値が低くても、ファイルのダウンロードが速いとは限らず、動画、ゲーム、特定のWebサイトの通信が安定するとも限りません。テストに失敗しても、テスト先に接続できないだけで、ほかの接続先ではノードを使える場合があります。ノードを選ぶときは一覧の順位だけでなく、実際の用途、接続成功率、一定期間の安定性も確認してください。

ブラウザーは使えるのに別のアプリで失敗する場合は、そのアプリがシステムプロキシに対応しているか、独自のプロキシが設定されていないか、一部の通信だけをプロキシに通す仕様ではないかを確認します。ログイン処理でシステムコンポーネントや別プロセスが使われ、メイン画面とログイン画面で通信経路が異なることもあります。すぐにグローバルモードへ切り替えて常用するのではなく、まず失敗した接続を特定してください。そのうえでアプリの設定変更、ルールの追加、通信制御範囲の拡大のどれが必要か判断します。

ノードやモードを切り替えても、既存の長時間接続は以前の経路を使い続けることがあります。新しい設定を確認するには、対象ページを開き直し、必要に応じて該当する接続だけを切断してリクエストを再送します。テストと関係のない接続をすべて消去する必要はありません。アプリによっては名前解決の結果や接続プールをキャッシュするため、アプリの再起動が必要なこともあります。古い接続を新しい設定の結果と誤認すると、変更が反映されているのに何も変わっていないように見えることがあります。

この段階を終えるまでに、成功する接続を再現し、使用したモード、入口、出口を説明できるようにします。初回接続の詳しい確認方法はノードの選び方、テスト方法、通信経路の確認をご覧ください。最短の接続経路が安定してからルールやTUNを変更すれば、追加設定の影響を判断しやすくなります。

6. ルールの順序、プロキシグループ、振り分けの管理

最初の一致ルールと最後のフォールバック

ルール一覧は通常、上から順に条件を照合し、最初に一致したルールで通信先が決まります。そのため、ルールの内容だけでなく順序も重要です。広い範囲を対象とするドメインサフィックスルールを先頭に置くと、後にある特定ドメイン向けのルールが適用されないことがあります。ルールを追加する前に、現在どのルールが適用されているか確認してください。単にファイル末尾へ追加するのは避けましょう。末尾にフォールバックアクションがあると、保存できたように見えても新しいルールが適用されないことがあります。

ドメインルールはWebサイトやサービスを指定し、IPアドレス範囲のルールは明確なネットワーク範囲を扱うのに適しています。プロセスルールはプラットフォーム、権限、識別機能に左右されます。1つのアプリが複数のドメインに接続したり、補助プロセスから通信したりすることもあります。主なドメインをルールに追加しただけで、アプリの通信すべてをカバーできるとは限りません。アプリ名から接続先を推測せず、実際の接続を確認して管理してください。

# 設定の一部を既存設定に追加する例。サブスクリプション全体ではありません
# この例では国内外などの地域ラベルを判定に使用しません
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

この例ではルールの順序を示すために組み込みのDIRECTアクションを使用しています。誰にでも適した振り分け設定ではありません。完全一致のドメインルールは指定した名前だけに適用され、サフィックスルールは対象ドメインとサブドメインをカバーします。IPアドレス範囲の追加オプションを使うと、そのアドレスの照合のために名前解決を明示的に行わずに済む場合があります。最後のフォールバックは、それ以前のルールに一致しない通信を処理します。プロキシを使う場合、指定先の名前が現在の設定にあるプロキシグループと一致している必要があります。

グループの種類を確認してからメンバーを調整する

手動選択グループは固定の選択に適しています。自動テストグループは設定されたテスト結果に応じてメンバーを選び、フェイルオーバーグループは順序と利用可能性を重視します。テスト先、間隔、許容値によって切り替え動作が変わります。「自動」という名前だけを見て、実際の用途に最適なノードが必ず選ばれると思い込まないでください。接続を維持する必要のあるアプリでは、切り替えによって既存の接続が切れたり再接続されたりしないかも確認しましょう。

プロキシグループ同士を参照させることはできますが、名称を正確に指定し、循環参照を避ける必要があります。サブスクリプションの更新でグループ名が変わると、ローカルルールが古い名前を参照したままになり、読み込みに失敗する場合があります。変更前に、ルールの転送先、グループのメンバー、最終的なノードの対応関係を整理し、すべての経路で利用可能な出口に到達できるか確認してください。複雑な設定では、ルールの構文よりも、似た名前の複数のグループから実際にどれが選ばれたのか分からないことが問題になりがちです。

推測ではなく接続ログでルールを検証する

振り分けを追加するときは、対象を1つに絞ります。変更前に適用中のルールと出口を記録し、対象範囲の狭いルールを適切な位置に置いて、接続を作り直して結果を確認してください。結果が変わらない場合は、現在の設定が正しいか、上書きが実際にマージされたか、より広いルールより前に配置されているか、対象のリクエストが古い接続ではないかを順に確認します。この4点を調べてから、ルールの種類が適切でない可能性を検討してください。

DNSの動作によって、IPアドレスの照合とドメイン名の照合結果が変わることがあります。コアが元のドメイン名を取得できない場合、手元にある情報だけで照合します。fake-ipのマッピングはドメインと接続の関連付けに役立ちますが、通信経路全体で一貫して利用できることが必要です。すべての問題をルールセットの古さのせいにしないでください。まず接続ログにドメイン名とIPアドレスのどちらが表示されているか確認し、ドメインルール、IPアドレスルール、名前解決経路の修正のどれが必要か判断しましょう。

ルールセットを使うと、継続的に更新される条件を再利用できます。ただし、どの動作タイプを使うか、どこに保存するか、ルールからどう参照するかを明確にする必要があります。ダウンロードできても、参照設定が自動的に存在するとは限りません。ファイル形式も混同しないでください。外部ルールセットを追加する前に、更新元と更新失敗時の影響を把握し、最後に利用できた内容を残しておきましょう。広い範囲をカバーしようと重複したルールを大量に重ねると、どのルールが適用されたのか分かりにくくなります。

しばらく運用したら、用途がなくなった例外設定を整理します。特に、一時的なテストで追加した強制DIRECTや強制プロキシのルールに注意してください。後から追加されたサブスクリプションのルールを無効にしてしまうことがありますが、画面から見つけにくい場合があります。安定したルール設定は項目数の多さでは決まりません。問題が起きたときに通信経路を説明でき、直前の変更を安全に取り消せることが大切です。

7. TUNによる通信制御とDNSの連携

通信制御の範囲を広げる必要がある場合に有効化する

TUNは仮想ネットワークインターフェースを通じてシステムの通信を受け取り、システムプロキシに従わないアプリを扱うのに適しています。ただし、新しいリモート出口を用意したり、利用できないノードを修復したりする機能ではありません。有効化する前にシステムプロキシでサブスクリプションとノードが使えることを確認し、現在の設定を保存してください。TUNを有効にして問題が起きたときに、権限、ルーティング、DNS、仮想インターフェースに調査対象を絞れます。通信経路を最初から疑い直す必要がありません。

デスクトップでは、通常、対応するサービス権限やネットワークコンポーネントが必要です。モバイル端末では主にシステムのVPNインターフェースが管理します。企業VPN、セキュリティツール、別の仮想ネットワークソフトを使っている場合は、それらがデフォルトルートやDNSも変更するか確認してください。個別には正常なツール同士でも、同時に使うと通信経路が競合する場合があります。テスト中は通信を制御するツールを1つに絞り、アクセスが必要なLAN内のリソースも記録して、1つずつ確認できるようにしましょう。

# mihomoの設定例。有効なノード、ルール、DNS設定と合わせてください
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

この例は一般的な設定項目の関係を示すもので、すべてのクライアントやシステムで使えるとは限りません。自動ルーティングは、関連するルートをコアが設定するかどうかを決めます。出口インターフェースの自動検出は実際のネットワーク出口の選択に使われ、スタックの設定はシステムとの互換性に関係します。クライアントの画面から各項目を生成できる場合があります。ファイルに直接書いた設定が上書きされるときは、競合する2つの設定を同時に管理せず、クライアントが用意する正式な設定画面から変更してください。

DNSは単なる追加スイッチではない

DNSのハイジャックは通常、通信制御経路を通る従来型の名前解決リクエストを対象とします。アプリに内蔵された暗号化DNSもすべて制御されるとは限りません。ブラウザーのセキュアDNS、アプリ独自の名前解決、社内ドメインでは、異なる経路が使われることがあります。トラブル対処では、一般的なWebサイト、LAN内の名前、特定の名前解決サービスに依存するアプリをそれぞれ確認してください。公開ドメイン1つの結果だけですべてのネットワークを判断しないようにしましょう。

fake-ipモードでは、アプリにマッピング用のアドレスを返し、その後の接続で元のドメイン名を関連付けます。ドメインによる振り分けに便利ですが、マッピングと接続の経路が一貫している必要があります。redir-hostは実際の名前解決アドレスを返す方式に近いものの、照合やキャッシュに関する条件があります。どちらが常に優れているということはありません。LAN内のサービスで問題が起きたら、DNSモードをすぐに全面変更するのではなく、ドメイン名とアプリの要件を先に確認してください。

コアの上流DNS、プロキシサーバーのドメイン名解決、直接接続先の名前解決は、それぞれ役割が異なる場合があります。一見適切な暗号化DNSの接続先でも、利用可能なプロキシができる前にアクセスする必要があると、起動時の依存関係が循環することがあります。ノードサーバー自体にドメイン名が使われている場合は、その名前を解決する経路も利用できる必要があります。項目間の関係はnameserver、fallback、fake-ipの設定解説を参照してください。

有効化後は段階ごとに確認し、問題があれば戻す

まずブラウザーをテストし、次に通常はシステムプロキシを使わないアプリを試します。最後にプリンター、ネットワークストレージ、リモートデスクトップなどLAN内のサービスを確認してください。各段階で接続ログとルーティング関連のログを確認します。LANに問題がある場合は、接続先がバイパス対象の範囲に含まれているか、名前解決の結果が正しいかを調べましょう。最初からシステムファイアウォールを無効にするのは避けてください。変更範囲が広がり、原因を隠してしまうことがあります。

Wi-Fiから有線LANやテザリングに切り替えたり、スリープから復帰したりすると、出口インターフェースやデフォルトルートが変わることがあります。TUNが切り替え後に動かなくなった場合は、まずインターフェースの検出とサービスの状態を確認し、該当する接続を再起動してください。環境によっては仮想インターフェースを再作成する必要がありますが、毎回クライアントを再インストールする必要はありません。切り替え前後のログを残せば、インターフェースの変化、ノードの再接続、DNSキャッシュの問題を見分けやすくなります。

出口確認や名前解決のテストは状況を把握する補助になりますが、Webページ1つだけでは端末上のすべてのアプリが同じ経路を使うとは証明できません。結論は、実際にテストしたアプリとリクエストの種類に限定してください。TUNの適切な状態とは、必要なアプリの通信が制御され、LANが使え、ネットワーク切り替え後に復旧できることです。設定を整って見せるために高度なスイッチをすべて有効にする必要はありません。

8. 日常のメンテナンス、バックアップ、トラブル対処

正常に使える状態を基準として記録する

接続が安定したら、クライアント名、コアの情報、現在の設定、サブスクリプションの入手元、通信制御の方法、必要なローカル例外を記録します。バックアップには個人の上書き設定や必要なプロキシグループの選択を含めます。ただし、アクセス識別情報を含むURLを公開してはいけません。メイン画面のスクリーンショットだけでは環境を復元できないことがあります。実行に影響する項目がサービス設定、DNS、ローカル拡張設定に含まれている場合があるためです。

バックアップファイルは、自分または許可された人だけがアクセスできる場所に保存してください。端末を移行する場合は、まずクライアントのエクスポート機能を使い、サブスクリプションの認証情報やローカルパスが含まれていないか確認します。デスクトップのパスがモバイル端末で使えるとは限らず、画面上の設定の一部はOS間で復元できません。移行の成功は、インポート時にエラーがないことではなく、新しい端末で想定した通信を再現できるかで判断します。

更新は分けて行い、動作確認の時間を確保する

クライアント、コア、サブスクリプション、ルールセットはそれぞれ別の更新対象です。問題の原因を特定できるよう、すべてを同時に変更しないでください。まずサブスクリプションを更新して動作を確認し、その後クライアントやコアを更新し、最後に個人ルールを調整します。毎回、元に戻せる状態を残してください。特に重要な作業の直前には、権限、ネットワーク拡張、ルーティングに関わる大きな変更を行わないようにしましょう。

更新ログに記載された機能変更は、実際に使っている設定と照らし合わせて確認します。新しいプロトコルへの対応が現在の用途に関係しないなら、すぐに移行する必要はありません。古い設定項目の動作が変わった場合は、まず複製した設定で検証してください。GUIクライアントの更新で設定のマージ順序や初期値が変わることもあります。以前のスイッチがオンのままかだけでなく、更新後の最終的な実行設定を確認しましょう。

影響範囲からトラブル対処の入口を選ぶ

症状	最初に確認する項目	比較・確認方法
特定のアプリだけで問題が起きる	アプリのプロキシ設定、独自DNS、接続ログ	ブラウザーとプロキシを明示したコマンドをそれぞれ試す
特定のノードだけで問題が起きる	ノードのログ、プロトコル、リモート側の状態	ルールは変えず、ノードだけを切り替える
TUNを有効にした後に問題が起きる	サービス権限、ルーティング、DNS、ほかのVPN	確認済みのシステムプロキシ設定に戻す
終了後にWebページが開かない	システムプロキシやDNSの設定が残っていないか	使えなくなった入口を無効にしてネットワークに再接続
更新後にルールが適用されない	現在の設定、上書きの順序、プロキシグループ名	最終設定と更新前のバックアップを比較

まず、問題が1つの接続先、1つのアプリ、すべての接続のどれに影響するか確認します。特定のWebサイトだけで起きるなら、接続先サービスの状態や個別ルールを優先して調べます。すべてのノードで失敗する場合は、ローカルの入口、名前解決、現在のネットワーク制限を確認しましょう。特定のノードだけに問題がある場合は、そのノードの接続エラーに絞って調べます。影響範囲の判断だけで原因が確定するわけではありませんが、根拠のない操作を繰り返さずに済みます。

ログはエラーが発生した時刻の少し前から読み、関連する最初の失敗を見つけてから、その後に続くエラーを確認します。名前解決の失敗が後続の接続タイムアウトを引き起こすことがあります。ローカルポートのバインド失敗が画面上の接続エラーにつながる場合もあります。最後の1行だけを切り取らないでください。トラブル対処のため一時的にログの詳細度を上げたら、作業後は通常のレベルに戻します。大量のログが長期間保存されると、ストレージを圧迫し、不要なアクセス情報が残るおそれがあります。

自動起動とスリープ復帰は分けて確認する

クライアントの起動、コアサービスの起動、システムプロキシの自動有効化は、別々の設定の場合があります。設定後は実際に端末を再起動し、ログイン前後のサービス状態と、ネットワーク接続の準備ができていないときのサブスクリプション更新を確認してください。スタートアップ一覧にアプリ名があるだけでは、プロキシが正常に動作していると判断できません。パスワードの解除やユーザー確認が必要な環境では、自動接続が完了するまで時間がかかる場合もあります。

スリープからの復帰やネットワークの切り替えも、メンテナンス時に確認してください。復帰後に古いセッションだけが失敗するなら、接続の再確立で解決することがあります。リクエストがまったく記録されない場合は、通信を受け付ける入口やサービスを確認します。ログはあるのに名前解決が続けて失敗するなら、DNSと出口を調べてください。層ごとに確認すれば、正常に動いている部分を維持できます。手がかりを消してしまう端末全体の再起動に毎回頼る必要はありません。

クライアントに接続済みと表示されてもアクセスに問題がある場合は、このガイドの最短の接続確認手順を使って再テストし、結果に応じて対処方法を選びます。変更の影響を説明できない場合は、最後に使えた状態へ戻し、一度に1項目ずつ再度変更してください。メンテナンスの目的は、すべてのエラーメッセージを覚えることではありません。安定した記録方法を作れば、同じ問題を次にすばやく特定でき、一時的な修正が長期的な問題になるのも防げます。

9. 使える設定から管理しやすい応用構成へ

まず最終的な設定を読み解く

応用設定の第一歩は項目を増やすことではなく、現在の実行設定がどのように生成されたか説明できることです。サブスクリプション、クライアントの初期値、画面上のスイッチ、ローカルの上書き設定がマージに関わることがあります。プレビュー、エクスポート、実行設定を確認する画面を見つけ、待ち受けポート、モード、DNS、プロキシグループ、ルールの順序を確認します。ファイルの値と画面の表示が異なる場合は、どちらが上書きされるかを理解してから変更する場所を決めてください。

実験専用の設定を複製し、日常使いの設定は基準として残しておきます。実験のたびに変更する項目は1つだけにし、期待する結果と確認方法を記録してください。たとえばルールセットを追加する場合は、まずファイルを更新できるか、次にルールが参照されているか、最後にテスト接続がそのルールに一致するかを確認します。失敗しても、どの段階で問題が起きたか説明できます。「すべて使えなくなった」という結論だけで終わらせずに済みます。

依存関係に沿って機能を拡張する

まずルールセットを理解し、その後ノードプロバイダーを学び、DNSの振り分けや複雑なプロキシグループに進む方法があります。ルールセットは条件の再利用に、ノードプロバイダーはノードの入手元の管理に使われます。目的は異なります。使う前にデータ形式、動作タイプ、更新場所、参照方法を確認してください。データを取得できても、その内容が既存のルールやプロキシグループに自動で追加されるとは限りません。明示的な参照設定が必要です。

定期更新、ヘルスチェック、自動選択も1つの依存関係として考えます。ノード一覧の更新でメンバーが変わり、ヘルスチェックで利用可能性が判定され、プロキシグループが種類に応じてメンバーを選択します。どこかの更新に失敗しても、画面に古い結果が残ることがあります。自動選択に問題がある場合は、テスト間隔を短くする前に、メンバーが最新か、テストに成功したか、選択ロジックがどう動くかを順に確認しましょう。

プロトコルを利用するには、コアとクライアントが対応し、サーバー側のパラメーターも正しく設定されている必要があります。ドキュメントにプロトコル名が載っていても、現在インストールされているコアで使えるとは限りません。古い設定を移行する際はmihomoとオリジナル版Clashコアの違いを読み、ソフトの名称から設定全体の互換性を推測せず、項目とプロトコルを確認してください。

ターミナルとサービス環境を分けて管理する

ターミナルの環境変数は通常、現在のセッションと子プロセスにだけ適用され、すべてのデスクトップアプリにプロキシを設定するものではありません。環境変数への対応もツールによって異なります。一時的なテストでは、まずコマンド固有のプロキシオプションを使ってください。セッション単位で設定する必要がある場合に限り、環境変数を利用します。ローカルアドレスを複数の起動ファイルに書き込んだまま出所を忘れると、クライアント終了後もターミナルが使えないポートを参照し続けることがあります。

# POSIXシェル：現在のセッションと子プロセスにのみ設定
# ポート番号はクライアントの実際の待ち受け値に合わせる
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

# テスト終了後はこの設定を解除する
unset http_proxy https_proxy

サービスマネージャーから起動したプロセスは通常、対話式ターミナルの環境変数をすべて引き継ぐわけではありません。サーバーに導入する場合は、設定ファイルのパス、作業ディレクトリ、実行ユーザー、ログの保存場所を明確にしてから、自動起動を設定してください。ターミナルで動いたことだけを理由に、システムサービスも正しく設定されたと判断しないでください。クライアントAPIや管理画面を使う場合も、待ち受け範囲を制限し、アクセス制御を設定して、不要なネットワークに管理用の入口を公開しないようにしましょう。

設定の複雑さではなくチェックリストで確認する

応用構成では、少なくとも次の点を確認できるようにします。一般的なWebページを表示できること、プロキシを必要とするアプリが接続ログに記録されること、LAN内のサービスにアクセスできること、サブスクリプションの更新で個人ルールが上書きされないこと、ネットワーク切り替え後に復旧すること、アプリ終了後にシステムのネットワーク設定が想定どおりに戻ることです。これらは特定の画面に依存しない使用結果です。新しい機能によってどれかが損なわれたら、機能を追加する前に通信範囲の問題を解決してください。

バイパスゲートウェイ、ルーター、複数端末への共有を扱うと、影響範囲は自分の端末からほかの端末にも広がります。ゲートウェイ、転送、ファイアウォール、戻り経路についても理解する必要があり、デスクトップ向けのTUN設定例をそのまま適用することはできません。まず独立した端末や隔離できるネットワークでテストし、元のゲートウェイとDNSに戻す方法も用意してください。知識の範囲を超える場合は、安定した単体端末の構成を維持することも、影響範囲を適切に管理する判断です。

基本の操作手順をもう一度確認する場合は入門ガイドへ。端末やクライアントを変更する場合はダウンロードセンターでプラットフォームを選んでください。具体的な設定の疑問は技術ノートからテーマ別に確認できます。総合ガイドの価値は、すべての設定項目を一度に読むことではありません。変更するたびに、目的、条件、確認方法、元に戻す手順を把握できることです。