Clash クライアント起動時のクラッシュ・強制終了対処:設定ファイル残留・カーネル権限・依存パッケージ不足の3パターン

まずクラッシュがどの段階で起きているか判断する

「強制終了」というのは曖昧な言い方で、実際に対処する際はまずクラッシュが発生している具体的なタイミングを見極める必要があります。関わっているコンポーネントが段階によって全く異なるためです。Clash系クライアント(Clash Verge、Clash Meta系のGUI、あるいはmihomoカーネルを使う他の実装であっても)は基本的に3つの部分から構成されています:GUIプロセス(ウィンドウ描画と設定管理を担当)、カーネルプロセス(mihomoまたは旧版clashバイナリで、実際のプロキシ転送を担当)、そしてローカルの設定ファイルです。どの層に問題があっても表面上は「起動しない」「開いた瞬間消える」といった症状になりますが、切り分け方は全く異なります。

起動即終了:アイコンをクリックしてもプロセスがごく短時間で消え、タスクバーに一瞬表示されるだけの状態。多くはGUIプロセスが設定読み込み時に未捕捉の例外を出しているケースです。
カーネル起動失敗:ウィンドウ自体は開くが、プロキシのスイッチを入れた瞬間にエラーが出たりフリーズしたりする。特にTUNモードを有効化した瞬間に多く見られます。
画面が真っ白・描画異常:ウィンドウは開き、タイトルバーも正常に表示されるが、コンテンツ領域が空白、または一部の要素しか表示されない。多くはシステム側のグラフィック関連の依存パッケージ不足が原因です。

以下、この3パターンについてそれぞれ詳しく解説します。各パターンにログの確認方法と修正コマンドを載せているので、まず自分がどのパターンに当たるかを確認した上で、該当箇所だけ読めば十分です。

パターン1:起動即終了——設定ファイルの残留・破損

最も多いクラッシュのタイプで、クライアントをバージョンアップした直後に特に起きやすいです。新バージョンでは設定ファイルのフィールドが旧バージョンと完全には互換性がない場合があり、解析できないフィールドを読み込んだ時点でGUIプロセスがエラーダイアログを出さずにそのまま落ちてしまいます。これが「何の反応もなく消える」ように見える原因です。

まずログを確認する、ファイルを先に削除しない

多くのGUIクライアントは、実行ログとクラッシュログを設定ディレクトリ配下のlogsサブディレクトリに書き込みます。一般的なパスは~/.config/<クライアントのディレクトリ名>/logs/です。デスクトップアイコンからではなく、まず端末(ターミナル)からクライアントを起動してみましょう。そうすればクラッシュ情報がそのまま端末に出力されるため、ログファイルを別途探す必要がありません:

# 実際にインストールされているバイナリ名に置き換える。一般的には clash-verge や対応する AppImage 名
clash-verge 2>&1 | tee ~/clash-crash.log

端末の出力にyaml: unmarshal errors、panic: runtime error、あるいはfailed to initialize configのような文字列が出ている場合、権限や依存パッケージの問題ではなく、設定ファイルの解析段階でクラッシュしていることがほぼ確定します。

問題のある設定ファイルを特定して整理する

設定ディレクトリには通常「クライアント自体の設定」と「サブスクリプションから生成されるルール設定」の2種類のファイルが存在します。前者が壊れることは少なく、後者が問題の大半を占めます。以下の順序で対処してください:

まず設定ディレクトリ全体をバックアップし、整理しすぎて自作ルールを失わないようにする:cp -r ~/.config/<クライアントのディレクトリ名> ~/clash-config-backup
現在有効になっているサブスクリプション設定ファイルをディレクトリ外に移動し、次回起動時にクライアントが旧設定を見つけられず内蔵デフォルト値を使うようにする:mv ~/.config/<クライアントのディレクトリ名>/profiles/*.yaml /tmp/
クライアントを再起動し、正常に開くか確認する。開ければ、いずれかのサブスクリプション設定ファイルが原因だったと分かるので、/tmp/内のファイルを1つずつ戻しながら、どのファイルがクラッシュを引き起こしているか特定する。
yamllintやクライアント内蔵の「設定検証」機能を使ってそのファイルの構文をチェックする。よくある原因はインデントのズレ、全角コロンの混入、ルール項目の必須フィールド欠落など。

注意

「リセット」のつもりで~/.config配下のクライアントディレクトリを丸ごと削除しないでください。ウィンドウ位置、言語設定、サブスクリプション一覧など、本来残しておける情報も一緒に消えてしまいます。まずは疑わしい単一ファイルだけを移動し、影響範囲を最小限に絞りましょう。

パターン2:カーネル起動失敗——多くはTUN権限不足

ウィンドウは正常に開くが、システムプロキシやTUNモードを有効にした瞬間にフリーズ・エラー・クライアント自体の強制終了が起きる場合、問題の大半はGUI自体ではなく、カーネルプロセス(mihomo)とOSの間の権限のやり取りにあります。

TUNモードに追加権限が必要な理由

TUNモードは、システム内に仮想ネットワークインターフェースを作成し、すべての通信をまずこの仮想インターフェースに引き込んでからカーネルプロセスに処理させる仕組みです。この動作にはネットワークデバイスを作成する権限が必要で、一般ユーザー権限にはデフォルトでこの権限がありません。多くのクライアントはこれを2つの方法で解決しています:1つはmihomoバイナリにCAP_NET_ADMINケーパビリティを付与する方法、もう1つはroot権限を持つ補助プロセスを経由して処理を代行する方法です。どちらの仕組みも機能していない場合、カーネルプロセスはTUNデバイスの作成を試みた時点でエラーを出して終了し、それに連動してGUIプロセスもカーネル異常と判断して一緒にクラッシュします。

切り分けの手順

# 1. カーネルバイナリにケーパビリティが付与されているか確認
getcap /usr/lib/clash-verge/mihomo
# 期待される出力例:
# /usr/lib/clash-verge/mihomo = cap_net_admin,cap_net_bind_service+ep

# 2. 出力が空なら手動でケーパビリティを付与(パスは実際のインストール先に置き換える)
sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/lib/clash-verge/mihomo

# 3. カーネルプロセスがデバイス作成を拒否されたログがシステムログにあるか確認
journalctl --user -u clash-verge -n 100 --no-pager
dmesg | grep -i tun

もう1つよくあるケースは、システムにtunカーネルモジュールが入っていない場合です。特にミニマル構成のサーバー向けディストリビューションや、一部のカスタムカーネルで発生しやすいです:

# モジュールが読み込まれているか確認
lsmod | grep tun

# 読み込まれていなければ手動で読み込み、起動時に自動読み込みするよう設定
sudo modprobe tun
echo "tun" | sudo tee -a /etc/modules-load.d/modules.conf

ケーパビリティを付与し、tunモジュールの存在を確認した上でTUNモードを再度有効にすれば、カーネルプロセスは正常に起動するはずです。それでも失敗する場合は、カーネルプロセス自体のログ(通常は設定ディレクトリ内のcore.logや類似の名前で単独保存されています)を確認し、ポート競合やDNSハイジャック設定のミスなど、他の原因がないか確認してください。

パターン3:画面が真っ白——システム側のグラフィック依存パッケージ不足

このタイプのクラッシュは、ウィンドウ自体は開き、タイトルバーや枠は正常に描画されるものの、コンテンツ領域が完全に空白、または一部の要素だけ読み込まれた状態でフリーズするのが特徴です。多くのGUIクライアントはWebViewや類似の組み込みブラウザ描画コンポーネントで画面を構築しています。こうしたコンポーネントはシステム提供のグラフィックライブラリに依存しており、それが不足していたりバージョンが合わなかったりすると、描画レイヤーが目立ったエラーを出さずに静かに失敗します。

よく不足している依存パッケージ

webkit2gtkまたはlibwebkit2gtk:GTKベースのGUIクライアントの多くが画面描画に必須。ディストリビューションの更新で誤って削除されたり、バージョンがダウングレードされたりすることがあります。
libayatana-appindicatorまたは旧版のlibappindicator:システムトレイアイコンの表示を担当。不足していると、一部のクライアントがトレイ初期化の段階でそのままフリーズします。
グラフィックドライバ関連のOpenGL/Mesaライブラリ:仮想マシンや一部のミニマルなデスクトップ環境では削られていることが多く、GPUアクセラレーション描画に失敗する原因になります。

コマンドラインで不足パッケージを特定する

まず端末からクライアントを起動し、動的リンクライブラリのエラーが出ていないか確認します。この時点で何が不足しているか直接わかります:

ldd $(which clash-verge) | grep "not found"

出力にlibwebkit2gtk-4.1.so.0 => not foundのような行があれば、そのライブラリが実際に不足しているということなので、ディストリビューションに応じて対応パッケージをインストールします:

# Debian / Ubuntu
sudo apt install libwebkit2gtk-4.1-0 libayatana-appindicator3-1

# Fedora
sudo dnf install webkit2gtk4.1 libappindicator-gtk3

# Arch / Manjaro
sudo pacman -S webkit2gtk-4.1 libappindicator-gtk3

インストール後にクライアントを再起動すれば、ほとんどの場合白画面の問題は解決します。依存パッケージが揃っているのに白画面が続く場合は、一時的にGPUアクセラレーションを無効にして起動し、グラフィックドライバの互換性問題を除外してみてください:

WEBKIT_DISABLE_COMPOSITING_MODE=1 clash-verge

3パターンのログ確認場所一覧

切り分けの際に最も時間を浪費しやすいのは、どのログを見るべきか分からない状態です。下の表に3パターンのクラッシュに対応する確認先をまとめました。問題が起きたときはこの表を見ればよく、本文を最初から読み直す必要はありません。

クラッシュのタイプ	典型的な症状	優先して確認する場所
起動即終了	アイコンをクリックしても一瞬で消え、ウィンドウが表示されない	端末から直接起動して出力を確認;`~/.config/<クライアント名>/logs/`
カーネル起動失敗	ウィンドウは正常、プロキシ/TUN有効化時にフリーズ・エラー	`journalctl --user`;`dmesg`;カーネルプロセス独自のログファイル
画面が真っ白	ウィンドウの枠は正常、コンテンツ領域が空白	`ldd`で動的ライブラリを確認;端末起動時の段階的なエラー出力を確認

対処後に再発を防ぐには

クラッシュを解消したら、次のバージョンアップや機種変更時に同じ問題に再び遭遇する確率を減らすため、あわせて2つのことをしておくのがおすすめです。1つ目は、現在正常に動作している設定ファイルをアーカイブとしてバックアップし、設定ディレクトリの外に別途保管しておくこと。クライアントをバージョンアップする前に一度バックアップしておけば、フィールドの互換性問題が起きてもすぐに元に戻せます。2つ目は、現在のシステムで手動付与したケーパビリティや手動インストールした依存パッケージを記録し、簡単なシェルスクリプトにまとめておくこと。機種変更やOS再インストール後にそのスクリプトを一度実行するだけで済み、再度切り分けし直す時間を省けます。

#!/bin/bash
# 機種変更後にClashクライアントの動作に必要なシステム条件を一括で整える
sudo apt install -y libwebkit2gtk-4.1-0 libayatana-appindicator3-1
sudo modprobe tun
echo "tun" | sudo tee -a /etc/modules-load.d/modules.conf
sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/lib/clash-verge/mihomo

最後に一点:上記3パターンをすべて確認しても解決しない場合、クライアントのバージョンと現在のシステムカーネルまたはグラフィックスタックとの間に、より深い互換性の問題がある可能性が高いです。この場合、同じカーネルでもGUIの異なるクライアントに切り替える方が、同じバージョンを何度も再インストールするより効果的なことが多いです。