Clash全プラットフォームインストール設定大全

本章では3つのことを解決する:クライアントとコアの役割分担を理解すること、使用可能なサブスクリプションリンクを準備すること、システムプロキシとTUNという2つの通信制御方式の違いを理解すること。これらの概念は後続の5つのプラットフォーム章を通じて使われるので、まず数分かけて読んでおくと、後の重複した調査の手間を大きく省ける。

クライアントとコアの役割分担

普段「Clash」と呼んでいるものは実際には2層構造になっている。コアエンジンが通信の転送、ルールマッチング、DNS処理を担当し、GUIクライアントが画面表示、サブスクリプション管理、システム設定の書き込みを担当する。現在の主要クライアントはほぼすべて Mihomo コアを採用しており、本文で触れる TUN、fake-ip、ルールマッチングなどの機能はすべてコア側が提供し、クライアントはそれらを可視化されたスイッチにしているだけだ。この構造を理解すると多くの現象が説明できる:異なるクライアント間でもコアの動作はほぼ同一で、差異は画面とOS統合の部分に集中する。クライアントのバージョンとコアのバージョンは別々に更新される2本の系列であり、両者は一致しない。ある機能が「このクライアントにはあるが、あのクライアントにはない」場合、多くは画面上に表示されていないだけで、コア層には実際には存在している。

クライアント選びで迷う必要はない:どのプラットフォームでも第一推奨は Clash Plus、Linux デスクトップでは Clash Verge Rev を推奨する。全一覧とインストーラーはクライアントダウンロードページを、画面・コア・メンテナンス状況の横並び比較は「主要な Clash クライアントの選び方」を参照。

サブスクリプションリンク:認証情報として厳重に管理

サブスクリプションリンクはサービス提供者が生成する HTTP(S) アドレスで、クライアントがこれにアクセスするとノードとルールを含む完全な設定を取得できる。心得るべき点が2つある。第一に、サブスクリプションリンクはアカウント認証情報と同等であり、流出はアカウント共有と同じことになるため、公開の場に貼り付けないこと。第二に、サービス提供者によって出力形式が異なり、よく見られるのは Clash YAML と Base64 の2種類で、対応状況と変換方法は「Clash サブスクリプション形式まとめ」を参照。インポート前に、手元にあるのがサブスクリプションリンク本体であり、単一ノードの共有リンクではないことを確認しておく——後者は1つのノードしか記述しておらず、完全なルールセットを生成できない。

システムプロキシと TUN:2つの通信制御方式

すべてのプラットフォームにおいて通信を制御する経路は2つしかない。システムプロキシ:クライアントがローカルにリスニングポート(通例 7890)を開き、「127.0.0.1:ポート番号」をOSのプロキシ設定に書き込む。システムプロキシに従うアプリ(ブラウザや大半のネット接続ソフト)の通信はすべてこれを経由する。実装が軽く負荷も小さいが、コマンドラインツールや一部のゲーム、システムコンポーネントは迂回してしまう。TUN モード:コアが仮想ネットワークカードを作成し、ネットワーク層でアウトバウンド通信を全て制御下に置く。プロキシ設定を読まないプログラムもカバーできる代わりに、より高い権限が必要になる——Windows ではシステムサービスの導入、macOS では権限付与された補助ツール、Linux では root またはケーパビリティ付与、モバイルではシステム VPN の許可が必要。

本文を通して守るべき鉄則がある:同時に有効化する通信制御方式は1つだけにすること。システムプロキシと TUN を重ねると通信のループやDNS異常など特定しづらい問題が起きやすく、第8章で扱う「原因不明の不具合」の多くはここに根がある。用語に不慣れな場合は用語早見表を随時参照してほしい。

インストール前のチェックリスト

• OSのバージョンが要件を満たしているか確認する:Windows 10 64bit以上、macOS 11以上が一般的な要件。それより古いOSの場合はダウンロードページ各プラットフォームの説明で確認すること。
• 有効なサブスクリプションリンクを用意し、ブラウザでアクセスして内容が返ってくることを確認する——YAMLテキストや長いエンコード文字列が返ってくればいずれも正常。
• 管理者/root権限を持っていること。TUNモードやシステムサービスの導入にはいずれも必要になる。
• 他のプロキシ系・アクセラレーター系ソフトを先に終了またはアンインストールしておく:これらは Clash とポートや仮想ネットワークカードを奪い合い、インストール段階で最も多い不具合の原因になる。

5つのプラットフォームの概要は以下の通り。アンカーをクリックすると対応する章に直接移動する:

Windows は設定項目が最も多いプラットフォームだ:インストール時の警告、システムプロキシの書き込み、TUNサービスの導入、UWPのループバック制限とそれぞれに関門がある。本章では操作順に沿って一つずつ説明する。

ダウンロードとインストール

ダウンロードページの Windows セクションからインストーラーを取得する。第一推奨は Clash Plus、代替として Clash Verge Rev、FlClash、Clash Nyanpasu がある。Clash for Windows は開発が停止しアーカイブとしてのみ残されているため新規インストールは推奨しない。インストーラーは .exe 形式で、ダブルクリックで実行できる。SmartScreen の青い警告画面が表示された場合は「詳細情報」→「実行」をクリックする。これは新しく配布されたインストーラーに対する定型的な警告で、ファイルに問題があるわけではない。インストール先はデフォルトのままか、少なくも全角文字やスペースを含むディレクトリは避けたほうがよい——一部のコアコンポーネントは全角パスを含む設定ディレクトリの解析に無言で失敗することがあり、事後の調査コストはパスを変えるより高くなる。インストール完了後の初回起動時、Windows ファイアウォールが確認ダイアログを出す場合があるので、プライベートネットワークにチェックを入れてアクセスを許可する。

サブスクリプションの導入

クライアントを開き、「サブスクリプション」または「設定」ページでリンクを貼り付けてインポート/更新をクリックする。成功の目印は設定リストに新しい項目が現れ、「プロキシ」ページでノードのグループが確認できることだ。インポートでエラーが出た場合は、まずブラウザで直接そのリンクにアクセスして到達可能か確認し、その上で第8章のサブスクリプション不具合の節を参照する。インポートに成功したら合わせてサブスクリプションの自動更新をオンにし、間隔は12〜24時間程度に設定しておくとよい。

システムプロキシを有効化する

クライアントのメイン画面で「システムプロキシ」のスイッチをオンにする。これは実質的に 127.0.0.1 とミックスポート(デフォルトは多くの場合 7890)を Windows のプロキシ設定に書き込む処理だ。確認方法:「設定 → ネットワークとインターネット → プロキシ」を開き、「プロキシサーバーを使う」がオンでアドレスが一致していることを確認する。海外のサイトにブラウザでアクセスして接続できるか確認し、さらにIP確認サイトで出口のIPアドレスが変わっていることを確かめる。特に注意:クライアントを終了する前にシステムプロキシのスイッチを先にオフにすること。プロセスを直接終了させるとプロキシ設定がシステムに残ってしまい、クライアント終了後にネットが全断するという症状になる——この場合はシステムプロキシの設定画面から手動でオフにすれば回復する。

TUN モードを有効化する

コマンドラインツールやゲーム、システムコンポーネントもプロキシを経由させたい場合は TUN モードに切り替える。初回有効化時にクライアントがシステムサービスの導入を要求する(管理者権限の確認が必要)。このサービスは高い権限でコアを起動し、仮想ネットワークカードを作成する役割を持つ。有効化に成功すると「ネットワーク接続」に Mihomo / WinTun の仮想ネットワークカードが追加される。TUN を有効化する際はシステムプロキシのスイッチを必ずオフにしておくこと。両方を重ねると通信のループやDNS異常が発生しやすい。サービスの導入に失敗した場合は管理者権限でクライアントを再起動して試す。繰り返し失敗する場合はクライアントの設定から残存サービスをいったんアンインストールし、再度インストールする。

このプラットフォーム特有の注意点

• ポートの競合:セキュリティソフトや開発用デバッグツールが 7890 を占有していることが多く、症状はシステムプロキシをオンにしても全く通信できないというもの。特定方法とポート変更手順は第8章のポート競合の節を参照。
• UWPアプリのループバック制限:ストアアプリはデフォルトでローカルのループバックアドレスへのアクセスが禁止されており、そのためプロキシを経由しない。一部のクライアントは「UWPループバック除外」ツールを提供しており、対象アプリにチェックを入れると有効になる。
• アンチウイルスの誤検知:コアが仮想ネットワークカードやシステムサービスを作成する動作がセキュリティソフトにブロックされる場合がある。インストール前にインストール先フォルダを信頼リストに追加しておくほうが、後から一件ずつ許可するより手間が少ない。
• 残存ネットワークカード:複数のクライアントを何度もインストール・削除すると、使われていない TAP / WinTun のゴーストアダプターが残ることがある。デバイスマネージャーの「ネットワークアダプター」からアンインストールできる。
• スタートアップ設定:ショートカットをスタートアップフォルダに手動で入れるのではなく、クライアントの設定内でオンにすること——前者ならシステムサービスも含めて正しい順序で起動される。

macOS の章で重要なのは2点:チップアーキテクチャに合ったインストーラーを選ぶこと、そしてシステムのセキュリティ許可の流れを一通り済ませることだ。許可は初回起動時とバージョン更新後にのみ求められ、一度設定すれば長期間有効になる。

チップとインストーラーの選択

macOS のインストーラーはチップにより Apple Silicon(arm64)と Intel(x64)の2種類に分かれる。左上のAppleメニュー →「このMacについて」を開き、「チップ」の項目が Apple M シリーズなら arm64、Intel なら x64 を選ぶ。アーキテクチャを間違えると初回起動時にクラッシュしたり、エミュレーション実行により性能が明らかに低下したりする。クライアントの選択は Windows と同様で、第一推奨は Clash Plus、代替として Clash Verge Rev、FlClash がある。ClashX Meta は開発が停止しアーカイブとしてのみ残っている。ダウンロードページの macOS セクションから dmg を取得し、開いたらアプリのアイコンを Applications フォルダにドラッグすればインストール完了。

初回起動とセキュリティ許可

初回起動時に「開発元を検証できません」や「不明な開発元からのアプリ」という表示が出ることがある。対処方法:「システム設定 → プライバシーとセキュリティ」を開き、ページ下部にブロックされたアプリの通知が表示されているので「このまま開く」をクリックする。その後、クライアントがシステムプロキシを書き込む時や補助サービスをインストールする時にもそれぞれ一度許可のダイアログが出るので、ログインパスワードを入力するか Touch ID で確認すればよい。これらの許可は初回起動時とメジャーバージョン更新後にのみ求められ、毎回聞かれるわけではない。

サブスクリプションの導入とシステムプロキシ

インポートの流れは他のプラットフォームと同じ:サブスクリプションページでリンクを貼り付け→更新→プロキシページでノードのグループが表示されることを確認する。「システムプロキシ」をオンにしたら、「システム設定 → ネットワーク →(使用中のインターフェース)→ 詳細情報 → プロキシ」で確認できる:Webプロキシ(HTTP)とセキュアWebプロキシ(HTTPS)が 127.0.0.1 とクライアントのポートを指していればよい。注意点として、macOS のプロキシ設定はネットワークサービス(Wi-Fi、有線、Thunderboltブリッジ)ごとに個別に保存される。Wi-Fiから有線に切り替えた後プロキシが効かなくなった場合は、システムプロキシのスイッチを一度オフ/オンし直し、クライアントに現在アクティブなインターフェースへ再書き込みさせればよい。

TUN モードを有効化する

macOS で TUN を有効化するには、クライアントがより高い権限でコアを実行する必要がある:初回有効化時に特権付き補助ツールのインストールまたはネットワーク拡張の許可が求められるので、指示に従って確認する。成功するとターミナルで ifconfig を実行した際に新しい utun インターフェースが確認できる。Windows と同様、TUN とシステムプロキシはどちらか一方を選ぶ。TUN を有効化した後にネットに繋がらない場合は、まずDNS設定が古い設定で上書きされていないか、また企業向けセキュリティソフトがネットワーク拡張のチャネルを占有していないかを確認する。

このプラットフォーム特有の注意点

• 終了時の残留:クライアントを強制終了させる(通常の終了ではなく)とシステムプロキシがオンのまま残ってしまい、ネットが切れる症状になる。ネットワーク設定から手動でプロキシをオフにするか、クライアントを再度開いて正常に終了させる。
• OSアップグレード:メジャーバージョンのアップグレード後にセキュリティ許可がリセットされることがある。初回起動時に「プライバシーとセキュリティ」で許可の手順をもう一度行えばよく、設定が失われることはない。
• MDM管理下のデバイス:会社が一元管理するMacでは、構成プロファイルによってプロキシやVPN設定がロックされている場合がある。この種の制限はクライアント側で回避できず、デバイス管理者に連絡する必要がある。
• 複数クライアントの併存:複数の Clash 系クライアントを同時にインストールしても問題ないが、同時に起動するのは1つだけにすること。そうしないとシステムプロキシ設定を互いに奪い合ってしまう。

Android には独立したシステムプロキシのスイッチがなく、クライアントは常にシステムのVPNインターフェースを通じて通信を制御する。これはTUNと同等の効果を持つ。本章で重要なのは、正しいアーキテクチャを選ぶこと、必要な許可を全て与えること、バックグラウンドでの生存対策をしっかり行うことだ。

ダウンロードとABIの選択

Android のインストーラーはプロセッサアーキテクチャ(ABI)によって分かれる:近年の主流機種であれば arm64-v8a を選ぶ。古い端末や入門向け端末は armeabi-v7a の場合がある。アーキテクチャが分からない場合は universal(汎用)パッケージを選べば、サイズは大きくなるが全機種に対応する。クライアントの優先順位はダウンロードページと同じ:第一推奨は Clash Plus、代替は Clash Meta for Android、FlClash、Surfboard で、インストーラーはダウンロードページの Android セクションから取得できる。

インストールと VPN 許可

APKをインストールする際、システムが一度「不明なアプリのインストールは許可されていません」と警告する:設定画面で現在のインストール元(ブラウザやファイル管理アプリ)の許可をオンにしてから戻って続行する。クライアントの接続ボタンを初めてタップすると、システムが「接続のリクエスト」ダイアログを表示する——これは Android の VpnService の許可要求で、必ず許可すること。許可が通るとステータスバーに鍵アイコンが表示され、トンネルが確立されたことを示す。この許可はアプリ単位で記憶されるため、アンインストールして再インストールした場合は再度許可し直す必要がある。

サブスクリプションの導入

設定/サブスクリプションページでリンクを貼り付けてインポートする。一部のクライアントはQRコード読み取りやクリップボードからのワンタップ認識にも対応している。モバイル通信環境ではサブスクリプションの自動更新をオンにし、間隔は24時間程度に設定しておくと、ノード変更が反映されるまでの遅延を抑えられる。更新失敗の典型的な原因と対処は「Clash のサブスクリプション更新に失敗する場合の対処法」を参照。

バックグラウンド生存対策

中国メーカー系のカスタムOSはバックグラウンドプロセスの終了処理が非常に積極的で、「使っているうちに接続が切れる」「画面ロック後しばらくすると通信が止まる」といった症状の多くは、クライアントがシステムに強制終了させられているためだ。対策は3点セット:1つ目、システムの電池設定でクライアントを「制限なし/最適化しない」に設定する。2つ目、自動起動管理(メーカーごとに名称が異なる)で自動起動とバックグラウンド動作を許可する。3つ目、マルチタスク画面でクライアントのウィンドウをロックする。この3つすべてを行うことで長時間の生存が保証される。1つだけだと一部の機種では依然として強制終了される。

このプラットフォーム特有の注意点

• プライベートDNSの競合:システムの「プライベートDNS」(DoT)が特定のホスト名に設定されている場合、DNSクエリがクライアントを迂回し振り分け異常を起こすことがある。「自動」に戻すことを推奨する。
• VPNの排他制御:Android では同時に1つのアプリしか VpnService を保持できないため、Clash を起動すると他のVPN系アプリが切断され、逆も同様に起こる。これはシステムの仕様による動作。
• アプリ別プロキシ:クライアントは一般にアプリ単位での許可/除外リストに対応している。ネットワーク環境に敏感な銀行系アプリは除外リストに入れて直接接続させるとよい。
• 省電力モード:積極的な省電力モードはバックグラウンドの通信を制限する。長時間の待機シーンではオフにするか、少なくともクライアントを個別に除外設定することを推奨する。
• 再起動時の挙動:一部のシステムでは再起動後もVPN許可は残るが自動接続しない場合がある。クライアントの「起動時に自動接続」オプションを自動起動権限と併せて有効にする必要がある。

iOS版クライアントは App Store から配布されており、設定の流れは5つのプラットフォームの中で最も短い。注意点はVPN設定の管理と、ネットワーク切り替え後のトンネルの挙動に集中している。

クライアントの入手

iOS では Clash Plus を第一推奨とし、App Store で検索してインストールすればよい。ストアへの直接リンクはダウンロードページの iOS セクションを参照。クライアントの公式サイトは clashplus.io で、対応プラットフォームや機能の詳細はそちらで確認できる。App Store版はストア側で自動更新されるため手動でインストーラーをダウンロードする必要はなく、これが iOS の章に「アーキテクチャの選択」という項目がない理由でもある。

サブスクリプションの導入と初回接続

クライアントを開いてサブスクリプションページに進み、リンクを貼り付けてインポートする。iOSでのより速い方法は、先にSafariでリンクをコピーしておき、クライアント起動時にクリップボードを認識してインポートするか確認してくるので確認すればよい。初めて接続をタップすると、システムが「"Clash Plus"がVPN構成の追加を求めています」というダイアログを表示する。「許可」をタップしてFace ID/Touch IDまたはパスコードで確認する——これはiOSのネットワーク拡張における標準的な許可プロセスで、構成は「設定 → 一般 → VPNとデバイス管理 → VPN」の一覧に表示される。接続に成功するとステータスバーにVPNの文字が表示され、トンネルが確立されたことを示す。

モードの選択とノードの切り替え

iOS版クライアントも同様にルール/グローバル/直接接続の3モードを提供しており、日常的にはルールモードのままでよい。3モードの動作の違いは「ルールモード・グローバルモード・直接接続モードの違いを詳しく解説」を参照。ノードの切り替えはプロキシページで行う:まずグループに対して遅延テストを実行し、数値が低く安定したノードを選ぶ。ノードの切り替えには再接続は不要で、トンネルはそのまま維持され、コアが内部でアウトバウンドの変更を完了させる。

システムVPN設定の境界

「設定」内のVPNスイッチとクライアント内の接続ボタンは同一のトンネルを制御している:システム設定側でVPNをオフにすると、クライアント側の表示も切断に同期する。VPN構成を削除する(設定 → 一般 → VPNとデバイス管理)ことは許可を取り消すことに相当し、次回接続時にクライアントが再度追加を要求する。複数のプロキシ系アプリはそれぞれ自分のVPN構成を管理しており、同時に有効化できるのは1つだけで、互いに置き換わるのはシステムの仕様であり不具合ではない。

このプラットフォーム特有の注意点

• ネットワーク切り替え時の再接続:Wi-Fiとモバイル通信を切り替える際にトンネルが一時的に再構築され、数秒の通信断が起きるのは正常。長時間回復しない場合は手動で一度切断して再接続する。
• 低速データモード:モバイル通信またはWi-Fiで「低速データモード」をオンにするとバックグラウンド通信が制限され、サブスクリプションの自動更新やトンネルの安定性に影響する。よく使うネットワークではオフにしておくことを推奨する。
• オンデマンド接続:一部のクライアントは「オンデマンド接続」ルールを提供しており、ネットワーク活動があるとシステムが自動的にVPNを起動する。VPNが「オフにできない、自動でまた起動する」場合は、まずクライアント内でオンデマンド接続をオフにしてから切断する。
• 地域アカウント:App Store でのアプリの表示はストアの地域設定によって変わる。検索で見つからない場合はダウンロードページに掲載されているストアへの直接リンクを利用すること。
• 省電力の影響:iOSの低電力モードはバックグラウンド活動を制限する。長時間の画面ロック後、最初のアクセスで遅延が高くなることがあるが、画面を点灯すれば自然に回復する。

Linux の章は2つの流れに分かれる:デスクトップ利用者はGUIクライアントを導入し、手順は他のプラットフォームに近い。サーバーやルーター利用者は Mihomo コアを直接動かし、設定ファイルと systemd で管理する。本章ではどちらの流れについても完全な手順を示す。

デスクトップクライアントのインストール

Linux デスクトップでは Clash Verge Rev を推奨し、代替として FlClash がある。インストーラーはダウンロードページの Linux セクションから取得する。Debian / Ubuntu 系では deb パッケージでインストールする:

sudo apt install ./clash-verge-rev_amd64.deb

dpkg -i ではなく apt install ./パッケージ名 を使うこと。前者なら依存関係が自動的に解決される。Fedora 系では対応する rpm パッケージを dnf install で導入する。インストール後はアプリメニューから起動し、サブスクリプションのインポート操作は他のプラットフォームと同じ:サブスクリプションページでリンクを貼り付け→更新→プロキシページでノードのグループを確認する。

プロキシを有効にする3つの方法

Linux では「システムプロキシ」は単一のスイッチではなく、カバー範囲が段階的に広がる3つの方法がよく使われる。1つ目、デスクトップ環境のプロキシ:GNOME / KDE のネットワーク設定にプロキシの設定項目があり、GUIクライアントの「システムプロキシ」スイッチはまさにここに書き込みを行う。この設定に従うデスクトップアプリに対して有効になる。2つ目、環境変数:ターミナルと大半のコマンドラインツールは以下の変数を読み取る:

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1

一時的な利用ならそのまま現在のターミナルで実行し、常用するなら ~/.bashrc または ~/.zshrc に書き込む。注意点として、環境変数はそれ以降に新しく起動するプロセスにのみ影響し、既に動いているプログラムには反映されない。3つ目、TUN モード:環境変数を読まないプログラムも含めて全ての通信をカバーする。GUIクライアントでTUNを有効化する際には許可が必要で、Clash Verge Rev は特権サービスの導入を案内してくれる。コアを手動で動かす場合は root 権限、またはバイナリにネットワークケーパビリティを付与する必要がある:

sudo setcap 'cap_net_admin,cap_net_bind_service=+ep' ./mihomo

サーバー:コア + systemd

デスクトップ環境がない場合は Mihomo コアを直接使用する。ダウンロードページのコアセクションから対応するアーキテクチャの圧縮ファイルを取得し(x86サーバーなら amd64、ARM機器はビット数に応じて arm64 または armv7)、展開して /usr/local/bin に配置し、設定ファイルは /etc/mihomo/config.yaml に置く。systemd で管理する:

[Unit]
Description=Mihomo Daemon
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure

[Install]
WantedBy=multi-user.target

/etc/systemd/system/mihomo.service として保存し、続けて:

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
journalctl -u mihomo -f

最後のコマンドはコアのログをリアルタイムに表示するもので、初回起動時には必ず確認しておくこと:設定の文法エラーやポート競合はここに直接出力される。設定を変更した後は systemctl restart mihomo で再起動して反映させる。

このプラットフォーム特有の注意点

• ディストリビューションの違い:Arch 系では AUR からパッケージを取得できるが、バージョンが公式インストーラーと同期していない場合がある。問題が発生したら、まずダウンロードページの公式パッケージと比較してパッケージング側の要因を排除する。
• Wayland のトレイ:一部の Wayland デスクトップはトレイアイコンの対応が不完全で、クライアントのウィンドウを閉じると入口が見つからなくなることがある。アプリメニューから再度起動すればメインウィンドウを呼び出せる。
• DNS制御:TUNを有効化した後に解析が異常な場合、systemd-resolved がコアのDNSハイジャックと競合していないか確認する。必要に応じて設定の dns セクションでリスニングを調整する。
• ファイアウォール:firewalld / ufw を有効にしているマシンで、LAN内の他のデバイスにプロキシを利用させたい場合は、ミックスポートを許可し、設定内で allow-lan: true を有効にする必要がある。
• ルーター機器:MIPS などの組み込みアーキテクチャでは mips-softfloat のコアパッケージを選ぶ。リソースが限られた機器ではルール数を絞り込み、メモリ使用量を抑えることを推奨する。

5つのプラットフォームのクライアントは最終的に同じ YAML 設定を動かしている。その構造が読めるようになれば、「画面のどこを押すか」という次元から離れ、クライアントの各スイッチが実際に何を変更しているのかを直接理解できる。本章では設定を手書きすることは求めない——サブスクリプションが既に完全な内容を生成しているからだ——が、読めるようになることを求める。

トップレベル構造の概観

典型的な設定の骨格は以下の通り:

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

dns:
  enable: true
  enhanced-mode: fake-ip

proxies:
  - name: "节点A"
    type: vless
    server: example-server.com
    port: 443

proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["节点A", "自动选择"]
  - name: "自动选择"
    type: url-test
    proxies: ["节点A"]
    url: https://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

6つの部分がそれぞれ役割を持つ:共通フィールドがポートと動作モードを定義し、dns セクションがドメイン解析の方針を決め、proxies がノードの一覧、proxy-groups がノードを選択可能なポリシーグループにまとめ、rules が各接続をどのグループに振り分けるかを決める。クライアントの画面上の「プロキシページ」が表示しているのは proxy-groups そのものであり、「モード切り替え」が変更しているのは mode フィールドだ。

よく使うフィールド早見表

ルールのマッチング方式

rules のリストは上から下へ順に1件ずつマッチングされ、命中すればそこで停止する。末尾の MATCH は最後の受け皿だ。よく使われるルールタイプ:DOMAIN-SUFFIX はドメインのサフィックスで判定、DOMAIN-KEYWORD はドメイン内のキーワードで判定、GEOIP は宛先IPの所属地域で判定、IP-CIDR はIP範囲で判定する。「順序に依存し、命中すれば停止する」という点を理解しておけば、振り分けに関する疑問の多くが説明できる:あるサイトが期待通りにプロキシを経由しない場合、通常はそれより前の位置にある別のルールに先に命中しているためだ。3種類の mode の使い分けは「ルールモード・グローバルモード・直接接続モードの違いを詳しく解説」を参照。

サブスクリプション更新の動作詳細

サブスクリプションを更新すると、クライアントはリモートの YAML を再取得してローカル設定全体を丸ごと置き換える——つまり設定ファイルを直接編集して行った手動変更は、次回の更新時に上書きされてしまう。長期的なカスタマイズ(独自ルールの追加、ポート変更など)が必要な場合は、クライアントが提供する上書き/マージ機構(Clash Verge Rev の Merge / Script など)を使い、変更をサブスクリプションの外側で宣言しておけば、更新後も自動的に再適用される。自動更新は全プラットフォームで有効化することを推奨し、間隔は12〜24時間程度がよい。更新失敗の分類別の調査法は「Clash のサブスクリプション更新に失敗する場合の対処法」を、形式が非対応な場合の変換方法は「Clash サブスクリプション形式まとめ」を参照。

本章では5つのプラットフォームに共通する頻出トラブルを症状別にまとめ、それぞれ特定の手順と対処法を示す。個別のQ&Aのより多くの項目はヘルプセンターを参照。

サブスクリプションの導入や更新に失敗する

3ステップで特定する。第1に、ブラウザで直接サブスクリプションリンクにアクセスする:開けない場合はリンクが無効になっているかローカルのネットワークが不通であることを意味する。前者はサービス提供者に再取得を依頼し、後者は一時的に使用可能なノードのグローバルモードでいったんサブスクリプションを取得してから元に戻す。第2に、ブラウザでは開けるがクライアントでエラーになる場合:多くはサービス提供者がユーザーエージェントでクライアントのアクセスを制限しているか、返却された形式がクライアントと互換性がない場合だ——前者はクライアントのサブスクリプション設定でUAを調整し、後者は形式変換が必要になる。第3に、インポートは成功したがノード一覧が空の場合:取得したものが単一ノードの共有リンクであってサブスクリプションリンクではない、あるいはサブスクリプションの内容がBase64でクライアントがYAMLしか認識しない、といった可能性がある。詳しい調査手順は対応する技術ノートを参照。

プロキシは有効なのにネットに繋がらない

近いところから遠いところへ順に確認する。ローカル層:システムプロキシとTUNが同時に有効になっていないこと、他のプロキシソフトがバックグラウンドで先取りしていないことを確認する。クライアントのログ(Linuxでは journalctl -u mihomo)にポート占有のエラーがないか確認する。ノード層:プロキシページで遅延テストを実行する。すべてタイムアウトする場合はサブスクリプション全体の不具合、またはローカルからサーバーへの経路が不通であることを意味するので、グループを変更するかサービス提供者に連絡する。一部だけタイムアウトする場合はそのノード単体の不具合なので切り替えればよい。ルール層:海外サイトは開けるが個別のサイトだけ異常な場合は、多くはルールが期待通りに命中していないことが原因だ。モードを一時的にグローバルに切り替えて検証してみる——グローバルでは正常でルールモードだけ異常なら、ルールの問題であると確認できる。

ポートの競合

症状:クライアントのログに bind / listen の失敗が現れる、またはシステムプロキシを有効にしても全く通信できない。Windows では netstat -ano | findstr 7890、macOS / Linux では lsof -i :7890 で占有中のプロセスを見つける。占有元を終了させるか、クライアントの設定でミックスポートを 7891 など空いているポートに変更する。ポートを変更した後、システムプロキシの指す先はクライアントが自動的に同期するが、環境変数やサードパーティソフトに固定で書かれた古いポート番号は手動で更新する必要がある。

DNS汚染と解析異常

症状:遅延テストは正常だがWebページが開けない、またはドメイン解析が明らかに間違ったアドレスを返す。対処の順序:設定の dns セクションで enable: true と enhanced-mode: fake-ip になっているか確認する。システム層で他のDNSコンポーネントが横取りしていないか確認する(Androidのプライベートdns、Linuxのsystemd-resolved、ルーターのDNSキャッシュなど)。TUNとシステムプロキシの2つの通信制御方式を切り替えて比較検証すれば、問題が解析層にあるのか転送層にあるのかを区別できる。fake-ip モードでは一部の古いアプリが仮想IPに対応していないことがあるので、dns セクションの fake-ip-filter で該当ドメインを除外できる。

速度が遅い

まず層を分けてから対処する:ノード自体(同じノードが他のデバイスでも同様に遅いか)、伝送経路(ピーク時間帯に規則的に遅くなるか、プロトコルを変えると改善するか)、ローカル設定(ルール数が多すぎないか、DNSが迂回していないか)。各層のテスト方法と対処法は「Clash の通信速度低下を層ごとに調査する方法」で詳しく展開しているので、ここでは繰り返さない。経験上、「遅い」をまず遅延の数値と帯域の数値に定量化してから、ノードを変えるか設定を調整するか決めるほうが、感覚に頼ってあちこち変えるより効果的だ。

クライアントの更新と設定の移行

クライアントをアップデートしてもサブスクリプションと設定には影響しない。これらはユーザーデータディレクトリに保存されているので、上書きインストールするだけでよい。クライアントを変える、あるいはデバイスを変える場合、旧設定をエクスポートする必要はなく、サブスクリプションリンクを新しい環境で改めてインポートし直すのが最もクリーンな方法だ——設定はサブスクリプションから生成されるものであり、リンク自体が完全な移行用の認証情報になっている。手動で移す必要があるのは、上書き/マージスクリプトのようなサブスクリプションの外側にあるローカルカスタマイズだけだ。クライアント間の移行(例えば開発が停止した Clash for Windows からの移行)も同様で、選定の参考はクライアント横並び比較、インストーラーはすべてダウンロードページから取得する。