トラブルシューティング · mihomo の設定とクライアント

Clashのトラブルシューティングガイド

まずリクエストがどの段階で止まっているかを確認し、該当する設定を見直します。このページでは症状ごとの確認手順を紹介します。クライアントをインストール済みで、具体的な問題を特定したい場合にご活用ください。初めて使う場合は、まず入門ガイドのサブスクリプションの追加と接続手順を完了してください。その後も問題が続く場合は、該当する項目を確認します。

新しいデバイスでは、まず Clash Plus をお試しください。他のクライアントではメニュー名が異なる場合があります。インストーラーを変更する場合は、クライアントのダウンロードページでOSとアーキテクチャを確認してください。以下のコア設定例は mihomo を基準にしています。最終的な確認対象は、クライアントが生成した実行時設定です。

インターネットに接続できない：通常のネットワークとプロキシ経路を切り分ける

まずプロキシを無効にしてネットワークを確認する

どのウェブサイトも開けない場合は、ノードを次々に切り替えるのではなく、まず現在の接続を停止してください。クライアントのシステムプロキシとTUNを無効にし、OSのプロキシ設定が元に戻ったか確認します。クライアントが異常終了した場合、画面からスイッチが消えていてもシステムプロキシが解除されたとは限りません。ブラウザーでプロキシ拡張機能が有効になっていないことを確認し、普段プロキシなしで接続できるサイトにアクセスします。Wi-Fiでウェブ認証が必要かどうかも確認してください。

プロキシを無効にしても接続できない場合は、ルーター、ネットワーク認証、IPアドレスの取得、他のVPNの残存設定を優先して確認します。同じデバイスでスマートフォンのテザリングに切り替え、クライアント設定は変えずに比較してください。テザリングでは接続でき、元のネットワークでは接続できない場合、元のネットワーク環境に問題がある可能性があります。ネットワークアイコンが接続済みでも、インターネットが使えるとは限りません。通常は、デバイスがLANに接続したことを示すだけです。

明示的なプロキシ接続で問題の段階を切り分ける

通常のネットワークに接続できることを確認したら、コアを起動し、TUNを一時的に無効にして、ローカルプロキシの入口を1つだけ使います。以下の例では、実際の混合ポートを 7890 としています。Windowsでは一部のPowerShell環境で curl が別のコマンドとして扱われるため、curl.exe を使ってください。macOSとLinuxでは curl を使用できます。コマンドのポート番号は、クライアントの実行時設定に合わせてください。

curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

接続が拒否された場合、通常はローカルポートを待ち受けるプロセスがないか、クライアントのコア起動に失敗しています。ローカルプロキシへの接続後に上流への接続エラーが発生した場合は、ノードの項目を確認してください。接続先サーバーからHTTPレスポンスが返れば、アクセス拒否のステータスであっても、そのリクエストはリモート側まで届いています。単純にローカルプロキシが動作していないとは判断できません。このテストで確認できるのは、指定したアドレスへのそのリクエストだけです。すべてのウェブサイトに接続できることを示すものではありません。

接続ログで入口と出口を確認する

クライアントの接続画面を開いてフィルターを解除し、ブラウザーでページを再読み込みします。新しい接続が記録されない場合は、アプリが実際にプロキシを使用しているか、バイパスリストに該当していないか、ローカルポートの設定が正しいかを確認してください。接続が記録されている場合は、接続先ドメイン、適用ルール、プロキシグループ、最終的な出口の順に確認します。プロキシグループ名は中間の選択先にすぎません。リクエストが最終的にどこへ送られるかを確認するには、実際のノードまで展開してください。

ルールモードで一部のサイトだけ開けない場合、ルールのマッチング、DNS、またはサイト側の問題が考えられます。一時的にグローバルモードへ切り替えてテストする場合は、グローバル用のプロキシグループで利用可能な出口が選択されていることを確認してください。DIRECTのままではテストになりません。グローバルモードでは正常でルールモードでは失敗する場合は、両方のリクエストで適用されたルールを比較し、該当ルールを修正してからルールモードに戻してください。各モードの通信の違いは、ルール・グローバル・DIRECTモードの比較をご覧ください。

復旧時に複数の通信経路を重ねない

システムプロキシ、アプリ内プロキシ、TUNを同時に有効にしても必ずしも誤りではありませんが、原因の特定が難しくなります。まず入口を1つに絞って接続できる状態を確認し、その後、設定を1つずつ戻してください。特に、ノードのドメインへの接続が別のVPNに再度取り込まれていないか、上流プロキシの接続先が同じローカルポートになっていないかを確認します。転送がループすると、ログに接続が繰り返し記録される一方、接続先サイトからの応答がありません。

最後に、異なる2つのサイト、1つのブラウザー、1つのコマンドラインリクエストで再テストします。特定のサイトだけ失敗する場合は、ネットワーク全体の設定変更を止め、そのサイトのルール、証明書、アカウント制限、サービス状態を確認してください。クライアント終了後に再び接続できなくなる場合は、システムのプロキシ設定がローカルのまま残っていないか確認します。TUNを再度有効にしたときだけ問題が起きる場合は、サブスクリプションを再インポートするのではなく、ルーティング、DNSの取り込み、権限を重点的に確認してください。

ノードがタイムアウトする：名前解決・接続・ハンドシェイクを確認する

タイムアウトが発生する段階を確認する

ノードのタイムアウトには複数の原因があります。サーバーのドメインを名前解決できない、IPアドレスを取得できても通信を確立できない、接続後の暗号化ハンドシェイクで失敗するなど、問題の段階はさまざまです。まずノードを1つ手動で選び、自動切り替えによる影響をなくして実際にアクセスし、同じ時間帯のログを確認してください。速度テストの一覧で失敗していても、実際のウェブページにアクセスできるなら、ノードが無効とは限りません。

ログにドメインの名前解決失敗が記録されている場合は、まずノードサーバー側のDNSを確認します。接続拒否は、ポートでサービスが待ち受けていないか、明示的に拒否されている場合によく発生します。接続タイムアウトは、通信経路でのパケット破棄、ファイアウォール、サービスへの到達不能などが考えられます。証明書の検証エラー、認証失敗、非対応のプロトコルは、別の段階の問題です。エラーの種類が分かるよう全文を記録してください。末尾の「timeout」だけを抜き出すと、原因の特定に必要な情報が失われます。

サーバーのポートを確認し、疎通テストだけで結論を出さない

ノードのアドレスとポートは、自分の有効な設定から確認してください。公開検索サイトに入力しないでください。Windowsでは、PowerShellで以下の対話型コマンドを実行し、アドレスとポートを入力できます。入力内容はウェブページの例には保存されません。このコマンドで確認できるのはTCP接続だけです。プロキシプロトコル、アカウント、TLS、UDPサービスの検証はできません。まず明らかなTCP接続不可を切り分けるために使います。

$server = Read-Host "ノードサーバーのドメイン名またはアドレスを入力"
$port = [int](Read-Host "ノードのポート番号を入力")
Test-NetConnection -ComputerName $server -Port $port

UDPベースのプロトコルは、TCPテストの結果から正常かどうかを判断できません。TCPの疎通に成功しても、接続先が別のサービスである可能性があります。反対に、サーバーがICMPを拒否していると、pingに応答しなくてもプロキシポートは利用できる場合があります。ノードのドメインが複数のアドレスを返す場合は、クライアントが実際にどのアドレスへ接続しているかも確認してください。IPv4とIPv6で到達性が異なることがあり、別のデバイスで成功しても同じ経路を使っているとは限りません。

プロトコルに応じて認証情報と時刻を確認する

サブスクリプションを更新した直後に一部のノードだけ失敗する場合は、ダウンロードに成功しただけでなく、現在の設定に反映されているか確認してください。パスワード、ユーザーID、暗号方式、トランスポートの種類、TLSパラメーターはサーバー側の設定と一致している必要があります。ネット上の記事を参考に適当に項目を変更したり、異なるプロトコルの設定項目を流用したりしないでください。クライアントに設定をインポートできても、ファイル構造が受け入れられたことを示すだけで、サーバーが認証情報を認めたとは限りません。

システムの日付、タイムゾーン、時刻同期の異常により、証明書がまだ有効でない、または期限切れと判断される場合があります。自動時刻合わせを有効にしてから、再接続してください。証明書検証を無効にして問題を長期的に回避しないでください。ドメイン名、証明書、中間ネットワークの問題が隠れてしまいます。設定にあるサーバーのドメイン名とTLSのサービス名は異なる場合があります。変更可能かどうかはサービス提供元の案内に従ってください。IPアドレスに直接変更すると、元のハンドシェイク条件が崩れることもあります。

比較テストで原因の範囲を絞る

同じノードでネットワークを変える、同じネットワークでノードを変える、同じ設定を対応クライアントで試す、の順に確認してください。一度に変える条件は1つだけにします。元のネットワークではすべて失敗し、テザリングでは正常な場合は、ネットワークの出口制限、UDPの可否、IPv6経路を確認します。どの環境でも1つのノードだけが失敗する場合は、サービス提供元に問い合わせてください。1台のデバイスではすべてのノードが失敗し、別のデバイスでは正常な場合は、端末のセキュリティソフト、時刻、コアとの互換性を確認します。

自動選択のプロキシグループでは、ヘルスチェックの結果によってノードが一時的に除外される場合があります。ヘルスチェック先が実際の用途を反映しているか、テストの通信経路が適切かを確認してください。テスト先自体が制限されていると、正常なノードがまとめて異常と表示されることがあります。復旧のためにチェック間隔を極端に短くしないでください。頻繁なチェックはリクエストを増やすだけで、サーバー側の障害は解決できません。ノードが実際に使えることを確認してから、自動選択に戻します。

サブスクリプションの更新に失敗する：取得・解析・反映を切り分ける

取得時と解析時のどちらで失敗したか確認する

サブスクリプションのインポートは、リモートコンテンツの取得、形式の解析、実行用設定の生成、設定の適用という複数の段階で行われます。画面にダウンロード失敗と表示された場合は、HTTPステータスまたは接続エラーを確認してください。設定形式のエラーが表示される場合は、少なくとも一部の内容を取得できているため、レスポンス本文を確認します。更新成功と表示されてもノードがない場合は、どの設定が現在有効になっているかを確認してください。問題ごとに原因が異なるため、何度も更新を繰り返すだけでは解決しません。

サービスサイトのトップページ、決済ページ、ブラウザーの共有URLではなく、サブスクリプションURL全体をコピーしていることを確認してください。コピー時の改行や前後の空白、チャットアプリによるクエリパラメーターの切り詰めで、リクエストが変わる場合があります。サブスクリプションURLにはアクセス権限が含まれることが多いため、機密情報として扱ってください。画面共有中に表示したり、オンライン変換ツール、公開の問い合わせフォーム、検索エンジンに貼り付けたりしないでください。漏えいした場合は、サービス側でURLを再発行してください。

レスポンス内容に応じて取得エラーを確認する

結果	まず確認する項目	対処方法
401 または 403	権限、アカウントの状態、アクセス制限	サービスの管理画面でURLと利用権限を確認する。
404	URLの期限切れ、またはコピー漏れ	サービス提供元からサブスクリプションURLを再取得する。
429	更新頻度とリクエスト制限	連続した再試行をやめ、サービス提供元の案内に従って待つ。
200だが解析できない	レスポンスがHTMLなど別形式になっていないか	サブスクリプションの形式とクライアントの互換性を確認する。

ステータスコードは確認の手がかりであり、最終的な原因を示すとは限りません。たとえばアクセス制御ページが正常なステータスを返していても、本文はログイン案内ということがあります。ブラウザーでURLを開けても、クライアントが取得できるとは限りません。ブラウザーではすでにログイン済みだったり、別のプロキシを使っていたり、必要なCookieが保存されていたりする場合があります。サービス提供元が明示的に対応しているクライアントのサブスクリプション機能を使い、ブラウザーのセッション情報を設定ファイルにコピーしようとしないでください。

YAMLとサブスクリプション形式の互換性を確認する

Clashの設定、ノードリスト、他のクライアント向けサブスクリプションは、同じ形式ではありません。エンコードされたノードURLのリストだけでは、完全なYAML設定としてそのまま動作しない場合があります。完全な設定には、プロキシグループ、ルール、DNSなどが含まれることがあり、クライアントがテンプレートで補完する場合もあります。インポート先が完全な設定を求めているのか、プロキシプロバイダーを求めているのか確認してください。拡張子の変更で形式を変換することはできません。

YAMLでよくあるエラーには、インデントにタブを使う、リストの階層がずれる、引用符を閉じ忘れる、同じトップレベルのキーを重複して定義する、といったものがあります。エラー行の前後も確認してください。パーサーが異常を検出した位置が、最初に間違えた箇所とは限りません。mihomoのローカル設定は、mihomoの検証コマンドでチェックできます。ここでの config.yaml は、現在のディレクトリにある検証対象のファイルです。実行前に、それが唯一のバックアップではないことを確認してください。

mihomo -t -f config.yaml

検証に成功しても、設定の構造と参照先をコアが受け入れられることを示すだけです。ノードのアカウントが有効であることや、すべてのルール用リソースを最新の状態に更新できることを保証するものではありません。不明なフィールドや非対応のプロキシ形式が表示された場合は、クライアントの外観上の名称だけでなく、同梱されているコアを確認してください。切り替える場合は、ダウンロードページでOSに合ったメンテナンス中のクライアントを選び、比較用に元の設定を残してください。

更新後に設定が実際に反映されたか確認する

サブスクリプションを更新したら設定一覧に戻り、正しい設定が有効になっていることを確認します。プロキシグループが古いノード名を参照していないかも確認してください。サービス側でノード名が変更されると、手動選択が無効になる場合があります。ローカルのオーバーライドが古いルールを残したり、新しいDNS設定を上書きしたりすることもあります。バックアップを取ったうえでオーバーライドを一時的に無効にして比較し、サブスクリプション自体の問題か、ローカルでのマージ処理の問題かを判断してから、変更する箇所を決めます。

複数のデバイスで同じサブスクリプションを使っていても、更新間隔、キャッシュ、テンプレートはクライアントごとに異なる場合があります。パソコンで更新できても、スマートフォンに同じ内容が適用されているとは限りません。サブスクリプションURLを公開せずに、ノード名と設定の更新時刻を比較してください。詳しくはパソコンとスマートフォンで設定を共有する方法をご覧ください。自動更新が復旧したら、手動での再試行を控え、レート制限による誤ったエラーを避けてください。

最後に、サブスクリプションの取得が現在利用できないプロキシに依存していないか確認します。クライアントで更新時のネットワーク経路を選べる場合は、通常のネットワークが使えることを確認したうえで、直接接続と利用可能な出口を比較してください。利用できるノードがないのに、失敗しているプロキシ経由でサブスクリプションのリクエストを強制しないでください。サービス提供元が指定する接続方法がある場合は、その案内に従い、仕組みの分からない変換サービスを重ねて使わないでください。

速度が遅い：初動・転送速度・安定性を分けて測る

どの操作が遅いのかを明確にする

ウェブページの表示が始まるまで時間がかかる、ダウンロード開始後の速度が遅い、動画再生中に何度もバッファリングする、といった症状は、それぞれ名前解決やハンドシェイク、継続的な転送速度、通信経路の不安定さなどが原因の可能性があります。まず遅くなる段階を記録し、それに合った方法でテストしてください。クライアントのノード一覧に表示されるレイテンシは、通常、短いリクエストによるものです。大容量ファイルのダウンロード速度とは異なり、特定の動画サイトやコードリポジトリの使用感をそのまま示すものでもありません。

普段使う接続先を1つ選び、近い時間帯に直接接続、固定したプロキシ出口、別のネットワークで比較してください。複数の速度テストを同時に実行すると、テスト自体が帯域を消費します。クラウドストレージの同期やシステムのダウンロードなど、バックグラウンドの処理を止め、Wi-Fiの電波状態も確認してください。ルーターに接続できていても、無線干渉が大きければ速度が低下します。プロキシノードに問題がないか、有線接続またはアクセスポイントの近くで比較してください。

合計時間ではなく、各処理にかかった時間を見る

以下のコマンドはローカルHTTPプロキシ経由でリクエストを送り、接続、ハンドシェイク、最初の1バイトを受信するまで、合計時間を出力します。これらはcurlが記録する累積時間であり、単純に足し合わせるものではありません。HTTPプロキシ経由でHTTPSトンネルを確立する場合、プロキシとのネゴシエーション時間が含まれることがあります。また、リモート側のドメイン名解決がローカルの名前解決時間に反映されるとは限りません。同じ条件で比較するのに適していますが、単独で特定のDNSサービスの性能を判断する用途には向きません。

curl.exe -o NUL -sS --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -w "connect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" https://example.com/

macOSとLinuxでは、curl.exe を curl に変更し、出力先の NUL を /dev/null に変更してください。小さなページを使ったテストは接続の確立状況を見るためのもので、最大帯域の測定には向きません。継続的なダウンロード速度を比較する場合は、信頼でき、テストが許可されたファイル配信元を選び、同じファイルを同じ時間帯に取得してください。接続先サーバーの速度制限も考慮します。1つのサイトの速度制限を、プロキシネットワーク全体の上限とみなさないでください。

プロキシグループの切り替えと接続の再利用を確認する

自動選択グループでは出口が頻繁に切り替わることがありますが、確立済みの接続は元のノードを使い続けます。切り替え直後にページを再読み込みしても、ブラウザーが古い接続を再利用し、画面上の選択と結果が一致しない場合があります。対象のページを閉じ、該当する接続を終了してから再テストしてください。常にすべての接続を終了するのは避けてください。ダウンロード、会議、その他の作業が中断されます。

同じ地域名でも回線が同じとは限らず、距離が近くてもネットワーク間の品質が良いとは限りません。比較時はプロキシグループ名だけでなく、最終的なノードを固定してください。特定のサービスだけ遅い場合は、地域制限、混雑、サーバーの応答を確認します。同じネットワークで複数の出口が遅く、スマートフォンのテザリングでは正常な場合は、分割ルールを次々に追加するのではなく、ローカルネットワーク、ISPの経路、他のトンネルソフトを優先して確認してください。

UDP、MTU、リソース使用量は慎重に確認する

一部のアプリはQUICなどのUDP通信を使用します。プロキシ経路でUDPがサポートされているかどうかが、使用感に影響する場合があります。ブラウザーの関連する実験的機能を一時的に無効にして比較することはできますが、プロトコルを恒久的に無効にする方法を一般的な高速化策としないでください。TCPは正常でUDPを使うアプリだけが不安定な場合は、ノードのプロトコル、クライアント設定、現在のネットワークでUDPが使えるかを確認してから、該当するルールやアプリの設定を調整します。

TUN環境で小さなウェブリクエストは正常なのに大きなデータ転送が止まる場合、パスMTUが関係している可能性があります。ただし、この症状だけで原因とは断定できません。まずサーバーの速度制限とパケットロスを確認し、元の設定をバックアップしてから、クライアントでサポートされている範囲内で1つずつパラメーターを変更してテストします。MTUをむやみに小さくするとパケット数が増え、転送速度が低下することもあります。企業ネットワークや複数のトンネルを重ねた環境では、ネットワーク管理者にも確認してください。

速度低下とともにCPU使用率が大きく上がった場合は、詳細ログ、頻繁なヘルスチェック、複数の設定更新処理が同時に動いていないか確認してください。接続数が増え続けている場合は、アプリの再試行が原因のこともあります。追加の処理を止め、まず1つのアプリで再テストします。リモートサービスや上流回線が原因と分かった後は、ローカルDNSの変更を続けないでください。DNSを調整しても、確立済み接続の継続的な転送帯域は改善しません。

DNSの問題：名前解決経路とFake-IPを確認する

端末側の名前解決とプロキシ側の名前解決を切り分ける

ブラウザーでドメインエラーが表示される場合、OSの名前解決、ブラウザーのセキュアDNS、クライアントのDNS、ノードサーバー側の名前解決経路などが関係している可能性があります。まず、解決できないのが接続先サイトのドメインか、ノードサーバーのドメインかを確認してください。ノードのドメインを解決できない場合、上流にはまだ接続できていません。接続先ドメインの問題であれば、プロキシの入口とDNSモードを確認します。すべての名前解決先を同じパブリックDNSに変更しないでください。

明示的なHTTPプロキシや、プロキシ側で名前解決するSOCKSを使う場合、接続先のドメイン名はプロキシ側で処理されることがあります。そのため、システムの名前解決コマンドが失敗しても、ブラウザーからプロキシ経由でアクセスできる場合があります。逆に、システムの名前解決に成功しても、クライアント内部のDNSが正常とは限りません。まずリクエストの経路を整理し、実際に使う入口からテストしてください。システムDNSの結果だけで、クライアント内部のDNSを判断しないでください。

Fake-IPの応答を理解する

Fake-IPモードではドメイン名にマッピング用のアドレスが割り当てられ、コアがその対応関係から元のドメイン名を特定して接続を処理します。予約済みアドレス範囲が表示されても、DNSが妨害されているとは限りません。まず、そのアドレスがクライアント設定のFake-IP範囲に含まれているか確認してください。アプリがそのアドレスをキャッシュしてコアを経由せずに直接接続すると、失敗する場合があります。モードを切り替えた後は接続を確立し直し、必要に応じて影響を受けるアプリを再起動してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - https://dns.alidns.com/dns-query

この設定例は項目間の関係を説明するものです。既存の設定にある dns ブロックへ統合してください。サブスクリプション全体をそのまま置き換えないでください。上流サーバーのアドレスは例です。実際に利用できるかどうかは現在のネットワークで確認してください。ドメイン名形式の暗号化DNSを上流に指定する場合、そのドメイン名自体を解決する必要があります。ブートストラップ用の名前解決は、使用中のコアのドキュメントに従ってください。社内ドメインには通常、社内のDNSサーバーが必要です。すべてをパブリックDNSに送らないでください。

特定のドメインに例外を設定する

LAN機器の検出、一部のゲーム、実際の名前解決結果の確認が必要なアプリでは、Fake-IPが適さない場合があります。まず問題のドメインを特定し、fake-ip-filter に追加して比較してください。フィルターを適用すると実際のIPアドレスが返されますが、最終的な通信が直接接続になるかどうかはルールで決まります。フィルターリストはDIRECT接続のリストではありません。すべてのドメインをフィルターに追加すると、このモードの主な利点が失われ、元の通信振り分けが変わる可能性もあります。

ブラウザー独自の暗号化DNSが有効だと、想定しているローカルDNSの経路を通らずに問い合わせる場合があります。原因を調べる間はシステムの名前解決を一時的に使い、問題が変化するか確認してから、使う方式を決めてください。TUNでDNSを取り込んでも、すべての暗号化DNSクエリを検出できるとは限りません。特にアプリ内蔵のHTTPSによる問い合わせは対象外となる場合があります。マッピングの仕組みについて詳しくは、Fake-IPとフィルターリストの解説をご覧ください。

名前解決経路に沿ってキャッシュを削除し、IPv6を確認する

まず設定が適用済みであることを確認してから、影響を受けた層のキャッシュを削除してください。設定が反映されていなければ、キャッシュを消しても一時的な変化しかありません。Windowsでは、以下のシステムコマンドでキャッシュを削除できます。ブラウザー、アプリ、クライアントに個別のキャッシュがある場合は、それぞれの画面から削除してください。macOSとLinuxではキャッシュの仕組みがシステムサービスによって異なるため、同じコマンドを何度も実行しないでください。

ipconfig /flushdns

同じドメインからIPv4とIPv6の両方が返される場合、アプリが到達できないアドレス種別を優先して試すことがあります。システムのIPv6ルート、ノードの出口、クライアントの名前解決設定を確認し、すぐにデバイス全体のIPv6を無効にしないでください。管理されたテストでアドレス種別ごとに比較し、実際に関係していると分かった場合は、クライアントがサポートする設定を調整します。名前解決の順序を変えた後は、接続を確立し直して結果を確認してください。

社内ドメインだけ解決できない場合は、検索サフィックス、社内DNSアドレス、接続中のネットワークが正しいか確認してください。企業VPNに接続すると、ドメインごとの名前解決設定が追加されることがあります。プロキシクライアントのDNS設定で一律に上書きすると、この仕組みが機能しなくなる場合があります。企業のポリシーを維持し、社内ドメインの名前解決とルーティングを適切に分けてください。トラブルシューティングの最後には、一般のウェブサイト、LAN機器、業務サービスをすべてテストし、インターネットを直した結果、社内ネットワークに接続できなくなる事態を防ぎます。

システムプロキシが動作しない：アプリの接続経路とTUNルートを確認する

アプリがシステムプロキシを参照しているか確認する

システムプロキシのスイッチは、OSが提供するプロキシ設定を変更するもので、すべてのプログラムにプロキシの使用を強制するものではありません。ブラウザーは通常この設定を読み込みますが、コマンドラインツール、ゲーム、コンテナ、一部のデスクトップアプリは独自のネットワーク処理を使う場合があります。入口が機能しているかどうかは、クライアントの接続ログで確認してください。アプリから接続がまったく記録されない場合は、アウトバウンドルールを調整する前に、そのアプリのプロキシ対応方式を確認します。

WindowsのユーザープロキシとWinHTTPの設定は別の入口です。一部のサービスは、ユーザー画面のプロキシ設定に従いません。macOSではネットワークサービスごとにプロキシが保存されるため、有線と無線を切り替えた後は、現在のサービスの設定を確認してください。Linuxでも、デスクトップ環境のプロキシ、環境変数、アプリ内の設定はそれぞれ異なります。1つのプログラムを動かすためにすべての入口へ同じ値を設定せず、そのプログラムが実際にどの設定を参照するか確認してください。

ポート、環境変数、バイパスリスト

クライアントの混合ポートを変更しても、アプリ内プロキシやターミナルの環境変数が以前のポートを参照したままの場合があります。現在の実行設定で実際のポート番号を確認してから、ローカルの待ち受け状態を調べてください。以下はWindowsとLinuxでの確認コマンドです。ポートが使用中の場合は、どのプロセスが使っているか特定してください。待ち受けているプロセスをまとめて終了しないでください。

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux
ss -lntp 'sport = :7890'

ターミナルの HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY はツールごとに異なる影響を与えますが、対応状況は統一されていません。変数の値に認証情報が含まれる場合があるため、表示や共有には注意してください。現在のターミナルで変数を変更しても、起動済みの他のプログラムには自動で反映されません。デスクトップアプリがターミナルの環境変数を引き継ぐとも限りません。バイパスリストに接続先ドメインが含まれていると、アプリが直接接続してクライアントのログに記録されない場合があります。

TUNには権限、ルート、適切な除外設定が必要

TUNは仮想ネットワークインターフェースで通信を取り込み、システムプロキシを参照しないアプリにも対応できますが、OSの権限とルート設定が必要です。まずクライアントの補助サービスや権限の許可が完了しているか確認し、仮想インターフェースが作成され、ルートが実際に設定されているか調べます。画面上では有効でも、ログに権限不足と表示される場合は、通信の取り込みに失敗しています。コンテナ、リモートデスクトップ、サーバー環境では特に注意してください。誤ったルート設定で管理用の接続が切れるおそれがあります。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

この例は、記載された項目に対応するmihomo環境向けであり、すべてのプラットフォームにそのまま適用できるわけではありません。クライアントの画面でTUN設定を生成し、上書きする場合があります。その場合は、指定された設定画面から変更してください。複数のネットワークインターフェース、仮想マシン、他のVPNがある環境では、出力インターフェースの自動検出を誤ることがあります。実際のデフォルトルートも確認してください。DNSポートを取り込んでも、すべての暗号化DNS通信を取り込めるとは限りません。

他のプロキシやネットワーク切り替え後の残存設定を確認する

ブラウザー拡張機能、別のVPN、企業のセキュリティソフト、プロキシクライアントが同時に動作すると、システムプロキシ、仮想ネットワークインターフェース、ルートを取り合うことがあります。診断時は、自分で停止できる追加ツールを一時停止し、企業の強制ポリシーは維持して、元の状態を記録してください。システムプロキシを制御する入口は1つだけにし、他のプロセスが設定を書き戻していないか確認します。スイッチを何度も切り替えて、別のプログラムと設定を奪い合わないでください。

Wi-Fiから有線への切り替え、スリープからの復帰、テザリングへの接続後は、デフォルトのネットワークインターフェースやゲートウェイが変わっている場合があります。ネットワーク切り替え後にだけTUNが動作しなくなる場合は、一度接続を切ってから通信の取り込みを再起動し、新しい接続ログを確認してください。再有効化で復旧するなら、システム全体を定期的に再起動するのではなく、インターフェースの検出方法とクライアントのログを確認します。macOSの権限に関する問題は、ネットワーク拡張機能とキーチェーンの設定方法をご覧ください。

検証では、システムプロキシに従うブラウザーと、以前はプロキシを使わなかったアプリを1つずつ確認してください。前者は正常で後者が失敗する場合、システムプロキシの経路は復旧していても、TUNやアプリ側の設定に問題が残っている可能性があります。最後にクライアントを終了し、通常のネットワークが復旧するかテストしてください。プロキシアドレスが解除され、仮想ルートが削除されたことを確認できて初めて、復旧手順が完了したと判断できます。信頼できないネットワークにローカルプロキシポートを長時間公開しないでください。

起動失敗・クラッシュ：画面、コア、設定を切り分ける

どのプロセスが終了したか確認する

クライアントのウィンドウが閉じる、タスクトレイのアイコンが消える、コアが停止することは、同じ状態ではありません。ウィンドウを閉じてもバックグラウンドで動き続けるアプリもあれば、画面は残っていてもコアがクラッシュしている場合もあります。タスクトレイ、タスクマネージャー、システムモニターを確認し、ローカルポートとログも調べてください。メインウィンドウが見えないからといって、何度も起動し直さないでください。複数のインスタンスがポート、設定ディレクトリ、補助サービスを取り合い、新たな起動問題を引き起こす可能性があります。

問題が起きるタイミングを確認してください。起動直後に終了する場合は、動作環境、権限、設定が関係していることがあります。設定をインポートした後に終了する場合は、設定内容やリソースを確認します。しばらく動作してから終了する場合は、メモリ、ディスク、ログの増加、特定の接続がきっかけになっていないか調べます。最後に正常だった操作と、その後に変更した内容を記録しておくと、すべてのデータを削除するより原因を特定しやすく、再現もしやすくなります。

OSのアーキテクチャとインストール環境を確認する

インストーラーはOSとプロセッサのアーキテクチャに合ったものを使ってください。Windows、macOS、Linuxではインストール方法が異なり、ファイル名が似ているだけで互換性があるとは限りません。macOSではApple SiliconとIntelを区別し、Linuxではディストリビューションのパッケージ形式、ランタイム、デスクトップ環境も確認します。プラットフォーム別ダウンロードページからClash Plus、または現在のシステムでメンテナンスされているクライアントを選んでください。古い記事に掲載された過去のインストーラーは使わないでください。

セキュリティソフトによる隔離、OSのアプリ制御、ファイルの実行権限が、起動を妨げている場合もあります。まずOSの具体的な警告を確認し、ファイルの入手元を確かめてから、OSの通常の手順で許可してください。セキュリティ機能を全体的に無効にしたり、正体の分からないサイトから不足コンポーネントをダウンロードしたりしないでください。企業のデバイスにインストール制限がある場合は、管理者に対応を依頼してください。ポリシーを回避すると補助サービスが正常に動作せず、後から通信の取り込みにも失敗する可能性があります。

バックアップを作成し、最小構成で起動する

設定の破損に対処する場合は、まずクライアントを終了し、データディレクトリをバックアップしてください。バックアップにサブスクリプションURLや認証情報が含まれる場合があるため、信頼できるローカルの場所に保存し、公開リポジトリに自動同期しないでください。その後、クライアントのリセット機能または新しい設定を使ってテストし、ディレクトリ全体を直接削除するのは避けます。最小構成で起動できたら、サブスクリプション、ルール用リソース、オーバーライドを少しずつ戻し、追加するたびに再起動して確認してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

この最小構成の例は、コアとローカルの待ち受けが動作するかを確認するためのものです。すべての通信をDIRECTで処理し、プロキシ出口は提供しません。テスト前にポートが使用中でないことを確認し、TUNを一時的に無効にしてください。この構成で正常に動作する場合は、元の設定にあるプロキシ形式、ルールプロバイダー、スクリプトによるオーバーライド、外部リソースを重点的に確認します。通常の設定に戻す前に、有効なサブスクリプションへ切り替えたことを確認してください。診断用のDIRECT設定を通常の動作状態と勘違いしないようにします。

ポート競合とリソース不足を切り分ける

ログにアドレスがすでに使用中と表示される場合は、該当ポートを待ち受けているプロセスを特定し、古いインスタンス、別のプロキシ、システムサービスのどれか確認してください。混合ポートを一時的に変更して検証できますが、アプリ側のプロキシ設定も同時に更新する必要があります。コントローラーポートとプロキシポートは用途が異なります。画面上の数値を1つ変えただけで、すべての競合が解消したと思わないでください。補助サービスに古い設定が残っている場合は、クライアントの手順に従ってサービスを再起動します。

起動後に徐々に動作が重くなる場合は、ディスクの空き容量、ログファイルの増加、ルール用リソースの規模、接続数を確認してください。デバッグログを長時間有効にすると、ディスクへの書き込み負荷が増えることがあります。接続が多い場合は、アプリの再試行が原因かもしれません。まず問題を引き起こしているアプリを止め、リソース使用量が落ち着くか確認します。メモリ使用量が高いだけでメモリリークとは限りません。継続的な増加、解放の状況、安定して再現できる条件を合わせて判断してください。

アップグレード後に問題が起きた場合は、更新前後の設定変更とシステムの警告を記録し、ロールバック用のバックアップを残してください。クライアントの更新、DNSの変更、サブスクリプションの切り替えを同時に行うと、原因を特定しにくくなります。問題を報告する際は、OSのアーキテクチャ、クライアント名、コアのエラー、最小限の再現手順を添え、機密情報を削除してください。再現条件が明確であれば、開発者は画面の問題、コアの問題、設定の互換性を切り分けやすくなります。

モバイル端末のトラブル：権限・バックグラウンド・ネットワーク切り替え

AndroidではVPNの許可と、通信を取り込むアプリが1つだけか確認する

Androidクライアントは通常、VpnServiceでローカルVPNインターフェースを作成します。システムの許可画面は通信を取り込むための手順であり、デバイスがリモートVPNサービスに接続したことを示すものではありません。初回起動時は許可が完了していることを確認し、ステータスバーとクライアントの接続状態を確認してください。通常、同じユーザーでは同時に有効にできるVPNは1つです。広告ブロッカー、仕事用プロファイルのVPN、他のプロキシアプリと通信の取り込みが競合する場合があります。

システムの「常時接続VPN」と「VPN未接続時の通信をブロック」の設定は、接続が切れた後の動作に影響します。ブロックが有効な場合、クライアントの停止後にデバイス全体がオフラインになるのは、ネットワークの故障ではなくシステムのポリシーによる可能性があります。診断時はまず設定を記録し、一時的に無効にするか判断してください。仕事用デバイスの管理対象VPNを自分で削除しないでください。個人用プロキシとの併用が許可されているか、どのアプリが管理対象かを管理者に確認します。

画面ロック後の切断ではバックグラウンド制限を確認する

画面が点灯している間は正常で、ロック後しばらくすると接続できなくなる場合は、バッテリー最適化、バックグラウンド動作、自動起動、メーカー独自のアプリ休止機能を確認してください。クライアントが厳しい省電力制限の対象にならないように設定し、画面をロックして再テストします。通知の許可だけでは不十分なことがあり、通知が表示されてもコアが正常に動作しているとは限りません。画面を点灯させた後、サービスの状態とログの時刻を確認し、プロセス終了、ネットワークの停止、接続の期限切れのどれが起きたか判断してください。

スマートフォンの省電力機能を一度にすべて無効にしないでください。まずクライアントだけバックグラウンド動作を許可し、他のアプリは元のままにして、同じ時間だけロックして再テストします。設定メニューの名称はOSによって異なるため、「バッテリー最適化」「バックグラウンド実行」「自動起動」などで検索してください。具体的な確認手順はAndroidのバックグラウンド切断と省電力の対象外設定をご覧ください。特定のネットワークでだけ問題が起きる場合は、ルーターのスリープ設定やWi-Fiの省電力設定も確認してください。

iOSではトンネルの状態とオンデマンド接続を確認する

iOSでClash Plusを使う場合は、まずクライアントで設定が有効になっていることを確認し、次にシステムのVPN画面でトンネルが実際に接続されているか確認してください。初回利用時に許可が完了していなければ、サブスクリプションを保存していても通信の取り込みは始まりません。インストールまたは再インストールする場合は、iOSのダウンロードページからApp Storeへ進んでください。公式サイトは clashplus.io です。再インストール前に、設定を安全にバックアップできていることを確認してください。

オンデマンド接続では、ネットワークの切り替えや再接続、条件への一致をきっかけにトンネルが自動で確立されることがあります。手動で切断した後に再接続しても、必ずしもアプリの異常ではありません。オンデマンド設定、システムに保存された他のVPN設定、現在有効な設定を確認し、ネットワーク設定全体を何度も削除しないでください。トンネルが接続済みで特定のアプリだけが失敗する場合は、端末のネットワーク全体をリセットする前に、ルールとDNSを確認します。

Wi-Fiとモバイルデータの違いを切り分ける

同じノードがWi-Fiでは正常でモバイルデータでは失敗する場合、UDP、IPv6、通信事業者の経路、モバイルデータの利用許可が関係している可能性があります。まずクライアントがモバイルデータの使用を許可されているか確認し、同じノードで比較してください。ネットワークによってNATの方式が異なる場合があります。サーバーにpingが通っても、プロキシプロトコルが使えるとは限りません。切り替え時に変更する条件は1つずつにし、切断した時刻と再接続に必要な手順を記録します。

公衆Wi-Fiでは、最初にウェブ認証が必要な場合があります。通信の取り込みを始めると認証ページが正しく表示されないことがあるため、プロキシを一時的に切断してネットワークへのログインを完了し、再接続してください。認証ページの信頼性はネットワーク環境を確認して判断し、不審なページにサブスクリプションURLやプロキシのアカウント情報を入力しないでください。ホテルや学校のネットワークで特定のプロトコルが制限されている場合は、管理者に利用可能な接続方法を確認してください。ローカル設定を何度もリセットする必要はありません。

モバイル端末では、アプリごとのプロキシ対象リストも確認してください。選択したアプリだけをプロキシ経由にするのか、選択したアプリを除外するのかを取り違えると、一方のアプリには接続ログがあるのに、もう一方にはまったく記録されない場合があります。変更後は通常、トンネルを再接続し、対象アプリを再起動する必要があります。テザリングで接続したデバイスの通信がスマートフォンのプロキシを通るかどうかは、OSとクライアントの機能によって異なります。スマートフォンで正常にアクセスできても、テザリング中のパソコンも同じ出口を使うとは限りません。

複数のデバイスで比較する場合は、スマートフォンとパソコンが実際に同じサブスクリプション内容と最終ノードを使い、片方だけルールモード、もう片方だけグローバルモードになっていないことを確認してください。モバイル版のメニューが簡略化されていても、コアの動作が完全に同じとは限りません。未対応の項目が無視されたり、画面の設定で上書きされたりする場合があります。用語が分からない場合は用語集をご覧ください。操作手順を最初から整理し直す場合は入門ガイドに戻り、インポート、選択、接続、確認の順に新たな成功状態を確立してください。