Clash 使い方ガイド：基本から応用まで

まず Clash の基本概念を理解する

操作を始める前に、クライアント、コア、設定ファイル、サブスクリプション、ノード、プロキシグループ、ルールを別々の概念として整理しましょう。複雑に見えるトラブルの多くは、実際にはこのうち2つの段階を混同しているだけです。たとえば、クライアントが正常に起動しても、利用可能な設定があるとは限りません。サブスクリプションの導入に成功しても、その設定が選択されているとは限りません。設定を選択した後も、プロキシグループでどのノードを使うか確認する必要があります。さらに、システムプロキシを有効にしても、システムプロキシ設定を参照するアプリだけが自動的に Clash へ接続します。この流れを一段ずつ確認するほうが、何度も再インストールするより問題を見つけやすくなります。

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

クライアントは目に見える GUI で、サブスクリプションの導入、設定変更、接続ログの表示、システムプロキシの制御を担当します。コアは設定を解析し、実際に接続を処理するプログラムです。Mihomo は現在よく使われている互換コアの1つです。設定ファイルは通常 YAML 形式のテキストで、ポート、プロキシノード、プロキシグループ、ルール、DNS などを含みます。GUI クライアントがコアを起動すると、現在選択されている設定をコアに渡して読み込ませます。設定の構文が有効であれば、コアは定義された順序に従って通信を処理します。

この3層ではトラブルの現れ方が異なります。クライアントが起動しない場合は、インストール、権限、OS との互換性を確認します。クライアントは起動するものの設定解析に失敗する場合は、YAML の形式やサブスクリプションの内容を確認します。コアは動作しているのにウェブページを開けない場合は、システムプロキシ、プロキシグループの選択、ルールの適用、ノードの利用可否を確認します。トラブルシューティングでは、まず問題がどの層にあるかを判断し、すべてを「ノードの障害」と決めつけないことが大切です。

サブスクリプション、ノード、プロキシグループの関係

サブスクリプション URL は、設定の提供元が用意するリモートアドレスです。クライアントがこのアドレスへアクセスすると設定内容を取得し、ローカル設定として保存します。ノードは設定内にある個々のプロキシ出口で、通常はサーバーアドレス、ポート、プロトコルのパラメーターを記録します。プロキシグループは複数のノードをまとめたもので、手動選択や遅延テスト、フェイルオーバーの方式で出口を選べます。ルールは通常、特定のノードへ直接向けるのではなく、「ノード選択」「自動選択」などのプロキシグループを指定し、最終的な出口はグループが決定します。

そのため、ノード一覧が表示されていても、現在の接続が特定のノードを使っているとは限りません。まずサブスクリプション設定を選択し、プロキシ画面で主要なプロキシグループを確認して、適切なノードへ切り替えます。プロキシグループが DIRECT の場合、接続は直接アクセスします。REJECT の場合は接続が拒否されます。自動選択の場合は、テスト先、テスト間隔、候補ノードによって結果が変わります。ノードはクライアントに付属するものではなく、Clash もインストール後に利用可能な回線を自動生成するわけではありません。

システムプロキシと TUN の適用範囲

システムプロキシは、OS が提供するプロキシアドレスの設定です。ブラウザーや多くのデスクトップアプリはこの設定を読み取り、HTTP または SOCKS 接続を Clash のローカル待受ポートへ送ります。設定が簡単で影響範囲も明確なため、初回利用時の方法として適しています。一部のゲーム、コマンドラインプログラム、ストアアプリ、独自のネットワークスタックを使うソフトはシステムプロキシを参照しません。そのため、スイッチがオンでも直接接続を続けることがあります。

TUN モードは仮想ネットワークアダプターでより多くのシステム通信を受け取るため、通常はシステムプロキシより広い範囲をカバーできます。一方で、管理者権限、ルーティングテーブル、DNS の引き継ぎ、セキュリティソフトとの互換性も関わります。まずシステムプロキシでサブスクリプションとノードが使えることを確認し、必要に応じて TUN を有効にするのが正しい順序です。最初からサブスクリプション、DNS、ルール、TUN を同時に変更すると、問題の原因を特定しにくくなります。

OS と使い方に合うクライアントを選ぶ

Clash には複数の GUI クライアントと、単独で動作するコアがあります。選ぶときはまず OS を確認し、次に TUN、ルール編集、サブスクリプション管理、デスクトップトレイなどが必要かを見ます。画面の見た目だけで比較する必要はありません。本サイトのダウンロードページでは Windows、macOS、Android、iOS、Linux、Mihomo コアに分けて掲載しており、クライアント一覧とここでの案内も一致しています。初めて使う場合は、メンテナンス状況が明確で操作項目が揃った GUI クライアントを優先し、サーバーやルーターではコアの直接運用を検討します。

プラットフォーム別の選び方

Clash Plus は Windows、macOS、Android、iOS に対応しており、本ガイドで全プラットフォーム向けに最初に推奨する構成です。複数の端末で近い操作感を使いたい人に適しており、サブスクリプションやプロキシの設定項目も分かりやすくまとまっています。Windows では Clash Verge Rev、FlClash、Clash Nyanpasu も選べます。Clash for Windows は開発が終了しているため、既存環境や古い設定の移行に限って利用し、新規インストールの出発点にはおすすめしません。

macOS では Clash Plus のほか、Clash Verge Rev と FlClash を選べます。ClashX Meta は開発が終了しているため、既存ユーザーはまずサブスクリプション情報をエクスポートまたは記録し、現在も保守されているクライアントへ移行してください。Android では Clash Plus、Clash Meta for Android、FlClash、Surfboard を利用できます。モバイル OS ではバックグラウンド動作やバッテリー最適化の制限が多いため、インストール後に VPN 権限、バックグラウンド動作、省電力設定を確認します。iOS では Clash Plus の App Store 版を利用し、詳しくはiOS ダウンロードセクションを確認してください。

Linux のデスクトップ環境では Clash Verge Rev または FlClash を選べます。デスクトップ環境のないサーバー、ソフトルーター、コンテナでは Mihomo コアを利用できますが、設定ファイル、サービス管理、ログの確認方法を自分で用意する必要があります。コアを直接実行しても GUI は表示されず、OS のデスクトッププロキシ設定も自動では変更されません。そのため、ポート、ルーティング、設定構造を理解しているユーザーに向いています。

GUI クライアントと単独コアの選び方

GUI クライアントは、日常的なデスクトップやモバイル端末に適しています。サブスクリプション更新、プロキシグループの切り替え、接続確認、システムプロキシ、TUN のオン・オフを画面上でまとめて操作でき、問題が起きたときも現在の状態を確認しやすくなります。単独コアは systemd、Docker、スクリプトで管理したい環境に適しています。柔軟に構築できる一方、設定パス、起動引数、ログローテーション、再起動方針を自分で管理する必要があります。

ブラウザーや普段使うアプリをルールに従って通信させたいだけなら、「機能が多い」という理由で最初からコアを選ぶ必要はありません。まず GUI クライアントでルールモード、プロキシグループ、接続ログに慣れてからサーバー環境へ移行すると、理解しやすくなります。逆に、デスクトップのない端末で長期間動かし、設定を自動化システムから配布する場合は、GUI は必要ありません。

旧クライアントから移行するときに残す情報

Clash for Windows や ClashX Meta から移行するときは、元のサブスクリプション URL と自分で作成したオーバーライドルールを保存することが重要です。クライアントごとに設定ディレクトリ、データベース、画面設定の構成が異なるため、キャッシュディレクトリだけをコピーしないでください。サブスクリプションにアクセスできるなら、新しいクライアントで URL から再導入するほうが確実です。ローカルルールセットやスクリプトが含まれる場合は、関連ファイルを別途バックアップし、新しいコアが対応する構文か確認します。

移行が完了したら、旧クライアントを終了し、2つのプログラムが同時にシステムプロキシを変更したり同じポートを使用したりしないようにします。タスクバー、メニューバー、バックグラウンドプロセスに残っているコアを確認し、1つだけにしてから新しいクライアントを起動します。その後、サブスクリプションの導入、設定の選択、プロキシグループの選択、システムプロキシの有効化を順に行います。旧クライアントは比較用に一時保存しても構いませんが、同時に実行しないでください。

インストール、権限付与、初回起動を完了する

インストール段階の目的は、すべての高度な設定をすぐに変更することではなく、クライアント、コア、システム権限を確認できる状態にすることです。インストール後は一度起動し、メイン画面が開くこと、コアが正常であること、ポート使用中の警告がないことを確認してからサブスクリプションを導入します。初回起動でエラーが出た場合は、設定の再導入を繰り返して隠すのではなく、まずインストールと権限の問題を解決します。

Windows のインストールとポート確認

Windows ユーザーはダウンロードページからシステムアーキテクチャに合うインストールパッケージを選び、セットアップウィザードに従ってインストールします。ファイアウォール経由の通信許可を求められた場合は、現在のネットワークの種類に応じて許可します。LAN でプロキシを共有する機能は初回利用に必須ではないため、事前に有効にする必要はありません。インストール後はスタートメニューからクライアントを起動し、コアが正常に動作しているか確認します。TUN を使う場合は、後でサービスのインストールや管理者権限による仮想ネットワークアダプターの初期化が必要になることがあります。

ポートの競合は、Windows で初回起動時によく起こる問題です。Clash の設定ではローカル HTTP、SOCKS、mixed の待受ポートが使われることがあり、古いプロキシツールがバックグラウンドで動作していると、新しいコアが同じポートを確保できません。まずほかのプロキシクライアントを終了してから Clash を再起動します。さらに確認する場合は、PowerShell で特定ポートの待受プロセスを調べます。

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 7890,7891,7892 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id <OwningProcess>

設定によって使用するポートは異なります。判断基準は、画面に表示されている実際の待受値です。慣れているポートが 7890 だからといって、システムプロキシを直接変更しないでください。GUI クライアントは通常、正しいアドレスをシステム設定へ自動的に書き込みます。

macOS のセキュリティ警告とネットワーク権限

macOS ではインストール後、アプリを「アプリケーション」フォルダへ移動して起動します。アプリの入手元の確認、ネットワーク構成の追加、管理者パスワードの入力を求められることがあります。システムプロキシはネットワークのプロキシ設定を変更するだけですが、TUN や高度な通信の取り込みには補助サービスのインストールが必要になる場合があります。許可操作は、そのとき実行している内容に対応しているか確認してください。許可を取り消しても画面は開けることがありますが、関連するスイッチは機能しません。

メニューバーのクライアントは、古いプロキシプログラムと同時に存在しやすいものです。メニューバーのアイコンと「アクティビティモニタ」を確認し、古いコアが終了していることを確認してください。システムプロキシを有効にしてもすぐオフになる場合は、まずクライアントログで権限不足がないか確認し、その後、ほかのネットワーク管理ツールがネットワーク設定を上書きしていないか調べます。Wi-Fi、有線、テザリングを切り替えると使用中のネットワークサービスが変わることがあるため、必要に応じてシステムプロキシを一度切り替え直します。

Android と iOS の VPN 許可

モバイル端末では通常、システム VPN インターフェースを通じて通信を取り込みます。初回接続時には VPN 構成または接続リクエストが表示され、同意しなければクライアントは動作できません。Android のステータスバーに VPN アイコンが表示されれば、通常はシステムインターフェースが確立していますが、設定とプロキシグループが正しいかも確認してください。バックグラウンドに移ると接続がすぐ停止する場合は、システムのバッテリー設定でバックグラウンド動作を許可し、厳しい省電力制限の対象からクライアントを外します。

通常、同時にシステム VPN インターフェースを使用できるアプリは1つだけです。端末に企業 VPN、別のプロキシクライアント、プライバシー保護ツールがある場合、Clash の起動時にいずれかが切断されることがあります。どの接続を残すか先に決め、複数の VPN を同時に有効にしないでください。iOS では VPN 構成を追加するとシステム設定に項目が表示されます。クライアントを削除する前に接続設定も完全に消したい場合は、システムの VPN 一覧も確認してください。

Linux デスクトップとコアの実行方法

Linux の GUI クライアントは、ディストリビューションに合うインストールパッケージを選びます。インストール後、アプリは起動するのにシステムプロキシを設定できない場合は、デスクトップ環境がプロキシ設定の自動書き込みに対応しているか確認します。GNOME、KDE、軽量デスクトップではプロキシ設定の保存方法が異なるため、必要に応じてデスクトップのネットワーク設定でアドレスとポートを手動確認します。Wayland やサンドボックス環境では、トレイアイコンや権限制限も確認してください。ただし、これらの画面上の問題がコアの動作に影響するとは限りません。

Mihomo コアを直接実行する場合は、まず専用の作業ディレクトリを用意し、設定を読み取り可能なファイルとして保存します。そのうえでフォアグラウンド起動し、ログを確認します。一般的な起動形式は次のとおりです。パスは実際の環境に合わせて置き換えてください。

mkdir -p "$HOME/.config/mihomo"
mihomo -d "$HOME/.config/mihomo"

設定が正常に読み込まれたことを確認してから、systemd などのサービスマネージャーへ移行します。初回テストでいきなりバックグラウンド実行すると、設定解析エラーやポート競合がサービスログに埋もれて気づきにくくなります。サーバーではコントロールインターフェースとプロキシポートの待受範囲も制限し、ローカル専用ならループバックアドレスにバインドします。

サブスクリプションを導入し、復元しやすい設定手順を作る

サブスクリプションの導入とは、リモート設定をクライアントで管理できるようにする作業です。開始前に完全なサブスクリプション URL を用意し、コピー時に余分な空白、改行、説明文が入っていないことを確認します。サブスクリプションは設定の取得元であり、ノード名、プロキシポート、コントローラーアドレスの入力欄に貼り付けるものではありません。クライアントによって入口は「設定」「サブスクリプション」「Profiles」「設定ファイル」など異なりますが、URL から設定をダウンロードし、ローカルに保存して現在の設定にするという基本操作は同じです。

URL から導入する標準手順

設定またはサブスクリプションのページを開き、URL から新しい設定を作成します。アドレス欄には完全なリンクを貼り付けてください。名前には用途や端末が分かる短い文字列を入力すると便利です。完全な URL をそのまま名前にするのはおすすめしません。送信後、クライアントがダウンロードするまで待ちます。成功すると新しい設定項目が表示され、更新日時や更新ボタンが示されます。次にその項目をクリックして現在の設定にします。導入後に自動選択されないクライアントもあり、「サブスクリプションは見えるのにノードがない」主な原因になります。

設定を有効にしたらプロキシ画面を開き、主要なプロキシグループが表示されているか確認してノードを選びます。その後システムプロキシを有効にし、ブラウザーで基本的なアクセスをテストします。「設定をダウンロード」「設定を選択」「ノードを選択」「通信の取り込みを有効化」の4段階に分け、サブスクリプション項目が存在するだけで完了と判断しないでください。詳しい手順はClash サブスクリプション URL の導入方法を参照してください。

クライアントが受け付ける URL 形式か確認する

一般的なサブスクリプションには、Clash YAML 設定、ノード一覧、変換しないと Clash が認識できない形式があります。クライアントは URL から内容を取得し、設定パーサーへ渡します。返された内容がログインページ、エラーページ、空のテキスト、非対応形式の場合、単純なネットワークエラーではなく解析失敗と表示されることがあります。その場合は、提供元のページから Clash または Mihomo 専用 URL を再度コピーしてください。ウェブページの URL をサブスクリプション URL として使わないでください。

基本的な YAML 設定には通常、ポート、プロキシ、プロキシグループ、ルールなどのフィールドが含まれます。次の例は構造の関係を示すもので、実際のノード情報は含みません。

mixed-port: 7890
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,LAN,DIRECT
  - MATCH,ノード選択

YAML はインデントに敏感で、通常はスペースを使用します。タブを混在させないでください。サブスクリプションがリモートで生成される場合、元ファイルを手動編集する必要はありません。カスタムルールを追加するときは、サブスクリプション更新のたびに変更が上書きされないよう、クライアントのオーバーライドやマージ機能を優先して使います。

更新失敗はレスポンスの種類に応じて処理する

サブスクリプションの更新がタイムアウトした場合、クライアントが制限時間内にリクエストを完了できていません。現在のネットワークから URL にアクセスできない、DNS 解析に問題がある、更新リクエストに既存のプロキシが必要などの原因が考えられます。まず通常のネットワークで提供元の管理ページを開き、サービスへ到達できるか確認します。クライアントに「プロキシ経由で更新」機能がある場合は、利用可能な設定があるときに試してください。初回導入でまだ利用可能な設定がない場合は、現在のネットワークから URL に直接アクセスできる状態を先に整えます。

404 やリソースが存在しないという表示は、リンクのパスが無効、トークンが変更済み、またはコピーが不完全であることを示します。再試行だけでは URL は直らないため、提供元に戻ってリンクを再生成してください。認証エラーやアクセス拒否が返る場合は、アカウント状態、リンク権限、サービス側の制限を確認します。エラー別の詳しい対処はサブスクリプション更新失敗の解決方法を参照してください。

自動更新間隔とローカルバックアップ

自動更新を頻繁に設定する必要はありません。ノードやルールはサーバー側の内容が変わったときだけ更新されます。短時間に連続してリクエストすると失敗しやすくなり、どの更新結果を使っているかも判断しにくくなります。普段使いの端末では、クライアントが提供する数時間単位の間隔を設定し、すぐ同期したいときだけ手動更新します。更新後にノード一覧が明らかにおかしい場合は、設定の更新日時を確認し、まだ使える以前のローカル設定へ戻してみてください。

サブスクリプション URL にはアカウントに対応する設定を取得できる可能性があるため、機密情報として管理します。スクリーンショットを共有するときは完全な URL を隠し、トラブル調査ではリンクを公開せず、エラーの種類とログの一部を提示してください。バックアップには URL、自作のオーバーライド、クライアント設定のメモを保存します。リモートで生成されるノード一覧は再ダウンロードできるため、複数端末間でキャッシュディレクトリ全体をコピーする必要はありません。

ルール、グローバル、ダイレクトの3つのプロキシモードを理解する

プロキシモードは、接続が Clash に取り込まれた後、どの出口を選ぶかを決めます。通信をクライアントへ取り込むのはモードではなく、システムプロキシまたは TUN です。モードを変えても、ノード自体の利用可否は変わりません。この境界を理解すると、トラブルの切り分けが容易になります。接続ログにリクエストがまったくない場合は取り込みを確認し、リクエストはあるものの出口が想定と違う場合はモード、ルール、プロキシグループを確認します。プロキシが選ばれているのに接続できない場合は、ノードと接続先のネットワークを調べます。

ルールモードは日常利用に適している

ルールモードでは、設定内のルールを上から順に確認し、最初に一致したルールが接続をどのポリシーグループへ渡すか、直接接続するか、拒否するかを決めます。一般的な条件には、ドメイン、ドメインサフィックス、IP アドレス、地理データベース、プロセス名、ルールセットがあります。LAN、ローカルサービス、普段使う直結サイトを直接接続し、プロキシが必要な通信だけを指定グループへ渡せるため、アクセス経路とローカルサービスの互換性を両立できます。

ルールモードは「すべてを自動判断する」機能ではありません。設定ファイルの条件に基づいて動作し、ルールの範囲と順序が結果を左右します。新しいドメインがルールセットにまだ含まれていない場合、末尾の MATCH ルールに到達します。特定サイトの出口がおかしいときは、まず接続ログで対象ドメインを見つけ、どのルールに一致し、最終的にどのポリシーが選ばれたかを確認します。長期的にグローバルモードへ切り替える前に、必要ならカスタムルールを追加してください。

グローバルモードは比較テストに使う

グローバルモードでは通常、取り込まれた接続をまとめてグローバルプロキシグループへ渡します。「問題の原因はルールか」を短時間で判断するのに適しています。ルールモードで失敗し、グローバルに切り替えると復旧するなら、ノードと取り込み経路はおおむね正常です。次にルールの適用結果や DNS を確認します。グローバルでも失敗する場合は、まずノード、ポート、権限、ネットワーク環境を確認します。

グローバルモードにしても、OS のすべての通信が取り込まれるわけではありません。システムプロキシだけを有効にしている場合、システムプロキシを参照しないアプリは直接接続することがあります。範囲を広げるには TUN が必要です。また、グローバルモードでは LAN 機器、プリンター、開発サービス、ローカルネットワーク専用リソースまでプロキシへ送られる可能性があります。そのため、トラブルをすべて解決する固定設定ではなく、テストや明確な目的がある場合の一時的な選択として使います。

ダイレクトモードは復旧と基準確認に使う

ダイレクトモードでは、Clash に取り込まれた接続をプロキシ出口へ送らず、直接アクセスさせます。元のシステムネットワークが正常か確認したり、クライアントを動かしたまま一時的にプロキシを停止したりする用途に使えます。ダイレクトへ切り替えても通常のサイトにアクセスできない場合は、リモートノードではなく、ローカル DNS、システムネットワーク、残ったプロキシ設定、TUN のルーティングに問題がある可能性があります。

クライアントを終了する前に、システムプロキシと TUN を無効にしてからプログラムを終了することをおすすめします。強制終了すると、システムプロキシのアドレスが存在しないローカルポートを指したままになり、システムプロキシに従うアプリが突然すべて接続できなくなることがあります。その場合はクライアントを再起動してスイッチを正常にオフにするか、システムのネットワーク設定でプロキシアドレスを削除します。ダイレクトモードと取り込みの無効化は完全に同じではありません。前者は接続をコアに通したうえで直接接続し、後者は対象の通信をコアへ送らなくします。

プロキシグループの手動選択、自動選択、フェイルオーバー

select タイプのプロキシグループは、ユーザーがノードまたは子グループを手動で選択します。結果が安定し、理解しやすいため、主要な出口に適しています。url-test タイプは定期的にテスト先へリクエストし、候補ノードから応答状況が比較的よいものを選びます。ただしテスト結果はそのテスト先だけを反映し、すべてのサイトでの実際の体感を示すものではありません。fallback タイプは利用可能性を順番に確認し、現在の項目が使えなくなると次の候補へ切り替えます。継続性を重視する場面に向いています。

自動グループが頻繁に切り替わると、既存の接続がスムーズに移行するとは限らず、ログインセッションやダウンロードにも影響することがあります。テスト間隔を短くしすぎず、候補ノードも無制限に増やさないでください。固定出口が必要なアカウントやサービスでは、安定した手動グループを選ぶほうが一貫性を保ちやすくなります。プロキシグループに別のプロキシグループが入れ子になっている場合もあるため、外側の名前だけで判断せず、各層を確認します。

ルール順序、分岐設定、DNS の連携を理解する

ルールによる通信分岐は Clash の中核機能であり、「一部のサイトは正常だが、一部は異常」という問題が起きたときに最も確認すべき箇所です。ルールは設定に記載された順に1つずつ照合され、一致すると後続の確認は止まります。そのため、範囲の広いルールを前に置くと、後ろの精密なルールが適用されなくなることがあります。通常は LAN と明確な例外を先に処理し、次に具体的なドメインやルールセット、続いて IP 系ルールを置き、最後に MATCH で残りの接続を受けます。

よく使うルールタイプの使い分け

DOMAIN は完全一致のドメインに使い、単一ホストの処理に適しています。DOMAIN-SUFFIX はドメインとそのサブドメインに一致します。DOMAIN-KEYWORD は範囲が広く誤一致しやすいため、ドメイン構造が安定せず、キーワードが十分に明確な場合だけ使います。IP-CIDR は IPv4 のネットワーク範囲、IP-CIDR6 は IPv6 に対して照合します。GEOIP は IP 地理データベースに基づいて処理し、RULE-SET は外部または内蔵のルールセットを参照します。

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - DOMAIN-SUFFIX,example.com,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,ノード選択

例の no-resolve は、その IP ルールの照合時にドメインの追加解析を行わないことを示します。明確なローカルネットワーク範囲に適しています。実際の設定では、サブスクリプション本来のルール構成を維持し、必要な例外だけを適切な位置に追加してください。クライアントがオーバーライドルールに対応している場合は、サブスクリプション更新後に自動マージできます。ダウンロードした設定を直接編集すると、次回更新時に変更が上書きされる可能性があります。

接続ログからルールの問題を逆算する

特定サイトを調べるときは、まず関係のないアプリを閉じるか停止し、対象ページへ再アクセスしてから接続ログをドメインで絞り込みます。ログには通常、対象ホスト、使用ルール、ポリシーグループ、経路が表示されます。意図しないダイレクトルールに一致していた場合は、範囲の広すぎるドメインサフィックスや地理ルールがないか確認します。MATCH に到達していた場合は、前のルールが対象をカバーしていません。想定したプロキシグループに一致しているのに最終的に DIRECT になった場合は、そのグループで現在どの項目が選ばれているかを確認します。

現在のウェブページは複数のドメインへ同時にアクセスします。メインページのドメインが正常でも、静的リソース、ログイン API、画像のドメインが同じポリシーを使うとは限りません。主ドメインのルールを1つ追加してもページが完全に表示されない場合は、失敗したリクエストから関連ドメインを見つけ、広すぎるキーワードをむやみに追加しないでください。ブラウザーの開発者ツールと Clash の接続ログを照合すると、前者で失敗したリクエストを確認し、後者でその出口を確認できます。

DNS がルール結果に影響する理由

DNS はドメインを IP アドレスへ変換します。アプリが Clash に入る前に自分で名前解決し、IP だけを送信すると、ドメインベースのルールは元のホスト情報を直接取得できないことがあります。ネットワーク環境の影響を受けた解析結果が返ると、ノードが利用可能でも誤ったアドレスへ接続する可能性があります。Clash の DNS モジュールは設定に従って問い合わせを処理し、fake-ip や redir-host などのモードでドメインの対応関係を保持できます。

fake-ip モードでは、アプリに予約アドレス範囲の一時アドレスを返し、コアが対応関係から実際のドメインを特定してルールを適用します。ドメインルールを認識しやすい一方、LAN 機器、古いアプリ、実 IP に依存するプログラムではフィルターへの追加が必要になることがあります。redir-host は実際の解析結果を返す方式に近く、互換性を理解しやすい反面、ドメインの対応付けや接続識別の方法が異なります。名前が見慣れないという理由だけで切り替えず、現在のサブスクリプションの DNS 設定が安定しているなら、まず元の設定を維持してください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  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"

この例はフィールドの関係を示すもので、すべてのネットワーク環境で同じ上流アドレスを使うべきだという意味ではありません。サブスクリプション設定では、DoH、DoT、システム DNS、ドメイン別に分岐する nameserver-policy などが使われることがあります。変更前に元の値を記録してください。変更後にすべてのドメインが解決できなくなった場合は、まずサブスクリプションのデフォルト設定へ戻し、1053 などの待受ポートの競合、システムファイアウォールの遮断、TUN の DNS ハイジャック先が正しいポートかを確認します。

IPv6、LAN、カスタムルールの境界

端末が IPv6 接続を持っていると、アプリが AAAA レコードを優先して要求することがあります。設定が IPv4 だけを処理し、OS が IPv6 で直接接続すると、出口が一致しない可能性があります。IPv6 を無効にするかどうかは、ノード、コア、ローカルネットワークが完全に対応しているかによって決まり、常に無効化すればよいわけではありません。まず接続ログで異常なリクエストが IPv6 を使っているか確認し、そのうえでルール追加、DNS の返却内容の調整、該当経路の一時無効化を判断します。

ルーター、NAS、プリンター、開発サーバーへアクセスするときは、プライベートアドレス範囲とローカルドメインを直接接続にします。TUN 環境では LAN ルートも維持し、ローカル接続がリモートプロキシへ送られないようにします。LAN 機器から Clash のローカルプロキシへ接続できるようにする機能は別の設定で、待受範囲を変更します。共有が必要な場合だけ有効にし、ファイアウォールで信頼できるネットワークに制限してください。「LAN にアクセスすること」と「LAN にプロキシを公開すること」を混同しないようにします。

必要に応じて TUN で全通信を取り込む

TUN モードは仮想ネットワークインターフェースを作成し、ルーティングによってより多くの接続を Clash へ渡します。システムプロキシを参照しないゲーム、コマンドラインツール、ストアアプリ、TCP と UDP をまとめて処理したい場面に適しています。TUN は取り込み範囲を広げますが、無効なノード、誤ったサブスクリプション、不適切なルールを修正する機能ではありません。必ずシステムプロキシで設定が使えることを確認してから有効にし、異常時に戻せるよう元の DNS とプロキシ設定を記録しておきます。

有効化前に行う4つの確認

1つ目は、現在の設定がルールモードとシステムプロキシで正常にアクセスできること。2つ目は、ほかの VPN、仮想ネットワークアダプター、ルートを変更する可能性のあるツールを閉じ、複数の取り込み層が干渉しないようにすること。3つ目は、クライアントに管理者権限があるか、必要なサービスがインストールされていること。4つ目は、現在使用している設定を保存し、TUN、システムプロキシ、クライアントを正確に無効化・終了する場所を把握することです。準備ができたら TUN を有効にし、仮想ネットワークアダプターの初期化を待ちます。

Windows クライアントでは、ルート変更に必要な権限をサービスモードで取得することがあります。スイッチをクリックするとすぐ元に戻る場合は、サービスのインストール、権限不足、ドライバーの初期化失敗に関する表示を確認します。macOS ではネットワーク拡張機能や補助サービスのインストールが必要になることがあります。Android と iOS はシステム VPN インターフェースを使うため、デスクトップとは実装が異なり、同じ名前の TUN スイッチを探す必要は通常ありません。

TUN の主なパラメーター

auto-route は必要なルートを自動追加する項目で、ほとんどのデスクトップクライアントに適しています。無効にすると、通信を仮想ネットワークアダプターへ入れる方法を自分で管理する必要があります。auto-detect-interface は実際に通信しているインターフェースを識別します。Wi-Fi、有線、テザリングを切り替える端末で役立ちます。dns-hijack は指定された DNS リクエストをコアの DNS モジュールへ渡し、システム DNS の迂回を減らします。strict-route はルーティングをより厳密に制御し、漏えいを改善する場合がある一方、複数 NIC、仮想マシン、LAN アクセスに影響することがあります。

stack パラメーターは TUN のネットワークスタック実装を決めます。OS やクライアントによって system、gVisor、mixed などの選択肢があります。system は通常、OS のネットワークスタックに近く、性能と互換性はプラットフォームに左右されます。gVisor はユーザー空間のネットワークスタックを使うため、環境によって分離性や互換性が異なります。mixed はプロトコルに応じて組み合わせて処理します。明確な問題がなければ、クライアントの推奨値を使い、理論上の違いを求めて頻繁に切り替えないでください。

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

この例は一般的な構造だけを示しています。設定ファイルで利用できる具体的なフィールドは、現在のコアとクライアントによって決まります。GUI が生成する設定には、デバイス名、MTU、ルートの包含・除外項目などが追加される場合があります。サブスクリプションのオーバーライドを使う場合は、マージ後の結果で tun ブロックが重複定義されていないか確認します。後から現れるフィールドが前の設定を上書きすることがあります。

有効化後の確認手順

TUN を有効にしたら、現在どの経路が通信を取り込んでいるか分かるよう、まずシステムプロキシをオフにします。通常のウェブページを開き、接続ログにドメインリクエストが表示されるか確認します。次に、システムプロキシに従わなかったアプリをテストします。その後、LAN 機器、DNS 解析、普段使うログインサービスを確認します。ウェブは使えるのに LAN だけ使えない場合は、プライベートネットワークのルートと strict-route を確認します。すべてのドメインを解決できない一方で IP への直接アクセスに応答がある場合は、DNS ハイジャック、待受ポート、上流 DNS を重点的に調べます。

コマンドラインでシステムルートを確認できますが、作用を理解せずルート全体を手動削除しないでください。Windows では route print や PowerShell でインターフェースを確認できます。macOS と Linux では netstat -rn、route -n get、ip route が使えます。有効化前後のデフォルトルートと仮想インターフェースを比較し、通信が実際に TUN へ入っているか確認します。詳しい仕組みと手順はClash TUN モードの有効化方法を参照してください。

異常時に安全に終了する方法

有効化後にネットワークが完全に途切れた場合は、まず TUN を無効にしてルートが戻るのを待ち、次にシステムプロキシをオフにしてクライアントを終了します。戻らない場合は Wi-Fi や有線を再接続し、OS にアドレスと DNS を再取得させます。その後、システムプロキシが残っていないか、仮想ネットワークアダプターが有効なままになっていないか確認します。接続できない状態で複数のクライアントを次々再インストールしないでください。古いサービス、古いアダプター、新しい設定が重なり、原因を判断しにくくなります。

スリープからの復帰、ネットワーク切り替え、会社のネットワークから家庭のネットワークへの移動後は、自動インターフェース検出が古いルートを一時的に保持することがあります。まず TUN スイッチを一度切り替え、クライアントにインターフェースを再構築させます。特定のネットワークで再現する場合は、そのときの物理インターフェース、DNS、ルート、ログを記録し、インターフェース除外、ルート除外、別の stack を使うか判断します。企業 VPN と TUN を同時に使うとルートの優先順位が衝突しやすいため、どのツールがどの宛先ネットワークを担当するか明確にしてください。

日常管理、トラブル解決、応用への道筋を作る

設定後の安定運用に必要なのは、パラメーターを絶えず調整することではなく、再現性のあるメンテナンス習慣です。正常なサブスクリプション、明確に選択したプロキシグループ、ルールモード、動作するシステムプロキシ、必要に応じて有効にする TUN という、検証済みの基本状態を1つ残しておきます。クライアント、サブスクリプション、カスタムルールを更新するたびに、この基本経路がまだ成立しているかだけ確認します。複数の要素を同時に変えると、異常時に確実な状態へ戻れません。

日常の更新は3つに分ける

クライアント更新、コア更新、サブスクリプション更新は別々の作業です。クライアント更新では画面、OS 連携、コアの管理方法が変わります。コア更新では設定構文、プロトコル、ネットワーク処理が変わる可能性があります。サブスクリプション更新はリモート設定、ノード、ルールを更新するだけです。問題が起きたら、直近でどの層を変更したかを記録します。サブスクリプションだけを更新してプロキシグループが消えたなら、新しい設定内容を確認します。クライアント更新後に TUN サービスが起動しないなら、権限とサービス状態を調べます。

普段は長めの固定間隔でサブスクリプションを更新し、更新後に現在の設定が選択されているか確認します。クライアントをアップグレードする前に、サブスクリプション URL、カスタムオーバーライド、重要な設定を記録してください。アップグレード後すぐに古い設定を削除せず、ブラウザーアクセス、接続ログ、LAN、TUN を一度テストします。長期間稼働する端末では、メンテナンス時間にクライアントを一度再起動し、自動起動、権限、設定読み込みの問題を早めに見つけます。

ログと接続記録で範囲を絞る

接続記録は「あるリクエストがどこを通ったか」を示し、ログは「コアの処理中に何が起きたか」を示します。サイトの出口が想定と違う場合は接続記録を優先し、サブスクリプション解析、ポートのバインド、DNS 問い合わせ、TUN 初期化、ネットワークエラーはログを確認します。トラブルシューティングではログレベルをまず info にします。通常はこれで十分な情報が得られます。debug は大量の記録を生成するため、短時間の問題を再現するときだけ一時的に有効にし、完了後に戻してください。

ログを取り出すときは、エラーの前後にある少量の文脈を残し、サブスクリプション URL、認証情報、端末識別子、不要なアクセス記録を削除します。よくあるキーワードには timeout、connection refused、network unreachable、address already in use、parse error、permission denied があります。それぞれタイムアウト、接続先による拒否、ルート不在、ポート競合、設定解析、権限の問題を示します。まずエラーの種類に応じて対処し、それでも解決しない場合にクライアント変更を検討します。

安定したトラブルシューティングの流れ

1. 元のネットワークを確認する。システムプロキシと TUN を無効にし、ローカルと普段使うサイトへ通常のネットワークでアクセスできるか確認します。元のネットワークに問題がある場合は、Wi-Fi、有線、認証ページ、システム DNS を先に確認します。
2. コアの状態を確認する。クライアントを起動し、設定解析、ポート競合、権限エラーがないか確認します。コアが動作していなければ、その後のモードやノード設定も反映されません。
3. 設定の経路を確認する。サブスクリプションの更新日時、現在選択されている設定、主要なプロキシグループ、最終ノードを確認します。必要なら手動で更新しますが、連続して何度もリクエストしないでください。
4. 通信の取り込みを確認する。システムプロキシを有効にして新しいリクエストを発生させ、接続ログを確認します。記録がない場合は、アプリがシステムプロキシを使っていないか、ローカルポートの設定に問題があります。
5. ルールと出口を確認する。ルールモードとグローバルモードの結果を比較し、対象ドメインに適用されたルールを確認します。グローバルでは使えるのにルールモードで失敗する場合は、通信分岐を重点的に調べます。
6. 最後に TUN を確認する。基本経路が正常になってから TUN を有効にし、DNS、LAN、UDP、スリープ復帰を個別にテストします。複数の変数を一度に追加しないでください。

症状別に詳しく調べる必要がある場合は、トラブルシューティングでシステムプロキシ、サブスクリプション、TUN、接続の問題を確認してください。プラットフォーム、クライアント名、取り込み方式、プロキシモード、接続ログにリクエストが表示されるか、エラーの種類を伝えると、「インターネットに接続できない」だけの場合より正確に判断できます。

本当に役立つバックアップ項目

バックアップする価値があるのは、サブスクリプション URL の一覧、カスタムルールのオーバーライド、カスタム DNS の一部、コアのサービス設定、重要な設定に関する短い説明です。クライアントの設定エクスポートに対応していれば補助として保存できますが、単一のエクスポートファイルだけを唯一の復元手段にしないでください。クライアント間の移行で最も汎用性が高いのは、サブスクリプション URL と標準的な YAML の断片です。

カスタム設定には変更理由を添えてください。たとえば、どのサービスのためのドメインルールなのか、なぜ特定の LAN 範囲を除外するのか、どのネットワーク環境に対する TUN パラメーターなのかを記録します。数か月後に見直すとき、説明があればそのルールがまだ必要か判断できます。理由のない設定は増え続け、最終的に重複、競合、順序の分かりにくさを招きます。

日常利用から上級設定へ進む

応用学習は、接続処理の順に進めると理解しやすくなります。まずプロキシグループの select、url-test、fallback に慣れ、次にルールセットとルールプロバイダーを学び、その後 DNS の fake-ip、分岐 DNS、IPv6 を理解し、最後に TUN ルーティング、プロセスルール、単独コアの構築を扱います。各段階で具体的な利用目的を持ち、すべての機能を一度に有効にする必要はありません。接続ログから、なぜあるリクエストが特定の出口を選んだか説明できることのほうが、大量のパラメーターを暗記するより重要です。

複数端末で使う場合は、安定したカスタムルールを独立したオーバーライドファイルとして管理し、リモートサブスクリプション本体を直接変更しないようにします。サーバー環境では、最小限の待受範囲、サービスユーザーの権限、設定ディレクトリの権限、ログ管理、起動失敗時の復旧をさらに学ぶ必要があります。GUI クライアントのユーザーも YAML の基礎を知っておくと、マージ結果や解析エラーを理解しやすくなりますが、日常の編集ではクライアントの構造化された入口を優先してください。