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

Clashクライアントが開かないときの対処法:起動時のクラッシュ・強制終了を解決する手順

起動に失敗する主な原因を頻度順に整理。ポート競合、設定ファイルの構文エラー、権限不足、カーネル破損、システムコンポーネント不足を確認し、修復手順を解説します。

まず起動のどの段階で問題が起きているか確認する

ClashのGUIクライアントは、単一のプログラムだけを実行しているわけではありません。一般的には、デスクトップシェルが画面を読み込み、アプリの設定とサブスクリプション設定を読み取った後、Clash Meta(mihomo)カーネルを起動し、最後にプロキシポート、コントロールポート、必要に応じてTUN仮想インターフェースをバインドします。どの段階で失敗しても、「クリックしても反応しない」「ウィンドウが表示された直後に消える」「画面は開くがカーネルの起動に失敗し続ける」といった症状になります。

確認を始める前に、古いプロセスを完全に終了してください。Windowsでは「タスク マネージャー」→「詳細」でクライアントのプロセスと mihomo.exe を終了します。macOSでは「アクティビティモニタ」でクライアント名と mihomo を検索し、Linuxでは ps で残存プロセスを確認できます。トレイアイコンが消えてもバックグラウンドプロセスが終了したとは限りません。連続して起動すると、2つ目のインスタンスや新たなポート競合が発生することがあります。

見えている症状 優先して確認する項目 よくある手がかり
クリックしてもウィンドウが表示されない 残存プロセス、システムコンポーネント、インストール先の権限 タスク マネージャーに一時的にプロセスが表示され、数秒後に終了する
ウィンドウが表示された直後に強制終了する アプリデータ、UIランタイム、アップデートの残骸 システムイベントログにモジュールの読み込み失敗が記録される
画面は開くが、カーネルが停止と表示される 設定の構文、ポート競合、カーネルファイル ログに parse、bind、permission などのキーワードが出る
通常のプロキシは使えるが、TUNの起動に失敗する 管理者権限、サービスモード、仮想ネットワークインターフェース ログに route、interface、operation not permitted が出る
サブスクリプション更新後から起動できない 現在の設定とproviderファイル エラーに具体的なYAMLの行番号やフィールド名が含まれる

問題の特定に役立つファイルを先に残す

リセットする前に、サブスクリプション設定、手動で作成したYAML、ルールセット、ログをコピーしておきます。クライアントの画面を開ける場合は、「設定」→「設定ファイルのフォルダー」と「設定」→「ログ」を順に確認します。画面を開けない場合は、システムのユーザーデータフォルダーを探してください。Windowsの一般的な場所は %APPDATA% または %LOCALAPPDATA%、macOSは ~/Library/Application Support/、Linuxは ~/.config/ です。クライアントごとにフォルダー名は異なるため、フォルダー全体を別のクライアントへそのままコピーしないでください。

最優先:ポート競合と重複プロセスを確認する

Clashの設定では、HTTPまたはmixedプロキシに 7890、SOCKSに 7891、外部コントロールに 9090 がよく使われます。ただし、固定値ではありません。旧版Clash、別のプロキシクライアント、開発用サーバー、終了していないmihomoが同じポートを使用している可能性があります。カーネルのログには通常、address already in usebind、または「ソケットアドレスは一度しか使用できません」といった情報が表示されます。

Windowsでの確認方法

PowerShellまたはコマンドプロンプトを開き、3つの代表的なポートをそれぞれ確認します。最後の列がプロセスPIDです。tasklist で具体的なプログラムを調べます。

netstat -ano | findstr :7890
netstat -ano | findstr :7891
netstat -ano | findstr :9090
tasklist /FI "PID eq 4321"

PIDが不要になった古いインスタンスに対応していることを確認したら、まずそのプログラムの終了メニューから閉じてください。正常に終了できない場合は、「タスク マネージャー」→「詳細」でタスクを終了します。ポートを使用中だからといって、システムプロセスを直接終了しないでください。別の重要なサービスが意図的に設定している可能性があります。

macOS・Linuxでの確認方法

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

ポートが別のプロキシツールに使われている場合は、そのツールを終了するか、Clashの現在の設定を変更します。たとえばmixedポートを一時的に 7890 から 17890 に、コントロールポートを 9090 から 19090 に変更します。変更後は、システムプロキシ、ブラウザー拡張機能、LAN内の端末も確認し、新しいポートへ接続するようにしてください。

mixed-port: 17890
external-controller: 127.0.0.1:19090
allow-lan: false
mode: rule

第2優先:YAML設定とサブスクリプションの内容を確認する

サブスクリプションの更新、ルールの編集、設定の切り替え直後に問題が発生した場合は、設定の解析エラーが疑われます。YAMLはインデントで階層を表現するため、Tab、コロンの書き忘れ、リスト項目のハイフン不足、文字列内の特殊文字を引用符で囲まない記述などにより、読み込み段階でカーネルが停止します。ログには通常、yamlunmarshalmapping values、または行番号が表示されます。

mihomoで設定を直接検証する

mihomoの実行ファイルを見つけられる場合は、ターミナルで設定テストを実行できます。-t は設定のテスト、-f の後にはファイルパスを指定します。パスにスペースが含まれる場合は引用符で囲んでください。

mihomo -t -f "C:\Users\Public\Documents\clash\config.yaml"

macOSとLinuxも同じ書式で、パスだけ置き換えます。

./mihomo -t -f "$HOME/.config/mihomo/config.yaml"

テストに成功すると、設定の初期化が完了したことを示す情報が返ります。失敗した場合は、フィールドや行・列の位置が表示されます。まず最初に出たエラーを修正してください。後続のエラーは、最初のインデントミスによる連鎖的な結果である可能性があります。

起動失敗につながりやすい記述例

  • インデントの混在:同じ階層ではスペース数を統一し、エディターはスペースを挿入する設定にしてTabを使わないでください。
  • 存在しないプロキシグループを参照:rules が参照するポリシー名は、proxy-groups 内に存在している必要があります。スペースを含む名前は完全に一致させてください。
  • ノード名の重複:サブスクリプションを手動で統合した後、複数の proxies 項目が同じ名前になると、参照関係に異常が起きる場合があります。
  • フィールドの型が誤っている:port は数値、allow-lan は真偽値である必要があります。構造の異なるリストやオブジェクトにはしないでください。
  • ルールの順序が誤っている:MATCH はルールリストの末尾に置きます。通常、構文エラーにはなりませんが、後続のルールが永遠にマッチしなくなります。
  • providerファイルが無効:メイン設定を解析できても、参照先のプロキシ集合やルール集合が読み込めるとは限りません。ダウンロード失敗、パスの変更、ファイル内容の形式も確認してください。

最も簡単な切り分け方法は、最小構成に切り替えてカーネルを起動することです。次の設定にはノードやサブスクリプションを含めず、カーネルが解析を完了してローカルポートを待ち受けられるかだけを確認します。

mixed-port: 17890
mode: direct
log-level: info
allow-lan: false

proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

最小構成では起動でき、元の設定では起動できない場合、原因は元のYAML、サブスクリプションの生成内容、外部providerに絞られます。最小構成でも失敗する場合は、ポート、権限、カーネル本体を確認してください。テスト時は元ファイルのコピーを残し、唯一のサブスクリプション設定を最小構成で上書きしないでください。

第3優先:権限、サービスモード、TUNの起動失敗に対処する

通常のシステムプロキシは主にローカルTCPポートを待ち受けるため、必要な権限は比較的少なくて済みます。一方、TUNモードでは仮想ネットワークインターフェースの作成、ルーティングテーブルやDNSの変更が必要なため、権限エラーが起きやすくなります。典型的には、クライアント画面は正常でシステムプロキシも使えるのに、「設定」→「TUNモード」を開くとカーネルが終了し、ログに permission deniedoperation not permittedfailed to set route、仮想インターフェースの作成失敗などが表示されます。

Windows:まずサービスモードを確認する

  1. クライアントの「設定」→「サービスモード」または「システムサービス」を開き、サービスがインストール済みで実行中か確認します。
  2. サービスのインストールに失敗した場合は、クライアントを完全に終了してから、右クリックメニューの「管理者として実行」を選択します。これはサービスのインストールまたは修復に限って使用してください。
  3. services.msc を開き、該当するクライアントサービスの状態を確認します。サービス名はクライアントによって異なるため、画面の表示を基準にしてください。
  4. サービスを修復したら、通常ユーザーとしてクライアントを再起動してTUNをテストしてください。デスクトップ画面を常に管理者権限で実行するのは避けます。

古いクライアントをアンインストールした後に同種のサービスが残っていると、新しいクライアントが自分のサービスを登録できない場合があります。その場合は、まず旧クライアントのサービス削除機能を使い、その後で現在のクライアントのサービスコンポーネントをインストールしてください。名前だけを見てシステムのネットワークドライバーを一括削除しないでください。VPN、仮想マシン、コンテナのネットワークに影響するおそれがあります。

macOS:ネットワーク拡張機能とシステム認証を確認する

TUNやシステム拡張機能を初めて有効にするとき、macOSで管理者の確認を求められる場合があります。「システム設定」→「プライバシーとセキュリティ」でブロックされたコンポーネントの通知を確認し、「システム設定」→「ネットワーク」→「VPNとフィルタ」で関連するネットワーク設定を確認してください。アプリを「アプリケーション」フォルダーへ移動してから起動すると、一時マウントされた場所から実行することで生じるパスや権限の変化を抑えられます。

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

AppImageを初めて実行する前に、実行権限を付与する必要があります。ファイルマネージャーのプロパティ画面で設定するか、次のコマンドを実行してください。

chmod +x ./Clash-Client.AppImage
./Clash-Client.AppImage

TUNに必要な権限は、クライアントのサービス設計によって異なります。mihomoをsystemdサービスで管理するクライアントもあれば、ネットワーク機能を個別に設定する必要があるクライアントもあります。まずはクライアントに用意されたサービスインストール機能を使い、GUI全体をrootで起動し続ける方法は避けてください。ログに /dev/net/tun が存在しないと表示された場合は、システムがTUNデバイスを提供しているか確認します。

ls -l /dev/net/tun
ip tuntap list
systemctl status NetworkManager

第4優先:カーネルファイルとバージョンの不一致を修復する

GUIクライアントとmihomoカーネルは別の層にあります。画面側のアップデートが成功しても、カーネルファイルが正しく置き換えられたとは限りません。セキュリティソフトによる隔離、ディスク書き込みの中断、古いプロセスによるファイルロック、異なるアーキテクチャのバイナリへの手動置換などにより、「カーネルを起動」の段階で失敗することがあります。ログにはファイルが見つからない、実行が拒否される、異常な終了コードが返る、x64システムでARM64ビルドを使っているといった症状が現れます。

システムのアーキテクチャを確認する

  • Windowsでは「設定」→「システム」→「システム情報」→「システムの種類」でx64またはARM64を確認します。
  • macOSでは「Appleメニュー」→「このMacについて」でチップを確認します。Appleシリコンはarm64、Intelプロセッサはx64に対応します。
  • Linuxでは uname -m を実行します。x86_64 はx64、aarch64 はARM64に対応します。

クライアントに「設定」→「カーネル」→「再ダウンロード」または「アップデートを確認」がある場合は、まず内蔵機能を使用してください。画面を開けない場合は、システムのアーキテクチャに合う完全なクライアントパッケージを再インストールします。インストール前にクライアントとmihomoを終了し、置換中のファイルを古いプロセスが使用しないようにしてください。カーネルだけをコピーする場合も、クライアントが対応するAPIや設定フィールドを考慮する必要があります。バージョン差が大きいと、フィールドを認識できないことがあります。

mihomoのバージョンはターミナルから直接確認できます。バージョン情報が正常に表示されれば、少なくともファイルを実行できることが分かります。

mihomo -v

ターミナルに形式エラーや実行不能と表示された場合は、まずアーキテクチャを確認します。ファイルが存在しないと表示された場合は、クライアント設定に記録されたカーネルパスを確認してください。プロセス起動直後に終了する場合は、最小構成でテストし、「カーネル本体の問題」と「設定読み込みの問題」を切り分けます。

第5優先:システムコンポーネントを補完し、アプリデータをリセットする

一部のWindowsクライアントはWebView2で画面を表示し、別のクライアントはElectronなどのデスクトップランタイムを使用します。ウィンドウがまったく表示されない、画面が透明になる、イベントビューアーにWebViewの読み込み失敗が記録される場合は、「設定」→「アプリ」→「インストールされているアプリ」でMicrosoft Edge WebView2 Runtimeの有無を確認してください。クライアントのインストール手順でVisual C++ 2015–2022 Redistributableが明記されている場合は、アプリのアーキテクチャに合うx64またはARM64版もインストールします。

Windowsの「イベント ビューアー」→「Windowsログ」→「Application」で、強制終了した時刻のエラーを確認できます。「障害が発生しているアプリケーション名」「障害が発生しているモジュール名」「例外コード」を重点的に記録してください。障害モジュールがクライアント自身の実行ファイルを指している場合は、まずクライアントを再インストールします。WebViewやシステムランタイムを指している場合は、該当コンポーネントを修復してください。

アプリデータを安全にリセットする

ポート、設定、権限、カーネル、ランタイムに問題がないのに、読み込み画面でクライアントが強制終了する場合は、新しいアプリデータフォルダーでテストできます。プログラムを完全に終了し、元のデータフォルダー名を日付付きのバックアップ名に変更します。たとえば clash-clientclash-client-backup-20260818 に変更してから再起動します。クライアントが初期データを生成します。

  1. 新しいデータフォルダーで起動できる:旧フォルダー内の画面設定、データベース、キャッシュに異常がある可能性があります。
  2. 新しいデータフォルダーでも強制終了する:インストールファイル、システムコンポーネント、グラフィック描画層に原因がある可能性が高くなります。
  3. サブスクリプションを戻すときは設定ファイルだけを読み込み、旧フォルダー全体をすぐに上書きしないでください。
  4. 項目を1つ戻すたびに再起動し、どのファイルで問題が再発したか確認します。

アップデート後に問題が発生した場合は、ポータブル版とインストール版が同時に残っていないかも確認してください。2つのコピーが異なるデータフォルダーを読み込みながら、同じポートやシステムプロキシ設定を共有している可能性があります。使用するインストールを1つに決め、古いショートカットを整理し、「タスク マネージャー」→「スタートアップ アプリ」で現在のクライアントだけが自動起動に設定されていることを確認します。

症状別の完全な修復手順

ケース1:アイコンをクリックしてもウィンドウがまったく表示されない

  1. 10秒待ち、「タスク マネージャー」または「アクティビティモニタ」でプロセスが存在するか確認します。
  2. クライアントとmihomoの残存プロセスを終了し、1回だけ再起動します。
  3. システムイベントログを確認し、WebView2、ランタイム、アプリモジュールのエラーかどうかを確認します。
  4. アプリデータフォルダーの名前を変更してバックアップし、初期データで起動します。
  5. それでも失敗する場合は、x64またはARM64に合うクライアントを再インストールします。

ケース2:画面は開くが、カーネルが常に「停止」と表示される

  1. 「ログ」ページで最初に出たerrorの記録を確認します。最後の行だけを見ないでください。
  2. 789078919090、または設定で指定されている実際のポートを確認します。
  3. mihomo -t -f で現在のYAMLを検証します。
  4. mixedポートを 17890 にした最小構成でテストします。
  5. mihomo -v を実行し、カーネルファイルとシステムアーキテクチャを確認します。

ケース3:TUNモードだけ開けない

  1. まずTUNを無効にし、通常のシステムプロキシが起動できるか確認します。
  2. Windowsではクライアントのサービスモードを修復し、macOSではネットワーク拡張機能を確認し、Linuxでは /dev/net/tun を確認します。
  3. 他のVPN、仮想ネットワークツール、別のプロキシクライアントを終了してから再テストします。
  4. ログにあるルーティング、DNS、インターフェースのエラーを確認し、具体的なインターフェース名を記録します。
  5. サービスを修復したらシステムを再起動し、ネットワーク制御ツールは1つだけ有効にします。

ケース4:サブスクリプション更新直後に強制終了またはカーネル終了が起きる

  1. 直前に使えていた設定へ戻し、自動サブスクリプション更新を一時停止します。
  2. 新しいYAMLのインデント、フィールドの型、プロキシグループの参照を確認します。
  3. メイン設定、proxy provider、rule providerを個別にテストします。
  4. 失敗した一時ダウンロードファイルを削除してから、もう一度更新します。
  5. サブスクリプションが生成したフィールドを、現在のmihomoのバージョンがサポートしていることを確認します。

起動復旧後にプロキシの状態を確認する

クライアントが開くことと、ネットワーク制御が復旧していることは同じではありません。起動後はまずログで設定の読み込み完了とプロキシポートの待ち受け開始を確認し、「プロキシ」ページでプロキシグループを選択します。続いて「設定」→「システムプロキシ」でシステムプロキシを有効にするか、サービスが正常なことを確認してからTUNだけを有効にしてください。設定、DNS、TUN、ルールモードを同時に変更すると、新しい問題が起きたときに原因を特定しにくくなります。

まず、直接接続するサイトとプロキシルールを通るサイトを1つずつ開き、ログに表示されるルールのマッチ結果とプロキシグループ名を確認します。画面は正常なのにすべてのリクエストが失敗する場合は、ノードの可用性、サブスクリプションの有効期限、DNS解決、ルールのマッチングを確認してください。クライアントの再インストールを繰り返す必要はありません。

復旧確認項目 合格基準
クライアント画面 連続2回の起動テストで、毎回安定してメイン画面が表示される
カーネルの状態 ログに設定の読み込み完了が表示され、プロセスが60秒以上継続して動作する
ポートの待ち受け 実際の待ち受けポートがクライアントの表示値と一致する
ルールモード 直接接続とプロキシ経由のリクエストが、それぞれ想定したルールにマッチする
TUNモード 仮想インターフェースの確立後、ルーティングとDNSのログに継続的なエラーが出ない
再起動テスト システム再起動後も正常に起動し、2つ目のインスタンスが作成されない
対応するクライアントを探す プラットフォーム別にダウンロードページへ