NETWORK DIAGNOSTICS / MIHOMO

Clashのトラブル対処
接続・設定・ネットワーク制御

まず障害の範囲を特定し、設定、接続経路、ルール、ノード、DNSの順に確認します。一度に変更する項目は一つに絞り、元に戻せる状態を保ちましょう。

初回インストール、サブスクリプションの登録、接続確認については、まず入門ガイドをご覧ください。このページは基本設定が完了した後のトラブル対処用です。実際の症状に合った章から確認し、最初からすべての操作を行う必要はありません。クライアントを選び直す場合はClash ダウンロードページへ。一般的なGUIクライアントにはClash Plusがおすすめです。OSとアーキテクチャに応じた選び方は選び方ガイドをご覧ください。

ネットに繋がらない：ローカルネットワークとプロキシ経路を切り分ける

まず、症状が発生した時刻と範囲を記録します。すべてのアプリが繋がらないのか、ブラウザーだけなのか。すべてのサイトで失敗するのか、特定のドメインだけなのか。クライアントを終了すると復旧するのかを確認してください。最初からノード変更、DNS変更、TUNの有効化、再インストールを同時に行うと、原因を示す手がかりが失われます。現在の設定をバックアップし、プロキシモード、選択中のプロキシグループ、システムプロキシの状態を記録します。その後の確認では毎回同じ接続先を使い、変更の効果を判断できるようにしましょう。

まずプロキシなしの状態で確認

クライアントでシステムプロキシとTUNを無効にし、通常の方法で終了します。OSのネットワーク設定に手動プロキシや自動プロキシ設定スクリプトが残っていないか確認してください。普段プロキシなしでアクセスできるサイトを開き、ルーター、Wi-Fi、ほかの端末も正常か確認します。同じネットワークのほかの端末でも接続できない場合は、まずネットワーク側を確認します。この端末だけで失敗する場合は、ネットワークアダプター、デフォルトルート、認証ページ、ほかのVPNを確認してください。公衆Wi-Fiでは先にWeb認証が必要なことがあり、プロキシによる通信制御が認証を妨げる場合もあります。

プロキシなしで接続できるようになったら、クライアントを起動します。画面が開いているだけでなく、コアが実際に動作していることを確認してください。ログに設定の読み込み失敗、ポートの競合、権限エラーがないか確認します。コアが起動していなければ、ノード選択やモード切り替えを行っても通信には反映されません。まずログにある最初の明確なエラーを修正し、後続の連鎖的なエラーに惑わされないようにします。クライアント終了後もネットワークが復旧しない場合は、プロセスを何度も強制終了するのではなく、システムプロキシのアドレスを再確認してください。

プロキシを明示したリクエストで入口を確認

以下では、ローカルの混合ポート7890を例にします。実行前にクライアントの設定で実際のポートを確認し、コマンドをその値に合わせてください。接続先のexample.comは説明用です。今回の障害に関係し、アクセスできることが確認済みのHTTPSアドレスに置き換えられます。Windowsでは、コマンドのエイリアスの影響を避けるためcurl.exeを使います。プロキシを明示するとシステムプロキシの読み取り方式の違いを避けられますが、TUNが有効な場合は仮想ネットワークアダプターのルーティングの影響を受けることがあります。

# ローカルのHTTPプロキシを明示して使用
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://example.com

# 環境変数のプロキシを使わない。プロキシなしで確認する前にTUNを無効にする
curl --noproxy "*" --connect-timeout 10 --max-time 25 -I https://example.com

ローカルポートへの接続に失敗する場合は、コアの動作、待ち受けアドレス、ポートを確認します。ローカルポートには接続できても、その後のリモート接続がタイムアウトする場合は、ノードと出口を確認してください。HTTPステータスコードが返るなら、少なくとも接続先のサービスまでは到達しています。単純に完全なネットワーク障害と判断しないでください。HEADリクエストに対応していないサイトもあり、メソッドエラーが返ってもプロキシの失敗とは限りません。-Iを外して再度試してください。ブラウザーに空白のページが表示されることだけを根拠に、ネットワーク層の原因を判断しないようにしましょう。

ルールとプロキシグループの実際の経路を確認

プロキシを明示したリクエストは成功するのに通常のアクセスが失敗する場合は、接続パネルを開き、同じ時刻、同じドメインへのリクエストを探します。適用されたルール、対象のプロキシグループ、最終的に選ばれたノードを確認してください。ルールモードでは、通信がDIRECTやREJECTに振り分けられていることがあります。プロキシグループ名が正しくても、グループ内で有効なノードが選ばれているとは限りません。一時的にグローバルモードに切り替えると比較できますが、効果があるのはコアに届いた通信だけです。アプリがそもそもプロキシを使っていない場合、グローバルモードにしても自動的に通信は取り込まれません。

一部のアプリだけで問題が起きる場合は、グローバルネットワーク設定を変更するのではなく、そのアプリのプロキシ設定、拡張機能、キャッシュを確認してください。すべてのHTTPSリクエストで証明書エラーが出る場合は、まずOSの日時とタイムゾーンを確認し、セキュリティソフトのHTTPS検査機能も確認します。証明書検証を無効にして恒久的に対処するのは避けてください。失敗したリクエストの時刻、ルール、エラーメッセージを記録しておけば、後の章でその情報を使えます。ネットワーク経路全体を何度も推測し直す必要はありません。

ノードのタイムアウト：速度テストと実際の通信を切り分ける

ノード一覧のタイムアウトは、あるテストが制限時間内に完了しなかったことを示すだけで、すべての通信が使えないことを直接証明するものではありません。テスト先に到達できない、ノードがテストに必要な接続方式に対応していない、短すぎるタイムアウトでリクエストが打ち切られた、といった可能性があります。まずノードを手動で選び、ブラウザーとプロキシを明示したコマンドで実際の接続先にアクセスして、接続ログを確認してください。速度テストと実際のリクエストの両方が失敗する場合に限り、ノードの接続性、認証情報、出口サービスを重点的に確認します。

同じネットワーク・接続先で比較する

ネットワーク、接続先、モードを固定し、異なるノードを2つ試します。一方だけ失敗するなら、ノード自体、経路、設定パラメーターに問題がある可能性が高いでしょう。すべて失敗するのにプロキシなしでは接続できる場合は、サブスクリプションのアカウント状態、サーバーのドメイン解決、クライアントのコアとの互換性を確認します。同じノードが別のネットワークでは使える場合、現在のネットワークがポートやプロトコルを制限している可能性があります。ネットワークを切り替えた後は接続をやり直してください。古い接続は、新しいネットワークの品質を測る有効なサンプルにはなりません。

ログに表示される接続タイムアウト、接続拒否、認証失敗、TLSハンドシェイクエラーは、それぞれ異なる段階の問題です。タイムアウトは経路の不通やサービスから応答がない場合によく発生します。接続拒否は宛先に到達できているものの、そのポートで接続を受け付けていないことを示します。認証失敗ではアカウント、パスワード、サーバー設定を確認します。ハンドシェイクエラーは時刻、サーバー名、証明書、プロトコルパラメーターに関係する可能性があります。画面上の赤い状態だけでなく、エラーメッセージ全文を保存しておくと、原因を特定しやすくなります。

ノードの提供元とプロトコル項目を確認

信頼できる提供元からサブスクリプションを再取得し、問題のノードが引き続き提供されているか確認してください。ネット上の断片的な情報を参考に、プロトコル項目を補ってはいけません。同じプロトコル名でも、トランスポート層、サーバー名、拡張パラメーターが異なることがあります。手動で設定する場合は、サーバーアドレス、ポート、認証情報、インデントを確認してください。ポートにはサーバーが実際に待ち受けている値を指定します。ローカルのプロキシポートではありません。設定を解析できても、それは構文が正しいという意味にすぎず、リモートのアカウントやプロトコルパラメーターが有効であるとは限りません。

プロトコルや項目がサポートされていないというエラーが出た場合は、クライアント名だけでなく、実際に動作しているコアを確認してください。Clash Plus、Clash Verge Rev、FlClashは設定管理用の画面を備えていますが、実際のネットワーク処理はコアとクライアントの連携に依存します。mihomo向けの設定一式を、互換性のない古いコアにそのまま渡さないでください。クライアントを変更する場合はダウンロードページをご覧ください。Clash for WindowsとClashX Metaはすでにメンテナンスが終了しています。トラブル対処では、互換性とOS連携の違いも考慮してください。

利用可能な状態を装うのではなく、速度テストの方法を調整する

以下は、自動速度テストを行うプロキシグループの構成例です。現在の完全な設定に线路甲と线路乙という名前のノードが存在することを前提としています。テスト先は説明用であり、すべてのネットワークからアクセスできるとは限りません。設定に組み込む際は、実際のノード名と接続確認済みのテスト先を使い、サブスクリプション内のほかのプロキシグループを上書きしないでください。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - 线路甲
      - 线路乙
    url: https://example.com/
    interval: 300
    tolerance: 50

intervalはテスト間隔を秒単位で指定します。toleranceは切り替え時の許容遅延をミリ秒単位で指定し、わずかな遅延の変化による頻繁な切り替えを抑えます。テスト頻度を上げても、利用できないノードは直りません。むしろリクエスト数が増えます。自動選択グループと手動選択グループは別々に考えてください。手動で選んだノードは使えるのに、自動選択グループが切り替わり続ける場合は、ノードをむやみに増やすのではなく、テスト先とグループのメンバーを確認します。

ノードが復旧しても使っていたアプリで接続できない場合は、アプリの長時間接続を切断するか、アプリを再起動して確認してください。プロキシグループを切り替えても、通常は新しい接続に反映されるだけで、確立済みのセッションが新しい出口に移るとは限りません。日常的な接続を安定させたい場合は、実際の用途で確認済みの予備ノードを用意しておくと便利です。遅延、倍率、地域の選び方はノードの選び方、自動選択の違いはプロキシグループの設定例をご覧ください。

サブスクリプションの更新失敗：取得経路、応答内容、設定の解析を確認

サブスクリプションの読み込みは、クライアントがリモートの内容を取得する段階と、その内容を設定として解析する段階に分かれています。ダウンロード失敗と解析失敗では、対処方法が異なります。サブスクリプションの詳細やログを開き、ドメイン解決の失敗、リクエストのタイムアウト、HTTPステータスの異常、コンテンツ取得後のYAML解析エラーのどれに当たるかを確認してください。更新に失敗した場合は、現在使える設定を残し、すべてのサブスクリプションを先に削除しないでください。既存の設定は比較テストに使える場合がありますが、サーバーが接続を許可し続けるかどうかはアカウントの状態によります。

アドレスが入力時に変わっていないか確認

サービス提供元のアカウントページからサブスクリプションのURLをコピーし直してください。メッセージアプリによる改行、全角の句読点、前後の空白、クエリパラメーターの欠落に注意します。URL内のパラメーターは認証に使われる場合があるため、不要に見えても削除しないでください。QRコードから読み込んだ場合も、設定名と読み込み結果を確認します。スキャンに成功しただけで、サブスクリプションが有効だと判断しないでください。サブスクリプションURL全体を公開フォーラム、スクリーンショット、オンライン変換ツールに貼り付けないでください。サポートを依頼する場合は、パスに含まれる認証情報とすべての機密パラメーターを隠してください。

未認証やアクセス禁止が返る場合は、アカウントの期限、リンクの再発行、提供元によるアクセス元の制限を確認してください。ページが見つからない場合は、URLが途中で切れていないか確認し、元の配布元から取得し直します。サーバーエラーやリクエスト過多が発生した場合は、更新ボタンを連打せず、しばらく待ってから再試行し、提供元のお知らせも確認してください。クライアントでローカルポートを変更しても、リモートのアカウントによる拒否は解決できません。サーバー側のエラーをローカル設定の破損と誤認しないようにしましょう。

プロキシなしでの取得とプロキシ経由の取得を切り分ける

一部のサブスクリプションはプロキシ経由でアクセスする必要がありますが、現在使っているサブスクリプションが無効だと、利用できないノードに設定取得を依存する状態に陥ることがあります。クライアントがサブスクリプションを更新するときの通信経路を確認してください。プロキシなし、システムプロキシ経由、指定したプロキシグループ経由、あるいは独自のダウンロード処理を使う場合があります。ブラウザーで開けるからといって、クライアントでも取得できるとは限りません。使える既存の接続を残すか、アクセス可能な別のネットワークで更新してから新しい設定をインポートします。どの経路が使われるかは、クライアントの設定とログで確認してください。

ブラウザーで設定テキストではなくログインページ、アクセス認証ページ、エラーページが表示される場合、クライアントは解析エラーを報告することがあります。この場合、YAMLエラーは結果であり、根本原因はリモートから期待した内容が返っていないことです。取得した内容がノードリンクの一覧、エンコードされたテキスト、別のクライアント向け形式で、完全なClash設定ではないこともあります。提供元が現在のクライアントに対応したサブスクリプション形式を提供しているか確認してください。形式自体が異なる入力に対して、インデントを変更して対処しようとしないでください。

失敗した段階確認できる症状まず確認すること
リクエスト未完了解析失敗、接続タイムアウトドメイン、取得経路、接続ネットワーク
サーバーによる拒否未認証、アクセス禁止アカウント、URLの認証情報、サービスの制限
コンテンツの形式が異なるWebページ、別形式のサブスクリプションサブスクリプションの種類、ログインページへの転送
設定の解析失敗行番号、不明な項目、参照先の欠落構文、コアの対応状況、プロキシグループの参照

エラーの位置をもとに設定の統合状態を確認

行番号が表示されたら、その行だけでなく前後も確認してください。YAMLはスペースでインデントします。タブ文字、トップレベルキーの重複、コロンの位置の誤りが解析エラーを引き起こすことがあります。存在しないノードを参照するプロキシグループや、存在しないルールセットを参照するルールは、構文が正しくても設定エラーになる可能性があります。クライアントのオーバーライド、グローバル拡張、スクリプトも設定の統合に加わるため、元のサブスクリプションが正しくても、最終的にコアへ渡される設定が正しいとは限りません。まず個人用のオーバーライドを無効にして比較し、元のファイルは復元できるように保管してください。

更新に成功したら、新しい設定が有効になっているか確認します。プロキシグループに有効な選択が残っているか確認し、実際のリクエストをもう一度試してください。更新完了の表示が出ても、使用中の設定に切り替わったとは限りません。クライアントを再起動するたびに古い内容に戻る場合は、何度もインポートを繰り返すのではなく、保存先ディレクトリの権限と個人用オーバーライドを確認してください。サブスクリプションの初回設定手順は入門ガイドをご覧ください。この章では取得と解析の問題を扱っており、更新のためにクライアント一式を再インストールする必要はありません。

速度が遅い：遅延、スループット、アプリ側の制限を切り分ける

まず、どのような遅さかを明確にします。Webページの表示開始が遅い、ダウンロードが遅い、動画が頻繁にバッファリングする、ゲームの応答が不安定など、症状ごとに関連する指標は異なります。ノードの速度テストは通常、小さなリクエストの往復時間を測定するもので、大容量ファイルのスループットや接続先サービスの速度制限を示すものではありません。実際に使う接続先を一つ決め、接続確立までの時間と転送速度の安定性を記録し、プロキシなしや予備ノードと比較してください。毎回異なるサイトでテストすると、サーバー側の違いが経路の違いを覆い隠してしまいます。

条件をそろえ、速度テスト同士の干渉を避ける

帯域を使用している同期、ダウンロード、システム更新を停止し、まず一つのタスクだけをテストします。Wi-Fiの電波が弱い、チャンネルが混雑している、端末が省電力状態にあると、ローカルの接続に影響します。プロキシなしのダウンロードも遅い場合は、まずLANやインターネット接続を確認してください。デスクトップでは有線接続と比較し、モバイル端末ではWi-Fiとモバイルデータをそれぞれ試します。比較テストは近い時間帯に行ってください。混雑時間帯と空いている時間帯の結果の違いを、設定項目だけに原因があると判断することはできません。

実際の通信が最終的にどのノードを通っているか確認します。画面で選択したノードはプロキシグループの一つに属していても、対象サイトの通信が別のグループやDIRECTルールに振り分けられていることがあります。画面上部の選択よりも、接続パネルに表示されるプロキシ経路の方が確実です。自動選択グループはテスト後に出口を切り替える場合があり、連続したテストで同じ経路が使われるとは限りません。切り分け中は一時的に手動選択グループでノードを固定し、原因が分かったら自動選択に戻してください。出口が頻繁に変わると、接続先サービスでセッションの再認証が発生し、再試行や表示の遅れにつながる場合もあります。

接続段階からボトルネックを特定する

ドメイン解決に時間がかかる一方、接続後の速度は正常なら、まずDNSを確認します。TCP接続やTLSハンドシェイクが遅く、ダウンロードは安定している場合は、経路の遅延や再送が考えられます。接続はすぐ確立するのに転送速度が低い場合は、サーバーの速度制限、回線の混雑、ローカルの帯域を確認してください。以下のコマンドはプロキシを明示して、いくつかの所要時間を出力します。同じ接続先での比較に使えます。HTTP CONNECTプロキシでは、表示される時間はクライアントから見た各段階の値です。リモートDNSの時間やノードのRTTとしてそのまま扱わないでください。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null -sS \
  -w 'connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/

この例はUnix系ターミナルの行継続と、出力先の破棄に使うデバイスファイルを使用しています。Windowsではコマンドを1行にし、curl.exeを使って/dev/nullをNULに置き換えてください。小さなページのtotalは接続の比較に使う値であり、スループットのテストにはなりません。継続的な転送をテストする場合は、提供元が明確でサイズが分かり、テストが許可されているファイルを選んでください。公開サービスに対して同時に負荷をかけるのは避けます。2〜3回繰り返して変動を確認し、単発のピーク値を日常的な品質とみなさないようにしましょう。

UDP、MTU、プロトコルの違いに注意

動画アプリやブラウザーはQUICを優先して使うことがあります。QUICはUDPを使用し、実際の動作はノードの対応状況、ネットワーク経路、通信の取り込み方によって異なります。WebサイトはTCPで正常に開けるのに特定のアプリが不安定な場合は、そのアプリに設定項目があれば一時的にQUICを無効にして比較できます。ただし、あらゆる状況でQUICを無効にしておくのが最適とは限りません。ノードのプロトコルがUDPに対応していても、サーバーや上流の経路でUDPが許可されるとは限りません。プロトコル名よりも、ログに対象の通信が記録されているかを確認する方が、実際の経路を判断するうえで役立ちます。

TUNで小さなリクエストは正常なのに、大きなリクエストが止まる場合は、経路MTUやフラグメント処理が関係していることがあります。まず現在のMTUを記録し、TUNを使わないプロキシ経路を試して、DNSとノードの問題を除外してください。違いが安定して再現する場合に限り、関連するパラメーターを一つずつ調整します。すべてのネットワークアダプター、トンネル、接続環境で共通して使えるMTU値はありません。スタック方式、MTU、ルーティング設定を一度に変更すると、一時的に復旧しても何が効いたのか分からず、ネットワークを切り替えた後の管理も難しくなります。

一つのサービスだけ遅い場合は、サービスの地域、出口IPのリスク判定、ログイン状態、アプリのダウンロード制限を確認します。同じ時間帯にすべてのノードで速度が低下する場合は、ローカルのネットワーク接続とサービス側の容量を確認してください。出口を変更した後は接続を作り直して比較します。既存の接続は古い経路を使い続けることがあります。ノード選択の詳しい比較は遅延・倍率・地域・プロトコルの比較をご覧ください。速度の問題を解決するために、ルール設定一式を先に削除する必要はありません。

DNSの問題：名前解決元とFake-IPの対応関係を確認

DNSの問題は、ドメインにアクセスできない、一部のアプリでネットワークエラーが表示される、ノードを変えても状況が変わらない、といった症状として現れます。まずログに名前解決の失敗が記録されているか確認し、接続先サイトのドメインとノードサーバーのドメインを切り分けてください。前者は実際の通信に影響し、後者はプロキシ自体を確立できるかどうかに影響します。ノードのアドレスを解決できない場合、Webサイトの振り分けルールを変更しても入口の問題は解決しません。また、アプリがシステムDNS、コアのDNS、ブラウザーのセキュアDNS、アプリ内蔵のDNSのどれを使っているかも確認してください。複数の仕組みが同時に使われる場合があります。

システムの名前解決とコアの名前解決を区別する

nslookup example.comで確認できるのは、通常、システムで選択されているDNSサービスの応答です。これだけでmihomoコアの名前解決が正常だとは判断できません。コアが独自にDNSポートを待ち受けている場合は、そのアドレスとポートを指定して問い合わせます。標準以外のポートで待ち受けている場合は、ポートを指定できるツールを使用してください。以下はローカルの1053ポートを使う設定例です。実際の設定でそのポートを待ち受けている場合に限り利用できます。テストツールがインストールされていない場合は、無理に一式をインストールせず、まずコアのログと接続記録を確認してください。

# システムのデフォルトDNSを確認
nslookup example.com

# digを使って、例にあるコアのDNS待ち受けポートを確認
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

システムの問い合わせは正常なのにアプリで失敗する場合は、アプリ独自のDNS、プロキシ経路、接続先への接続を確認します。コアへの問い合わせが失敗する場合は、上流のDNSサービスへの接続性と起動ログを確認してください。IPアドレスへのHTTPS接続は、証明書や仮想ホストが引き続きドメイン名に依存するため、確実な代替手段にはなりません。hostsファイルに手動で登録すれば一時的に名前解決を回避できる場合がありますが、アドレスの変更や振り分けの問題を隠してしまうことがあります。アドレスと用途を把握している場合の一時的な比較に限って使い、確認後は設定を元に戻してください。

Fake-IPの仕組みを正しく理解する

Fake-IPでは合成アドレスを返し、コアがドメインとアドレスの対応を保存します。後続の接続でドメイン名を復元し、ルールに照合するためです。予約済みアドレス範囲の応答が返っても、必ずしも異常ではありません。また、そのアドレスを実際のサービスアドレスとして、ほかの端末の恒久設定に登録しないでください。アプリが合成アドレスを受け取った後、対応情報を管理するコアを通らずに接続すると、接続に失敗することがあります。システムプロキシ、TUN、DNSの取り込み、アプリのキャッシュが一貫した経路になる必要があります。一部だけを有効にしても正しく動作しません。

以下はローカルDNS設定の一部を示す例です。待ち受けアドレス、モード、上流DNSの関係を示すもので、汎用的な修正設定ではありません。上流アドレスが現在のネットワークから到達可能であること、システムの転送設定との間でループが発生しないことを確認してください。統合する前に設定全体をバックアップします。待ち受けにはループバックアドレスを使用し、ローカルでのトラブル対処のためにDNSサービスをLAN全体へ公開しないでください。クライアントが該当項目を上書きする場合があるため、元のサブスクリプションだけでなく、最終的に動作している設定を確認してください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

互換性の例外とキャッシュに対処する

LAN上のデバイス検出、一部のゲーム、実際のアドレスが必要なプログラムでは、Fake-IPを利用できない場合があります。まず影響を受けるドメインを特定し、現在のコアがサポートするフィルター設定で、必要最小限の例外を追加してください。最初からすべてのドメインを除外すると、ドメインの対応付けや振り分けが変わってしまいます。LAN内の名前解決にはルーターのDNS、検索ドメイン、マルチキャストによるデバイス検出が使われることがあり、パブリックDNSとは別の仕組みです。パブリックDNSに切り替えても、プリンターや社内ホストを解決できるとは限りません。

モードを変更しても、古いシステムキャッシュ、ブラウザーのキャッシュ、アプリの接続が以前の結果を使い続けることがあります。Windowsではipconfig /flushdnsを実行してシステムのキャッシュを消去できます。ほかのOSでは、使用中の名前解決サービスに応じて消去方法が異なります。その後、影響を受けたアプリを再起動し、クライアントでサポートされている操作を使ってコアのマッピングを作り直してください。古い接続が大量に残った状態でFake-IPと別のモードを何度も切り替えないでください。古いアドレスと新しい対応情報が混在し、断続的で再現しにくい問題につながります。

IPv4では使えるのにIPv6で失敗する場合は、AレコードとAAAAレコードの応答、ノードの対応状況、実際のルーティングを個別に確認してください。一つの設定スイッチだけを見て判断しないでください。ブラウザーのセキュアDNSがシステム設定を迂回し、ブラウザーとターミナルで異なる結果になることもあります。トラブル対処中は一時的に名前解決元を統一して検証し、確認後に恒久設定を決めます。特定のドメインだけ失敗する場合は、すべてのDNSパラメーターを何度も変更するのではなく、ルールの対象とDNSサービスの応答を確認してください。

システムプロキシが機能しない：アプリごとに接続経路を確認

システムプロキシは、すべての端末通信を切り替えるスイッチではありません。一般に、システムプロキシ設定を参照するアプリへHTTPまたはSOCKSの入口を提供します。実際に使うか、どのように使うかは、アプリとOSのインターフェースによって決まります。一方、TUNは仮想ネットワークアダプターとルーティングを使って、対象経路に入った通信を取り込みますが、ルート、除外設定、権限の影響を受けます。まず、ブラウザー、ターミナル、ゲーム、LAN上のデバイスのどれを取り込みたいのかを明確にしてから、確認方法を選んでください。二つの仕組みを同じスイッチの別名として扱わないようにしましょう。

まずOSとブラウザーの設定を確認

OSのネットワークプロキシ設定を開き、プロキシのアドレスとポートがクライアントの設定と一致しているか確認します。一般的なローカルの入口には127.0.0.1が使われます。これは現在の端末を指すアドレスであり、別の端末からこのPCに接続するためのものではありません。手動プロキシ、自動構成スクリプト、ほかのプロキシツールが同時に有効になっていないか確認してください。ブラウザー拡張がOSの設定を上書きする場合や、企業ポリシーによって変更が制限される場合があります。ブラウザー独自のプロキシ設定を使うこともあります。まず関連する拡張機能を無効にして比較し、対象のリクエストがコアの接続パネルに表示されるか確認してください。

同じ接続先に対し、プロキシを明示したコマンドを実行します。コマンドでは成功するのにブラウザーの接続記録がない場合は、ブラウザー側の接続経路を確認してください。ブラウザーの記録があり、DIRECTに振り分けられている場合は、システムプロキシのスイッチではなくルールの問題です。既存の接続が使われている場合は、設定を切り替えた後にページを開き直すか、ブラウザーを再起動して比較してください。プライベートブラウジングで拡張機能の影響を減らせる場合はありますが、企業ポリシーやシステムレベルのネットワークソフトを回避できるとは限りません。

ターミナルのプロキシは個別に設定する

多くのコマンドラインツールは環境変数を参照し、システムプロキシを自動では読み込みません。以下はUnix系シェルで、現在のセッションだけに適用する例です。ポートは実際の値に変更してください。HTTPS_PROXYにHTTPプロキシのアドレスを指定しても問題ありません。ツールはHTTP CONNECTでHTTPSトンネルを作成できます。一部のツールは小文字の環境変数、独自の設定、起動パラメーターしか読み取りません。すべてのプロセスで同じ環境変数が使えると考えず、各ツールの説明を確認してください。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

curl -I https://example.com

# 比較テストが終わったら現在のセッション設定を解除
unset HTTP_PROXY HTTPS_PROXY NO_PROXY

PowerShellでは$env:HTTPS_PROXY='http://127.0.0.1:7890'を使って現在のプロセス環境を設定できます。テスト後はRemove-Item Env:HTTPS_PROXYで削除してください。環境変数は子プロセスの起動前に設定する必要があります。すでに動作中のエディター、ターミナル、サービスには、新しい値は自動的に反映されません。NO_PROXYに対象ドメインや広すぎる範囲が含まれていないか確認してください。古い小文字の変数と大文字の変数が同時に設定され、プログラムによって異なる入口が使われる場合にも注意が必要です。

入口主な利用アプリ確認ポイント
システムプロキシシステム設定を参照するブラウザーやアプリシステムプロキシのアドレス、拡張機能、自動構成スクリプト
環境変数対応する環境変数を使うターミナルツール環境変数の継承、除外リスト、ツールの設定
アプリ内プロキシアプリ側でプロキシを個別設定するソフトプロトコル、ポート、認証
TUN仮想ネットワークアダプターのルートに入る通信権限、ルーティング、DNS、VPNの競合

TUNを有効にした後もルートを確認

TUN用サービスがインストールされ、仮想ネットワークアダプターが作成されていることを確認し、権限やルートの書き込みエラーがコアのログにないか調べます。管理者権限やシステム権限を求められた場合は、クライアントの案内に従ってください。権限設定の代わりにシステムのセキュリティ機能を無効にしたままにしないでください。ほかのVPN、仮想マシンのネットワークアダプター、企業のトンネルがデフォルトルートを変更することがあります。不要な同種のツールを一時的に終了して比較してください。ただし、業務ネットワークに管理上のルールがある場合は管理者のポリシーに従い、管理対象のルートを無理に上書きしないでください。

TUNでLANに接続できない場合は、すべての宛先をプロキシに振り分けるのではなく、ルートの除外設定とローカルのネットワーク範囲が正しいか確認してください。社内ドメインを使う場合は、社内DNSとスプリットトンネルも考慮します。一部の設定ではシステムプロキシとTUNを併用できますが、トラブル対処の初期段階では個別にテストした方が原因を切り分けやすくなります。UDPを使うアプリだけ失敗する場合は、ノードと出口がUDPに対応しているか、実際に通信がコアへ取り込まれているか確認してください。HTTPプロキシは、汎用的なUDPの入口としては使えません。

確認が終わったら、一時的に設定した環境変数を削除し、ブラウザーの設定を元に戻して、必要なプロキシの入口だけを残します。ブラウザーとターミナルの経路を分けて確認する詳しい手順はシステムプロキシを有効にしても機能しない場合をご覧ください。対象の通信が接続パネルに表示されているのに接続できない場合は、システムプロキシのスイッチを何度も押すのではなく、ノードまたはDNSの章を確認してください。

クライアントのクラッシュ：画面、コア、サービスを切り分ける

クライアントの突然終了、画面のフリーズ、コアの終了は、それぞれ異なる問題です。画面のプロセスは表示と管理を担当し、コアはネットワーク接続を担当します。サービスコンポーネントが権限やTUNを担う場合もあります。まず、ウィンドウが消えたか、システムプロキシが残っているか、コアのプロセスがまだ動作しているか、ログの最後にどのエラーが記録されているかを確認します。トレイにアイコンが表示されていても、ネットワークが正常とは限りません。画面が開かないからといって、すべての設定が壊れたとは限りません。障害の発生時刻を記録してください。後でシステムイベントの記録と照合する際に必要です。

まずネットワークを復旧し、証拠を保管する

クラッシュ後にネットワークへ接続できなくなった場合は、まずOSの設定で残存するプロキシを無効にし、基本のプロキシなし接続が復旧するか確認してください。できるだけクライアントの通常の終了操作を使い、操作できない場合に限って関連プロセスを終了します。リセットを検討する前に、設定、サブスクリプションの管理データ、個人用オーバーライドをコピーしてください。サブスクリプションのURL、ノードの認証情報、ログ内の完全なURLには機密情報が含まれる場合があります。問題を報告する前に必ず伏せてください。最初の手段としてアプリデータを消去しないでください。障害時の情報と、既知の復旧経路も同時に失われます。

ログに設定の解析失敗がある場合は、サブスクリプションの章を確認します。ポートの競合が表示される場合は、プロキシクライアントが二つ起動していないか、以前のコアが残っていないか調べてください。まずポートを使用しているプロセスを特定し、不要なインスタンスを終了するか、待ち受けポートを変更して、システムプロキシとアプリの設定も更新します。コアのポートだけを変え、アプリ側の入口を更新しないと、起動エラーが新たな接続失敗に変わります。プロセス名だけを見てシステムサービスを終了しないでください。企業向けソフトウェアや開発ツールが同じポートを正当に使っている場合があります。

# Windows：プロキシポートの確認例。出力されるPIDでプロセスを特定
netstat -ano | findstr ":7890"

# Linux：待ち受けポートと確認できるプロセス情報を表示
ss -lntp

# macOS：TCPの待ち受けポートを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

設定と画面の状態を最小限の変更で切り分ける

特定の設定を有効にするとクラッシュする場合は、直前に使えていた設定に戻し、個人用スクリプト、オーバーライド、追加のルールプロバイダーを無効にして比較します。復旧中に大量のリソースを再取得すると、リモート側の変更も同時に取り込むことになるため避けてください。接続パネルを開いたときだけ画面が固まる場合は、接続数、ログレベル、画面の更新頻度による負荷を確認します。ログの詳細度を一時的に下げ、頻繁な更新を止めて、ネットワークが引き続き正常か比較してください。トラブル対処のため詳細ログを有効にする場合は、短時間にとどめ、大量の記録を長期間続けないようにしましょう。

何もしていないときにもクラッシュする場合は、ディスクの空き容量、ユーザーディレクトリへの書き込み権限、セキュリティソフトのブロック記録、システムイベントを確認します。インストール先とデータ保存先は別の場合があり、プログラムを再インストールしてもユーザー状態の破損が解消されるとは限りません。クライアントのリセット機能を使う前に説明を読み、削除される項目を確認してバックアップしてください。ユーザーディレクトリ全体を不用意に削除したり、すべてのファイルの権限を一括で引き上げたりしないでください。拒否されたパスが特定できているなら、その場所だけを修正する方が安全で、後から確認もしやすくなります。

OS、アーキテクチャ、起動方法を確認

インストールパッケージはOSとプロセッサーのアーキテクチャに合ったものを選びます。macOSではApple SiliconとIntel、Androidでは端末のABIを確認してください。Linuxではディストリビューションに対応したパッケージ形式と実行時の依存関係を確認します。パッケージが合っていない場合、一般的なネットワーク障害ではなく、起動失敗、サービスのインストール失敗、更新エラーとして現れることがあります。適切なパッケージをダウンロードページから選んでください。一般ユーザーにはClash Plusがおすすめです。Linuxのグラフィカルデスクトップでは、ページの案内に従ってClash Verge RevまたはFlClashを選択できます。

Linuxでグラフィカルクライアントと手動起動したmihomoを同時に実行すると、ポートを取り合ったり、ルートを変更したりすることがあります。systemdで管理する場合は、実行ユーザー、作業ディレクトリ、設定ファイルのパス、ファイルへのアクセス権を確認してください。デスクトップ上のコアを動かしたまま、サービスの起動を繰り返さないようにします。ネットワークを実際に担当しているプロセスからログを取得してください。ターミナルで別のテスト設定を動かした結果は、バックグラウンドサービスの状態を示すものではありません。ディレクトリ構成と権限の関係はLinux向けmihomoのデプロイ方法をご覧ください。

問題を報告する際は、OSとアーキテクチャ、クライアント名、発生手順、障害の時刻、TUNの使用有無、機密情報を隠した主要なエラーを伝えてください。整理されていないログを丸ごと送るより、少ない手順で安定して再現できる情報の方が役立ちます。Clash for WindowsとClashX Metaはすでにメンテナンスが終了しています。新しいOSとの互換性が関係する場合は、現在もメンテナンスされているクライアントを優先的に検討し、移行に備えて古い設定も保管してください。問題が修正されたと判断するために、根拠のないバージョン番号を作り上げないでください。

モバイル端末のトラブル：VPN権限、バックグラウンド動作、バッテリー消費

モバイル端末では、OSのVPN状態、クライアントの動作状態、実際のネットワーク接続をあわせて確認します。ステータスバーにVPNアイコンが表示されても、OSが何らかのVPN接続を確立したことしか分かりません。選択中のノード、DNS、接続先サービスが正常とは限りません。まずアプリを前面に表示した状態で接続し、実際の接続先にアクセスします。その後、画面ロック、アプリの切り替え、ネットワークの切り替えを行い、どの段階で失敗するか記録してください。モバイル端末の問題にデスクトップのシステムプロキシの方法をそのまま当てはめると、権限、バックグラウンド制限、ネットワーク切り替えといった条件を見落としやすくなります。

Android：権限とバックグラウンド制限を個別に確認

初回接続時にOSのVPN権限を許可し、同種のVPN接続を別のアプリが使用していないことを確認します。「常時接続VPN」や「VPNを経由しない接続をブロック」が有効な端末では、クライアントが停止するとすべての通信がOSによって遮断される場合があります。トラブル対処の前にこれらの設定を記録し、用途に応じて比較した後、元の方針に戻してください。アプリをアンインストールするだけで、関連するOS設定を放置しないようにします。仕事用プロファイルや管理対象端末のVPNは管理者が制御している場合があります。制限がある場合は、まず管理上のルールを確認してください。

アプリを前面に表示している間は正常でも、画面ロック後に切断される場合は、バッテリー最適化、バックグラウンド動作、自動起動、メーカー独自の省電力設定を確認します。設定画面の項目名はメーカーによって異なるため、現在の端末に合わせて確認してください。まず対象アプリだけを調整し、省電力機能をすべて無効にする必要はありません。クリーナーやワンタップ最適化ツールがバックグラウンドサービスを終了させることがあります。最近使ったアプリの画面でロックしても、OSのバッテリー最適化対象外にできるとは限りません。変更後はしばらく画面をロックし、アプリを開き直しただけで復旧したのではなく、実際の接続が戻ることを確認してください。

アプリ単位のプロキシ設定を使うと、通信を取り込む範囲が変わります。対象アプリが対象リストに含まれているか、除外リストに入っていないか確認してください。ブラウザーで接続できても、ゲームやメッセージアプリの通信が取り込まれているとは限りません。アプリの更新、仕事用プロファイル、デュアルアプリでは別のIDやパッケージ名が使われることがあるため、対象を選び直してください。AndroidのプライベートDNSも名前解決の経路に影響する場合があります。まずクライアントのDNSとの関係を確認し、一時的に名前解決元を統一して比較してください。一度失敗しただけで、OSのDNS機能をすべて恒久的に無効にしないでください。

iOS：システムのVPN設定とトンネル状態を確認

iOSではiOSのダウンロードページからClash Plusをインストールできます。公式サイトはclashplus.ioです。初回利用時はOSの案内に従ってVPN構成の追加を許可し、接続後にアプリ内のトンネル状態とOSのVPN設定をあわせて確認してください。ほかのVPN構成、管理対象ネットワークのポリシー、既存のトンネルが接続に影響する場合があります。不要な同種の接続を一時的に無効にして比較してください。アプリの再インストールでOS権限の確認を代用することはできません。

iOSのネットワークトンネルと通常のアプリ画面は、動作の仕組みが異なります。アプリをバックグラウンドに移したからといって、プロキシが必ず停止するわけではありません。同様に、「Appのバックグラウンド更新」を許可しても、トンネルが常に動作するとは限りません。アプリを再度開くと復旧する場合は、OSのVPNが切断されていたか、ネットワークが切り替わったか、ログにトンネルの再確立が記録されているか確認してください。常時接続を保つためにアプリを何度も強制終了するのではなく、通常の切断と再接続で確認します。必要に応じて端末を再起動し、不安定なトンネル状態を解消してください。

症状まず確認する項目有効な比較方法
画面ロック後に接続が切れるVPNの状態、バックグラウンド制限前面表示中とロック後に同じ接続先を試す
ネットワーク切り替え後に接続できないトンネルの再接続、DNS、既存のセッション再接続してから新しいリクエストを実行
一部のアプリがプロキシを経由しないアプリごとの対象設定、実際の接続記録同じノードでアプリを一つずつテスト
バッテリー消費が大幅に増えた速度テスト、ログ、再接続の頻度設定を一つずつ変え、似た時間帯で比較

ネットワーク切り替えとテザリングの注意点

Wi-Fiからモバイルデータに切り替えると、既存のTCPセッションが切断され、DNSやデフォルトルートも変わることがあります。まずクライアントの再接続を待ち、失敗したページを閉じるか、アプリの通信をやり直してください。公衆Wi-Fiでは先に認証ポータルを完了します。ローミング中は、モバイルデータ通信自体が利用できるかも確認してください。スマートフォンでVPNを有効にしても、テザリング先のPCの通信が同じトンネルを通るとは限りません。転送された通信に対するOSの処理は異なります。テザリング先の端末でもプロキシの入口を個別に検証し、スマートフォンのVPNアイコンだけで判断しないでください。

バッテリー消費は繰り返し処理から確認

頻繁なノード速度テスト、ルールセットの更新、詳細ログ、失敗を繰り返す再接続は、バッテリー消費を増やす場合があります。まず不要な定期処理を減らし、安定して使えるノードを選んで、同じような使用時間帯にバッテリー残量と端末の温度を比較してください。バックグラウンド通信は、システムの同期やアプリの通信が原因の場合もあり、すべてをプロキシのせいにすることはできません。短時間のアイドル状態だけでは電波強度や充電状態の影響を受けやすいため、OSのバッテリー画面とクライアントのログをあわせて確認します。設定の詳しい比較はモバイル端末のバッテリー消費とバックグラウンド動作をご覧ください。

トラブル対処が終わったら、一時的に変更したバッテリー、DNS、VPNの設定を元に戻し、問題を再現するために必要な最小限の記録を保管します。クライアントを移行する場合は、サブスクリプションの取得元と個人ルールを保存したうえで、入門ガイドに従って再インポートしてください。古いアプリの内部データ一式を別のクライアントにそのままコピーしないでください。問題が続く場合は、該当するノード、DNS、プロキシの入口の章に戻って確認します。モバイル端末の制限は通信経路の一部にすぎず、リモートサービスの検証に代わるものではありません。