なぜクライアントは起動直後にクラッシュするのか
Clash系クライアント(Clash Verge、Clash Meta クライアント、mihomo カーネルをベースにした各種 GUI ラッパーを含む)は構造上2層に分かれている。上層は画面表示・システムトレイ・サブスクリプション管理を担うクライアントプロセス、下層は実際の通信転送を行うカーネルプロセス(通常は mihomo、あるいはその前身の Clash Premium)だ。起動時のクラッシュはどちらの層でも発生し得るが、原因はまったく異なる——クライアント側のクラッシュはインストール破損・依存ライブラリの欠落・システム権限の問題が多く、カーネル側のクラッシュはほぼ必ず設定ファイル・ポート競合・残留プロセスの3種類のどれかに原因を追跡できる。
再インストールに手を出す前に、「画面自体が開かない」のか「画面は開くが接続した瞬間に落ちる」のか「自動起動後に一瞬で消える」のかをまず切り分けよう。この3パターンはそれぞれ調査の道筋が完全に異なり、闇雲なアンインストール・再インストールでは根本原因は解決せず、次の更新で同じ症状が再発しがちだ。
ステップ1:ログを確認する(推測しない)
ほぼすべてのクラッシュの一次情報はログに記録されている。この手順を飛ばして「クラッシュ 対処法」を検索するだけでは時間の無駄になる。ログは大きく2種類ある——クライアント自体の動作ログと、カーネルが出力する接続ログだ。
- Windows:クライアントのログは通常ユーザーディレクトリ内の
AppData\RoamingやAppData\Localにあるプロダクト名のフォルダに保存され、サブディレクトリ名には大抵logsが含まれる。カーネルのログは設定ディレクトリ内のlogsサブフォルダに日付単位で保存される。 - macOS:クライアントのログは多くが
~/Library/Logs/内のプロダクト名フォルダに落ちる。「コンソール」アプリを開いてプロセス名でフィルタすれば、クラッシュ時にシステムが出した例外スタックも確認できる。
最新のログを開き、次の3種類のキーワードを重点的に探す。
yaml: lineまたはunmarshal—— 設定ファイルの構文または型のエラー。bind: address already in use—— ポートが競合している。panicまたはfatal error—— カーネルのランタイムクラッシュで、大抵コールスタックが伴う。
該当のエラー文をそのままコピーしておけば、残り3ステップはエラー種別に応じて対処するだけで済み、ログ全体を読み通す必要はない。
time="2026-05-20T21:14:02+08:00" level=fatal msg="Parse config error: yaml: line 47: mapping values are not allowed in this context"このようなエラーは設定ファイルの47行目付近に問題があることを示している。多くはインデントが1文字ずれている、あるいはコロンの後にコロンを余分に打っているだけで、クライアント本体に問題があるわけではない。
ステップ2:キャッシュと残留カーネルプロセスを整理する
ログに明確な設定エラーが見当たらないのに、クライアントが途中で消えてしまう場合、ローカルのキャッシュファイルが破損しているか、前回の異常終了で残ったカーネルのゾンビプロセスがリソースを握っている可能性が高い。対処方法は以下の通り。
- まず OS のタスクマネージャー(Windows)またはアクティビティモニタ(macOS)でカーネルプロセス名(一般的には
mihomo、clash-meta、clash)を検索し、すでに動作中のインスタンスがあれば手動で終了させてからクライアントを起動する。 - クライアントを終了させた状態で、設定ディレクトリ内のキャッシュファイル(通常
cache.dbのような名前、サブスクリプションのyamlファイルは削除しないこと)を削除する。この種のキャッシュ破損はアップデート後のクラッシュでよくある原因だ。 - クライアントに「パネルキャッシュのリセット」や「デフォルト設定に戻す」機能があれば、手動でファイルを削除するより画面上のリセット機能を使うほうが安全で、サブスクリプション情報を誤って消すリスクが少ない。
- クライアントを再起動し、正常に動作するか確認する。
ステップ3:ポートが競合していないか確認する
Clash系クライアントは起動時にいくつかのローカルポートをバインドする必要がある——HTTP/Mixed プロキシポート(デフォルト値の例:7890)、コントロールパネルポート(デフォルト値の例:9090)、そして TUN モード有効時の仮想NIC関連ポートだ。これらのポートが他のプログラムに既に使われていると、カーネルプロセスはそのまま起動に失敗し、クライアント画面が一瞬で消える、あるいは「接続中」のまま止まる症状として表れる。
確認方法:
- Windows:コマンドプロンプトを開き、
netstat -ano | findstr 7890(7890 は実際の設定ポートに置き換える)を実行する。出力があればそのポートは既に使用中で、最後の列のプロセス PID をメモし、タスクマネージャーで該当プロセスを確認して終了するか判断する。 - macOS:ターミナルを開き、
lsof -i :7890を実行すると、同様にそのポートを使用しているプロセス名と PID が確認できる。
ポート競合のよくある原因は、Clash系クライアントを2つ同時にインストールしている(新旧バージョンが完全に削除されていない)、他のプロキシツールが同時に動作している、あるいは前回のカーネルプロセスが正常終了せずゾンビプロセスとしてポートを握り続けている、などだ。原因を特定したら不要なプロセスを終了するか、設定ファイル内の port、external-controller を別の空きポートに変更して保存し、再起動する。
mixed-port: 7891
external-controller: 127.0.0.1:9091ステップ4:設定ファイルの構文を検証する
YAML 形式はインデントやコロン後のスペースに非常に敏感で、手動で設定を編集したり異なる出典のルールを結合したりすると、構文エラーが入り込みやすい。ログに表示された行番号を確認するだけでなく、以下の方法でも事前にセルフチェックできる。
- 各行のコロンの後にスペースが1つ入っているか確認する。YAML では
key: valueの間にスペースが必須で、key:valueと書くと単なる文字列として解析され失敗する。 - インデントがスペースで統一されているか確認する。Tab とスペースを混在させず、同じ階層のインデントスペース数は完全に一致させる。
proxy-groupsで参照しているプロキシ名がproxiesリストに実在するか確認する。スペルが一致していないと参照先が見つからず、クライアントによってはエラー表示なしで即クラッシュすることがある。- 設定がサブスクリプションリンクから自動生成されたものなら、まずクライアント内蔵の「設定検証」や「構文チェック」機能を一度試してみる。多くのGUIクライアントは設定画面にこの入口を用意している。
最終的にサブスクリプション提供元から配布された設定自体に問題があると分かった場合は、一時的に動作確認済みの古い設定に切り替え、クライアント自体に問題がないことを確認したうえで提供元に問い合わせるとよい。
Windows と macOS のクラッシュ事例対照表
| 症状 | Windows でよくある原因 | macOS でよくある原因 |
|---|---|---|
| アイコンをクリックしても反応がなく、画面が全く表示されない | インストールディレクトリのファイルがセキュリティソフトに誤削除・ブロックされている。再インストールして信頼リストに追加する | アプリが「アクセシビリティ」または「ネットワーク拡張機能」の権限を得ていない。システム設定で手動許可する |
| 画面が開いて数秒で自動終了する | キャッシュファイルの破損、または旧バージョンの残留ファイルとの衝突 | Gatekeeper が未署名コンポーネントをブロックしている。初回実行時は「プライバシーとセキュリティ」で許可が必要 |
| 「接続」をクリックまたはサブスクリプション読み込み後にクラッシュ | 設定ファイルの構文エラーまたはポート競合 | 設定ファイルの構文エラーまたはポート競合(OSに依存せず両者共通) |
| TUN モード有効化後にクラッシュ | 仮想NICドライバが正しくインストールされていない。管理者権限で再インストールが必要 | システム拡張が承認されていない。「プライバシーとセキュリティ」で手動許可後に再起動が必要 |
| 自動起動後に姿が見えなくなる | 自動起動項目の起動順序がネットワークサービスの準備より早く、カーネルのポートバインドが失敗する | ログイン項目の権限が不完全。古いログイン項目を削除して再登録することを推奨 |
それでも解決しない場合の最終チェック順序
上記の4ステップをすべて実行しても問題が残る場合は、以下の順序で最終確認を行うと大半の残存ケースをカバーできる。
- ダウンロードしたインストーラーとシステムアーキテクチャが一致しているか確認する。Windows で ARM デバイスに x64 版を入れた、macOS で Intel チップに Apple Silicon 専用ビルドを入れた、といったケースは起動異常を引き起こす。
- 完全にアンインストールした後、残留した設定ディレクトリを手動で削除し(事前にサブスクリプションリンクを必ずバックアップ)、最新版を再インストールする。バージョン間のフィールド不整合を避けられる。
- セキュリティソフトやファイアウォールを一時的に無効化して対照テストを行う。無効化すると正常に起動する場合、セキュリティソフトのリアルタイム保護がカーネルプロセスをブロックしていることを示す。クライアントをホワイトリストに追加する必要がある。
- サードパーティ経由でインストーラーを入手した場合は、公式ダウンロード経路から改めて取得し直すことを推奨する。インストーラー自体の改変・破損による動作異常を避けられる。