Clashクライアントの初回インストール：各OS共通の初期設定と初心者がつまずきやすいポイント
インストーラーの選び方からサブスクリプションの追加、システムプロキシの設定まで、各OS共通の初期設定を解説。ポート競合や証明書警告、権限エラーへの対処も紹介します。
Clash系クライアントを初めて起動するときは、システムプロキシ、TUN、自動起動を一度に有効にしないでください。「インストール → 設定 → プロキシグループ → 通信の取り込み → 接続確認」の順に進め、各手順の完了ごとに動作を確認しましょう。接続できない場合に、サブスクリプションの取得に失敗したのか、端末の通信がそもそもコアに届いていないのかを切り分けやすくなります。
1. インストーラーとシステムアーキテクチャ
Clash系クライアントは通常、GUIとプロキシコアで構成されています。GUIでは設定のインポート、ポリシーの管理、システム設定の変更を行い、コアはポートの待ち受け、ルールの判定、接続の確立を担います。GUIをインストールしただけでは、利用できるノードがあるとは限らず、すべてのアプリが自動的にプロキシを経由するわけでもありません。
| プラットフォーム | 確認する場所 | インストーラーの選び方 |
|---|---|---|
| Windows | 「設定」→「システム」→「バージョン情報」→「システムの種類」 | 一般的な Intel・AMD 搭載デスクトップPCは x64 を選択します。ARM 端末では、クライアントがネイティブ対応しているかを先に確認してください。 |
| macOS | Apple メニュー →「この Mac について」 | Apple シリコン搭載機は arm64、Intel プロセッサ搭載機は x64 を選択し、macOS の最低要件も確認してください。 |
| Linux | ターミナルで uname -m を実行 | x86_64 は x64、aarch64 は arm64 に対応します。Debian 系と RPM 系では、それぞれ対応するパッケージを選んでください。 |
| Android | OSのバージョン、端末のプロセッサ、インストールページの要件 | 最近の端末の多くは arm64-v8a ですが、古い端末では別のアーキテクチャが必要な場合があります。メーカー名だけで判断しないでください。 |
| iOS / iPadOS | アプリストアの製品ページにある互換性情報 | 対応する構成のクライアントを選択してください。Windows 用の EXE や Android 用の APK をそのままインストールすることはできません。 |
インストールに失敗したら、まずシステムのメッセージを確認
- 互換性がないと表示される：OSのバージョンとプロセッサのアーキテクチャを照合してください。ファイル名が似たパッケージを次々に試すのは避けましょう。
- 実行環境が不足していると表示される：クライアントのリリースノートに記載されたランタイムをインストールしてください。出所不明のダウンロードサイトから、同名の DLL を入手するのは避けましょう。
- 配布元や署名に問題があると表示される：ダウンロード元、発行元、プロジェクトの説明を確認してください。セキュリティ警告は一律に「続行」を選べばよいものではありません。組織の端末管理ポリシーを、保護機能を無効にして回避するのも避けてください。
Windows で最初にシステムプロキシだけを試す場合、通常はGUI全体を常時管理者として実行する必要はありません。サービスのインストールや仮想ネットワークアダプターの作成が必要になった段階で、該当する権限を許可してください。組織管理のPCでは、ネットワークサービスをインストールしてよいか事前に確認しましょう。
2. サブスクリプションの追加と設定の有効化
多くのクライアントには「設定」「Profiles」「サブスクリプション」などの項目があります。サービス提供元から取得した Clash または mihomo 対応のサブスクリプションURLをコピーし、その画面で「インポート」「リモート設定を追加」「Download」などを実行してください。旧版 CFW の場合は「Profiles」→画面上部の URL 入力欄→「Download」の順です。ダウンロード後、該当する設定カードをクリックして現在の設定として有効にします。
- 形式を確認：通常のWebページのURL、ノード共有リンク、ほかのクライアント専用のサブスクリプションは、Clash の YAML 設定として読み込めるとは限りません。
- ダウンロード結果を確認：設定一覧に新しい項目が表示され、更新成功の状態になっていることを確認してください。URLを保存しただけでダウンロードに失敗している場合、インポートは完了していません。
- 有効化されているか確認：「プロキシ」または「Proxies」画面を開き、設定で定義されたプロキシグループが表示されるか確認してください。何も表示されない場合は、まず選択中の設定を確認しましょう。
- コアとの互換性を確認：「未対応のプロトコル」「不明なフィールド」「サポートされていないプロキシタイプ」などのエラーが出る場合は、更新を繰り返すのではなく、サブスクリプションが必要とするコアを確認してください。
サブスクリプションのダウンロード失敗とノードの利用不可は別の問題
サブスクリプションの取得では設定サーバーにアクセスし、ノードのテストでは選択したプロキシを通して接続先にアクセスします。サブスクリプションの応答が HTTP 401 または 403 の場合は、まずURLの有効性、認証、サービス側の制限を確認してください。HTMLが返る場合は、ログインページやエラーページを取得している可能性があります。パーサーで YAML エラーが出たら、インデントを適当に変更するのではなく、応答内容が本当に設定ファイルか確認しましょう。
クライアントによっては、リモート設定のローカルコピーを保存します。このコピーを手動で編集しても、次回のサブスクリプション更新で変更が上書きされることがあります。初期設定では元の設定のまま動作を確認してください。独自ルールが必要な場合は、クライアントが備えるオーバーライド、マージ、拡張の仕組みを確認してから追加しましょう。
3. ルールモードとプロキシグループの選択
設定を読み込んだら、まず Rule（ルール）モードを選び、プロキシグループからノードを選択してください。Global（グローバル）モードでは通常、コアに届いた接続がグローバルポリシーに渡されます。Direct（直結）モードは、プロキシを介さず直接接続するためのモードです。ここでいう「グローバル」とは、コアが受け取った通信の処理方法を指します。コアに届いていないアプリの通信まで自動的に取り込むという意味ではありません。
- 手動選択グループ：一般的なタイプは
selectです。ノードまたは下位のプロキシグループを選択します。 - 自動テストグループ：一般的なタイプは
url-testです。選択結果は設定内のテスト用URL、間隔、許容値などに左右されます。 - ルールの振り分け先：ルールの振り分け先にはプロキシグループのほか、
DIRECTやREJECTを指定できます。グループを1つ変更しただけでは、すべてのサイトの接続先が変わるとは限りません。
遅延テストでミリ秒の数値が表示されても、そのテストリクエストで応答が得られたことしか分かりません。動画のビットレートやダウンロード速度が保証されるわけではありません。初回の動作確認では、実際のWebページとクライアントの「接続」または「Connections」画面をあわせて確認し、そのリクエストに適用されたルールとポリシーを把握しましょう。
4. システムプロキシとモバイル端末のVPN許可
Windows：待ち受けアドレスとポートを確認
旧版 CFW では「General」画面でポートを確認し、「System Proxy」を有効にできます。ほかのクライアントでは、通常ホーム画面または設定画面に項目があります。以下は設定項目の関係を説明するための例です。ノードやルールを含む完全なサブスクリプションではなく、すべてのクライアントの初期値でもありません。
mixed-port: 7890
allow-lan: false
mode: rulemixed-port: 7890 は、同じ待ち受けポートで HTTP と SOCKS の両方のプロキシ接続を受け付ける設定です。クライアントが実際には 7897 で待ち受けている場合は 7897 を指定してください。例の 7890 をそのまま使わないでください。端末内だけで使う場合、接続先アドレスは通常 127.0.0.1 です。allow-lan: false はLANからの接続を制限します。ブラウザーをインターネットに接続するためだけに、LAN共有を有効にする必要はありません。
システムプロキシを有効にしたら、Windows 11 の「設定」→「ネットワークとインターネット」→「プロキシ」で設定を確認してください。一般的な方式では、手動プロキシにローカルアドレスとポートを設定します。プロキシスクリプトを使うクライアントもあります。すべての項目を有効にすることではなく、システム側の設定とクライアントの通信取り込み方式が一致していることが重要です。
macOS・Linux・スマートフォンで異なる点
- macOS：「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」で設定を確認できます。クライアントによっては、システムのネットワーク設定を変更するためにヘルパープログラムのインストールを求められます。
- Linux：デスクトップ環境のネットワークプロキシ設定が、ターミナルのプログラムやすべてのアプリに反映されるとは限りません。ブラウザー、パッケージ管理ツール、コマンドラインツールが、それぞれ異なるプロキシ設定を参照する場合があります。
- Android：一般的には、Windows の「System Proxy」を使うのではなく、ローカルVPNサービスを起動してシステムの許可を与えます。アプリごとのプロキシ設定や「除外」リストによって、実際に通信を取り込む範囲も変わります。
- iOS / iPadOS：通常はクライアントでVPN構成を作成し、システムの案内に従って許可します。対応プロトコル、バックグラウンドでの動作、設定の互換性は、使用するアプリによって異なります。
システムプロキシが対象とするのは、システム設定に従うアプリが中心です。ゲームやコマンドラインツールが接続一覧に表示されなくても、ノードの障害とは限りません。アプリがシステムプロキシを参照していない可能性があります。まずアプリ独自のプロキシ設定を確認し、その後で TUN の利用を検討してください。
5. ポート競合と接続確認
初回の接続確認では、プロキシクライアントを1つだけ起動しておくのがおすすめです。旧クライアント、開発ツール、バックグラウンドサービスがポートを使用していることがあります。ログに address already in use や bind の失敗が表示されたら、サブスクリプションを再ダウンロードするのではなく、まず待ち受けポートを確認してください。
Windowsで7890番ポートの使用状況を確認
netstat -ano | findstr :7890ローカルポートが 7890 で、状態が LISTENING の行があるか確認します。最後の列に表示されるのが PID です。「タスク マネージャー」→「詳細」で PID に対応するプログラムを調べてください。不要な旧プロキシだと確認できた場合は、通常の方法で終了します。正体の分からないシステムプロセスを、むやみに終了しないでください。未使用のポートに変更する方法もありますが、その場合はシステムプロキシと手動設定しているアプリもあわせて変更してください。
プロキシを明示したリクエストで問題を切り分ける
実際の待ち受けがローカルの HTTP ポートまたは混合ポート 7890 の場合は、Windows のターミナルで次の診断コマンドを実行できます。macOS・Linux では curl.exe を curl に置き換えてください。
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/このコマンドはプロキシポートを明示して接続するため、ブラウザーがシステム設定を読み取るかどうかに左右されません。ただし、コアのルールは適用されるため、応答があってもリモートノード経由とは限りません。ルールの振り分け先が直結なら、接続先へ直接アクセスすることがあります。接続パネルで通信経路を確認してください。例の 10 秒は接続時のタイムアウト、20 秒はリクエスト全体の制限時間であり、実測値ではありません。
| 発生している現象 | まず確認する項目 |
|---|---|
| ローカルポートへの接続にすぐ失敗する | コアが起動しているか、待ち受けポートが一致しているか、ポートのバインドエラーが出ていないか。 |
| リクエストが接続パネルに表示された後、タイムアウトする | 選択中のポリシー、ノードの接続ログ、接続先サイト、端末のネットワークで接続が許可されているか。 |
| コマンドではアクセスできるが、ブラウザーではアクセスできない | システムプロキシ、ブラウザー独自のプロキシ設定、拡張機能、ブラウザーに残っている接続キャッシュ。 |
| ブラウザーは使えるが、特定のアプリは使えない | アプリがプロキシに対応しているか、システム設定を迂回していないか、追加の通信取り込みが必要か。 |
6. 証明書の警告と TUN の権限
ブラウザーの証明書エラーを安易に無視しない
通常の HTTP CONNECT トンネルや SOCKS 転送で、HTTPSサイトを閲覧するために出所不明のルート証明書をインストールする必要はありません。証明書の有効期限切れ、ドメイン不一致、発行元が信頼されていないという警告が表示されたら、まずシステムの日付、タイムゾーン、時刻同期を確認してください。そのうえで、組織のネットワーク検査、セキュリティソフトの HTTPS スキャン、ログイン認証ページの有無を確認しましょう。
クライアントのインストール時に表示されるアプリ署名の警告、サブスクリプション取得時の TLS エラー、ブラウザーでサイトを開いた際の証明書エラーは、それぞれ別の段階で発生します。証明書関連の設定をすべて無効にするより、正確なエラー内容と発生箇所を記録するほうが、原因の特定に役立ちます。また、skip-cert-verify を万能の対処法として使わないでください。該当する接続の証明書検証方法が変わり、ノード以外の問題を隠してしまう可能性があります。
基本的な接続を確認してから TUN を使う
TUN は仮想ネットワークインターフェースとルーティング設定を使い、対象となる IP 通信を取り込みます。システムプロキシを参照しないプログラムに有効ですが、有効にするだけで全通信が必ずプロキシを経由するわけではありません。経路の除外設定、アプリごとの設定、IPv6、DNSの処理、システム権限によって対象範囲は変わります。
- まずシステムプロキシ経由でブラウザーが正常にアクセスできることと、接続パネルに想定したポリシーが表示されることを確認してください。
- 使用するクライアントの説明に従ってサービスをインストールまたは有効化し、その後 TUN を有効にしてください。Windows ではサービスの登録や権限の昇格、macOS・Linux ではヘルパープログラムやネットワーク管理権限が必要になる場合があります。
- ログに仮想インターフェースの作成失敗、ルート設定の失敗、DNSの待ち受け競合がないか確認してください。別のVPNアプリの通信取り込み機能と同時に有効にしないでください。
- 通常はシステムプロキシを使わないアプリで動作を確認してください。有効にした後、端末全体がインターネットに接続できなくなった場合は、まず TUN を無効にして通信を復旧し、ログを確認しましょう。
DNSのリダイレクトルールは、特定のDNS通信をコアに処理させるためのものです。ブラウザー内蔵の暗号化DNS、すべてのネットワークインターフェース、すべてのアプリが同じ経路に従うとは限りません。初期設定でDNSモード、IPv6の方針、ルーティング設定を一度に変える必要はありません。変更は一度に1つに絞ると、どの設定が影響したか判断できます。
7. 終了後の復旧と最終チェック
初期設定が終わったら、自動起動、起動時の接続、サブスクリプションの定期更新を有効にするか検討してください。まずは通常の方法で終了できるか試します。通信の取り込みを無効にしてから、トレイまたはメニューでクライアントを終了し、通常のネットワーク接続に戻ることを確認しましょう。プロセスを強制終了すると、システムプロキシがローカルを指したままになり、待ち受けていたプログラムはすでに終了している場合があります。
Windowsで終了後にインターネットへ接続できない場合は、「設定」→「ネットワークとインターネット」→「プロキシ」で、手動プロキシやスクリプト設定が残っていないか確認してください。自分で追加した設定だけを元に戻しましょう。組織管理のPCに元から設定されているプロキシポリシーは、むやみに削除しないでください。モバイル端末では、システムのVPN状態と「常時接続VPN」「VPN未接続時の接続をブロック」などの設定を確認します。
- インストール：アーキテクチャ、OSの最低要件、クライアントのメンテナンス状況を確認済み。
- 設定：サブスクリプションを取得でき、現在の設定が有効で、プロキシグループも正常に表示されている。
- モード：ルールモードを使用し、テストした通信に適用されたルールとポリシーを把握している。
- ポート：システムプロキシやアプリの設定が実際の待ち受けポートと一致し、複数のクライアントによる競合もない。
- 権限：サービス、VPN、TUN が必要な場合に限って適切な権限を付与し、セキュリティ検証を無効にして問題を回避していない。
- 復旧：通信の取り込みを無効にして通常終了した後も接続できることを確認し、残った設定を元に戻す場所も把握している。
この6項目を確認してから、独自ルール、アプリごとの通信振り分け、TUNによる通信の取り込みを追加しましょう。その後のトラブルシューティングも同じ順番で確認すると整理しやすくなります。設定は有効か、コアは待ち受けているか、通信は取り込まれているか、ルールはどう適用されるか、接続先へ到達できるか。何度もアンインストールと再インストールを繰り返すより、原因を特定しやすくなります。