Clashのトラブル対応ガイド

インターネットに接続できない：ネットワークの基本状態を確認

「インターネットに接続できない」原因は、Wi-Fi接続、システムのルーティング、ローカルプロキシ、ルール選択、リモート側の通信など、さまざまな箇所にあります。まずクライアント名、OS、現在のモード、すべてのアプリで発生するのか特定のサイトだけなのかを記録してください。使用中の設定を複製して保存し、スクリーンショットを撮る場合はサブスクリプションURL、パスワード、接続情報を隠してください。クライアントの更新、ネットワークのリセット、サブスクリプションの変更を同時に行うと、復旧しても原因を特定できません。

まずプロキシを切断して通常のネットワークを確認

クライアントで「システムプロキシ」と「TUNモード」をオフにし、クライアントを通常の方法で終了します。OSのネットワーク設定を開き、手動プロキシにローカルアドレスが残っていないか確認してください。モバイル端末ではVPNが切断されていることを確認します。通常なら直接接続できるHTTPSサイトにアクセスし、ルーターの管理画面が開けるかも確認してください。それでも接続できない場合は、Wi-Fi認証、ゲートウェイ、ブロードバンド接続、公共Wi-Fiのログイン画面を先に確認します。通常のネットワーク接続が復旧するまでは、ノードを変更しても解決しないことがあります。

公共Wi-FiではWeb認証が必要な場合があります。VPNを切断し、OSの案内に従って認証してからクライアントを再接続してください。1台だけで問題が起きる場合は、同じネットワークにつないだ別の端末と比較します。すべての端末で問題が起きる場合は、ルーターと上位ネットワークを優先して確認してください。比較のため一時的にスマートフォンのテザリングへ切り替える方法もありますが、テザリングで復旧しても、元のネットワークに原因があることを示すだけで、サブスクリプションが無効とは限りません。2つのネットワークの違いを記録し、あとでDNS、UDP、ファイアウォールの制限を確認してください。

ローカルプロキシと実際の通信先を確認

クライアントを再起動し、正常に読み込まれた設定を選択します。まずTUNをオフのままシステムプロキシだけを有効にしてください。「設定」でHTTPまたは混合プロキシの実際のポートを確認し、プロキシを明示したリクエストでテストします。以下のコマンドはクライアントのポートが7890の場合に限り使用できます。画面に別のポートが表示されている場合は、その値に変更してください。Windows PowerShellでは、コマンドの別名による引数の違いを避けるため curl.exe を使用します。テスト先は、確認中の対象サイトに変更してもかまいません。

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

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

すぐに「接続が拒否されました」と表示される場合、ローカルポートで待ち受けていない、ポート番号が間違っている、またはコアが起動していない可能性があります。まずリモートノードの問題と決めつけないでください。ローカルプロキシに接続できた後でタイムアウトする場合は、クライアントの「接続」と「ログ」を確認します。ログに DIRECT と表示される場合は、ルールと対象ドメインが想定どおりか確認してください。プロキシのポリシーグループに一致する場合は、そのグループで実際に選択されている出力先を確認します。画面に表示された設定名と現在有効な設定が異なることもあります。インポート後に有効化されているか確認してください。

原因を絞り込み、通常の設定に戻す

必要な場合に限り、「グローバル」モードへ一時的に切り替え、同じ対象に再度アクセスします。グローバルモードでは接続でき、ルールモードではできない場合は、ルールの順序、ポリシーグループ名、末尾のフォールバックルールを確認してください。どちらのモードでも失敗する場合は、ノードがタイムアウトするの項目を確認します。グローバルモードでも、すべてのアプリがプロキシを使うとは限りません。システムプロキシを参照しないアプリは、直接接続する場合があります。モードとTUNの設定を同時に変更すると、ルールと通信の取り込みのどちらに問題があるか判断できません。

クライアントを終了しても接続できない場合は、まずシステムに残ったローカルプロキシを解除し、ほかのVPN、仮想ネットワークアダプター、セキュリティソフトがルーティングを制御していないか確認してください。すべてのネットワークアダプターを削除したり、ファイアウォール全体をリセットしたりしないでください。関連するプログラムを停止して再起動し、どの操作でネットワークが復旧したか確認してから、該当コンポーネントを修復します。原因を特定できない場合は、エラー発生時刻と最初のエラーログを記録し、後の項目で調査を続けてください。

ノードがタイムアウトする：疎通確認と実通信を切り分ける

クライアントのタイムアウトは、指定時間内に何らかの疎通確認が完了しなかったことを示します。その出力先がすべての宛先で使えないという意味ではありません。疎通確認では、名前解決、接続の確立、プロトコルのハンドシェイク、テスト先からの応答が順に必要です。どの段階で失敗してもタイムアウトになることがあります。まず1つの出力先を選び、対象サイトに実際にアクセスして、ログのエラーと照らし合わせてください。グループ全体のテストを何度も実行しないでください。大量の同時テストはサーバー側の制限に触れる可能性があり、ローカルネットワークの負荷で本来の問題が見えにくくなります。

エラーが発生した段階で分類する

「ログ」を開き、一時的にログレベルを info に設定します。古い記録を消してからリクエストを1回実行してください。さらに詳しい情報が必要な場合は、短時間だけ debug を使用します。最後の「リクエスト失敗」だけでなく、対象リクエストに関連する最初のエラーを探してください。接続タイムアウトはネットワークへの到達不能やポート制限、接続拒否は接続先からの拒否が考えられます。TLSハンドシェイクエラーは、サーバー名、システム時刻、証明書が関係する場合もあります。エラー文は手がかりであり、1行だけで原因が確定するわけではありません。

ノードサーバーのドメイン名を解決する段階でエラーが出る場合は、DNSの問題を確認し、DNSの初期解決を調べてください。名前解決後にサーバーのポートへ接続できない場合は、Windowsで次のコマンドを使い、TCPで到達できるか確認できます。サーバー名とポートには現在の設定値を指定してください。コマンド内のドメイン名は説明用です。このテストで確認できるのはTCP接続だけです。プロキシプロトコルの認証成功を証明するものではなく、UDPを使うプロトコルの確認にも使えません。

# ドメイン名とポートを現在の出力先の設定に置き換えてください
Test-NetConnection -ComputerName proxy.example.com -Port 443

プロトコルの設定値とシステム時刻を確認

サブスクリプションから追加した出力先は、項目ごとに推測で変更せず、まず更新し直してください。手動設定の場合は、サーバーアドレス、ポート、パスワードまたはユーザーIDに加え、トランスポート層、パス、サーバー名などのパラメーターを確認します。名前が似ているプロトコルでも互換性があるとは限りません。古いコアは新しいフィールドを認識できない場合があります。設定読み込みログに「未対応のタイプ」やフィールド解析エラーがないか確認してから、クライアントの更新を検討してください。更新版はクライアントのダウンロードページから入手してください。異なるクライアントのデータフォルダーを上書きしないでください。

HTTPSの接続先も、TLSを使うプロキシ接続も、システム時刻の影響を受けます。システムの「日付と時刻」を開き、自動同期が有効でタイムゾーンが正しいことを確認してください。証明書エラーを解消するために、証明書の検証を恒久的に無効化しないでください。まずサブスクリプション提供元が指定するサーバー名と証明書設定を確認します。社内ネットワークのHTTPS検査、期限切れの証明書、間違ったドメイン名もハンドシェイクエラーの原因になります。社内ネットワークだけで失敗し、テザリングでは正常な場合は、セキュリティ設定を下げ続けるのではなく、ネットワーク管理者に制限を確認してください。

自動ポリシーグループの判定条件を確認

url-test は設定したテスト先を使って候補の出力先を評価し、fallback は利用可否と順序に応じて切り替えます。どちらも疎通確認が完了するかどうかに左右されます。テスト先に到達できない、応答が変化した、現在のネットワークに適していない場合、実際には使える出力先がポリシーグループで異常と判定されることがあります。以下はフィールドの構造例です。既存のポリシーグループに統合し、実際に使用する候補リストを残してください。候補が空の状態では、使用可能なプロキシグループになりません。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

例の DIRECT は構造と直接接続のテストを示すためのものです。実際のプロキシ選択には、設定に存在する出力先名を指定してください。interval はテスト間隔を秒で指定する値で、接続タイムアウトではありません。tolerance は切り替え時の許容差であり、到達できないサーバーを修復するものでもありません。手動選択なら使えるのに自動グループで異常が続く場合は、テスト先とグループ内の参照を確認し、ポリシーグループの種類と違いも参照してください。

最後に、変更する条件を1つずつにして比較します。同じ出力先でネットワークを変更し、同じネットワークで出力先を変更し、同じ出力先で対象サイトを変更してください。1つの対象だけ失敗する場合は、その対象のルールやサービス側の制限を確認します。同じネットワークですべての出力先が失敗する場合は、ローカルファイアウォール、時刻、ネットワーク制限を確認してください。タイムアウト時間を繰り返し延長するより、安定して使える条件を記録するほうが原因の特定に役立ちます。変更後は実際のリクエストを再確認し、画面の疎通確認の色だけで復旧と判断しないでください。

サブスクリプションを更新できない：取得と解析を確認

サブスクリプションの更新は、ネットワーク経由で応答を取得する段階と、その応答を設定または出力先リストとして解析する段階に分かれます。「ダウンロード失敗」と「設定が無効」では確認すべき箇所が異なります。まずサブスクリプションの表示やログにあるエラー全文を確認し、HTTPステータス、解析メッセージ、発生時刻を記録してください。サブスクリプションURLには通常、アクセス情報が含まれます。フォーラム、スクリーンショット、オンライン変換ツールに掲載しないでください。相談時はドメインの種類、エラーコード、機密情報を削除した構造だけを共有し、元のURLは送らないでください。

URLとアカウントの状態を確認

サブスクリプション提供元のページからURL全体をコピーし直し、正しいHTTPSアドレスで始まっているか、末尾のパラメーターがチャットツールに切り詰められていないか確認してください。コピー時に日本語の句読点、改行、空白が混ざらないようにします。ログインページ、共有ページ、サブスクリプションAPIは別の種類のURLです。アカウントページが開けても、そのURLからクライアント用の設定が返されるとは限りません。URLが再発行されている場合、クライアントに古いURLが保存されていても、アクセス拒否が続くことがあります。

401または403が返される場合は、アカウントの認証、サブスクリプションの有効状態、APIのアクセス要件を確認してください。404の場合はパスが変更されていないか確認し、429の場合は再試行を止めて提供元の案内に従って待ちます。サーバーエラーは上流側の一時的な問題の可能性があり、設定を何度も削除しても解決しません。APIによってはリクエスト元のクライアントに応じて異なる形式を返します。ファイル拡張子だけで判断せず、提供元がClashまたはmihomo互換として明示しているサブスクリプションを選んでください。

ダウンロード経路と内容の形式を分けて確認

現在の出力先が使えず、サブスクリプションの更新もその出力先を経由する設定の場合、「接続に更新が必要、更新に接続が必要」という循環が起こります。サブスクリプションの更新設定を開き、直接接続、システムネットワーク、プロキシのどれを使っているか確認してください。可能であれば別の正常なネットワークから更新します。クライアントによっては画面のプロセスが更新を実行し、別のクライアントではコアが実行します。そのため、ブラウザーからアクセスできても、クライアントのリクエストが同じとは限りません。ログを確認してから更新経路を変更してください。

応答がログインページ、認証画面、ゲートウェイの案内ページの場合、クライアントはHTMLを設定として解析しようとし、先頭行の構文エラーなどが発生します。エラーを消すために先頭行を削除しないでください。応答内容を確認する場合は、ローカルに保存してテキストエディターで冒頭の構造を確認し、公開サイトにはアップロードしないでください。有効なYAMLでも、完全な設定とは限りません。出力先リストだけを含む内容は proxy-providers から参照する必要があり、常にメイン設定として直接有効化できるわけではありません。

構文を修正し、既存の設定を保護

YAMLを手動編集する場合はスペースでインデントし、タブを混在させないでください。特殊文字を含むパスワードやアドレスには適切な引用符を使います。エラーに表示された行番号は、解析を続けられなくなった位置を示しているだけの場合があります。実際の原因は1つ前の行のコロン、引用符、リストの階層にあるかもしれません。まず複製を保存し、関連箇所だけ変更してください。Web上の設定全体をサブスクリプションファイルに上書きしないでください。更新時に上書きされることが多く、一時的な変更を追跡しにくいうえ、失われる可能性があります。

サブスクリプションのダウンロードに成功しても選択可能な出力先がない場合は、アカウントから有効な内容が返されているか、フィルター式ですべての項目が除外されていないか確認してください。ログに存在しない名前へのポリシーグループ参照が表示される場合は、ローカルのオーバーライド、サブスクリプションの名前変更、グループ内の参照を確認します。最近追加したオーバーライドやマージスクリプトを無効にし、元のサブスクリプションを再読み込みしてください。元の設定で動作することを確認してから、項目を1つずつ戻します。標準的なインポート手順はサブスクリプションの追加ガイドを参照してください。

速度が遅い：応答時間と転送速度を切り分ける

Webページの表示が遅い、ダウンロード速度が低い、動画が止まる、音声が途切れるといった症状は、それぞれ原因が異なります。Webページは名前解決、ハンドシェイク、複数リソースのリクエストに影響されやすく、大容量ファイルは継続的な転送速度が重要です。リアルタイムアプリではパケットロスやジッターも影響します。まず遅いアプリ、対象、時間帯を記録し、直接接続でも遅いか確認してください。ポリシーグループの疎通確認からダウンロード速度を推測しないでください。短いリクエストにすばやく応答する出力先が、継続的な転送にも優れているとは限りません。

条件をそろえて比較する

同じ端末、同じネットワーク、同じ対象を使い、直接接続と手動で選んだ出力先をそれぞれテストします。比較中はクラウドストレージの同期、OSの更新、ほかの大容量通信を一時停止し、バックグラウンドの通信が影響しないようにしてください。Wi-Fiではルーターに近づき、必要に応じて有線接続と比較します。ローカルネットワーク内の転送も遅い場合は、電波強度、干渉、ネットワークアダプターを優先して確認します。特定のリモートサイトだけ遅い場合は、接続先のサービス、経路、アクセス元の出口に対する制限が関係している可能性があります。

複数回テストする場合は、異なるサイト、ファイル、時間帯の結果を比べず、条件をできるだけそろえてください。ブラウザーのキャッシュにより2回目の表示が大幅に速くなることがあります。ダウンロードサイトがサーバーを動的に割り当てる場合もあります。ブラウザーの開発者ツールにある「ネットワーク」パネルで、最初の応答を待つ時間、接続の確立、コンテンツのダウンロードにそれぞれどれだけかかるか確認できます。最初の応答まで時間がかかっても、帯域不足とは限りません。サーバー側の処理、遠回りの経路、接続の再試行が原因の可能性もあります。

ルールの振り分けとアプリの接続動作を確認

クライアントの「接続」を開き、対象ドメインまたはプロセスで絞り込みます。遅いリクエストに一致したルールと、実際の出力先を確認してください。1つのページが画像、スクリプト、APIを同時に読み込む場合、メインドメインだけを確認しても一部のリソースの問題を見落とすことがあります。広告ブロック、ブラウザー拡張機能、セキュリティソフトがリソースを遮断し、ページが待ち続ける場合もあります。原因を特定できていない段階でルールセット全体を変更せず、新しいブラウザープロファイルや拡張機能を一時的に無効にした状態で比較してください。

自動ポリシーグループが頻繁に切り替わると、アプリが再接続することがあります。継続的なダウンロードや長時間のセッションでは特に影響が出やすくなります。調査中は使用可能な出力先を1つに固定し、問題が解消するか確認してから、テスト間隔や切り替え許容差を調整してください。「常に最適」を狙って間隔を極端に短くしないでください。疎通確認自体も接続と通信量を消費します。ポリシーグループの動作については、url-test、fallback、load-balanceの解説を参照してください。

UDP、MTU、同時接続数を慎重に確認

動画やリアルタイム通信に問題があり、通常のWebページは表示できる場合は、アプリがUDPを使っているか、使用中のプロトコルや出力先、サーバーがその通信に対応しているか確認してください。ブラウザーのHTTP/3もUDPに依存するため、制限のあるネットワークでは何度か試行した後にフォールバックする場合があります。比較のためアプリの関連機能を一時的にオフにしてもかまいませんが、すべてのUDPを無効にするべきだとは限りません。音声通話、ゲーム、一部のトンネルプロトコルではUDPが必要です。長期的に無効化すると、別の問題が発生する可能性があります。

TUNモードで大容量ファイルの転送だけが止まり、小さなリクエストは正常な場合は、パスMTUが関係していないか調べてください。まず別のVPNが同時に動作していないことを確認します。そのうえで、クライアントが許容する範囲内でTUNのMTUを少しずつ下げ、変更する値は毎回1つにして接続を張り直します。すべてのネットワークに共通する最適値はありません。安定した改善が見られない場合は元の値に戻し、一時的な回避策を恒久設定として残さないでください。MTUのテスト結果はOSや回線の種類にも左右されるため、単一のコマンドの結果をそのまま適用しないでください。

最後に端末のリソース状況を確認します。クライアントが長時間にわたって異常にリソースを消費する場合は、大量のデバッグログ、重複したルール、複数のコアが同時に動いていないか確認してください。ディスク容量が不足すると、ログの書き込みも遅くなることがあります。デバッグレベルを解除し、重複した処理を減らしてから再テストします。ネットワークや出力先を変えると安定する場合は、その比較結果を記録してください。特定の対象だけ、どの経路でも遅い場合は、ローカルソフトの破損と決めつけず、対象サービスまたはサブスクリプション提供元に確認してください。

DNSの問題：名前解決の経路を確認

DNSの問題は、ドメインを開けない、初回接続に時間がかかる、LAN内の機器名を解決できない、ログに名前解決のタイムアウトが出るなどの形で現れます。まず、通常のドメインをOSがどう解決するか、コアが接続先のドメインをどう解決するか、プロキシサーバー自身のドメインをどう解決するかを分けて考えてください。3つの経路は別のコンポーネントが処理する場合があります。IPアドレスで直接接続できても、証明書や仮想ホストにはドメイン名が必要なため、HTTPSが正常とは限りません。IPアドレスへの接続を根本的な解決策にしないでください。

どのリゾルバーがリクエストを処理するか確認

OSで現在のネットワークインターフェースに設定されたDNSを確認し、次のコマンドで基本的な名前解決を調べます。コマンドの結果はOSの問い合わせ経路を示すもので、ブラウザーのセキュアDNSやコア内部の名前解決と一致するとは限りません。ブラウザーで暗号化DNSを有効にしている場合、OSのリゾルバーを経由しないことがあります。TUNでDNSハイジャックを使用している場合は、通常の問い合わせがコアに処理されることもあります。テスト前にそれらの機能が有効か記録してください。異なるツールの結果は、条件を確認しないまま比較できません。

# Windows
nslookup example.com
ipconfig /flushdns

# macOS / Linux：dig がインストールされている場合に使用
dig example.com A
dig example.com AAAA

キャッシュを消去しても、古い結果を削除できるだけで、上流DNSへの到達不能や設定ミスは修復できません。まず名前解決の経路を変更し、その後でOSとアプリのキャッシュを消去して再接続してください。問い合わせ結果の NXDOMAIN は該当する名前が見つからないことを示しますが、ドメイン自体が存在しないのか、上流からの応答に問題があるのかは引き続き確認が必要です。問い合わせのタイムアウトは、経路やサービス側の問題が考えられます。失敗をすべて「キャッシュ汚染」と決めつけたり、リゾルバーによってIPアドレスが違うだけでどちらかが誤りと判断したりしないでください。

fake-ipと初期解決の仕組みを確認

fake-ip はアプリに内部マッピング用のアドレスを返し、コアがその対応関係から実際のドメイン名を特定します。該当する設定で 198.18.0.0/16 の範囲内のアドレスが見えるのは正常な場合があり、対象サイトがそのアドレスに実際に設置されているわけではありません。アプリが古いマッピングを保持したままコアが再起動すると、接続に失敗することがあります。まず影響を受けたアプリを終了して開き直し、クライアントが案内する方法でDNSマッピングを消去してください。マッピングを回避するため、アドレス範囲全体を直接接続のルールに追加しないでください。

プロキシサーバーのドメイン名は、プロキシ接続を確立する前に名前解決できる必要があります。そうでないと起動時に依存関係の循環が発生します。mihomoの proxy-server-nameserver では、このようなドメイン名の解決に使うDNSサーバーを指定できます。default-nameserver はDNSの上流サーバー自体のドメイン名を解決するために使われます。以下の例は依存関係を示すものです。使用前に、指定するDNSサーバーに現在のネットワークから到達できることを確認してください。既存のクライアント設定と競合するDNS待ち受けポートを追加したり、サブスクリプション全体を直接置き換えたりしないでください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

LAN内のドメイン名とIPv4・IPv6の違いを確認

社内ネットワーク、家庭内ストレージ、ルーターのホスト名は、通常内部DNSに依存します。すべての問い合わせをパブリックDNSに送ると、これらの名前を解決できなくなることがあります。まずLAN内の端末が元々使用しているDNSサーバーを確認し、明確な内部ドメインのサフィックスには nameserver-policy で解決経路を指定してください。fake-ipとの互換性に問題がある場合は、必要なドメインだけをフィルタリングできます。ただし、フィルタリングしてもパブリックDNSに内部レコードを解決する機能が加わるわけではありません。その名前を解決できる上流DNSを設定する必要があります。

IPv4では正常でもIPv6の経路が不完全だと、アプリが先にIPv6で接続を試み、待機してからIPv4へ切り替わることがあります。AレコードとAAAAレコードを別々に確認し、ログで実際に接続されたアドレスファミリーを調べてください。比較のためクライアントのIPv6名前解決を一時的にオフにしてもかまいませんが、OSでIPv6を恒久的に無効化する必要があるとは限りません。ネットワークによっては完全な接続にIPv6が必要です。原因を確認したらルートまたは出力先の対応を修正し、必要なデュアルスタック設定を戻してください。

修復後は、一般公開サイト、ノードのドメイン名、よく使うLAN内サービスをそれぞれ確認します。公開Webサイトだけ復旧し、プリンターや社内システムが使えない状態では解決とはいえません。ルールとDNSの関係はルールベースの振り分け実践ガイドを参照してください。用語の違いが分からない場合は用語一覧で各フィールドがどの経路を担当するか確認してから、変更するか判断します。

システムプロキシが効かない：アプリごとの接続方法を確認

「システムプロキシ」は主に、プロキシのアドレスをOSに登録する機能です。登録された設定を参照するアプリだけが利用します。一方、TUNは仮想ネットワークインターフェースを通じて、ルーティング条件に合う通信を取り込みます。両者が作用するレイヤーは異なります。ブラウザーでは接続できてもターミナルから直接接続される場合、必ずしもクライアントの異常ではありません。ゲームや専用のダウンロードアプリが個別の接続設定を使うこともあります。まずプロキシを明示したリクエストが成功するか確認し、アプリ側の設定を修正するのかTUNを有効にするのか判断してください。すべての状況をノードの問題として扱わないでください。

ブラウザー、ターミナル、サービスを個別に確認

ブラウザーのプロキシ拡張機能がシステム設定を上書きしていないか確認し、重複するプロキシ管理機能をオフにしてからブラウザーを再起動します。Firefoxなどは独自のプロキシ設定を使う場合があります。システムプロキシを使用する設定になっているか、正しいローカルポートが指定されているか確認してください。次にクライアントの「接続」を開き、対象サイトにアクセスして該当リクエストが記録されるか確認します。記録がないことだけで断定はできませんが、プロキシを明示したリクエストが成功しているなら、通常はアプリ側を重点的に調べられます。

ターミナルのツールが環境変数を参照するかどうかは、プログラムによって異なります。以下の設定が適用されるのは現在のターミナルと、そこから起動するプロセスだけです。すでに起動しているプログラムには反映されません。ポートをクライアントの実際の値に変更し、同じ対象にアクセスして確認してください。NO_PROXY はプロキシを経由しない接続先を指定します。広すぎるドメイン範囲を設定しないでください。テスト後は一時的な変数を削除します。クライアントを終了した後も、ターミナルが存在しないローカルポートに接続しようとするのを防げます。

# PowerShell：現在のセッション
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
curl.exe -I https://example.com/

# 現在のセッションの一時設定を解除
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

# macOS / Linux：このコマンドだけに適用
https_proxy=http://127.0.0.1:7890 curl -I https://example.com/

HTTPSの接続先に使うプロキシのアドレスが http:// でも問題ありません。これはローカルプロキシへの接続方法を示すもので、接続先のWebサイトを平文通信にする意味ではありません。SOCKSポートとHTTPポートは自由に入れ替えて使えません。socks5h を使うツールでは、接続先のドメイン名をプロキシ側で解決する場合があり、ローカルDNSの問題を切り分けるのに役立ちます。バックグラウンドサービス、コンテナ、リモートセッションにはそれぞれ独自の環境があります。ホストOSのブラウザーで接続できても、同じ設定が適用されるとは限りません。

TUN起動後は権限とルーティングを確認

システムプロキシを参照しないアプリの通信を取り込む必要がある場合は、クライアントの案内に従ってサービスコンポーネントをインストールまたは有効化してからTUNをオンにします。スイッチをオンにした直後に戻る場合は、ログの権限、デバイス作成、ルーティングに関するエラーを確認してください。Windowsのサービスモード、macOSのシステム認証、Linuxのネットワーク管理権限はそれぞれ異なる仕組みです。あるOS向けの手順を別のOSにそのまま適用しないでください。まずClash Plusを選択肢として検討してください。他のクライアントの画面やシステム要件はダウンロードページで確認できます。

TUNが有効と表示されているのに通信が通らない場合は、別のVPN、仮想マシンのネットワーク、手動の静的ルート、アプリの除外ルールがないか確認してください。以下はmihomoで一般的なフィールドの例です。クライアントが対応するオーバーライド機能で統合し、画面が自動生成するTUN設定と重複しないようにしてください。auto-route はルートを自動設定し、auto-detect-interface は出力インターフェースの選択を補助します。必要なシステム権限の代わりにはならず、複雑なネットワークすべてで正しく自動認識できるとは限りません。

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

LANへの経路を維持し、残った設定を整理

TUNを有効にした後にLANへ接続できなくなった場合は、LANのサブネットが誤って取り込まれていないか、内部ドメイン名が正しいDNSに渡されているかを確認します。ルートの除外とルールによる直接接続は同じ操作ではありません。前者は通信をトンネルに入れるかを決め、後者はコアに入った通信の出力先を決めます。業務上の要件を確認してから、必要なサブネットだけを指定してください。広すぎる範囲を除外して、すべての通信を迂回させないでください。社内VPNに専用ルートがある場合は、組織のネットワークポリシーを優先してください。

トラブル対応が終わったら、まずTUNをオフにし、次にシステムプロキシをオフにしてクライアントを通常終了します。直接接続に戻せることを確認してください。異常終了後にプロキシ設定が残った場合は、OSのネットワーク設定から残ったアドレスを削除します。すぐにクライアントをアンインストールする必要はありません。ブラウザーとターミナルを使った詳しい確認手順はシステムプロキシが効かない場合の対処記事を参照してください。ルーターに導入する場合はOpenWrtのバイパスルーター構築ガイドを確認し、デスクトップのシステムプロキシの手順を流用しないでください。

クライアントがクラッシュする：画面とコアを切り分ける

ウィンドウが閉じる、通知領域からアイコンが消える、コアが停止する、設定を読み込めないのは、それぞれ異なる状態です。まずクライアントがバックグラウンドで動作しているか、システムプロキシがそのクライアントを指しているか、ログが出力され続けているかを確認してください。画面を開けないのにプロキシが使える場合は、画面のプロセスだけに問題がある可能性があります。ウィンドウが正常でもすべてのリクエストが失敗する場合は、コアが起動していない可能性があります。プログラムを何度も起動すると、プロセスの重複やポート競合が増えます。再起動する前にタスクマネージャーまたはシステムのアクティビティモニターで既存のプロセスを確認してください。

証拠と復元用データを先に保存

障害が発生する前に最後に行った操作を記録します。サブスクリプションの更新、オーバーライドの追加、TUNの有効化、ルールのインポート、クライアントの更新などが該当します。「設定」からログや設定フォルダーを開き、関連ファイルを保存してください。フォルダーの場所はクライアントとインストール方法によって異なるため、他のソフトの固定パスを流用しないでください。画面を開けない場合は、OSのアプリログやクラッシュレポートを参考にします。外部に共有する前に、サブスクリプションURL、パスワード、コントロール用インターフェースの認証情報、アクセス履歴が漏れるおそれのある内容を削除してください。

サブスクリプションの参照先、ユーザーオーバーライド、ルールファイル、ポリシーの選択履歴をバックアップします。生成中のランタイム設定だけをコピーしないでください。キャッシュや一時的なフィールドが混在していたり、次回起動時に読み込まれる元ファイルと異なったりする場合があります。データフォルダーを移動する前にプログラムを終了し、書き込み中のデータベースやファイルが破損しないようにします。復元用のバックアップは、アクセスを管理できるローカルフォルダーに保存してください。相談のために設定フォルダー全体を公開しないでください。

起動失敗の原因を確認

ログにアドレスが使用中と表示される場合は、どのプロセスがプロキシポートまたはコントロール用インターフェースのポートを使用しているか確認してください。以下のコマンドは7890の使用状況を調べるものです。実際の設定に合わせてポートを変更してください。待ち受け中のプロセスが見つかったら、強制終了する前にプログラム名を確認します。よくある原因は、古いクライアントがバックグラウンドで動作している、別のコアが同時に起動している、再起動の際に一時的にプロセスが重複していることです。ポートをいくつも変更するより、使用するインスタンスを1つに決めるほうが管理しやすくなります。

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

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

# Linux：待ち受けポートを確認
ss -lntp

コアが起動直後に終了する場合は、設定の解析エラー、ルールファイルの読み取り権限、ディスク容量、外部リソースの読み込み失敗を確認してください。最近追加したオーバーライドやルールプロバイダーを無効にし、以前動作していた設定を読み込みます。特定の設定だけで障害が起きる場合は、画面を再インストールするのではなく、まず設定を修正してください。ファイルに書き込めない場合は、インストール先とデータフォルダーのアクセス権を確認します。問題を回避するために、すべてのファイルを全ユーザーが書き込み可能な状態に変更しないでください。

ウィンドウが白くなる、画面コンポーネントのエラーが表示される場合は、クライアントのドキュメントでOSの実行コンポーネントとサポート対象を確認してください。セキュリティソフトの隔離履歴も確認し、どのファイルがどの理由でブロックされたかを調べます。保護機能をすべて無効にした状態を恒久的な解決策にしないでください。信頼できる配布元から再ダウンロードし、OSの案内に従って認証を設定します。インストーラーのアーキテクチャが端末に合っているか確認してください。古いOSでは新しい画面コンポーネントの要件を満たさない場合があります。対応情報はダウンロードページとプロジェクトの説明を確認してください。

データを消去せず、隔離してテスト

キャッシュやローカル状態の破損が疑われる場合は、クライアントを終了してからデータフォルダーの名前を変更し、保存しておきます。クライアントのドキュメントで案内されている方法で新しいフォルダーを作成してください。新しい環境で起動できたら、サブスクリプションとユーザーオーバーライドを1つずつ読み込み、問題の原因を特定します。古いフォルダーをすぐに削除したり、キャッシュ全体を一度に戻したりしないでください。ポータブル版とインストール版を使っている場合は、データの保存先を共有しているか確認します。同じ問題のある状態を参照したままでは、テストになりません。

クライアントを変更する必要がある場合は、ダウンロードページから現在のプラットフォームに対応するClash Plusを選ぶか、用途に合わせてClash Verge Rev、FlClashなどを選択してください。Clash for WindowsとClashX Metaはメンテナンスが終了しているため、新しいシステムの問題を解決する汎用手段としては推奨できません。復旧後は通常のプロキシ接続を先に確認し、次にTUNと自動更新を有効にして、最後にOS起動時の自動起動を設定します。プログラムの起動、ネットワークの取り込み、バックグラウンド権限の3つの経路を切り分けられ、再発時の調査もしやすくなります。

モバイル端末の問題：VPN、バックグラウンド動作、ネットワーク切り替え

モバイル端末のプロキシは通常、OSのVPN機能を使います。接続状態はバッテリー制御、バックグラウンド制限、Wi-Fiとモバイルデータ通信の切り替えにも影響されます。まず「システムVPNが切断されている」状態と「VPNは接続中だが通信に失敗する」状態を区別してください。前者では権限とプロセスの動作を確認し、後者では出力先、DNS、ネットワークの変化を確認します。AndroidとiOSでは権限の仕組みが異なります。デスクトップのシステムプロキシの説明をそのまま適用したり、ステータスバーのアイコンだけで通信がすべて転送されていると判断したりしないでください。

Android：VPNの許可とアプリ別設定を確認

初回接続時にOSのVPN許可を確認し、システムのVPN設定で現在どのアプリが接続を管理しているか確認してください。広告ブロック、ファイアウォール、別のVPNツールが同じ機能を使おうとして競合することがあります。調査中はほかのツールを終了してください。「常時接続VPN」や「VPNを使わない接続をブロック」が有効な場合、クライアントの停止後にすべての通信が遮断されることがあります。各設定の動作を理解してから一時的に無効にするか判断し、Wi-Fiの故障と誤認しないでください。

一部のアプリだけがプロキシを経由しない場合は、クライアントのアプリ別プロキシリストを確認してください。画面によって「選択したアプリだけをプロキシ経由にする」と「選択したアプリをプロキシから除外する」という逆の設定があります。同じアプリを選択しても結果は異なります。変更後は通常VPNを再接続し、対象アプリを完全に終了してから開き直します。仕事用プロファイル、アプリの複製、システムコンポーネントは別の識別情報を持つ場合があります。ホーム画面のアプリ名だけで判断せず、実際に使っているアプリのインスタンスを確認してください。

画面を消すと接続が切れる場合は、OSの「バッテリー」と「アプリ管理」を開き、クライアントのバックグラウンド動作を許可し、バックグラウンド通信が制限されていないか確認します。端末によっては自動起動の管理もあります。使用状況に合わせて必要な権限を付与してください。設定後、しばらく画面をロックしてから復帰し、同じ接続先にアクセスします。プロセスが再起動したことがログに記録されているかも確認してください。最近使ったアプリ一覧でロックするだけでは、バッテリー制限が解除されない場合があります。1つのアプリの問題を直すために、端末全体の省電力機能をオフにする必要もありません。

iOS：設定、許可、再接続を確認

iOSではClash Plusを利用できます。インストール方法はiOSダウンロードを参照してください。公式サイトはclashplus.ioです。クライアントを開いてサブスクリプションが有効になっていることを確認し、OSの案内に従ってVPN構成を追加して許可してください。接続直後に切断される場合は、クライアントのエラーログとOSのVPN一覧を確認し、古い構成や別のアプリが接続を繰り返していないか調べます。すべてのネットワーク設定を削除せず、競合している項目を無効にしてから1つずつ確認してください。

アプリによっては切り替え前の長時間接続を保持することがあります。出力先またはネットワークを変更した後は、VPNをいったん切断して再接続し、影響を受けるアプリも完全に終了してから開き直してください。OSでVPN接続中と表示されても、サブスクリプション内のすべての出力先に到達できるとは限りません。1つのサイトだけが失敗する場合は、ルールとDNSを確認します。すべてのリクエストが失敗する場合は、同じネットワークにつないだ別の端末と比較し、ネットワーク側の制限か確認してください。

ネットワークの切り替えとテザリングを個別に確認

Wi-Fiでは正常でモバイルデータ通信では失敗する場合、まずクライアントによるモバイルデータ通信がOSで許可されているか、通信容量が残っているか、低データモードで制限されていないか確認してください。次に同じ出力先を選んでテストし、ネットワークごとのUDPやIPv6の動作の違いを切り分けます。Wi-Fiとモバイルデータ通信を切り替えると、ローカルアドレスとルートが変わるため、既存の接続が失効することは珍しくありません。再接続で復旧する場合は、ネットワーク設定全体をリセットする前に、クライアントのバックグラウンド動作に問題がないか確認してください。

スマートフォン本体で接続できても、テザリング中のほかの端末の通信がスマートフォンのVPNを経由するとは限りません。共有通信が取り込まれるかはOSとクライアントの実装によるため、個別に確認してください。「LAN内接続を許可」は、ほかの端末からプロキシの待ち受け先に接続できるようにする設定です。ほかの端末のプロキシ設定を自動的に変更するものではありません。利用する場合は信頼できるネットワークだけで有効にし、待ち受けポートを公共ネットワークに公開しないでください。接続先端末にはスマートフォンのLAN内アドレスと正しいポートを設定する必要があります。

モバイル端末のトラブル対応後は、アプリを開いている状態、画面ロックからの復帰、ネットワーク切り替えの3つをそれぞれ確認してください。必要なバックグラウンド権限を残し、一時的に許可したLAN内の待ち受けを無効にして、普段使うモードに戻します。問題が続く場合は、端末のOS、クライアント名、障害が起きるネットワークの種類、発生時刻、実施した比較手順をまとめてください。原因の特定に役立つ情報はこれで十分です。元のサブスクリプションを添付する必要はありません。再設定はクイックスタートガイドを参照し、用語が分からない場合は用語解説を確認してください。