Clash デスクトップ版
基礎からわかる使い方ガイド

Clash は単なる「オン・オフ」のスイッチではなく、ローカル環境で動作する通信処理チェーンです。アプリはまずローカルの待受ポートまたは仮想ネットワークインターフェースに接続を渡します。Clash のコアは、宛先ドメイン、宛先 IP、通信プロトコル、プロセスなどの情報を読み取り、設定ファイルのルールを上から順に照合します。その結果、接続は DIRECT、いずれかのプロキシグループ、または REJECT に振り分けられます。この経路を理解することは、クライアント画面のボタンを覚えることより重要です。システムプロキシを有効にしても特定のアプリだけ直接接続する、ノードのテストは成功するのにウェブページを開けない、ルールモードとグローバルモードで挙動が変わるといった問題は、たいていこの経路のどこかに原因があります。

クライアント、コア、設定ファイル

デスクトップクライアントは、画面表示、設定管理、システムプロキシの切り替え、ログ表示、更新などを担当します。Mihomo などの互換コアは、実際の待受ポート、ルール解析、接続転送を処理します。YAML 設定ファイルには、ポート、DNS、プロキシノード、プロキシグループ、ルールが記述されます。この3つは分けて理解する必要があります。クライアントを変えても設定構文が変わるとは限らず、同じ設定を使えるかどうかは主にコアが対応するフィールドとクライアントのインポート方式で決まります。クライアントが正常に起動しても、サブスクリプション、DNS、システムプロキシが正しく設定されているとは限りません。

一般的なローカルポートには、HTTP プロキシポート、SOCKS5 ポート、両方のプロトコルを受け付ける mixed-port があります。デスクトップクライアントでは通常、これらの値を自動管理します。たとえば mixed-port: 7890 の場合、ブラウザーやターミナルのプロキシアドレスを 127.0.0.1:7890 に設定すると、通信がコアへ渡されます。external-controller は制御インターフェースで、クライアント画面が接続情報を読み取ったり、プロキシグループを切り替えたり、設定を読み込んだりするために使われます。プロキシポートとは別のものです。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: true
external-controller: 127.0.0.1:9090

システムプロキシと TUN の違い

システムプロキシは、OS がアプリに公開する HTTP または SOCKS プロキシ設定です。ブラウザーや多くのデスクトップソフトはこれを読み取りますが、ターミナルコマンド、ゲーム、一部のストアアプリ、仮想マシン、独自のネットワークスタックを使うアプリは無視することがあります。TUN モードは仮想ネットワークインターフェースを作成し、より低い層で IP 通信を引き受けるため、通常は適用範囲が広くなります。両者は速度設定ではなく、必ず同時に有効にする機能でもありません。普段のウェブ閲覧ではシステムプロキシを使い、明らかにシステムプロキシを読み取らないアプリがある場合に TUN の必要性を検討してください。

ドメイン、DNS、ルール照合

ユーザーがドメイン名を入力すると、まず DNS が名前を IP アドレスへ変換します。ルールエンジンは、名前解決前にドメインで照合する場合もあれば、IP 取得後に GEOIP や IP-CIDR ルールを続けて適用する場合もあります。DNS リクエストが誤った経路を通ると、ページを開けない、ルールの命中結果が想定と違う、ローカルネットワークのドメインだけ使えないといった問題が起きます。「ノードは正常なのにサイトが開かない」場合、原因はノードではなく、名前解決、IPv6、ブラウザーのセキュア DNS、ルールの順序にあることが少なくありません。

ログと接続ページは、この処理チェーンを確認するための2つの入口です。ログでは、設定の読み込み状況、ポートの競合、DNS エラーを確認できます。接続ページでは、どのアプリがセッションを作成したか、宛先は何か、どのルールに命中したか、最終的にどのポリシーを使ったかを確認できます。初めてクライアントを使うときは、クライアント画面の見方も参考にして、プロキシ、設定、接続、ログ各ページの役割を把握してください。これらの概念を理解すれば、インストール、サブスクリプション登録、ルール設定を機械的にクリックする必要がなくなります。

デスクトップ向けのクライアントには Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash for Windows、ClashX Meta があります。モバイル向けには Clash Meta for Android と Surfboard もあります。当サイトのダウンロード一覧では、全プラットフォーム対応を重視し、Windows、macOS、Android、iOS で近い操作感を保ちたいユーザー向けに Clash Plus を第一候補として案内しています。コミュニティ製のデスクトップクライアントを好む場合は、Clash Verge Rev、FlClash、Nyanpasu を比較するとよいでしょう。Clash for Windows と ClashX Meta は開発が終了しているため、古い環境や既存設定の扱いに限って利用し、新規インストールの標準候補にはしないことをおすすめします。

Windows：アーキテクチャ、インストール先、ループバック制限

多くの Windows PC では x64 インストーラーを使います。ARM デバイスでは、クライアントが明示的に提供する ARM 版を選んでください。画面が似ているからといって混用してはいけません。インストール後はまずクライアントを通常どおり起動し、タスクトレイアイコン、設定ページ、ログページが開くことを確認してからサブスクリプションを登録します。ネットワークから取得したアプリについて確認を求められた場合は、ダウンロード元とファイル名を確認したうえで、OS の手順に従って処理してください。一度の警告を回避するために、セキュリティ機能全体を無効にするのは避けます。

システムプロキシを有効にすると、従来型のデスクトップブラウザーは通常そのまま使えます。ただし一部の UWP アプリは Windows のループバック分離により、ローカルのプロキシポートへ接続できません。その場合はクライアント付属の UWP ループバックツールを使い、実際にプロキシが必要なアプリを例外リストへ追加してから、対象アプリを再起動します。ループバック設定で解決できるのは「アプリがローカルプロキシに接続できない」問題であり、無効なサブスクリプション、誤ったノード、DNS 設定は修復できません。詳しいプラットフォーム操作とよくある問題はWindows への Clash インストール手順を参照してください。

macOS：チップアーキテクチャとネットワーク権限

「この Mac について」でプロセッサが Apple Silicon か Intel かを確認し、対応するインストーラーを選びます。アーキテクチャが合わないと、アプリが起動しないか、追加の互換レイヤーが必要になる場合があります。システムプロキシ、サービスモード、TUN を初めて有効にするとき、macOS は管理者パスワードの入力やネットワーク拡張の承認を求めることがあります。許可はシステムダイアログの指示に従って行ってください。アプリをアプリケーションフォルダから直接移動した後も使い続けると、ログイン時の起動項目や補助サービスのパスが無効になることがあります。

Linux：パッケージ形式とデスクトップセッション

Debian、Ubuntu および派生ディストリビューションでは通常 DEB、Fedora、RHEL 系では通常 RPM を使います。インストール後すぐにメニュー項目が表示されない場合は、デスクトップセッションを終了して再ログインするか、ターミナルから一度起動して具体的なエラーを確認します。Linux のデスクトップ環境ではシステムプロキシの実装が完全に統一されていません。ブラウザーは GNOME や KDE のプロキシ設定を読み取る一方、ターミナルツールは通常環境変数に依存します。システム全体を制御する必要がある場合に TUN を設定し、仮想インターフェースの作成とルート変更の権限があることを先に確認してください。

# Debian / Ubuntu にローカル DEB パッケージをインストール
sudo apt install ./client-package.deb

# よく使うポートが使用中か確認
ss -lntp | grep -E '7890|9090'

まだクライアントを比較中なら、Clash Plus、Verge Rev、FlClash の比較を参照してください。選ぶ際は、画面の機能数よりも、現在のシステムへの対応、TUN の実装、設定の互換性、更新状況を優先します。決定したらダウンロードセンターから対応プラットフォームへ進み、異なる配布元のインストーラーと設定説明を混在させないようにしてください。

Clash の設定は通常 YAML ファイルとして保存されます。完全な設定にはプロキシノードだけでなく、プロキシグループ、ルール、DNS、TUN、待受ポートなどが含まれる場合があります。サブスクリプション URL は設定のリモートソースで、クライアントは URL から内容を取得してローカル設定として保存します。登録後にコアが実際に読み込むのはローカルコピーです。サブスクリプションを更新するとリモートの内容が再取得されるため、生成された設定を直接編集すると、次回更新時に上書きされることがあります。

まず手元のデータ形式を確認する

ブラウザーのアドレスバーで開けるサブスクリプション URL、長いエンコード文字列で構成された汎用サブスクリプション、proxies:、proxy-groups:、rules: を含む YAML ファイルは、同じ形式ではありません。クライアントで形式エラーが出たら、何度も登録を押す前に URL が返す内容を確認します。サーバーがログインページ、期限切れの案内、汎用 Base64 ノード一覧を返す場合、クライアントは保存できても完全な Clash 設定として読み込めないことがあります。

有効な YAML はインデントに厳密で、タブではなくスペースを使います。同じ階層のフィールドは同じインデントにそろえ、リスト項目はハイフンで始めます。コロン、シャープ記号、特殊文字を含む名前は引用符で囲んでください。ブラウザーからコピーするときは、全角記号やスマートクォートも避けます。YAML、Base64、形式変換の違いについては、Clash サブスクリプションの形式と相互変換も参照してください。

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

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

  - name: "自動選択"
    type: url-test
    proxies:
      - "サンプルノード A"
      - "サンプルノード B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,example.com,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

登録、アクティブ化、更新は別の操作

登録はサブスクリプションやファイルをクライアントの設定一覧へ追加する操作です。アクティブ化は、その設定を選んでコアに実行させることを指します。更新はリモートの内容を再取得する操作です。まず設定ページにサブスクリプション URL を貼り付け、ダウンロード完了を確認します。次に設定を選び、プロキシページでプロキシグループのポリシーを選択し、最後にシステムプロキシを有効にします。設定一覧に複数のファイルがある場合は、現在のアクティブ設定を明確にしておきましょう。A の設定を編集したつもりで、実際には B が動作しているという事態を防げます。

サブスクリプションの更新に失敗したら、HTTP リクエストの経路に沿って調べます。まず URL が期限切れでなく、現在のネットワークからアクセスできることを確認します。次にシステム時刻を確認します。時刻のずれで TLS 接続に失敗することがあります。最後にクライアントログのステータスコードや名前解決エラーを確認します。401、403 は通常、認証または URL の状態に関係します。HTML が返る場合は、設定ではなくウェブページを指している可能性があります。解析エラーでは YAML の構造とクライアントのコア互換性を確認します。完全なサブスクリプション URL をフォーラムやスクリーンショットで公開しないでください。URL 自体にアクセス認証情報が含まれることがあります。

上書きリスクとローカル拡張

カスタムルールを追加する場合は、クライアントが提供する上書き、設定のマージ、スクリプト拡張、ルールセット機能を優先して使います。サービス側が管理するノード部分とローカルルールを分離できるためです。マージに対応していないクライアントでは、サブスクリプション設定をローカルファイルへコピーして編集し、更新用と比較用に元のサブスクリプションを残します。更新後にノードやプロキシグループの変更をローカルコピーへ反映するほうが、自動更新されるファイルを直接編集するより復旧しやすくなります。

設定の読み込みに失敗した場合、ログの行番号は通常、パーサーが問題を見つけた位置を示します。ただし本当のインデントエラーは、その数行前にあることもあります。エラー行から上へたどり、同じ階層のフィールド、引用符の閉じ忘れ、リストのインデントを確認してください。設定は読み込めるのにプロキシグループが空の場合は、proxy-groups が参照するノード名と proxies の名前が完全に一致しているか確認します。ノードが存在するのに選べない場合は、グループの種類、provider の参照、サブスクリプション変換結果が不完全でないかを調べます。「ダウンロード失敗」「解析失敗」「実行失敗」を分けて記録すると、原因を絞り込みやすくなります。

Clash クライアントでよく使われる Rule、Global、Direct モードは、コアが最終的なポリシーを決める方法を制御します。アプリが Clash に通信を渡すかどうかを変えるものではなく、利用できないノードを自動修復するものでもありません。システムプロキシを無効にしている場合、Global に切り替えてもローカルプロキシポートへ入っていないブラウザー通信はコアを通りません。TUN が通信を引き受けている場合に限り、モード切り替えが対象通信へ反映されます。したがって、モードは通信経路全体の中で理解する必要があります。

Rule：ルールを順に判定

Rule は日常利用での標準的な選択肢です。コアはルール一覧の先頭から照合し、命中した時点で後続の確認を止めます。一般的には、ローカルネットワークや明示的な直接接続ドメインを DIRECT に送り、プロキシが必要なドメインをプロキシグループへ、広告や接続したくない宛先を REJECT へ振り分けます。残りの通信は最後の MATCH が受けます。ルールモードの利点は、すべての通信を同じ出口へ送ることではなく、アクセス範囲、通信経路、ローカルサービスとの互換性を両立できることです。

Global：全体を1つのグループで選択

Global モードでは通常、コアに入ったすべての接続をグローバルプロキシグループへ渡します。「問題はルールが原因か」を一時的に切り分けるのに適しています。たとえば Rule では失敗し、Global では成功する場合、ノードと基本的なプロキシ経路はおそらく利用可能で、ルールの命中、DNS、プロキシグループの選択を確認すべきだと判断できます。両方で失敗するなら、ノード、ポート、システムプロキシ、名前解決を優先して調べます。Global を誤ったルールの隠れみのとして常用するのは避けてください。ローカルサービス、LAN 機器、プロキシ不要の通信までプロキシへ送られる可能性があります。

Direct：引き受けた通信を直接接続

Direct モードでは、コアに入った接続を宛先へ直接接続します。クライアントによる通信の引き受け自体が影響しているかを確認したり、コアを動かしたまま一時的にプロキシを止めたりする際に使えます。ただし Direct はクライアントを完全に終了する操作ではありません。ローカルポート、TUN、DNS モジュール、接続記録は動作し続ける場合があります。OS 本来のネットワーク経路へ戻すには、システムプロキシまたは TUN を無効にしてからコアを終了し、OS のプロキシ設定が元に戻っていることを確認します。

実際の出口に近いのはモードよりプロキシグループ

モードは「どこでポリシーを探すか」を決め、プロキシグループが実際に使うノードやサブグループを決めます。select グループはユーザーが手動で選択します。url-test は指定したテスト URL への到達性を定期的に測定し、利用可能な候補を選びます。fallback は利用可能なノードを順番に使い、load-balance は実装と設定した方式に基づいて接続を分配します。テスト結果が示すのはテスト先への接続状況だけで、すべてのウェブサイトの体感や継続的な帯域幅を保証するものではありません。

ノードを切り替えても、確立済みの TCP、QUIC、長時間接続が新しいノードへ必ず移行するわけではありません。ブラウザーが古い接続を再利用したり、アプリが DNS キャッシュを保持したりすることもあります。切り替え結果を確認するときは、接続ページで関連セッションを閉じ、対象アプリを再起動し、必要に応じて古い接続が解放されるまで待ちます。ルールが宛先を別のプロキシグループへ送っている場合、現在のグループを切り替えても結果は変わりません。まず接続ページでルールと経路を確認し、プロキシページのハイライトだけを見て判断しないでください。

モード切り替えは、闇雲な試行ではなく原因判定のために行います。切り替えるたびに、対象ドメイン、命中ルール、実際のポリシー、接続結果を記録すれば、ルールの問題と経路の問題をすばやく切り分けられます。日常利用では Rule に戻し、少数の例外だけをカスタムルールで調整するほうが、Global を常用するより管理しやすくなります。

ルール一覧は上から下へ実行され、最初に命中したルールが接続ポリシーを決めます。ルールシステムは複数条件の総合点を計算するものではなく、「より具体的なルール」を自動的に選ぶこともありません。前方に広い範囲を対象とする DOMAIN-SUFFIX、GEOIP、IP-CIDR があると、後ろに書いた例外ルールは実行されない可能性があります。ルールは「正確な例外を前、広範な分類を中央、最後にフォールバック」という構成にします。

よく使うルールタイプ

DOMAIN は完全なドメイン名に一致します。たとえば api.example.com だけが対象です。DOMAIN-SUFFIX は指定したドメインとサブドメインに一致し、サイト単位の振り分けに向いています。DOMAIN-KEYWORD はドメイン内の文字列で一致するため範囲が広く、誤判定が起きやすくなります。IP-CIDR と IP-CIDR6 は IPv4、IPv6 のネットワーク範囲で一致します。GEOIP は IP 地理データベースで分類します。PROCESS-NAME はプロセス名で一致しますが、利用可否は OS、権限、コアの対応状況に左右されます。MATCH は前のルールに一致しなかった残りの接続を処理します。

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.org,ノード選択
  - DOMAIN-KEYWORD,example,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

no-resolve は、IP 系ルールを実行するとき、照合のためにドメイン名を追加で解決しないようコアへ指示します。すでに宛先 IP を取得している接続に適しており、不要な DNS クエリを避けられる場合もあります。ただし、名前解決後の IP が必要なルールでは、追加すると結果が変わることがあります。機械的に付け足さず、ルールタイプと接続メタデータを確認して判断してください。

ポリシーフィールドには実在するグループを指定する

ルールの末尾は任意のラベルではなく、プロキシグループ名、ノード名、または組み込みポリシーです。設定に ノード選択 と書いた場合、proxy-groups に同名のグループが存在しなければなりません。文字、スペース、大文字・小文字まで一致させます。DIRECT は直接接続、REJECT は接続拒否を意味します。カスタム名に日本語を使っても問題ありませんが、複数の設定や上書きファイルで管理する場合は、短く安定した名前のほうが参照ミスを防ぎやすくなります。

ローカルの例外を管理しやすい位置に置く

家庭の NAS、プリンター、ルーター管理画面、社内ネットワークは通常、直接接続が必要です。まず明確なドメインを列挙し、一般的なプライベートアドレス範囲も対象にしながら、ローカル DNS の利用を維持します。未知のアドレスをすべてプロキシへ送ると、LAN アクセスが迂回したり失敗したりすることがあります。反対に、直接接続の範囲が広すぎると、本来プロキシを通す宛先が先に命中します。ルールを追加するときは接続ページから実際の宛先をコピーし、ウェブページの表示名からドメインを推測しないでください。1つのページでも複数の API、静的リソース、認証ドメインへ接続することがあります。

ルールセットと provider

大規模なルールをすべてメイン設定へ記述するのは適切ではありません。rule-provider に対応するコアでは、ローカルファイルやリモート URL からルールセットを読み込み、RULE-SET で参照できます。ルールセットでは、動作タイプ、形式、更新間隔、保存先を明確にします。リモートルールの更新に失敗した場合、コアがキャッシュを使い続けることもあれば、設定方法によってはエラーになることもあります。重要なルールについては、キャッシュ方式と失敗時の挙動を確認してください。

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-network.yaml
    url: https://example.com/rules/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,ノード選択

ルールを調べるときは、まず接続ページで対象セッションを見つけ、Host、宛先 IP、命中ルール、最終ポリシーを記録します。命中ルールが想定と違う場合は、前に広範なルールがないかを確認します。ルールは正しいのにポリシーが違う場合は、プロキシグループの現在の選択を確認します。ドメインルールが表示されない場合は、アプリが IP を直接使っていないか、DNS を別のプログラムが処理していないか、古いセッションを再利用していないかを調べます。変更後は設定を再読み込みして新しい接続を作成し、古い接続で新しいルールを検証しないようにします。

サブスクリプション設定では、更新時に rules が書き換えられることがよくあります。カスタムルールを長期運用するなら、クライアントの prepend、append、上書き機能を優先してください。優先して命中させる例外はルール一覧の前方へ、通常の追加ルールは MATCH の前へ置きます。各カスタムルールの横に用途を記録し、不要になった項目は定期的に削除します。ルール数が多いほどよいわけではありません。各ルールの出所、優先順位、対象を説明できることが、保守しやすい分岐設定につながります。

TUN モードは仮想ネットワークインターフェースで IP 通信を受け取り、Clash のルールエンジンへ渡します。ターミナルツール、ゲーム、一部のストアアプリ、独自にネットワーク接続を管理するソフトに適しています。システムプロキシより適用範囲が広い一方、ルーティング、DNS、ファイアウォール、仮想マシン、他の VPN ソフトの影響を受けやすくなります。システムプロキシで対象アプリをカバーできない場合にだけ有効化し、普段の閲覧で TUN を必須条件にする必要はありません。

有効化前に確認する基本条件

Windows では通常、仮想ネットワークインターフェースの作成とルート変更にクライアントの補助サービスまたは管理者権限が必要です。macOS ではネットワーク拡張を承認し、Linux では TUN デバイスの権限とルート・ファイアウォールルールを変更する権限が必要です。クライアントに「サービスモード」がある場合は、サービスのインストールが成功したことを確認してから TUN を有効にします。スイッチがすぐ元に戻る、ログに permission denied、operation not permitted、interface の作成失敗が出る場合、問題は権限またはサービス層にあります。ノードを入れ替え続けるべきではありません。

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

stack は TUN のネットワークスタック実装を指定します。一般的な値には system、gvisor、mixed があり、対応範囲はコアと OS によって異なります。system は OS のネットワークスタックに依存し、gvisor はユーザー空間でより多くのネットワーク処理を行い、mixed は互換性と性能のバランスを取ります。特定の UDP、ゲーム、LAN 接続に問題がある場合は、ネットワークスタックを個別の変数としてテストできます。ただし変更後はコアを完全に再起動し、古い接続を削除してください。

auto-route は、通信の引き受けに必要なルートをコアが自動設定するための項目です。auto-detect-interface は現在の出口インターフェースを識別し、有線と無線を切り替える環境に適しています。複数の NIC、仮想マシン、コンテナ、ダイヤルアップ接続、他の VPN が同時に存在すると、誤ったインターフェースが選ばれることがあります。TUN 有効後に全く通信できない、LAN に届かない、2つの仮想インターフェース間で通信がループするといった症状が出ます。その場合はまず他の通信制御ソフトを無効にし、システムのルートテーブルとデフォルト出口を確認します。

DNS 乗っ取りと fake-ip

dns-hijack は、指定ポートへの DNS クエリをコアで処理し、アプリが Clash の DNS を迂回するのを防ぎます。fake-ip モードではドメインに予約アドレスを返し、コアがマッピングから元のドメインを復元してルールを適用します。ドメインルールが安定して命中しやすい一方、実 IP に依存する LAN 機器、一部のゲーム、企業認証、特殊プロトコルでは fake-ip-filter への追加が必要になる場合があります。redir-host は実際の名前解決結果を返すため、互換性のある経路が異なります。強化モードを切り替えるとキャッシュや既存接続に影響するため、確認前に OS とブラウザーの DNS キャッシュを更新してください。

LAN と予約アドレス

TUN を有効にしても、プライベートネットワーク、リンクローカルアドレス、ローカルドメインが直接接続できる状態を維持する必要があります。家庭内ネットワークでよく使われる IPv4 範囲には 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 があります。IPv6 のローカルアドレスも実際の環境に合わせて扱います。直接接続ルールだけでは不十分です。DNS が NAS の名前を外部リゾルバーへ送ると、正しいアドレスを取得できないことがあります。内部ドメインは LAN の DNS に解決させるか、hosts、nameserver-policy などで解決経路を明示してください。

最小限のトラブル対処手順

TUN を有効にして通信できなくなったら、最初に TUN を無効にして元のネットワークが戻るか確認します。次にログで権限、インターフェース、ルートのエラーを確認します。続いて他の VPN と仮想 NIC プログラムを停止します。その後、enable、stack、auto-route、auto-detect-interface など必要な項目だけを残してテストします。最後に DNS 乗っ取りとカスタムルートを追加します。ウェブページは開けるのに特定のゲームだけ失敗する場合は、TCP、UDP、IPv4、IPv6 の経路を重点的に比較し、設定全体をすぐに作り直さないでください。

TUN の確認では、ブラウザー、ターミナル、LAN、システム復元の4項目をテストします。ブラウザーがルールどおりにアクセスできること、プロキシ環境変数を設定していないターミナルの通信が接続ページに表示されること、ルーターや NAS にアクセスできること、TUN を無効にした後に OS のデフォルトルートと DNS が戻ることを確認します。4項目すべてに合格して初めて、通信の引き受けから終了までの経路が完成したと判断できます。

安定した利用には、使える設定の保管、必要に応じたサブスクリプション更新、クライアントとコアの更新内容の確認、不要なルールの整理、ネットワーク環境変更後のプロキシ設定確認といった、少量でも継続的なメンテナンスが欠かせません。問題が起きても、クライアントの再インストールは通常、最初に行う対策ではありません。サブスクリプション、システムプロキシ、DNS、TUN の権限、ルールの誤りは再インストール後も残るためです。アプリ層、通信制御層、コア層、ポリシー層、リモート経路の順に確認するほうが効果的です。

再現可能なヘルスチェックを作る

クライアントや設定を更新するたびに、まずコアが起動しているか、設定が読み込まれているか、ポートが待ち受けているかを確認します。次にブラウザーのページとターミナルのリクエストを1つずつ使って検証します。接続ページに該当セッションが表示され、ルール欄が想定どおりで、プロキシグループが実際の選択先を示していることを確認します。最後に LAN アドレスへ接続し、直接接続の例外が影響を受けていないかを確認します。毎回実施する必要はありませんが、大幅な設定変更、OS 更新、ネットワーク環境の切り替え後には有効です。

# macOS / Linux：現在のターミナルだけ一時的にプロキシを設定
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

# テスト完了後に削除
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

# PowerShell：現在のウィンドウだけに適用
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# 現在のウィンドウの設定を削除
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

ターミナルの環境変数とシステムプロキシは別々に動作します。ブラウザーは使えるのにコマンドラインだけ使えない場合は、まずターミナルのプログラムがシステムプロキシを読み取るか確認し、次に HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を確認します。反対に、クライアントを終了してもターミナルが 127.0.0.1:7890 へ接続しようとする場合は、環境変数が残っていることがよくあります。ブラウザーとターミナルを分けて確認する方法は、システムプロキシが効かないときの2つの確認ルートを参照してください。

よくある障害と確認ポイント

ポート競合と残留プロセス

ログに address already in use と表示される場合、別のプロセスが同じポートを待ち受けています。二重起動したコア、別のプロキシクライアント、異常終了後に残ったプロセスなどが考えられます。まず OS のタスクマネージャーやポート確認ツールで使用中のプロセスを特定し、該当プログラムを通常の手順で終了します。ポート番号を別の値へ変更すればコアは起動できますが、ブラウザー、ターミナル、システムプロキシが古いポートを参照したままだと、「クライアントは正常なのに通信できない」という別の問題になります。ポートを変更する場合は、参照しているすべての場所も同時に更新してください。

更新方針とロールバック

クライアント、コア、サブスクリプション、ルールセットは、それぞれ別の更新経路です。4つを同時に更新しないでください。まず現在の設定とクライアント設定を保存し、1項目だけ更新して基本テストを完了します。コア更新後は設定フィールドの互換性、サブスクリプション更新後はプロキシグループ名とルールの変化、ルールセット更新後は命中結果、クライアント更新後はシステムプロキシ、サービスモード、起動項目を重点的に確認します。異常時にどの層を戻すかを明確にするほうが、設定をすべて作り直すより確実です。

システムのスリープ、ネットワーク切り替え、社内ネットワークから家庭のネットワークへの移動後は、古い接続、デフォルト NIC、DNS キャッシュが残っていることがあります。まずコアを再起動し、対象アプリを開き直します。TUN で自動的に出口を判定している場合は、現在のデフォルトインターフェースが変わっているか確認してください。特定のウェブサイトだけに問題があるなら、そのサイトの接続と DNS キャッシュを削除すればよく、システム全体のネットワークをリセットする必要はありません。メンテナンスでは変更範囲を小さくし、毎回の変化を説明できる情報を残すことが重要です。

最初の7章を終えると、アプリの通信がコアへ入り、サブスクリプションが更新でき、Rule モードで想定どおりに分岐し、必要なときだけ TUN を有効にし、ログと接続ページで障害を特定できる基礎経路が整います。次の段階では機能を追加し続けるのではなく、設定を明確で検証可能、かつ元に戻せるモジュールへ分けます。設定が成熟しているかはルール数ではなく、ネットワーク切り替え、サブスクリプション更新、クライアントアップグレード後も動作し続けるかで判断します。

第1段階：設定の役割を分離する

メイン設定にはポート、モード、DNS、プロキシグループ、ルールの入口を残します。サービス側のサブスクリプションにはノードと基本グループを任せ、ローカル上書きには固定のカスタムルールを置き、大規模なルールは rule-provider へ分離します。デバイス固有の設定も別に記録します。こうすればサブスクリプション更新でローカルポリシーが上書きされず、クライアントを変更するときも移行対象をすぐ判断できます。設定ファイル名には desktop-rule、laptop-tun、home-lan のように用途と環境を含め、「新しい設定2」のような後から判別できない名前は避けてください。

複数のデバイスで同じポリシーを管理する場合でも、ノード認証情報を含む完全なファイルをそのまま同期しないでください。機密情報を含まないルール断片、DNS テンプレート、説明文書だけを同期し、サブスクリプションは各デバイスで個別に登録します。分岐ロジックを統一しながら、ポート、ネットワークインターフェース、ローカルパスなどのシステム差異がデバイス間で上書きされるのを防げます。

第2段階：ドメイン単位で DNS ポリシーを設計する

複雑なネットワークでは、単一の nameserver がすべてのドメインに適するとは限りません。コアが対応している場合は、nameserver-policy を使って内部ドメイン、特定の公開ドメイン、異なるルールセットごとにリゾルバーを指定できます。設計前に、問題が「内部ドメインを LAN DNS でしか解決できない」のか、「特定ドメインで誤った結果を避けたい」のか、「IPv6 経路が不安定」なのかを明確にします。目的が曖昧なまま複数のリゾルバー、fallback、フィルター条件を重ねないでください。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1
    "+.internal.example":
      - 10.0.0.53
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.home.arpa"

内部 DNS アドレスは、対象ネットワーク上で実際に到達できなければなりません。ノート PC が家庭や社内ネットワークを離れると、これらのアドレスがタイムアウトする可能性があるため、ネットワーク環境の切り替えを考慮します。クライアントが設定切り替えに対応しているなら、ネットワークごとに DNS の上書きを用意できます。1つの設定だけを使う場合は、内部ドメインのルールが通常の公開 DNS に影響しないようにします。DNS を調整した後は、明確なドメインで名前解決の結果と接続ページのルール命中を確認し、ページが開くかどうかだけで判断しないでください。

第3段階：制御インターフェースで読み取り専用診断を行う

制御インターフェースでは、現在の設定、プロキシグループ、接続状態を読み取れます。デフォルトでローカルアドレスだけに待ち受けさせるほうが安全で、デスクトップクライアントには十分です。コマンドラインからアクセスする前に、external-controller のアドレスとポートを確認します。secret を設定している場合は、クライアントの方式に従って認証情報を渡してください。制御インターフェースを公開ネットワークへ直接公開してはいけません。以下の例は、応答があるかを確認するためにローカルの制御ポートを読み取るだけです。

curl http://127.0.0.1:9090/configs
curl http://127.0.0.1:9090/proxies
curl http://127.0.0.1:9090/connections

診断では変更よりも読み取りを優先します。/configs では現在のモードと一部の実行パラメーターを確認でき、/proxies ではプロキシグループの構造を、/connections ではアクティブな接続を確認できます。互換コアによって API フィールドが異なる場合があるため、自動化スクリプトではフィールドの欠落や API の利用不可を処理し、すべてのクライアントが同じ構造を返すと仮定しないでください。

第4段階：変更に対応するテスト項目を作る

ルールや DNS を変更するたびに、少なくとも4種類の宛先をテストします。明確に直接接続すべき LAN サービス、明確にプロキシを通すドメイン、MATCH が受ける未知の宛先、特別な処理が必要なアプリです。対象、想定ポリシー、実際のルール、最終経路を記録します。テスト項目に沿って確認するほうが、感覚でいくつかのサイトを閲覧するより、広範なルールの先行命中、DNS ポリシーの漏れ、プロキシグループの参照ミスを発見しやすくなります。

TUN を使う設定では、終了時のテストも追加します。TUN を無効にした後にデフォルトルートが戻り、システム DNS が使え、ブラウザーがローカルポートに依存しなくなることを確認します。自動起動を使う場合は、OS 再起動後に補助サービス、コア、設定、システムプロキシの起動順も確認してください。起動項目が有効と表示されても、各層が準備完了とは限りません。ログの時系列から、設定の読み込みがネットワーク確立より前か、システムプロキシがまだ待ち受けていないポートを指していないかを判断できます。

次の学習は3つの方向から選べます。より細かな分岐が必要なら rule-provider、プロキシグループの連携、プロセスルールを深掘りします。より多くのアプリをカバーしたいなら、TUN ルーティング、DNS 乗っ取り、複数 NIC の挙動を調べます。長期運用が目的なら、設定のバージョン記録、変更内容、構文チェックの自動化を整えます。3つを同時に進めず、現在の環境で最も明確な問題から始めてください。

基礎から使いこなすまでのゴールは、すべてのフィールドを暗記することではありません。通信がどのように Clash へ入り、なぜ特定のルールに命中し、最終的にどのポリシーが選ばれ、失敗時にどの層を確認すべきかを説明できることです。最短の操作手順をもう一度確認するなら入門ガイドへ、インストールやクライアントの変更ならダウンロードセンターへ進んでください。すぐに使うための手順と、詳しく調べるための情報を分けることで、日常のメンテナンスが安定します。