Clashの初回インストール設定：クロスプラットフォームの初期設定とよくあるエラー

インストール前の確認：システム、アーキテクチャ、クライアントのコア

Clashの初期設定で最初に行うべきことは、すぐにインストーラーを実行することではありません。OS、プロセッサーのアーキテクチャ、クライアントの種類を確認しましょう。ファイルを最後までダウンロードできても、現在のデバイスに適しているとは限りません。アーキテクチャを間違えると、インストーラーが起動しない、システムに互換性がないと表示される、起動直後に終了するといった問題が起こります。

Windowsの一般的なデバイスはx64を使用しますが、ARMプロセッサー搭載の一部の薄型ノートPCやタブレットにはARM64版が必要です。macOSではIntelとApple Siliconを区別します。MシリーズのチップはApple Siliconまたはarm64、旧世代のIntel Macはx64に対応します。Linuxではx86_64とarm64に加え、パッケージ形式も確認してください。DebianやUbuntuでは通常deb、FedoraやRocky Linuxなどではrpmがよく使われます。AppImageは、クライアントが現在のアーキテクチャに対応した形式を明確に提供している場合に限り選択します。

クライアント名とプロキシコアも分けて考える必要があります。デスクトップクライアントは設定管理、サブスクリプション更新、システムプロキシの切り替え、ログ表示を担当し、コアはルール判定、接続転送、DNS、TUNなど実際のネットワーク処理を担います。現在も継続的に開発されているクライアントの多くはmihomoコアを採用しています。mihomoはClash Metaの後継発展系で、一般的なClash設定との互換性に加え、ルール、プロトコル、トラフィック取り込み機能を拡張しています。サブスクリプションとクライアントの設定形式が一致していれば、名称の違いだけを理由にコアを頻繁に変更する必要はありません。

ダウンロードファイルを素早く選ぶ手順

まずWindows、macOS、Linuxのいずれか、対応するプラットフォームのページを選びます。
次に、x64、arm64、Apple Siliconからプロセッサーのアーキテクチャを選択します。
Linuxユーザーは、システムで管理できるパッケージ形式を選びます。
クライアントが現在も保守されていることを確認し、リリースノートに記載された最低システム要件を読みます。
旧クライアントに既存の設定がある場合は、先に設定をエクスポートするかサブスクリプションURLを控えてから移行します。

ファイル名に「ユニバーサル版」とあるだけで互換性を判断するのはおすすめしません。複数のmacOSアーキテクチャを同梱したパッケージもあれば、複数のOSバージョンに対応するという意味だけの場合もあります。最終的にはダウンロードページの表記とクライアントのリリースノートを確認してください。

クロスプラットフォームへのインストール：プログラムの導入と初回起動

プラットフォームによって画面は異なりますが、初期設定の目的は共通しています。クライアントが設定を保存し、プロキシコアを起動し、システムプロキシの変更や仮想ネットワークインターフェースの作成に必要な権限を取得できる状態にします。初回起動時は、他のプロキシ、VPN、ネットワークフィルタリングツールを同時に起動しないでください。ポートの競合やルーティングの衝突が原因の切り分けを難しくします。

Windows：インストール先と権限に関する確認

アーキテクチャに合ったインストーラーを実行し、ウィザードに従ってインストールします。通常のデスクトップ利用では、特別なフォルダーに配置する必要はなく、理由を確認しないまま常に管理者として実行するのも避けてください。TUNを有効にすると、クライアントが個別に権限昇格や仮想ネットワークコンポーネントのインストールを求める場合があります。その際は、表示元が先ほどインストールしたクライアントであることを確認します。

起動後は、コアの状態、設定ページ、ログページが正常に開くか確認します。ウィンドウが表示されない場合は、タスクバーの通知領域を確認してください。一部のクライアントは初期設定でトレイに最小化されます。起動アイコンを繰り返しクリックしても、既存のプロセスを呼び出すだけで新しいウィンドウは作成されないことがあります。

macOS：アプリケーションフォルダーとシステム権限

dmgでインストールする場合は、通常アプリを「アプリケーション」フォルダーへドラッグし、そのフォルダーから起動します。Intel用とApple Silicon用のインストーラーは混用できません。初めてシステムプロキシを有効にするとき、ネットワーク設定の変更許可を求められる場合があります。TUNや拡張モードを有効にする際は、ネットワーク拡張、補助サービス、管理者パスワードの確認が表示されることもあります。

システムがアプリの起動を阻止した場合は、まずファイルの入手元とクライアントのリリース情報を確認し、macOSの「プライバシーとセキュリティ」設定で該当する記録を確認します。システムのセキュリティ機能を無効にすることを、通常のインストール手順にしないでください。クライアント更新後に権限の確認が再び表示された場合は、古い補助プロセスが終了しているか確認します。

Linux：パッケージ、デスクトップセッション、プロキシ環境

debまたはrpmパッケージは、システムのパッケージマネージャーでインストールすると、依存関係やアンインストール情報を適切に登録できます。AppImageは通常、実行権限を付与してから起動しますが、具体的な手順はクライアントの配布方法によって異なります。デスクトップ環境の「システムプロキシ」は、GNOME、KDE、環境変数の設定を参照するアプリにしか影響しない場合があります。ターミナルプログラムやシステムサービスが自動的に従うとは限りません。

LinuxでTUNを有効にするには、ネットワーク管理、ルーティングテーブル、デバイス権限が関係します。初回設定では、まず通常のシステムプロキシでサブスクリプションとノードを確認し、プロキシコア自体が接続できることを確かめてからTUNの権限を設定します。これにより、「ノードが利用できない」と「仮想インターフェースの設定に失敗した」を別々の問題として切り分けられます。

サブスクリプションの読み込み：設定URLから利用可能なプロキシグループまで

Clashクライアントは通常、サブスクリプションURL、リモート設定ファイル、ローカルYAMLファイルに対応しています。初めてインストールする場合は、サービス提供元から発行されたClash用サブスクリプションURLを貼り付ける方法が一般的です。このURLには認証情報が含まれることがあるため、アカウントの秘密鍵と同じように扱い、スクリーンショット、公開ログ、コードリポジトリ、チャットグループに掲載しないでください。

クライアントの設定またはProfilesページを開き、「サブスクリプションを追加」「URLから読み込む」など、同様の項目を探します。完全なURLを貼り付けて保存し、更新を実行します。ダウンロードに成功しただけでは、クライアントが設定ファイルを取得したことしか分かりません。続けて、その設定を現在の有効な設定として選択する必要があります。読み込み後に自動で有効になるクライアントもあれば、設定名を手動でクリックする必要があるクライアントもあります。

正常に読み込まれた設定には、通常プロキシノード、プロキシグループ、ルール、DNSなどが表示されます。プロキシグループは追加のノードではなく、特定の種類の通信にどのノード、自動選択、直接接続を使うかを決める設定単位です。たとえば「ノード選択」では回線を手動指定でき、「自動選択」では遅延テストの結果に応じて切り替えられます。「DIRECT」は直接接続を意味します。

読み込み後に確認する項目

設定一覧に更新成功時刻が表示され、読み込み中のままになったりエラー状態になったりしていない。
プロキシページにノードまたはプロキシグループがあり、グループ内に少なくとも1つ選択可能な項目がある。
現在の設定が選択され、コアのログに解析失敗が継続して表示されていない。
ルールモードでは、主要なプロキシグループにノードまたは有効な自動選択が設定されている。
サブスクリプションの自動更新間隔が適切で、短時間にリモートURLへ繰り返しアクセスしていない。

ローカルYAMLの読み込みは、既存の設定ファイルを使うユーザーやルールを手動管理したいユーザーに適しています。YAMLはインデントと文字形式に敏感です。Tab、全角句読点、重複フィールド、階層の誤りによって解析に失敗することがあります。変更前に元ファイルを保存し、一度に少しだけ変更して、クライアントで再読み込みした後に最初のエラーログを確認してください。

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

上記の断片はよく使われる基本フィールドを示したもので、完全な設定ではありません。実際のサブスクリプションには、プロキシノード、プロキシグループ、ルールなども必要です。ポートは7890に固定されていないため、現在のクライアントに表示される値を使用してください。クライアントがポートを自動管理している場合は、例に合わせるために元の設定を無理に上書きしないでください。

プロキシを有効化：ルールモード、システムプロキシ、TUNの正しい順序

設定を読み込んだら、まず「ルール」モードを選び、次に利用可能なノードを指定し、最後にシステムプロキシを有効にすることをおすすめします。ルールモードでは、設定内のルールに基づいて直接接続、プロキシ、接続拒否を決めるため、日常利用に適しています。グローバルモードは、該当する通信の大部分を選択したプロキシ経由にするため、短時間の比較テストには便利ですが、すべての問題を調べる唯一の手段には向きません。直接接続モードではプロキシを迂回でき、障害がプロキシ経路に関係するか確認できます。

システムプロキシは最も確認しやすい入口です。クライアントは本体のHTTP、HTTPS、SOCKSプロキシアドレスをOSの設定に書き込み、ブラウザーやシステムプロキシに従うデスクトップアプリが接続をClashへ渡します。ただし、すべてのプログラムを自動的に取り込むわけではありません。一部のゲーム、コマンドラインツール、システムサービス、独自のネットワークスタックを実装したソフトは、システムプロキシを無視することがあります。

TUNモードは仮想ネットワークインターフェースとルーティングを使って、より広い範囲の通信を取り込みます。システムプロキシを読み取らないアプリにも適しており、コアの設定と組み合わせてUDPやDNSも処理できます。通常はより高い権限が必要で、他のVPN、仮想マシンのネットワーク、ゲーム向け通信高速化ツール、セキュリティソフトのネットワークドライバーと競合することがあります。初回インストール時にシステムプロキシ、TUN、複数のネットワークツールを同時に有効にすると、通信できなくなった際に原因の切り分けが難しくなります。

TUNが必要になるケース

対象のプログラムがOSのプロキシ設定に明確に従わない。
一部のUDP通信を取り込む必要があり、ノード、コア、設定がその機能に対応している。
複数のプロトコルを個別にプロキシ設定するのではなく、まとめてルール判定にかけたい。
システムプロキシが正常に動作することを確認したうえで、アプリの対象範囲をさらに広げたい。

ブラウザーと一般的なデスクトップアプリだけを使う場合は、通常システムプロキシのほうが管理しやすくなります。TUNは「速度を上げるスイッチ」ではなく、通信をコアへ取り込む方法を変える機能です。接続の主な品質は、回線の状態、ノードの負荷、接続先サイトによって決まります。

基本確認：ノード、ルール、DNS、ログを段階的に確認

「接続済み」と表示されても、すべての通信が想定どおり転送されているとは限りません。確実に確認するには、まずコアの状態を確認し、次にノードの遅延、ブラウザーのリクエスト、ルールの適用、DNSの結果を調べます。テスト中は一度に1つの要素だけを観察し、ノード、モード、設定を連続して切り替えないでください。

第1層：コアとポート

クライアントのステータスページでコアが実行中になっていることを確認し、HTTP、SOCKS、Mixedのポートを確認します。ログに「address already in use」やポート競合のメッセージが表示される場合、同じポートを別のClashプロセス、旧クライアント、または他のプロキシプログラムが使用している可能性があります。競合しているプログラムを終了してコアを再起動するか、クライアントで許可されている範囲で待ち受けポートを変更します。

第2層：プロキシグループとノード

遅延テストで分かるのは、テスト先へその時点で接続できたことだけです。ダウンロード速度や長期的な安定性を完全に示すものではありません。まず遅延テストを完了できるノードを選び、普段安定して開けるサイトへアクセスします。自動選択グループが何度も切り替わる場合は、一時的に手動ノードへ変更し、選択の変化による影響を除外します。

第3層：ルールの適用

接続履歴またはリアルタイムログを開き、対象ドメインがどのルールに一致し、最終的にどのプロキシグループへ入ったかを確認します。対象が誤ってDIRECTに割り当てられている場合は、ルールの順序と現在の設定を確認します。プロキシグループに入っているのに接続できない場合は、ノード、DNS、リモート側の応答を続けて確認します。ルールは通常、設定の上から順に判定されるため、前にある広いルールが後ろの具体的なルールを上書きすることがあります。

第4層：DNS

ドメインを開けない一方で、既知のIPアドレスへ直接アクセスすると応答がある場合は、DNSが関係している可能性があります。ログにある名前解決のタイムアウト、上流DNSへの到達不能、転送ループのメッセージを確認します。システム上で別のDNS変更ツールも動作している場合は、まず明確な名前解決経路を1つに絞ります。TUNモードでは、クライアントが要求するDNS設定が有効になっていることも確認し、仮想インターフェースが通信を取り込んだ後も到達できないアドレスへ問い合わせを送らないようにします。

確認が終わったら、動作した設定名、モード、ノード、プロキシの有効・無効状態を記録します。今後クライアントを更新したりサブスクリプションを切り替えたりする際、この状態を復旧の基準として使えます。

よくあるエラー：問題が発生した場所から対処する

サブスクリプションのダウンロードに失敗する、またはタイムアウトになる

まずサブスクリプションURLが完全で、コピー時に余分な空白、改行、全角句読点が入っていないことを確認します。次に、システム時刻が正確か、通常のネットワークからサブスクリプションサーバーへアクセスできるか、サービス提供元がURLの更新を要求していないかを確認します。旧クライアントでは更新できるのに新しいクライアントで失敗する場合は、両者のUser-Agent要件、ネットワーク出口、サブスクリプション形式の対応状況を比較します。失敗時に短時間で何度も更新しないでください。リモートサービスにリクエスト回数を制限される可能性があります。

サブスクリプションの更新は成功したがノードが表示されない

設定がまだ有効になっていないか、プロキシ提供者への参照だけが含まれており、クライアントがproviderの内容を続けて読み込む必要がある可能性があります。設定の詳細とログを確認し、リモートproviderのダウンロードが成功したか確認します。ログに未対応フィールドやYAML解析エラーがある場合は、サブスクリプション形式と現在のコアが一致していません。サービス提供元が用意したClashまたはmihomo形式を使用し、他のクライアント用形式を名前だけ変えて読み込まないでください。

システムプロキシを有効にするとブラウザーがネットワークに接続できない

まずコアが実行中か、システムプロキシが指しているポートとクライアントの待ち受けポートが一致しているか確認します。次にシステムプロキシを無効にして直接接続が復旧することを確認し、コアを再起動します。クライアントが異常終了した後も古いプロキシアドレスが残っている場合は、OSのネットワーク設定で手動プロキシを無効にします。復旧後は、1つのプロキシクライアントだけを起動して再テストしてください。

ノードには遅延があるのにWebページを開けない

遅延テストの接続先と対象サイトは、同じ接続とは限りません。リアルタイムログで対象ドメイン、ルールの適用、プロキシグループ、エラーの種類を確認します。接続タイムアウトの場合は、同じサブスクリプション内の別ノードへ切り替えて比較します。特定のドメインだけ失敗する場合は、ルールとDNSを重点的に確認します。すべてのノードで同時に失敗する場合は、ポートを1つずつ変更するのではなく、まずローカルネットワーク、サブスクリプションの状態、サービス側の状態を調べます。

TUNを有効にできない、または有効化後にネットワークへ接続できない

クライアントが仮想インターフェースを作成するために必要な権限を取得していることを確認し、他のVPN、古いプロキシコア、ルートを変更する可能性のあるネットワークツールを終了します。Windowsでは異常な仮想アダプターが残っていないか確認し、macOSではネットワーク拡張の許可を確認します。LinuxではTUNデバイス、ルーティング権限、ネットワーク管理サービスを確認してください。TUNを無効にするとシステムプロキシが動作する場合、ノードとサブスクリプションはおおむね正常で、問題は権限、ルーティング、DNSの取り込み層にあります。

LAN内のデバイスから本体のプロキシを利用できない

初期状態のローカル待ち受けは、通常この端末からの接続だけを受け付けます。LAN内のデバイスにプロキシを提供する必要がある場合は、クライアントでLAN接続の許可を有効にし、他のデバイスからアクセスできるアドレスで待ち受ける必要があります。OSのファイアウォールでも対象ポートを許可してください。公開する前に、現在のネットワークが信頼できることを確認し、クライアントが対応するアクセス制御を設定します。本体だけで使う場合はLANアクセスを無効のままにすると、不要な公開を減らせます。

クライアント更新後に元の設定が使えなくなった

まず、設定が移行されていないのか、コアのパスが変わったのか、新しいバージョンで古いフィールドがサポートされなくなったのかを判断します。旧設定のコピーを保存し、更新後に最初に出た解析エラーを確認してください。設定を一度にすべて削除しないでください。サブスクリプションを再取得できる場合は、新しい設定を作成して再読み込みし、必要なローカルルールだけを少しずつ戻すのが安全です。クライアント間の移行では、画面上の設定、オーバーライドルール、スクリプトは通常サブスクリプションだけでは引き継がれません。

初期設定完了後のメンテナンスチェックリスト

Clashが正常に動作した後は、設定の入手元を明確にし、重複するネットワークコンポーネントを減らし、変更があったときに比較できる状態を残すことが大切です。クライアントの更新、サブスクリプションのルール更新、OSのネットワーク設定のリセットによって、以前のプロキシ動作が変わることがあります。

現在利用できるクライアントのバージョン、設定名、アーキテクチャを記録しておく。
サブスクリプションサービスが推奨する頻度で更新し、意味のない連続更新を行わない。
ネットワークを切り替えたら、すぐに再インストールせず、ノードの遅延とDNSを再確認する。
同じシステムプロキシポートとTUNルートを担当するクライアントは1つだけにする。
クライアントを終了する前にシステムプロキシを無効にし、異常終了後はOSのプロキシ設定を確認する。
YAML、オーバーライドルール、DNS設定を変更する前に、元の設定を保存する。
トラブル対処では、まずログに記録された最初のエラーを確認し、その後に続く連鎖的なメッセージは後から処理する。

Clashの初回インストールは、対応するインストーラーを選び、コアの起動を確認し、サブスクリプションを読み込んで有効化し、ルールモードとノードを選択し、まずシステムプロキシで確認してから必要に応じてTUNを設定する流れです。問題を層ごとに切り分ければ、接続に失敗しても、インストール、設定、ノード、ルール、DNS、トラフィックの取り込みのどこに原因があるかをすばやく判断できます。

対応するプラットフォームのインストーラーを選択

ダウンロードセンターでOSとプロセッサーのアーキテクチャを確認し、利用ガイドに従ってサブスクリプションの読み込み、ノード選択、プロキシ接続の確認を行います。

ダウンロードページへガイドを見る