diagnostics / mihomo

Clashのトラブル対処ガイド

接続、サブスクリプション、DNS、プロキシ経路を症状別に確認

最も近い症状を選び、各章の手順に沿ってテストしてください。使い方ガイド ›では、インストールから初回接続までの手順を解説しています。このページは、すでに設定済みの環境で問題の原因を調べるためのガイドです。クライアントをまだインストールしていない場合は、ダウンロードページ ›でプラットフォームに合ったものを選び、初めて使う方はClash Plusもご検討ください。

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

まずクライアントのシステムプロキシとTUNモードをオフにし、普段から直接アクセスできるWebサイトを開いてみてください。TUNは仮想ネットワークアダプターを使って通信を取り込む方式です。いったん無効にすると、通常のネットワークに絞って原因を調べられます。直接接続も失敗する場合は、Wi-Fi、回線の認証、学校のネットワーク認証、ルーターの問題を先に確認してください。この状態でノードを何度も切り替えても、端末のネットワーク接続自体が必要なプロキシサーバーには届かないため、原因の特定が難しくなるだけです。

カーネルの起動を確認し、待ち受けポートを調べる

クライアントのログを開き、ローカルプロキシのポートが待ち受けを開始した記録を探してください。GUIが表示されていても、mihomoカーネルが動作しているとは限りません。設定の解析とリクエストの転送を担うのはカーネルです。ログが設定の読み込み段階で止まっている場合は、最初のエラーを確認し、設定ファイルのパス、インデント、ポートの競合を調べてください。最後の終了メッセージだけを見ても、前のエラーの結果であることが多いため、原因は分かりません。実際のポート番号を控え、以降のテストでは同じ番号を使ってください。

mihomoを単体でインストールして使っている場合は、まず次のコマンドで設定をテストできます。このコマンドで確認できるのは、指定ディレクトリの設定を読み込めるかどうかです。リモートノードが利用可能かどうかは確認できません。テストに通ったらカーネルを起動してください。GUIクライアントを使っている場合は、クライアントからカーネルを再起動するのが基本です。手動で別のプロセスを同時に起動すると、ポートを取り合う可能性があります。また、GUIクライアントの作業ディレクトリは、以下のデフォルトパスとは異なる場合があります。

mihomo -d ~/.config/mihomo -t

システム設定を介さずローカルプロキシを直接テストする

まず明示的にプロキシを指定するコマンドで、同じURLにアクセスしてください。明示的なプロキシ指定では、テストするプログラムに接続先のローカルポートを直接伝えるため、システムプロキシの設定状況に左右されません。以下の例では混合ポートを7890としています。実際のポートはクライアントの設定を確認してください。Windows PowerShellでは、コマンド名をcurl.exeとすると、端末ごとのコマンド名の解釈による違いを避けられます。テストに失敗した場合は、エラーメッセージと発生時刻を記録してください。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -I https://example.com
テスト結果確認する項目
ローカルポートに接続できないカーネルが起動しているか、ポート番号が正しいか、待ち受けアドレスが一致しているか
プロキシには接続できるが、リモートのリクエストがタイムアウトする実際の出口、ノードの接続状況、接続先サイト、ルール
コマンドは成功するが、ブラウザーでは失敗するシステムプロキシ、ブラウザー拡張機能、アプリ個別のプロキシ設定

ログからリクエストの経路をたどる

リクエストを1回送信したら、すぐに接続一覧を開き、接続先ドメイン、適用されたルール、最終的な出口を確認してください。ルールモードではルールに応じてプロキシまたは直接接続が選択されます。グローバルモードでは通常、グローバルポリシーグループにリクエストが渡されますが、そのグループで実際に何が選ばれているかは確認が必要です。切り分けのため一時的にグローバルモードにしてみてください。これで復旧するなら、問題はネットワーク全体ではなく、ルールまたはポリシーの選択にある可能性が高いです。テスト後は元のルールモードに戻してください。

特定のWebサイトだけ開けない場合は、別のWebサイトでも確認し、すべてのノードが使えないとすぐに判断しないでください。接続先のサービスでログインが必要な場合や、現在の出口IPアドレスが拒否されている場合もあります。クライアントを終了するとすべてのWebサイトに接続できなくなる場合は、システムにローカルプロキシの設定が残っていないか確認してください。プロキシアプリが終了しているのにシステムがそのアドレスへリクエストを送ると、端末全体がオフラインになったように見えます。残ったプロキシ設定を解除してから、診断を続けてください。

02 ノードがタイムアウトする：疎通テスト、接続ハンドシェイク、出口の問題を切り分ける

まず、どの段階でタイムアウトしているかを確認してください。クライアントのノードテストは、通常、ノード経由で特定のテストURLにアクセスするもので、サーバーに単純な疎通確認を行うものではありません。テストURLにアクセスできない、応答ステータスが想定と異なる、名前解決に失敗するといった場合も、タイムアウトと表示されることがあります。まずノードを1つ手動で選び、ブラウザーで実際に使いたいWebサイトにアクセスしてログと照らし合わせてください。一覧のテスト結果だけを根拠に、設定全体を削除しないでください。

ノード1つの問題か、グループ全体の問題かを確認する

まずノードを1つだけテストし、同じサブスクリプション内にある別のサーバーアドレスのノードも試してください。最初のノードだけ失敗する場合は、サービスの稼働状況、ノードの有効期限、接続パラメーターの変更を確認します。すべてのノードが同時に失敗する場合は、まずローカルネットワーク、サブスクリプションのアカウント、システム時刻、パブリックDNSの問題を切り分けてください。表示名が異なるノードでも同じサーバーを指している場合があるため、名前を変えるだけでは有効な比較にならないことがあります。

家庭のWi-Fiからスマートフォンのテザリングに切り替えるなど、接続するネットワークを1度変えてテストしてください。モバイルデータ通信量には注意が必要です。同じ設定がテザリングでは使えて元のネットワークでは使えない場合、元のネットワークのアクセス制限、ルーティング、名前解決が手がかりになります。どちらでも失敗する場合は、サブスクリプションやプロトコルのパラメーターを確認してください。ネットワーク、クライアント、設定を同時に変更すると、復旧しても何が原因だったか分からなくなります。

エラーの末尾ではなく、接続の各段階を確認する

ログでサーバーアドレスと失敗した段階を確認してください。ローカルでの名前解決に失敗している場合、サーバーアドレスを取得できていません。接続拒否は、通常、接続先ポートが接続を受け付けていないことを示します。接続タイムアウトは、経路上のパケット損失やサービスへの到達不能が原因かもしれません。暗号化ハンドシェイクに失敗した場合は、プロトコル、サーバー名、認証パラメーターを確認してください。これらの情報だけでサービス提供元の障害と断定はできませんが、ローカル設定とリモートサービスのどちらを調べるべきか判断できます。

OSの日付、時刻、タイムゾーンを確認し、自動時刻同期を有効にしてください。TLS接続では証明書の有効期間を検証するため、端末の時刻がずれているとネットワーク障害のようなハンドシェイクエラーが発生することがあります。証明書の名前が一致しないというログが出た場合は、サブスクリプションの内容が完全か、サービス提供元が指定するサーバー名になっているかを確認してください。証明書検証の無効化は通常の解決策ではありません。設定ミスを見えにくくし、接続の認証を弱めるおそれがあります。

# PowerShell：サービス提供元が案内する実際のアドレスとポートを確認
# 以下の予約済みドメインはコマンドの構造を示すためのものです
Test-NetConnection example.com -Port 443

上記のポートテストで確認できるのは、指定したアドレスへのTCP接続が確立するかどうかだけです。プロキシプロトコルの検証や、リクエスト全体のテストにはなりません。主にUDPを使うプロトコルでは、TCPテストの結果から利用可否を判断することもできません。サーバーが疎通確認を制限している場合や、アプリが異なる経路を使う場合もあるため、ポートテストは補助的な情報として扱ってください。プロキシ経由のリクエスト、カーネルログ、サービス提供元の案内を合わせて判断します。

ポリシーグループで出口が実際に切り替わったか確認する

ノードを選んだら、接続の詳細を開いて実際の出口を確認してください。ポリシーグループが別のグループを内包している場合、画面上では「自動選択」を選んでいても、実際にはその内側のノードが使われていることがあります。すでに確立された長時間接続が以前の出口を使い続ける場合もあります。まず該当する接続だけを閉じて、リクエストを再実行してください。ダウンロードや会議など、進行中のタスクに影響する可能性があるため、最初からすべての接続を切断しないでください。

最後にサブスクリプションを更新し、サービス提供元に連絡する場合は、問題が発生した時刻、ネットワークの種類、プロトコル名、実施済みの比較テストを伝えてください。サブスクリプションURL全体は送らないでください。更新後に一部のノードだけ復旧した場合は、使えるノードをそのまま利用し、残りの回線はサービス提供元の対応を待ちましょう。ログに未知のプロトコルや未対応のフィールドが明記されている場合は、カーネルの互換性を確認し、ダウンロードページで現在もメンテナンスされているクライアントを選んでください。安全設定をむやみに緩めるのは避けましょう。

03 サブスクリプションを取得できない：ダウンロード、解析、設定のマージを切り分ける

まず、サブスクリプションのどの段階で失敗しているかを特定してください。サブスクリプションURLは、ノードや設定全体を取得するためのアドレスです。インポート失敗の原因は、内容をダウンロードできないこともあれば、ダウンロードできても解析できないこともあります。サブスクリプション管理画面で更新結果を確認し、カーネルログの詳細なメッセージも調べてください。失敗の原因をすべてURLの無効化と決めつけないでください。また、アクセス用の認証情報が含まれている可能性があるため、非公開URLを公開の変換サイトに貼り付けてテストしないでください。

URLと応答内容を確認する

サービス提供元のアカウントページからURLをコピーし直してください。説明ページやQRコード画像のURLをコピーしていないか、余分な空白が入っていないかも確認します。チャットアプリでURLが途中までしかコピーされていない、末尾の句読点まで含まれているといったことにも注意してください。長いクエリパラメーターが含まれるURLでは、疑問符より前だけを残しても使えません。アカウントの更新やサブスクリプションURLの再発行後は、以前のURLが無効になっていることがあります。アカウントページに現在表示されているURLを使ってください。

更新エラーの種類を確認してください。認証エラーやアクセス禁止の場合は、アカウント権限、URLに含まれる認証情報、サービス提供元の制限を確認します。リソースが見つからない場合は、URLのパスが変更されている可能性があります。リクエストがタイムアウトする場合は、まず通常のネットワーク接続とサブスクリプションサイトへの到達性を確認してください。ログインページ、メンテナンスページ、アクセス確認ページが返されている場合、ダウンロード自体が成功と表示されても内容は有効な設定ではありません。明確な権限エラーを、何度も再試行して覆い隠さないでください。

サブスクリプションURLへのアクセスにプロキシが必要な場合は、更新時の接続経路をクライアントで選択できるか確認してください。使用可能な設定がすでにある場合は、それを有効にしてから更新できます。使えるノードがまったくない場合は、サービス提供元が案内する別の正規の取得方法を使ってください。見覚えのないドメインに更新先を変更したり、サブスクリプションの取得のために設定ディレクトリ全体を公開したりしないでください。

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

ノードの一覧と設定全体を区別してください。設定全体にはポート、ルール、ポリシーグループなどを含められます。一方、ノードの一覧はプロキシプロバイダーに登録して使う形式の場合があります。これはproxy-providersで定義されるデータソースです。クライアントのサブスクリプションインポート機能が、すべての共有リンク形式に対応しているとは限りません。サービス提供元がClashまたはmihomo用の形式を提供しているか確認し、適切なインポート方法を使ってください。ファイルの拡張子を変更しただけでは形式を変換できません。

YAMLのエラーに行番号が表示された場合は、ファイルをバックアップしたうえで、その行の前後にあるインデント、コロン、リスト記号を確認してください。YAMLでは階層をスペースで表し、タブとの混在は避けます。ただし、エラー行番号は前の行の引用符が閉じていないことによる影響を示している場合もあります。ダウンロードした設定を大幅に手作業で書き換えるのは避け、まず元のファイルを再取得してください。コピー、保存、自動マージの際に破損していないか確認しましょう。

# プロキシプロバイダーのフィールド階層を示す例です。完全な設定に組み込んでください。
# 構造の説明用に予約済みドメインを使用しています。実際にインポートできるサブスクリプションURLではありません。
proxy-providers:
  subscription:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/subscription.yaml
    interval: 3600

有効な設定を残し、上書きや更新の問題を特定する

元のサブスクリプションはダウンロードできるのに、ローカルオーバーライドを有効にした場合だけ起動に失敗するなら、問題はマージ処理に絞られます。オーバーライドは、サブスクリプションにローカル設定を追加するクライアントの機能で、DNS、ルール、ポートを変更することがあります。まず最近追加したオーバーライドを1つ無効にし、実行用設定を再生成してください。クライアントが自動生成した一時ファイルを直接編集するのは避けましょう。次回更新時に変更が上書きされ、同じ問題が繰り返し起きているように見えることがあります。

更新は成功したのに新しいノードが表示されない場合は、更新した設定が現在有効になっているか、ポリシーグループが新しいノードを除外していないか確認してください。自動更新と、現在使う設定の切り替えは別の操作です。ローカルファイルへの書き込み権限とディスクの空き容量も確認してください。最後に使えた設定を残し、新しい設定のテストが終わってから切り替えましょう。サブスクリプションの基本的な追加方法は、サブスクリプションのインポート方法で確認できます。

04 通信速度が遅い：転送速度、応答時間、特定サイトの制限を切り分ける

まず、どのように遅いかを整理してください。Webページを開くまで長く待つ、ダウンロード開始後の速度が遅い、動画再生が時々止まるという現象は、それぞれ原因が異なります。最初のケースはDNSや接続ハンドシェイク、2つ目は継続的な転送速度、最後のケースは配信サーバーの状況が関係している可能性があります。同じ時間帯、同じURL、同じネットワークでの状況を記録して比較してください。ノードテストの応答時間を、そのままダウンロード速度とみなさないでください。

再現性のある条件で比較する

クラウドストレージの同期、OSの更新、その他の大容量通信を一時停止し、同じ端末で直接接続とプロキシ接続のリソースをそれぞれテストしてください。直接接続も遅い場合は、Wi-Fiの電波強度、ルーターの負荷、回線自体を先に確認します。Wi-Fiに接続済みと表示されても、通信が安定しているとは限りません。ルーターに近づくか、可能であれば有線接続に切り替えてください。テスト中は端末を移動しないようにし、電波状況の変化が結果に影響しないようにします。

信頼できる配信元からサイズが適度なファイルを1つだけダウンロードし、複数の速度測定ツールを同時に動かさないでください。短時間に多くの接続を使うテストは帯域を取り合い、接続先で制限されることもあるため、普段の利用状況を反映しない場合があります。ノードを比較するときは同じリソースを使い、実際の出口を記録してください。測定サイトは所在地やサービス能力が異なるため、結果をそのまま横並びで比較することはできません。

接続の詳細から実際のボトルネックを確認する

遅いリクエストにどのルールが適用されたか確認してください。Webサイトのメインページと画像、動画が別ドメインで配信されている場合があります。メインドメインだけがプロキシ経由で、関連リソースは使えない直接接続に流れていると、読み込みに失敗することがあります。反対に、近くから直接接続できるリソースを遠隔の出口経由にすると、待ち時間が長くなります。まず接続一覧から、失敗または遅延している具体的なリソースのドメインを探し、適切な範囲のルールを追加してください。広すぎるキーワードでネットワーク全体にルールを適用しないでください。

特定のサービスだけ遅い場合は、同じノードで別のサービスにアクセスし、さらにノードを変えて元のサービスにアクセスしてください。ノードを変えて改善する場合は、出口経路や接続先サービスによる出口ごとの振り分けが関係している可能性があります。すべてのノードで同じサービスが遅い場合は、サービス自体、アカウント制限、クライアントの再生設定を確認しましょう。動画サイトのバッファー表示は、プロキシカーネルの転送速度を直接測るものではありません。接続一覧と実際の再生状況を合わせて確認してください。

症状次に確認すること
最初の読み込みが遅く、その後は正常DNS、ハンドシェイク時間、接続の再利用、初回リソースの読み込みを確認
すべてのダウンロード速度が継続して遅い接続回線の帯域、出口の混雑、端末のリソース使用率を確認
一部のリソースだけ遅いリソースのドメイン、ルールで選ばれた出口、接続先サイトの制限を確認

プロトコルやネットワークアダプターの設定は慎重に変更する

クライアントと他のVPN、通信フィルターツールが同じ接続を二重に処理していないか確認してください。二重に通信を取り込むと処理負荷が増え、遠回りになることもあります。すぐにアンインストールするのではなく、まずどちらか1つを終了してテストしましょう。TUNを有効にしたときだけ遅くなる場合は、ルーティング、DNSの取り込み、セキュリティソフトによるブロックを確認してください。システムプロキシモードで問題がなければ、当面はそちらで作業し、TUNの互換性を別途調べられます。

通信速度が遅いときに、最初からMTUを変更しないでください。MTUは1回のネットワーク通信で送れるパケットサイズの上限です。経路と合わないと一部の接続が停止することがありますが、値を小さくすればよいわけではありません。特定のネットワークで大きなリクエストが頻繁に止まり、別のネットワークに切り替えると解消する場合に限り、バックアップを取ってから慎重に調整してください。変更前後の値と同じリクエストの結果を記録し、改善しなければ元に戻します。

最後にCPU使用率、端末の温度、省電力状態を確認してください。古い端末では、暗号化転送、多数の接続、詳細ログの記録がリソースを消費することがあります。まず通常のログレベルに戻し、不要なバックグラウンド接続を減らしてから様子を見ましょう。原因が分からないうちに、いわゆる高速化用の設定をまとめて追加しないでください。設定同士の影響で、問題の再現や切り分けが難しくなります。速度の改善は、一度の測定で最高値が出たかではなく、普段の利用環境が安定して改善したかで判断してください。

05 DNSの問題：システム、カーネル、プロキシ出口の名前解決を切り分ける

まず、名前解決がどこで行われるかを確認してください。DNSはドメイン名をネットワークアドレスに変換する仕組みで、OS、ブラウザー、mihomoがそれぞれ問い合わせを行う場合があります。OSのコマンドでアドレスを取得できても、プロキシカーネルが同じ結果を使うとは限りません。ブラウザーでセキュアDNSが有効になっていると、想定した経路を通らないこともあります。ドメインに関するエラーが出たら、まずどのプログラムが失敗を報告したかを特定し、実際に使われた名前解決の方法を確認してください。

異なる接続方法で問題の段階を切り分ける

まずOSの名前解決ツールで普段使えるドメインを検索し、次に明示的にHTTPプロキシを指定するコマンドで同じドメインにアクセスしてください。前者で確認できるのはOSによる名前解決、後者では接続先ドメインをローカルプロキシに渡して処理します。結果が同じになるとは限りません。URLをIPアドレスに置き換えるだけのテストは避けてください。HTTPSでは証明書の名前とサイトの識別も関係するため、IPアドレスへの直接アクセスに失敗してもネットワーク切断の証拠にはなりません。一般ユーザー向けの最終確認方法としても適していません。

nslookup example.com
curl --proxy http://127.0.0.1:7890 -I https://example.com

# socks5hは、接続先ドメインの名前解決をSOCKSプロキシに任せる指定です
curl --proxy socks5h://127.0.0.1:7890 -I https://example.com

比較テストを始める前に、プロキシのポート番号と動作モードを記録してください。SOCKSではローカルでの名前解決とプロキシ側での名前解決は異なり、コマンドに特定の接尾辞があるかどうかで、どこで解決するかが変わります。システムの名前解決に失敗してもプロキシ経由のリクエストが成功する場合は、OSのDNSを優先して調べてください。システムの名前解決は正常なのにカーネルログにエラーが出る場合は、カーネルのDNS設定、上流のDNSサービスへの接続、確立前のプロキシ接続に名前解決が依存していないかを確認します。

設定の階層と名前解決の依存関係を確認する

実際に読み込まれている設定を開き、dns.enable が有効か確認したうえで、nameserver の参照先を確認します。これは通常のドメイン名前解決に使う上流サーバーのリストです。proxy-server-nameserver は、プロキシサーバー自体のドメイン名を解決するために使えます。ノードのドメイン名を解決するために、そのノードへの接続が必要だと、依存関係が循環するおそれがあります。まずサーバー名を独立して解決できる経路を確保してから、ほかのドメインを設定してください。

# 診断用のDNS設定例です。既存の完全な設定に統合してください。
# 上流DNSは、現在のネットワークからの到達性と用途に応じて選んでください。
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

Fake IPの仕組みを理解してから、アドレスに異常があるか判断してください。このモードではドメインに予約済みアドレスを割り当て、後続の接続でカーネルが接続先を復元します。そのため、予約済みアドレスが表示されても、名前解決が壊れているとは限りません。確認すべきなのは、その後の接続が正しく取り込まれているかどうかです。アプリが仮想アドレスを取得したのにプロキシを経由せず直接アクセスすると、失敗することがあります。その場合は通信の取り込み範囲を確認するか、互換性の問題が確認されたドメインだけを適切にフィルタリングしてください。DNS設定全体を消去する必要はありません。

キャッシュ、IPv6、ブラウザーの設定を個別に確認する

DNSを変更しても、既存の接続やキャッシュには以前の結果が残っていることがあります。まず対象アプリの該当接続を閉じ、クライアントの手順に従ってDNSキャッシュを更新してから再アクセスしてください。必要であれば対象アプリを再起動します。最初から端末全体のネットワーク設定をリセットしないでください。ブラウザーで独自のセキュアDNSが有効になっている場合は、一時的に無効にして比較できます。元の設定を記録し、問題の確認後にどの名前解決経路を使うか決めてください。

IPv6対応ネットワークでだけ問題が起きる場合は、アドレスファミリーとルーティングが一致しているか、それぞれ確認してください。IPv6アドレスを取得できても、そのアドレスへの経路が使えるとは限りません。プロキシがIPv6に対応していても、ローカルネットワークがIPv6に対応しているとは限りません。必要に応じて一時的に片方のアドレスファミリーだけで比較できますが、OSのIPv6を恒久的に無効化することを一般的な解決策にしないでください。復旧後は、接続ネットワーク、ルール、プロキシ出口のどれが原因だったか確認します。

TUNを使っている場合は、DNSリクエストが正しく取り込まれているか、LAN内の端末や社内ドメインにローカルDNSが必要かも確認してください。社内ドメインをすべてパブリックDNSに送らないでください。通常、そのネットワーク内のDNSでしか解決できません。設定項目の詳しい関係や用途別の設定例は、mihomoのDNS設定を詳しく解説で確認できます。設定を変更するたびに、パブリックサイトと社内リソースの両方で動作を確認してください。

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

まず、システムプロキシと通信の取り込みを区別してください。システムプロキシは、OSにプロキシアドレスを登録し、その設定を参照するアプリで使う仕組みです。すべての接続を強制的に転送するわけではありません。ターミナルツール、ゲーム、バックグラウンドサービス、一部のストアアプリは同じ設定を読み込まないことがあります。スイッチがオンでも、クライアントが設定を書き込もうとしていることしか分かりません。すべてのアプリがプロキシを使っている証明にはなりません。まず明示的にプロキシを指定してテストし、カーネル自体が使えることを確認してください。

システム設定が実際に反映されているか確認する

OSのネットワーク設定を開き、プロキシサーバーのアドレスとポートを確認してください。自動構成スクリプトも同時に有効になっていないか確認します。クライアントがローカルのループバックアドレスで待ち受けている場合、システム設定でも該当するローカルアドレスを指定し、ポート番号を現在の実行設定と一致させてください。他のガイドに記載されたポート番号をそのまま使わないでください。設定を保存してもすぐに元に戻る場合は、別のプロキシツール、デバイス管理ポリシー、セキュリティソフトが設定を継続的に書き換えていないか確認します。

Windowsではネットワーク関連のコンポーネントによって参照するプロキシ設定が異なるため、ブラウザーでは使えてもバックグラウンドのプログラムでは使えないことがあります。macOSでは現在のネットワークサービスを確認してください。以前Wi-Fi向けに設定したプロキシが、後から接続した有線ネットワークにも適用されるとは限りません。Linuxデスクトップ環境のネットワークプロキシ設定も、すべてのコマンドラインプログラムに適用されるとは限りません。まず対象アプリを特定し、そのアプリが対応する方法で設定してください。複数のシステム層を一度に変更しないようにしましょう。

ブラウザーとターミナルをそれぞれテストする

ブラウザーでは、プロキシを制御する拡張機能を一時的に無効にしてから、ブラウザーを完全に終了し、再起動してテストしてください。拡張機能によってはシステム設定を上書きします。シークレットウィンドウでも、企業ポリシーや拡張機能の権限がすべて無効になるとは限りません。ブラウザー独自のプロキシ設定がシステム設定に従っているか確認し、新しいリクエストを送信して接続一覧を見てください。ページが開けてもカーネルに新しい接続がない場合は、キャッシュされたページではないかも確認しましょう。画面表示だけで通信経路を判断しないでください。

ターミナルでは、まずコマンドの引数でテストし、その後必要に応じて環境変数を設定してください。環境変数はプロセスに設定を渡す仕組みで、通常は新しく起動する子プロセスにだけ適用されます。すでに起動しているすべてのターミナルウィンドウの設定が自動で変わるわけではありません。以下の例では、現在のshellセッションに一般的な変数を設定します。ツールによって対応する変数名が異なる場合があります。ビルドツール、パッケージマネージャー、リモート開発環境を使う場合は、各ツールのプロキシ設定に関するドキュメントも確認してください。

# macOS / Linux：現在のshellと、以降に起動する子プロセスにのみ適用
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

# テスト後に設定を解除
unset http_proxy https_proxy no_proxy

https_proxyはHTTPSの接続先に使う環境変数です。変数の値にローカルHTTPプロキシのアドレスを指定することもできます。接続先URLがHTTPSだからといって、ローカルアドレスのプロトコルもHTTPSに変更する必要はありません。既存のALL_PROXYや大文字の変数名、ツール内部の設定も確認し、すでに停止したポートを参照する設定が残っていないか調べてください。クライアントを終了した後は、ターミナルに保存されたプロキシ変数も合わせて解除する必要があります。

必要な場合にのみTUNを使い、除外設定を確認する

プロキシ設定に対応していないアプリを使う必要がある場合は、TUNの利用を検討してください。有効にする前に、クライアントに必要な権限があること、サービスモードや仮想ネットワークアダプターが正常に起動したこと、カーネルログにルーティングエラーがないことを確認します。サービスモードは、バックグラウンドサービスに権限が必要な処理を任せる仕組みです。画面を何度も管理者として起動するだけでは、問題の診断になりません。有効にした後、社内ネットワークに接続できなくなったら、まずTUNを無効にして接続を復旧し、除外ルートと内部DNSを確認してください。

最後にバイパスリストを確認してください。アプリによってはローカルアドレスの除外、特定ドメインへの直接接続、独自のネットワーク分離が設定されている場合があります。該当条件に一致した接続がプロキシを通らないのは正常な動作です。コンテナ、仮想マシン、リモート開発環境のループバックアドレスは、それぞれの環境を指すため、ホスト端末のポート番号をそのまま使えるとは限りません。別の端末からプロキシにアクセスできるようにする場合は、アクセス制御を明確にしてください。通常のローカル利用では、LANからのアクセスを無効にしておきましょう。詳しい比較手順はブラウザーとターミナルを分けてトラブルシューティングで確認できます。

07 クライアントがクラッシュする：ログを保存し、競合を切り分けて設定を戻す

まず、終了したのがGUIかカーネルかを確認してください。画面が突然消える、画面は表示されたまま接続だけが切れる、起動後にバックグラウンドサービスが繰り返し再起動する、といった症状はそれぞれ異なる箇所の問題を示している可能性があります。ソフトの起動時、サブスクリプションの更新後、特定機能の有効化後など、再現する操作を記録してください。アプリのデータディレクトリ全体をすぐに削除しないでください。ログ、設定、復旧の手がかりがまとめて失われ、サブスクリプションの認証情報やローカルルールを取り戻せなくなることがあります。

発生時の状態を保存し、設定を読み込めるか確認する

画面を開ける場合は、クライアントに用意されているログや設定ディレクトリへのリンクを使ってください。画面を開けない場合は、クライアントのドキュメントを参照してデータディレクトリを見つけ、設定、オーバーライドルール、直近のログを非公開の場所にコピーします。バックアップにも機密情報が含まれる可能性があるため、公開フォーラムへそのままアップロードしないでください。スクリーンショットにはエラーの種類、ファイル名、発生順序が分かる情報を残しつつ、サブスクリプションURLと認証情報を隠してください。質問のために情報をむやみに公開しないようにしましょう。

設定変更の直後に問題が起きた場合は、まず直近の変更を元に戻し、設定テストを実行してください。構文が正しくても、すべてのリソースを読み込めるとは限りません。ログにルールファイルがない、プロキシグループの参照先が間違っている、パスへのアクセス権がないといったエラーが続くことがあります。相対パスがどの作業ディレクトリを基準としているか確認してください。端末内にファイルが存在するかどうかだけでは不十分です。GUIクライアントが生成する設定は元のサブスクリプションと異なるため、実際にカーネルへ渡されるファイルを調べてください。

ポートの競合と実行権限を確認する

ログにアドレスが使用中と表示された場合は、別のクライアントや古いカーネルプロセスが動作していないか確認してください。同じポートを複数の通常の待ち受けプロセスで同時に使用することはできません。以下のコマンドでは、ポートを使っているプロセスを特定する手がかりを確認できますが、プロセスを自動終了することはありません。プロセスIDが分かったら、タスクマネージャーなどのシステムツールでプログラム名を確認してください。ネット上の一括終了コマンドをそのまま実行して、別のサービスを誤って停止しないようにしましょう。

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

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

使用中のポートが古いクライアントのものなら、正常に終了してから現在のクライアントを再起動してください。ポートが別の必要なサービスに使われている場合は、クライアントで空いているポートに変更し、システムプロキシとターミナルの環境変数も合わせて更新します。設定を1か所だけ変更してテストを始めないでください。アプリが古いポートに接続し続け、ポート競合が接続拒否のように見えることがあります。変更後はログ、システム設定、明示的なテストコマンドで同じポートが使われていることを確認してください。

権限不足のエラーが出た場合は、設定ディレクトリが読み取り専用になっていないか、別のアカウントからコピーされていないか、セキュリティソフトがカーネルや仮想ネットワークアダプターの動作をブロックしていないか確認してください。保護機能をすべて無効にするのは避けましょう。まずOSの通知を確認し、ブロックされたファイルのパスと入手元を特定してから、必要なコンポーネントだけを許可します。インストールパッケージのアーキテクチャも端末に合わせてください。特にCPUの異なるmacOSやLinuxでは、拡張子だけで判断できません。

すべて消去せず、必要最小限の復旧を行う

まずTUNを無効にし、新しく追加したオーバーライドを停止して、最後に使えた設定に戻します。基本画面とカーネルが安定して動くか確認してください。ユーザーデータの破損を調べる必要がある場合は、クライアントの方法に従って独立したテスト環境を作るか、完全なバックアップを取ったうえで関連設定を一時的に移動します。ファイルをすべて恒久的に削除するのは避けましょう。テスト環境で復旧したら、サブスクリプション、ルール、高度な設定を1つずつ追加し、そのたびに起動ログを確認してください。

特定のクライアントだけ終了し続け、同じサブスクリプションがメンテナンス中の別のクライアントでは使える場合は、ログを保存して該当プロジェクトに報告してください。クライアントを変更するときは、クライアントのダウンロードページでプラットフォームに合ったバージョンを選び、複数のプロキシクライアントで同時に通信を取り込まないようにしてください。詳しいロールバック手順はクライアントの起動時にクラッシュする場合の対処法で確認できます。連続起動、サブスクリプション更新、正常終了をすべて確認してから、古いバックアップを整理してください。

08 モバイル端末の問題：VPNの許可、バックグラウンド制限、ネットワーク切り替えを確認する

まずアプリを前面に表示したまま接続テストを行い、その後、画面をロックするかバックグラウンドに切り替えて動作を確認してください。モバイルOSはバックグラウンド動作、ネットワーク権限、VPN接続を管理します。デスクトップで同じ設定が使えても、スマートフォンで同じ権限や実行時間が得られるとは限りません。前面では正常でロック後に切断する場合は、バックグラウンド制限を確認してください。最初から接続できない場合は、権限、サブスクリプション、ノードを確認します。モバイル端末の問題をすべて省電力設定のせいにしないでください。

Android：VPNの許可とバックグラウンド動作を確認する

初回接続時は、OSのダイアログでVPN接続の確立を許可してください。また、必要なVPN接続を他のアプリが使用していないか確認します。ここでいうVPNはOSが提供する通信の転送機能であり、特定のプロキシプロトコルを使うという意味ではありません。広告ブロック、企業ネットワークへの接続、その他のネットワークツールも同じ機能を使うことがあります。そのうち1つを有効にすると、別の接続が置き換えられる場合があります。まず他の通信取り込みツールを一時停止し、Clashクライアントだけでテストしてください。

OSのアプリ設定で、バッテリー最適化、バックグラウンド動作、データ使用の権限を確認してください。メニューの名称は端末によって異なるため、実際の設定画面に表示される項目を基準に、使用するクライアントのバックグラウンド動作を許可します。最近使ったアプリの一覧にカードが残っていても、サービスが動作し続けているとは限りません。画面をしばらくロックした後、カーネルログを再確認し、サービスが停止したのか、サービスは動作していてネットワーク接続だけを再確立する必要があるのか判断してください。

アプリごとのプロキシ設定が有効か確認してください。アプリがバイパスリストに追加されていたり、選択したアプリだけをプロキシするモードになっていたりする場合があります。新しくインストールしたアプリが選択されていないと、そのアプリだけプロキシを使わないように見えます。設定後は対象アプリを再起動し、接続一覧でリクエストを確認してください。AndroidのプライベートDNSも名前解決に影響することがあります。ドメインの問題が起きたら、一時的にOSのデフォルト設定に切り替えて比較し、必要に応じて元の設定に戻してください。

iOS：トンネルの状態、ネットワーク権限、リソース更新を切り分ける

iOSでは、まずiOSのダウンロードページからClash Plusをインストールし、OSの案内に従ってVPN構成の追加を許可してください。OSのVPNアイコンが表示されても、トンネルが接続状態になっていることしか分かりません。ノード、ルール、接続先サービスが利用可能である証拠ではありません。クライアントに戻って現在のサブスクリプション、選択中の出口、直近のログを確認し、新しいリクエストを送信してください。特定のアプリだけ問題が起きる場合は、モバイルデータ通信の使用が許可されているかも確認します。

LAN内のリソースに接続できない場合は、必要なローカルネットワークへのアクセス権をアプリに許可しているか、内部アドレスが誤ってプロキシに送られていないか確認してください。アクセス権と通信の振り分けは別の問題です。直接接続ルールを追加しても、OSの許可設定の代わりにはなりません。大規模な設定やルールリソースを更新した後に切断が起きた場合は、不要なルールセットや並行処理を減らしてからシステムログを確認してください。接続を復旧するために、すべてのサブスクリプションを一度に削除しないでください。

ネットワークを切り替えて再確認し、問い合わせ用の情報を整理する

Wi-Fiからモバイルデータ通信に切り替えると、以前の接続が使えなくなることがあります。切り替え先のネットワークでは、IPv6、DNS、アクセス制限も異なる可能性があります。OSのネットワークが安定するまで待ってからプロキシ接続を確立し直し、対象アプリの以前のリクエストを閉じてテストしてください。特定のWi-Fiだけで失敗する場合は、Webページでのログイン認証が必要か確認します。まずプロキシを一時停止して認証を完了し、その後接続を再開してください。認証ページが誤ってリモート出口に送られるのを防げます。

「常時接続VPN」や「VPN以外の接続をブロック」といったOSのポリシーを有効にする場合は、切断時の動作が変わることを理解しておいてください。トンネルが一時的に失敗すると、端末全体がオフラインになる場合があります。これはポリシーによる想定動作で、Wi-Fiの故障とは限りません。トラブルシューティングでは元の設定を記録し、比較のため一時的に制限を解除してみてください。テスト後は必要な保護レベルに応じて設定を戻し、意図しないままシステムポリシーを長期間変更しないようにしましょう。

最後に、再現可能な状況説明をまとめてください。端末のOS、クライアント名、接続ネットワーク、前面とバックグラウンドでの違い、特定のアプリだけで失敗するかどうか、機密情報を伏せた最初のエラーを記載します。サブスクリプション全体、アカウントのスクリーンショット、設定ファイル一式は送らないでください。基本事項はよくある質問と用語集で確認できます。インストールから初回接続までやり直す場合は、使い方ガイドに戻り、まず最小限の設定で接続を復旧してから、高度な機能を1つずつ有効にしてください。