インストール前に知っておきたいクライアント・コア・設定ファイルの違い

Clash Nyanpasuはデスクトップ向けのGUIクライアントです。ウィンドウが開いても、起動したのは画面のプロセスだけです。通信には、稼働中のプロキシコア、有効な設定、コアに通信を渡す入口が必要です。初回設定は「インストール → 設定をインポート → コアを起動 → 手動プロキシでテスト → システムプロキシ」の順に進め、まずはTUNをオフにしておきましょう。

  • クライアント：プロファイル管理、設定画面、ログ表示、システムとの連携を担います。
  • コア：設定を読み込み、通信を処理します。mihomoはClash Metaコアとも呼ばれますが、選択できるコアはクライアントの配布バージョンによって異なります。
  • Profile：ローカル設定またはリモートサブスクリプションの登録情報です。通常、設定にはノード、プロキシグループ、DNS、ルールが含まれます。
  • プロキシの入口：ローカルのHTTP/SOCKS待ち受けポートやTUN仮想インターフェースなどです。入口によってプロキシの対象範囲が異なります。

Windows・macOS・Linuxのインストール手順

Windows：システムの種類とインストール権限を確認

  1. 「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。x64とARM64では対応するビルドを選んでください。Windows 11という名前だけでアーキテクチャを判断しないようにしましょう。
  2. ダウンロードページから、現在のリリースで提供されているインストーラーを選びます。通常どおりインストールして起動し、不足している依存関係やWindowsのセキュリティ警告が表示された場合は、内容を記録してください。
  3. 初回は通常のユーザー権限で設定をインポートし、ローカルポートをテストします。サービスモードやTUNが必要になった段階で、クライアントの案内に従ってサービスのインストールや権限の付与を行ってください。
  4. WebView2関連のエラーが表示された場合は、そのバージョンのインストール手順に従ってランタイムを確認します。オフライン端末では、アーキテクチャに合ったランタイムのインストーラーを用意してください。画面表示に必要な依存関係のエラーを、サブスクリプションの問題と混同しないようにしましょう。

Windowsのシステムプロキシは、「設定」→「ネットワークとインターネット」→「プロキシ」で確認できます。テスト中にシステムプロキシを変更するクライアントを複数起動しないでください。最後に設定を書き込んだプログラムが、先に起動したプログラムのアドレスやポートを上書きする場合があります。

macOS：チップを確認してからセキュリティ警告に対処

  1. Appleメニューから「このMacについて」を開き、「チップ」または「プロセッサ」を確認します。Appleシリコン搭載機では対応するARM64ビルド、Intel搭載機では対応するx64ビルドを選択してください。ユニバーサルビルドの有無はダウンロードページの表記を確認します。
  2. ディスクイメージをダウンロードした場合は、開いてアプリを「アプリケーション」フォルダにコピーしてから起動します。マウントしたディスクイメージ内から常用するのは避けてください。
  3. macOSに起動を阻止された場合は、まず配布元とシステムとの互換性を確認し、「システム設定」→「プライバシーとセキュリティ」に表示される選択肢に従って対処します。アプリを起動するために、システム全体のセキュリティ機能を無効にしないでください。
  4. 権限の許可は、該当する機能を使う場合に限って行います。ローカルプロキシの待ち受けやシステムプロキシを使うだけなら、すべてのネットワーク拡張やキーチェーンへのアクセスを許可する必要はありません。

新しいmacOSでは、「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」から状態を確認できます。macOSのバージョンによって項目名が多少異なる場合があります。認証ダイアログが繰り返し表示される場合は、要求元の名前と内容を記録し、サービスのインストール、ネットワーク設定、認証情報へのアクセスのどれに該当するか確認してください。

Linux：パッケージ形式・アーキテクチャ・デスクトップ環境を確認

まず uname -m を実行してアーキテクチャを確認します。よくある結果では、x86_64 がx64、aarch64 がARM64に相当します。次に、ディストリビューションと現在のリリースで提供されているファイルに合わせてインストール方法を選びます。パッケージマネージャーでのインストールとAppImageの実行は別の手順です。コマンドを混同しないでください。

  • ディストリビューションのパッケージ：システムのパッケージマネージャーでインストールし、依存関係の解決結果を確認します。GUIライブラリが不足している場合は、エラーメッセージに基づいて必要な依存関係を追加してください。
  • AppImage：まず実行権限を付与します。ログにFUSE関連の問題が表示された場合は、ディストリビューションとビルドの説明に従って対処してください。GUIをrootで常用して問題を回避するのは避けましょう。
  • デスクトップのシステムプロキシ：GNOME、KDE、ターミナルの各アプリでは設定の参照方法が異なります。クライアント上でシステムプロキシが有効になっていても、対象のアプリがその設定を使っているか確認してください。

Linuxのデスクトップで起動してもウィンドウが表示されない場合は、ターミナルから実際にインストールした実行ファイルを起動し、出力を保存します。共有ライブラリの不足、ディスプレイセッションの問題、コアの設定エラーはそれぞれ別の段階の問題です。最初に確認できた明確なエラーから対処してください。

設定をインポート：まず動作するProfileを用意

クライアントのプロファイル管理画面で、ローカルのYAMLファイルまたはリモートサブスクリプションを追加します。インポート完了後、その設定を現在使用するプロファイルに指定してください。バージョンによってボタン名は「設定」「Profiles」など異なりますが、目的は設定を登録して有効化することです。リンクを入力欄に保存するだけでは使えません。

  1. サブスクリプションの提供元がClash YAML、または現在のコアが認識できる形式に対応していることを確認します。ブラウザーでリンクを開けても、返された内容をそのままインポートできるとは限りません。
  2. ダウンロードした内容が設定ファイルかどうか確認します。ログインページ、期限切れの通知、HTML形式のエラーページ、ノード一覧だけのデータは、解析に失敗したりプロキシグループが不足したりする原因になります。
  3. 設定を有効にしたらログを確認し、YAMLの解析エラー、未知のフィールドによる起動失敗、存在しないルールの転送先がないか確認してください。
  4. プロキシまたはプロキシグループの画面を開き、選択できるノードがあることを確認します。グループに DIRECT しかない場合は、システムプロキシを何度も切り替えるのではなく、設定内容を確認してください。

サブスクリプションURLにはアクセストークンが含まれる場合があります。スクリーンショットの共有、質問の投稿、ログのコピーを行う前に、URLのクエリパラメーター、ノードのパスワード、コントローラーのシークレットを伏せてください。リモートサブスクリプションを更新すると元の内容も更新されます。ローカルの変更が保持されるかどうかは、クライアントの設定処理によって異なります。継続的にカスタマイズする場合は、そのバージョンでサポートされているオーバーライド機能を使いましょう。

コアとポート：実際に有効な値を確認

初回インストールでは、まずクライアントの配布バージョンに同梱されたコアを使います。mihomo固有のフィールドが必要な場合は、現在稼働しているコアとそのバージョンが対応しているか確認してください。コアを切り替えたら設定を再読み込みし、新しいプロセスの起動ログを確認します。画面上でコア名を選択しただけでは、新しいコアが正常に動作しているとは限りません。

項目・設定用途初回に確認すること
mixed-portHTTPとSOCKSのプロキシ入口を同じポートで提供します。実際の待ち受けポートを記録し、テスト時はクライアントのアドレスと一致させます。
allow-lanLAN内のデバイスからプロキシへの接続を許可するかどうかを設定します。この端末だけで使う場合はオフにし、バインド先アドレスも確認します。
modeルール、グローバル、直接接続などの動作モードを選びます。日常利用ではルールモードから始め、ルールの転送先が有効か確認します。
external-controllerクライアントとコアの間で使うコントローラーの接続口を提供します。コントローラーのポートに、ブラウザー用のプロキシポートを設定しないでください。

以下は項目同士の関係を説明するためのYAML断片です。ノードやルールを含む完全なサブスクリプションではありません。現在の設定全体をこの内容で置き換えないでください。クライアントのオーバーライドによって最終的な値が変わることがあるため、実際に有効な設定とログを基準にしてください。

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

コントローラーの接続口と通信の入口は別のものです。たとえば、設定でコントローラーを 127.0.0.1:9090 に指定した場合、このアドレスはコアの管理用であり、Webリクエストの転送には使いません。必要なアクセス制御を設定せず、コントローラーをすべてのネットワークインターフェースで待ち受けさせないでください。

接続の確認：手動プロキシ・システムプロキシ・TUN

手順1：明示的なプロキシ指定でポートをテスト

まず利用可能なプロキシグループとノードを選び、単一のリクエストがローカルプロキシを経由するよう明示してテストします。以下のコマンドは、HTTPSの標準的なサンプルドメインにアクセスします。応答が返っても、今回のリクエストが完了したことを示すだけで、すべてのサイト、プロトコル、アプリの通信がプロキシ経由になったとは限りません。Windowsでは curl.exe を使い、PowerShell環境によっては同名のエイリアスが引数の解析に影響する問題を避けます。

# Windows PowerShell
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com

# macOS / Linux
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com

127.0.0.1 に接続できない場合は、まずポートとプロセスを確認します。プロキシへの接続は確立したもののタイムアウトする場合は、ログを確認しながらノードへの接続、TLS、DNS、ルールの判定結果を調べます。HTTPエラーが返っても、ローカルプロキシが動作していないとは限りません。「接続できるか」と「接続先サイトが何を返したか」を分けて考えてください。

手順2：システムプロキシを有効にして接続を確認

明示的なプロキシ指定でのテストが成功してから、クライアントのシステムプロキシを有効にします。テストするアプリを再起動するか、新しい接続を開始し、クライアントの接続一覧で対象ドメイン、適用されたルール、最終的なプロキシ設定を確認してください。システムプロキシが影響するのは、システム設定に従うアプリだけです。既存の接続、一部のターミナルツール、独自にネットワークを管理するプログラムは、切り替えても変わらない場合があります。

ターミナル環境の HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY もリクエスト経路を変える場合があります。特定のプログラムを調査する場合は、そのアプリ独自のプロキシ設定と環境変数を先に確認し、システムプロキシが効いていないと決めつけないでください。

手順3：必要な場合のみTUNを有効化

TUNは仮想ネットワークインターフェースとルーティングを利用して通信を取り込み、システムプロキシではカバーできない一部の用途に対応します。追加の権限やサービスが必要になることが多く、DNS、ルート、インターフェースの選択も関係します。通常のブラウザーでの接続テストが成功していない段階では、TUNを同時に有効にしないでください。ノードの問題とルーティングの問題を切り分けにくくなります。

  • ルートやDNSの二重制御を避けるため、ほかのVPNや同種のTUNクライアントを終了します。
  • 現在のバージョンの案内に従ってサービスのインストールや権限の許可を行い、ログで仮想インターフェースが正常に作成されたことを確認します。
  • 通常のWebサイト、LAN内のアドレス、プロキシ対象にするアプリをそれぞれ確認します。TUNのスイッチがオンになっているかだけで判断しないでください。
  • ネットワーク全体に接続できなくなった場合は、まずTUNをオフにして接続が戻るか確認します。その後、ルートとDNSの設定を調べてください。設定を次々と重ねて変更しないようにしましょう。

起動失敗とポート競合の確認手順

ウィンドウが開かない：まずGUIの問題を切り分ける

インストーラーのアーキテクチャ、対応するOSの範囲、インストール先を確認します。Windowsでは依存関係の通知、macOSではシステムのセキュリティ警告、Linuxではターミナルの出力を確認してください。この段階ではまだコアの待ち受け処理に到達していないため、サブスクリプションのルールを変更しても画面の起動失敗は通常解決しません。アップデートの前後で動作が変わった場合は、設定のバックアップ、クライアントのバージョン、エラーが発生した時刻を記録してください。

ウィンドウは開くがコアが起動しない：最初のエラーを確認

ログに address already in use や bind に関するエラーがある場合は、競合しているのがプロキシポート、DNSの待ち受けポート、コントローラーのどれか確認します。以下のコマンドは例としてプロキシポート 7890 を調べます。エラーに表示された実際の番号に置き換えてください。

# Windows PowerShell：待ち受けプロセスのPIDを確認
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS：TCPの待ち受けプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：待ち受け情報を確認（プロセスの詳細表示には追加権限が必要な場合があります）
ss -ltnp 'sport = :7890'
  1. PIDから該当するプロセスを特定し、重複して起動した古いクライアントは通常の方法で終了してください。出所の分からないシステムプロセスを強制終了しないでください。
  2. 2つのプログラムを同時に使う必要がある場合は、片方のプロキシ待ち受けポートを未使用の値に変更します。たとえば 7891 を使います。
  3. ポートを変更したら、システムプロキシ、ブラウザー、ターミナルで明示的に指定したプロキシアドレスも更新し、設定を再読み込みしてください。
  4. 待ち受け状態をもう一度確認してから、接続テストを再実行します。画面に表示された値だけを変更し、実際に有効な設定を見落とさないようにしてください。

ログにYAMLの行番号、インデント、プロキシグループ名のエラーが表示された場合は、まず設定を修正します。YAMLの階層にはスペースを使い、同じ階層の項目の位置をそろえてください。ルールが参照するプロキシ名は、実際に存在するグループ名と一致させます。各フィールドの意味はYAML設定リファレンスを参照してください。

起動するがアクセスできない：通信経路を順番に確認

「アプリがプロキシを使っているか → ローカルポートが待ち受けているか → どのプロキシにルールが振り分けたか → ノードに接続できるか → DNSが正常か」の順に確認します。遅延テストの数値だけでは通信経路全体の状態は分かりません。ルールモードでは、リクエストが DIRECT に振り分けられ、手動で選んだノードを経由していない場合もあります。

初期設定後に記録・確認しておくこと

  • バージョンと設定値を記録：クライアントのバージョン、コアのバージョン、現在のProfile名、プロキシポート、TUNの有効・無効。
  • 終了時の動作を確認：クライアントを通常の方法で終了した後、システムプロキシが元に戻ることを確認します。予期せず終了してプロキシ設定が残った場合は、システムのネットワーク設定で手動でオフにしてから、ネットワークを確認してください。
  • 自動起動は最後に設定：終了、再起動、接続確認を一度済ませてから、ログイン時の自動起動を有効にします。ログイン後に同じエラーが繰り返し発生するのを防げます。
  • バックアップを安全に保管：設定のエクスポートにはサブスクリプションのトークンやノードの認証情報が含まれる場合があります。信頼できる場所だけに保存し、設定ファイル全体を公開フォーラムに投稿しないでください。

初回インストールの完了は、すべてのスイッチをオンにすることではありません。現在の設定を読み込めること、プロキシの入口が待ち受けていること、対象アプリの通信経路を確認できることが基準です。検証済みの基本設定を保管し、カスタムルール、オーバーライド、TUNは必要に応じて1つずつ追加すれば、元に戻すときも原因を調べるときも簡単です。