トラブル対応
読了目安 12分

Clashクライアントの起動直後のクラッシュ対策：ポート競合・設定エラー・権限問題を解決

起動時クラッシュの主な原因を発生頻度順に整理。ポート競合、YAML構文エラー、コアファイル破損、システム権限不足、残留プロセスの競合について、確認方法と対処法を解説します。

まず画面が終了したのか、Clashコアの起動に失敗したのかを切り分ける

「ダブルクリックしてもウィンドウが表示されない」「ウィンドウが1秒ほどで消える」「トレイアイコンはあるのにネットワークへ接続できない」――似た症状でも、実際には異なる層の問題です。ClashのGUIクライアントは通常、画面プロセス、Clash Meta（mihomo）コア、システムプロキシ、TUNサービスで構成されます。画面プロセスの終了はクライアント自体の問題です。画面は残っているのにコアが何度も停止する場合は、設定、ポート、コアファイルを確認します。コアが正常に動作しているのに通信できない場合は、クライアントを再インストールするのではなく、システムプロキシ、DNS、ルール、TUNを確認してください。

切り分ける前に、「スタートアップ起動」と「サイレント起動」を一時的に無効にします。クライアントを短時間でも開ける場合は、「設定」→「一般」からスタートアップ起動を無効にし、「ツール」または「ログ」画面で直近の起動記録をコピーします。クライアントによってメニュー名は多少異なりますが、よくある入口は「設定」→「ログ」、「ツール」→「アプリログ」、「コア」→「実行ログ」です。終了時刻の直前後にある最後の20～50行を記録しましょう。

症状 優先して確認する項目 よくあるログのキーワード
ウィンドウ表示直後に消える アプリの権限、ユーザーディレクトリ、画面ランタイム permission denied、access denied、panic
画面は正常だが、コアが何度も停止する ポート、YAML、コアファイル bind、parse、unmarshal、config error
TUNを有効にすると終了する サービス権限、ドライバー、ルーティングの競合 tun、service、route、operation not permitted
再起動後に既存のインスタンスがあると表示される 残留プロセス、ロックファイル already running、lock、address in use

1つ目：7890、7891、コントロールポートの使用状況を確認する

ポート競合は、コアの起動に失敗する最も一般的な原因の1つです。典型的な設定では、HTTPポートに 7890、SOCKS5ポートに 7891 を使うか、mixed-port: 7890 で2種類のプロキシ入口を統合します。外部コントローラーの一般的なアドレスは 127.0.0.1:9090 です。これらは必須の標準値ではありませんが、同じデバイス上で2つのプログラムがまったく同じアドレスとポートを同時に待ち受けることはできません。

Windowsでポートの使用状況を確認する

現在のClashクライアントを完全に終了し、PowerShellまたはコマンドプロンプトを開いて、次のコマンドを順番に実行します。

netstat -ano | findstr :7890
netstat -ano | findstr :7891
netstat -ano | findstr :9090

結果に LISTENING が表示された場合、右端の数字がPIDです。たとえば 127.0.0.1:7890 に対応するPIDが 8420 なら、続けてプロセスを確認できます。

tasklist /FI "PID eq 8420"

古いClash、mihomo、プロキシソフト、デバッグサービスであることを確認したら、まず元のプログラムの終了メニューから正常に終了します。そのプロセスが他の処理を担っていないと確認できた場合のみ、次のコマンドで終了してください。

taskkill /PID 8420 /F

macOSとLinuxで待ち受けプロセスを確認する

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

Linuxでは ss も使用できます。

ss -lntp | grep -E ':7890|:7891|:9090'

2つのクライアントを同時に残す必要がある場合は、一方のクライアントで「設定」→「ネットワーク」→「ポート」を開き、待ち受け値を変更します。たとえばmixedポートを 7897、コントロールポートを 9097 に変更します。変更後はOSのプロキシ設定も確認し、システムが古い 127.0.0.1:7890 を参照し続けないようにしてください。

2つ目：YAML設定エラーとサブスクリプション異常を切り分ける

Clash Metaは起動時にYAMLを解析します。インデントの誤り、フィールドの型違い、同じ階層でのキー重複、ルール形式の誤りなどにより、コアが設定を拒否することがあります。ログには yaml: line 42、cannot unmarshal、proxy group not found、invalid mode などがよく表示されます。この場合は、後続する連鎖エラーを1つずつ追うのではなく、最初に発生した設定エラーを見つけることが重要です。

最小構成でコア単体の起動を確認する

現在の設定をバックアップしてから、ローカル待ち受けと直結ルールだけを含むテスト設定を作成します。

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

proxies: []

proxy-groups: []

rules:
  - MATCH,DIRECT

この設定にはサブスクリプションのノードを含めず、日常のプロキシ用途にも使いません。目的は、YAMLの解析、ポートの待ち受け、コアプロセスの起動が完了するかを確認することです。最小構成で動作するなら、問題は元の設定にあるDNS、ノード、プロキシグループ、ルール、または上書き内容にある可能性が高いです。それでも終了する場合は、コアファイル、ディレクトリ権限、残留サービスを確認します。

すべてを一度に戻さず、ブロック単位で復元する

  1. まず dns ブロックを復元してコアを再起動し、現在のmihomoバージョンがフィールドを認識できるか確認します。
  2. 次に proxies またはサブスクリプションプロバイダーを復元し、ノードのプロトコルパラメーターと証明書フィールドを確認します。
  3. proxy-groups を追加し、グループ内で参照しているノード名、プロバイダー名、他のプロキシグループが実際に存在するか確認します。
  4. 最後に rules を復元します。特にルールセット名、適用先のプロキシグループ名、末尾の MATCH ルールを確認してください。

YAMLのインデントは階層を表すため、スペースによるインデントにTab文字を混在させないでください。リスト項目のハイフンの後にはスペースが必要です。たとえば - MATCH,DIRECT のように記述します。真偽値、数値、文字列も自由に入れ替えることはできません。コロン、シャープ記号、特殊文字を含むノード名は引用符で囲みます。囲まないと、シャープ記号以降がコメントとして扱われます。

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

サブスクリプション更新後に問題が発生した場合は、「設定」画面で前回正常だった設定に戻し、自動更新を無効にして比較します。サブスクリプションのダウンロード成功は、サーバーが内容を返したことを意味するだけで、必ずしも解析可能なClash設定とは限りません。ログインページ、HTMLのエラーページ、途中で切れたYAMLが返された場合、ファイルは保存されても、コアの読み込み時にエラーが発生します。

3つ目：mihomoコアのファイルとアーキテクチャが一致しているか確認する

GUIクライアントが開くからといって、コアの実行ファイルが使えるとは限りません。更新の中断、セキュリティ機能によるファイル隔離、異なるアーキテクチャの手動置換などにより、「コアを起動」をクリックした直後に停止することがあります。Windowsで一般的なアーキテクチャは amd64 と arm64 です。Appleシリコン搭載Macは arm64、Intel Macは amd64 を使用します。Linuxでもamd64、arm64などのビルドを区別する必要があります。

クライアントの「設定」→「コア」または「コア管理」を開き、現在表示されているコア名とバージョンを記録します。たとえばログに mihomo v1.19.10 windows amd64 と表示されていれば、少なくともファイルが実行され、バージョン情報を出力したことを確認できます。バージョン情報すらなく、ログに「プロセスを起動できません」や「ファイルが存在しません」だけが表示される場合は、ファイルパスと実行権限を確認してください。

まずはクライアント内蔵のコア管理機能を使う

コアを手動でコピーする際は、ファイル名だけでアーキテクチャを判断しないでください。誤ったアーキテクチャでは、Windowsで「このアプリはお使いのPCでは実行できません」、Linuxで Exec format error が表示されることがあります。macOSで開発元や隔離属性に関するブロックが表示された場合は、ファイルの入手元とクライアントのバージョンを確認し、「システム設定」→「プライバシーとセキュリティ」で実際のブロック記録を確認してください。何度もダブルクリックするだけでは解決しません。

4つ目：権限、TUNサービス、保護されたディレクトリを確認する

通常のシステムプロキシはローカルの高位ポートで待ち受けるだけですが、TUNモードでは仮想ネットワークインターフェースの作成、ルートの変更、システムサービスの呼び出しが必要になるため、より高い権限が求められます。よくある症状は、TUNを無効にすると安定するのに、有効にするとコアがすぐ終了するケースです。この場合はTUNを独立した変数として切り分けます。

Windows：アプリの権限とサービスの権限を分けて確認する

クライアントを右クリックして「管理者として実行」する方法は、一時的な診断には使えますが、すべての問題に対する恒久的な解決策ではありません。管理者として起動するとTUNが正常で、通常起動では失敗する場合は、クライアントの「設定」→「TUNモード」または「サービスモード」からシステムサービスを再インストールします。その後、管理者セッションを終了し、通常の方法で再度テストしてください。

アプリが追加の書き込み権限を必要とするディレクトリに置かれていないかも確認します。クライアントの実行データを C:\Program Files 配下の読み取り専用の場所に保存したり、圧縮ファイルのプレビュー画面から直接実行したりしないでください。プログラムをユーザーが書き込めるディレクトリへ完全に展開し、ユーザーディレクトリ内の専用アプリフォルダーなどから起動します。

macOSとLinux：実行権限とネットワーク機能を確認する

Linuxで手動配置したコアに実行権限がない場合、Permission denied が直接返されます。まず権限を確認してください。

ls -l ./mihomo
chmod u+x ./mihomo

これはファイルの実行権限を解決するだけで、TUNデバイスの作成に必要な権限が自動的に付与されるわけではありません。デスクトップクライアントでTUNを使う場合は、クライアントが提供するサービスインストール手順を優先してください。systemdで構成する場合は、サービスユニットのユーザー、ネットワーク権限、作業ディレクトリ、設定パスを確認します。デスクトップクライアントと、同じポートを待ち受ける別のsystemdサービスを同時に動かさないでください。

macOSでは「システム設定」→「プライバシーとセキュリティ」でブロックされたシステム拡張機能やアプリの記録を確認し、「システム設定」→「ネットワーク」で重複したVPN設定が残っていないか確認します。変更後はクライアントを完全に終了してから起動し、古いネットワーク拡張機能の状態がテストに影響しないようにします。

5つ目：残留プロセス、ロックファイル、重複した自動起動項目を整理する

クライアントのウィンドウが消えた後も、mihomoコアやシステムサービスがバックグラウンドで動作していることがあります。再起動時に新しいインスタンスがポート競合、データベースロック、「既存のインスタンスが実行中」という警告に遭遇する原因です。Windowsではタスクマネージャーの「詳細」タブでクライアントのメインプロセス、mihomo.exe、旧版の clash.exe を確認します。macOSではアクティビティモニタを使い、Linuxでは次を実行できます。

ps -ef | grep -E 'mihomo|clash'
systemctl --user status mihomo
systemctl status mihomo

同じプログラムにシステムサービス、ユーザーサービス、デスクトップのスタートアップが同時に設定されていると、ログイン時に2～3回起動することがあります。起動方法は1つだけ残してください。Windowsでは「設定」→「アプリ」→「スタートアップ」とタスクマネージャーの「スタートアップ アプリ」を確認します。macOSでは「システム設定」→「一般」→「ログイン項目」を確認します。Linuxではsystemdサービスとデスクトップ環境の自動起動ディレクトリを両方確認してください。

ロックファイルは、関連するすべてのプロセスが終了したことを確認してから処理します。コアが動作中にデータベース、キャッシュ、実行ディレクトリを削除しないでください。クライアントに「実行状態をリセット」や「キャッシュをクリア」ボタンがある場合は、内蔵機能を優先します。ユーザーデータを再構築する必要がある場合は、サブスクリプションURL、ローカルYAML、ルールの上書き、アプリ設定を先にバックアップし、元のディレクトリは直接完全削除せず、名前を変更して残してください。

6つ目：決めた順番で再現性のある切り分けを行う

クラッシュ問題は、「5つの設定を同時に変更した」ことで切り分けが難しくなりがちです。次の手順では、リスクが低く検証しやすい項目から始め、各ステップで変更する変数を1つに絞ります。

  1. クライアントを完全に終了し、画面プロセス、mihomo、clashの残留プロセスがないことを確認します。
  2. 実際の設定で使用している 7890、7891、9090 などのポートを確認し、競合するプロセスを終了するか、ポートを変更します。
  3. TUN、システムサービス、スタートアップ起動を無効にし、通常のmixed-portだけを残します。
  4. 最小構成のYAMLを読み込み、コアが少なくとも30秒間安定して動作するか確認します。
  5. コアのアーキテクチャとバージョンを記録し、クライアントのコア管理画面から一度再配置します。
  6. DNS、ノード、プロキシグループ、ルールを順番に復元し、復元するたびに再起動してログを確認します。
  7. 最後にシステムプロキシを再び有効にし、その後TUNとスタートアップ起動をテストします。

各テストで「操作、結果、最後のエラーログ」を記録します。たとえば「ポートを7890から7897へ変更し、最小構成は60秒正常動作。サブスクリプションに戻すと184行目で解析エラーが発生」のように記録すれば、問題をクライアントのバージョンではなく設定へすばやく絞り込めます。

クライアントを再インストールすべきケース

画面プロセス自体が起動しない、アプリのファイルが欠落している、内蔵のコア管理機能でも復旧できない、または最小構成でもユーザーデータディレクトリの読み書きエラーが続く場合に限り、再インストールを検討します。再インストール前にシステムプロキシとTUNサービスを停止し、必要な設定をバックアップしてから旧バージョンをアンインストールします。インストール後はすぐに古いデータをすべて読み込まず、まず初期設定で一度起動し、解析できることを確認した設定を1つだけ読み込んでください。

再インストールが不要なケース

クライアントをダウンロード Windows、macOS、Android、iOS、Linux