Clash 起動時のクラッシュ対策：設定ファイルのエラー、ポート競合、権限問題

Clashクライアントの起動直後に終了する場合、原因は一つとは限りません。GUI、mihomoまたはClashコア、設定ファイル、リスニングポート、TUNコンポーネントが順番に初期化されるため、どこか一つでも失敗すると、ウィンドウが一瞬表示されて消える、トレイアイコンが消える、数秒後にプロセスが終了するといった症状が起こります。何度もダブルクリックするだけでは新しい情報は得にくいため、まず終了した層を切り分けるのが正しい手順です。

GUIのクラッシュ、コアの終了、バックグラウンドプロセスを切り分ける

起動時の症状は、まず3種類に分けられます。1つ目はウィンドウがまったく表示されず、タスクマネージャーやアクティビティモニタにもプロセスがないケースです。アプリファイル、実行権限、システムのセキュリティ警告を確認します。2つ目はGUIが表示された直後に閉じるケースで、設定の読み込み失敗やGUI自体のデータ破損がよくある原因です。3つ目はウィンドウだけ消えてバックグラウンドプロセスが残るケースです。トレイに最小化されているだけの場合もあれば、古いプロセスが新しいインスタンス用のポートを占有している場合もあります。

60秒で初期判断を行う

1. 確認中も通信が使用不能なポートへ流れ続けないよう、システムプロキシとTUNモードを無効にします。
2. タスクマネージャー、アクティビティモニタ、またはシステムモニターを開き、名前にClash、mihomo、または該当クライアント名を含む残留プロセスを終了します。
3. クライアントを再起動し、プロセスがどの程度継続するか確認します。2秒未満で終了する場合は実行権限とアプリファイルを優先して確認し、2～10秒後に終了する場合は設定とポートを優先して確認します。
4. クライアントのデータディレクトリにあるログを確認します。GUIを一時的に開ける場合は、「設定」→「ログ」または「設定」→「実行ログ」からログレベルを一時的にinfoへ変更します。
5. GUIにログが残っていない場合は、ターミナルからコアを直接実行し、設定テストを行ってエラー出力を画面に残します。

設定ファイルのエラー：まずYAMLをテストし、最小構成に戻す

Clashとmihomoはリスニングポートを作成する前にYAML設定を読み込みます。インデントの誤り、フィールド型の不一致、不完全なルール形式、存在しないノードを参照するプロキシグループなどがあると、コアが直接終了することがあります。サブスクリプションを更新した直後、または設定を手動編集した後にクラッシュし始めた場合は、最初に設定を確認してください。

よくあるYAMLエラー

• Tabでインデントしている。YAMLではスペースを使い、同じ階層のフィールドは同じ幅でインデントします。
• コロンの後にスペースがない。たとえば mixed-port: 7890 を mixed-port:7890 と記述している。
• ルールにポリシー名がない。たとえば DOMAIN-SUFFIX,example.com だけを記述し、最後のプロキシグループを指定していない。
• proxy-groups が存在しないノードやグループ名を参照している。特にノード名を変更した後、グループのメンバーを更新していない場合に起こります。
• Webページからコピーした際に全角記号が混ざり、英語のコロン、カンマ、引用符が置き換わっている。
• mihomo専用フィールドを古いClashコアに読み込ませており、コアが現在の設定構造を認識できない。

ターミナルで設定をテストする

mihomoでは -t で設定をテストし、-f でファイルを指定できます。WindowsではコアのあるディレクトリでPowerShellを開き、macOSとLinuxではターミナルで該当ディレクトリへ移動します。以下のコマンドは設定をテストするだけで、プロキシサービスを常時起動しません。

# Windows PowerShell
& ".\mihomo.exe" -t -f ".\profiles\config.yaml"

# macOS または Linux
./mihomo -t -f ./profiles/config.yaml

# 旧版Clashコアを使用する場合
./clash -t -f ./profiles/config.yaml

出力に具体的な行番号が含まれている場合は、その行と直前の3～5行を確認します。YAMLパーサーは次のフィールドを読み込んだ時点で、前の構造の誤りを検出することがよくあるため、エラー行が問題の開始位置とは限りません。構文テストに通ってもクライアントが終了する場合は、プロキシグループが空、providerのダウンロードに失敗、ルールセットのパスを読み取れないといった実行時エラーがないか確認します。

最小構成で問題の範囲を切り分ける

元のファイルを直接何度も編集しないでください。まず元の設定をコピーし、ポート、モード、空のルールだけを含む一時設定を作成します。この設定で、コアが基本的な起動を完了できるか確認できます。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

最小構成で起動できる場合、コアファイルと基本権限はおおむね正常で、問題は元のサブスクリプションまたはカスタム部分に絞れます。次に dns、proxy-providers、rule-providers、tun の順に各セクションを戻し、毎回1つだけ追加して再テストします。最小構成でも起動できない場合は、ポート、権限、コアファイルを確認します。

7890番ポートが使用中：数字を変えるだけでなく、プロセスを特定する

mixed-port: 7890 は、Clashが7890番でHTTPとSOCKSのプロキシ接続を同時に受け付ける設定です。古いインスタンスが終了していない、別のプロキシソフトが動作している、システムサービスがそのポートをリッスンしているといった場合、新しいコアは address already in use、bind failed などのエラーを出します。GUIクライアントによってはエラーが表示されず、起動時のクラッシュに見えることもあります。

Windowsで7890番ポートを確認する

PowerShellで以下のコマンドを実行します。1つ目はポートを使用しているプロセスIDを返し、2つ目はそのIDからプログラム名を確認します。

Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue
Get-Process -Id 4321

例の 4321 を、1つ目のコマンドに表示されたOwningProcessの値へ置き換えます。システム標準のコマンドでリスニング項目を確認することもできます。

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

macOSとLinuxで7890番ポートを確認する

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

lsof はmacOSと多くのLinux環境で利用でき、ss はLinuxでよく使われます。使用中のプロセスが古いClashまたはmihomoであることを確認したら、まずクライアントから通常終了します。終了できない場合のみ、該当するPIDを終了します。名前の不明なシステムサービスをいきなり終了せず、実行ファイルのパスと用途を先に確認してください。

別のポートへ変更する場合は3か所をそろえる

7890番を別のプログラムに割り当てる必要がある場合、Clashのmixed-portを7893に変更できます。ただし、設定、クライアントの設定、システムプロキシをすべて一致させる必要があります。

1. 設定ファイルで mixed-port: 7893 を指定します。
2. 「設定」→「パラメータ設定」→「ポート」を開き、混合ポートが7893になっていることを確認します。
3. システムプロキシを再度有効にし、HTTPとSOCKSのアドレスが 127.0.0.1:7893 を指していることを確認します。

7890番以外に、7891、7892、9090も確認してください。古い設定では7891をSOCKSポート、7892をリダイレクトポート、9090を外部コントロールインターフェースとして使うことがあります。必要なリスニング項目のどれか1つでも競合すると、コアが終了する場合があります。確認時は、現在のYAMLで実際に有効になっているポートを基準にします。

TUNモードの起動に失敗する：ドライバー、サービス、管理者権限を確認する

通常のシステムプロキシはローカルポートで待ち受けるだけですが、TUNモードでは仮想ネットワークインターフェースの作成、ルート変更、DNS処理も行うため、より高い権限が必要です。TUNを無効にするとクライアントが安定して動作し、「設定」→「ネットワーク」→「TUNモード」を有効にした途端に終了する場合、原因はドライバー、サービス権限、残留する仮想NICにあることが多いです。

Windows：サービスモードとWintunインターフェースを確認する

• まずクライアントを一度管理者として起動し、サービスまたは仮想NICの初期化を完了させます。その後も管理者権限が必要かどうかは、クライアントのサービスモードによって異なります。
• 「デバイスマネージャー」→「ネットワークアダプター」を開き、警告マークの付いたWintun、Mihomo、Clashの仮想インターフェースがないか確認します。
• クライアントに「設定」→「サービスモード」がある場合は、古いサービスを停止してからサービスを再インストールし、GUIとバックグラウンドサービスのバージョン不一致を避けます。
• WindowsのInternet Connection Sharingや、ほかの仮想ネットワークソフトが競合するルートを継続的に再作成していないか確認します。

ログに Access is denied、operation requires elevation と表示される場合、現在のプロセスに権限が不足しています。device already exists の場合は残留インターフェースを確認します。start tun failed だけで詳細がない場合は、ログレベルをdebugに変更して一度だけ再試行し、その後infoに戻します。大量のログが長期間生成されるのを防ぐためです。

macOS：ネットワーク拡張の許可を確認する

macOSクライアントで初めてTUNを有効にすると、ヘルパーサービスのインストールやネットワーク拡張の許可を求められることがあります。「システム設定」→「プライバシーとセキュリティ」を開き、下部に確認待ちのシステムソフトウェア通知がないか確認します。続いて「システム設定」→「ネットワーク」→「VPNとフィルタ」を開き、該当する構成が接続を繰り返していないか確認します。クライアント更新後にヘルパーサービスのバージョンが同期されていない場合は、古い補助プログラムを手動でコピーせず、クライアントの設定からサービスを再インストールします。

Linux：TUNデバイスと権限を確認する

まずシステムに /dev/net/tun が存在することを確認し、現在のアカウントにインターフェース作成とルート変更の権限があるか確認します。

ls -l /dev/net/tun
ip tuntap list
ip route
getcap ./mihomo

ターミナルから直接実行すると、ネットワーク管理権限が不足して operation not permitted と表示されることがあります。systemdサービスを使う場合は、サービスユニットのユーザー、能力制限、作業ディレクトリも確認します。デスクトップクライアントのTUNと別のmihomo systemdサービスを同時に起動しないでください。インターフェース名、DNSポート、ポリシールートを奪い合う可能性があります。

AndroidとiOS：VPNの許可を再設定する

モバイル端末のTUNは通常、システムのVPNインターフェースを通じて実現します。Androidでは「設定」→「ネットワークとインターネット」→「VPN」を開き、動作しない常時接続を削除してから再認証します。同時に、別のVPNアプリがシステム唯一のVPN経路を使用していないか確認します。iOSでは「設定」→「一般」→「VPNとデバイス管理」から構成状態を確認します。アプリが起動直後に接続してシステムに終了させられる場合は、バッテリー最適化とバックグラウンド動作制限も確認してください。

コアファイルがない、または破損している：パスを確認し、対応バージョンを再インストールする

GUIクライアントは通常、プロキシコアそのものではありません。起動時にmihomo、Clash、またはクライアントに付属するコアファイルを呼び出します。コアが移動した、アップグレードが中断した、アーキテクチャが合っていないといった場合、GUIが実行ファイルを見つけられなかったり、コア起動直後に異常終了ステータスを受け取ったりします。

まずクライアントが実際に呼び出しているコアを確認する

1. クライアントの「設定」→「コア」または「設定」→「バージョン情報」を開き、コア名、バージョン、ファイルパスを記録します。
2. パスで指定されたファイルが存在するか、ファイルサイズが明らかに0 KBになっていないか確認します。
3. ターミナルで mihomo -v または clash -v を直接実行し、バージョン情報が出力されることを確認します。
4. システムアーキテクチャを確認します。WindowsとLinuxではamd64またはarm64が一般的で、Appleシリコン搭載Macではarm64を選択します。

# Windows PowerShell
& ".\mihomo.exe" -v

# macOS または Linux
./mihomo -v
uname -m

バージョンコマンドもすぐ終了する場合は、サブスクリプションの編集を続けないでください。OSとCPUアーキテクチャに合うクライアントまたはコアを再インストールし、最小構成でテストします。Linuxでは実行権限も確認します。ファイルを読み取れても実行権限がない場合、ターミナルには Permission denied と表示されます。

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

クライアント更新後にクラッシュし始めた場合は、GUIとコアのインターフェース不一致も確認します。新しい設定の一部はmihomoの新しいフィールドに依存しており、古いコアでは読み取れません。逆に、古いGUIが新しいコアの返すデータを認識できない場合もあります。復旧時は同じリリースパッケージに含まれるGUIとコアを優先してインストールし、複数の配布元・バージョンのファイルを同じディレクトリに混在させないでください。

クライアントデータの破損：設定を残して実行ディレクトリを再構築する

設定テストに通り、ポートも空いていて、コアを単独実行できるのにGUIがクラッシュする場合、ウィンドウ状態、データベース、キャッシュ、クライアント自身の設定に問題がある可能性があります。この場合はアプリデータを再構築できますが、先にサブスクリプションURL、profiles設定、カスタムルール、スクリプトを必ずバックアップしてください。

安全な再構築手順

1. クライアントを完全に終了し、バックグラウンドにClashまたはmihomoのプロセスが残っていないことを確認します。
2. 設定ディレクトリをデスクトップへコピーしてバックアップします。現在のYAMLだけでなく、providerファイルやカスタムルールも復元が必要になる場合があります。
3. 元のデータディレクトリはすぐ削除せず、名前を変更します。たとえばディレクトリ名の末尾に -backup-20260722 を追加します。
4. クライアントを再起動し、プログラムにクリーンなデータディレクトリを生成させます。
5. まず動作確認済みの設定を1つだけインポートし、古いキャッシュをすべて一度にコピーしないでください。
6. 起動が安定したことを確認してから、サブスクリプションとカスタムルールを1つずつ戻します。

Windowsのアプリデータは通常、ユーザーのAppData配下にあります。macOSではユーザーライブラリのApplication Support、Linuxでは ~/.config にあることが一般的です。具体的なディレクトリ名はクライアントによって異なります。クライアントの「設定」→「設定ディレクトリ」またはログのhome directory、config directoryフィールドで確認し、別のクライアントのディレクトリ名を基準に削除しないでください。

OSごとに完全な復旧手順を実行する

Windowsの復旧手順

1. 「設定」→「ネットワークとインターネット」→「プロキシ」にある手動プロキシを無効にします。
2. タスクマネージャーで残留しているクライアントとmihomoのプロセスを終了します。
3. PowerShellで7890、7891、7892、9090がLISTEN状態か確認します。
4. ターミナルでコアのバージョンコマンドと設定テストコマンドを実行します。
5. 通常のプロキシが起動した後、サービスモードとTUN仮想インターフェースを確認します。
6. それでも失敗する場合はデータディレクトリをバックアップし、クライアントを再インストールして、検証済みの設定を1つだけ復元します。

macOSの復旧手順

1. 「システム設定」→「ネットワーク」で動作しないプロキシまたはVPN構成を無効にします。
2. アクティビティモニタで残留プロセスを終了し、lsof でリスニングポートを確認します。
3. ターミナルからコアを実行し、バージョンとYAML設定をそれぞれ確認します。
4. 「プライバシーとセキュリティ」の許可通知と、「VPNとフィルタ」のネットワーク拡張を確認します。
5. 通常のプロキシは正常でTUNだけ失敗する場合は、クライアント内でヘルパーサービスを再インストールします。

Linuxの復旧手順

1. デスクトップクライアントとsystemdサービスが同時に動作していないか確認します。
2. ss -lntp でポートを確認し、journalctl でサービスが終了した原因を確認します。
3. コアのアーキテクチャ、実行権限、作業ディレクトリ、設定ファイルの読み取り権限を確認します。
4. TUNを無効にしてmixed-portをテストし、その後 /dev/net/tun とルート変更権限を確認します。
5. 修復後は起動方法を1つだけ残し、2つのインスタンスが同じ設定を重複して読み込まないようにします。

修復後の確認リスト

クライアントがクラッシュしなくなっただけでは、プロセスが動作できることしか分かりません。プロキシ経路、DNS、ルールの動作も復旧していることを確認する必要があります。以下の順番で確認し、どこかで失敗したらその段階で止め、複数の項目を同時に変更しないでください。

• クライアントを少なくとも5分間継続して動作させ、ログにerrorが繰り返し表示されないことを確認します。
• 7890またはカスタムのmixed-portがリッスン状態で、プロセス名が現在のコアと一致していることを確認します。
• システムプロキシのアドレスがmixed-portと完全に一致していることを確認します。例：127.0.0.1:7890。
• ルールモードに切り替え、DIRECT、プロキシグループ、MATCHが想定どおりマッチすることを確認します。
• サブスクリプションを手動更新でき、更新後の設定チェックにも通ることを確認します。
• 通常のプロキシが安定してからTUNを有効にし、仮想インターフェース、デフォルトルート、DNSが正常か確認します。
• OSを再起動してもう一度テストし、古いサービスが7890を占有したり、コアを重複起動したりしていないことを確認します。

最も効果的な確認手順は、まずターミナルでエラー情報を残し、次に設定をテストし、その後ポートを確認し、最後にTUNとアプリデータを調べることです。設定エラーは通常、行番号から特定できます。ポート競合はPIDから特定でき、TUNの障害はTUNを無効にして切り分けられます。コアの問題はバージョンコマンドと最小構成で確認できます。毎回1つの変数だけを変更することで、どの操作が起動時のクラッシュを本当に解決したのか判断できます。