CLASH / TROUBLESHOOTING

Clash トラブル対処
接続・サブスクリプション・システムプロキシ

症状を手がかりに、ネットワーク、設定、ノード、ルール、通信の取り込みを順に確認します。変更は一度に一つだけにし、元に戻せるよう設定を保存してから、同じアプリとアドレスで再テストしてください。

初めて使う場合は、まずClash 入門ガイドを読み、インストール、サブスクリプションの追加、接続確認を済ませてください。このページでは、すでにクライアントを設定していて、具体的な問題の原因を調べたい場合の手順を紹介します。ボタン名はクライアントによって異なるため、実際のログ、接続履歴、適用中の設定をもとに判断してください。

ネットに接続できない：まず原因の層を切り分ける

「Clashを起動するとWebページが開かない」だけでは、ノードの障害とは限りません。ネットワーク認証が済んでいない、システムプロキシが古いポートを参照している、ルールで通信が拒否されている、DNSの応答がないなど、原因が異なってもブラウザーには同じようなエラーが表示されることがあります。まず、クライアントの起動前後どちらで問題が起きるか、すべてのアプリで発生するのか特定のサイトやアプリだけなのかを確認してください。

通信の取り込みを停止し、通常のネットワークを確認する

クライアントでシステムプロキシとTUNモードを無効にし、クライアントのウィンドウを開いたまま、普段そのまま開けるWebサイトにアクセスします。それでも失敗する場合は、Wi-Fiの接続状態、ゲートウェイへの到達性、ホテルや大学のネットワークでWebログインが必要かを確認してください。通常のネットワークが復旧する前にノードを何度も切り替えると、ネットワーク自体の問題とプロキシの出口の問題を区別しにくくなります。

クライアントを終了するとネットワークが使えなくなる場合は、OSのネットワーク設定に手動プロキシが残っていないか確認してください。先にアドレスとポートを記録し、使われていないプロキシ設定を無効にします。組織管理の端末ではプロキシがネットワークポリシーの一部の場合があるため、安易に削除しないでください。通常のネットワークを復旧したらクライアントを再起動し、最初はシステムプロキシだけを有効にしてテストします。仮想ネットワークアダプターやカスタムDNSを同時に設定するのは避けてください。

接続履歴を確認し、通信がコアに届いているか調べる

接続一覧またはログ画面を開き、古い記録を消してから、確認しやすいアドレスに再アクセスします。該当する接続が記録されていれば、リクエストは少なくともコアに届いています。適用ルール、出口のポリシー、エラーの原因を確認してください。記録がまったくない場合は、アプリがシステムプロキシに従っているか、ブラウザーに個別のプロキシ設定がないか、コアが実際に起動しているかを優先して調べます。画面に「実行中」と表示されていても、ポートが利用可能とは限りません。

接続履歴に表示される拒否、名前解決失敗、接続タイムアウトは、それぞれ原因の層が異なります。拒否の場合はルールや出口のポリシー、名前解決失敗の場合はDNS、接続タイムアウトの場合はノードのアドレスとネットワーク経路を確認します。エラーの最後の行だけで判断せず、接続先ドメイン、適用されたポリシーグループ、最終的に選択されたノードを記録してください。バックグラウンドの更新失敗が同じログ画面に表示されても、現在のWebアクセスに影響しているとは限りません。

ルールによる振り分け：適用順と最終出口を確認する

ルールモードではルールが順番に評価され、通常は最初に一致したルールで通信先が決まります。問題の接続にどのルールが適用されたかを確認し、そのルールが参照するポリシーグループが存在し、グループ内で有効な選択がされているかを調べます。グローバルモードでは使えるのにルールモードで失敗する場合は、クライアントを再インストールする前に、振り分け設定を重点的に確認してください。グローバルモードは比較テストには使えますが、すべてのサイトを同じ出口に通すのが適切だという証明にはなりません。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

この例は、Proxyという名前のポリシーグループがすでに存在することを前提としています。完全な設定なしでは動作しません。最後のMATCHは、それ以前のルールに一致しなかった接続を処理します。グループ名は定義と完全に一致させ、大文字・小文字も揃えてください。ドメインルールは接続にドメイン情報が残っている場合に利用され、IPルールは名前解決を発生させることがあります。そのため、同じサイトへの接続でも別々のルールが適用される場合があります。

変更を最小限にして復旧を確認する

利用できることを確認済みのノードを選び、通信の取り込み方式は初期設定のまま、以前開けなかったサイトと別のサイトを試します。特定のサービスだけが失敗する場合は、サービス側の状態、アカウント制限、出口の地域要件を確認してください。クライアント全体の障害と決めつけないでください。すべてのリクエストが失敗する場合は、次の章でノードを確認します。一部のアプリで接続記録が残らない場合は、システムプロキシが機能しないの章に進んでください。

ノードがタイムアウトする：通信経路を分けてテストする

ノードのテストがタイムアウトした場合、テスト条件のもとでクライアントが所定時間内に期待した応答を受け取れなかったことを示します。あらゆる用途でノードが使えないという意味ではありません。テスト先へのアクセス失敗、ノードのドメイン名解決エラー、認証情報の無効化、通信ハンドシェイクの異常は、いずれも似た結果になることがあります。端末からサーバーまでの経路、プロトコルのハンドシェイク、サーバーから接続先サイトまでの3段階に分けて確認し、テストボタンの色だけで判断しないでください。

テスト対象と実際の接続先を確認する

現在の接続が単一ノード、自動選択グループ、フォールバックグループのどれを使っているか確認します。ポリシーグループの中にさらに別のグループが含まれている場合があり、画面上の最上位グループ名が実際の出口とは限りません。接続の詳細を開いて最終的な経路を確認し、使用中のノードとテストしたノードが同じか確かめてください。グループ内で自動選択が変わり続ける場合は、テスト中だけ候補のノードを1つに固定し、変動要因を減らします。

2つの結果を比較します。クライアント内蔵のテストが失敗するか、そのノード経由でブラウザーから一般的なWebサイトにアクセスできるかを確認してください。内蔵テストは指定されたテスト先に依存するため、接続先の制限や応答方式の変更によって、実際の閲覧は正常でも失敗することがあります。テストを成功させるためだけに、見覚えのないアドレスを指定しないでください。まずクライアントの既定のテスト先を使い、現在のネットワークからアクセスできるか確認します。

エラーの種類から名前解決、接続、認証を切り分ける

ログにホストが見つからない、サーバーアドレスを解決できないと表示される場合は、ノードのサーバー名とローカルDNSを確認します。接続拒否の場合、通常は接続先が明示的に拒否しています。ポートの誤りやサービスが待ち受けていない可能性があります。接続タイムアウトの場合は、パケットロス、アクセス制限、サーバーから応答がないことなどが考えられます。これらの情報で原因を絞り込めますが、サーバーが恒久的に停止していると断定することはできません。

認証失敗、ハンドシェイク失敗、証明書エラーが発生した場合は、サブスクリプションが有効か、端末の時刻が正確か、クライアントのコアがノード設定に対応しているか確認してください。問題を隠すために証明書検証を無効にしないでください。証明書名、サーバー名、通信パラメーターは設定の提供元に確認する必要があります。ログに記録されたエラーの種類と時刻を提供元に伝えれば十分です。ノードのパスワードや接続文字列全体を公開の掲示板に投稿しないでください。

ネットワークを変えて比較する

同じ端末、同じ設定で、自宅のネットワークとスマートフォンのテザリングをそれぞれ試します。特定のネットワークだけで失敗する場合は、そのネットワークの認証、アクセス制限、DNSを重点的に確認します。複数のネットワークで失敗し、同じサブスクリプションの他のノードが正常なら、特定ノードまたはプロトコル設定の問題が考えられます。テザリングではモバイルデータを消費するため、まず簡単なWebページで確認し、大容量ファイルの速度テストは不要です。

別の端末で同じ有効なサブスクリプションを試す方法もありますが、サービスが定める端末数や同時接続数の制限を守ってください。別の端末で使えたとしても、その環境で設定が機能したことしかわかりません。コアの対応状況、システム時刻、通信の取り込み設定も比較する必要があります。同じアカウントで複数のクライアントを同時にテストすると、アカウント側の同時接続制限によって新たなタイムアウトや切断が起きることがあるため避けてください。

ノードの障害と特定プロトコルの制限を切り分ける

Webページは開けるのに音声通話、ゲーム、リアルタイム通信が失敗する場合は、アプリがUDPに依存しているか、ノード、ポリシーグループ、通信の取り込み方式が該当する通信に対応しているか確認してください。HTTPプロキシで利用できるアプリの動作は、仮想ネットワークアダプターによる取り込みと同じではありません。リアルタイム機能が1つ失敗しただけでノード全体の障害と判断せず、Webページが正常だからといってすべての通信方式が検証済みだと考えないでください。

症状	優先して確認する項目	次の手順
サーバーのドメイン名を解決できない	ノードのドメイン名、ローカルのDNSリゾルバー	DNSログを確認し、別のネットワークでも試す
1つのノードだけ失敗する	ノードの状態、認証、ポート	別のノードを選び、提供元に問い合わせる
1つのアプリだけ失敗する	通信の取り込み範囲、プロトコル、ルール	接続履歴で最終的な出口を確認する

ノードの障害を確認したら、サブスクリプションを手動で更新し、別の利用可能なノードを選んでください。タイムアウト時間を長くしても待ち時間が延びるだけで、誤ったアドレス、認証失敗、到達できない経路は修復できません。更新後もすべてのノードが失敗する場合は、サブスクリプションの章で設定の入手元を確認してください。クライアントの選び方とOSへの対応状況はダウンロードセンターで確認できます。初めて選ぶ場合はClash Plusがおすすめです。

サブスクリプションの更新に失敗する：応答内容を確認する

サブスクリプションの追加には、データの取得、形式の解析、設定の読み込みという3つの段階があります。リンクへのリクエスト失敗とYAML構文エラーは別の問題で、対処の順番も異なります。まずエラーメッセージ全文を書き留め、ダウンロード時と設定の読み込み時のどちらで発生したかを確認してください。すでに適用済みの設定は復旧に使える場合があります。新しいサブスクリプションが使えると確認する前に、古い設定やノードをすべて削除しないでください。

リンク全体とアカウントの状態を確認する

サービス提供元のアカウントページからサブスクリプションURLをコピーし直してください。チャットアプリによる改行、ブラウザーでの省略表示、手動選択の漏れに注意します。前後に空白や引用符が入っていないか、特にクエリパラメーターが途中で切れていないか確認してください。サブスクリプションURLには通常アクセス用の認証情報が含まれます。公開投稿、オンライン整形ツール、よく知らない変換サービスに貼り付けないでください。スクリーンショットを撮る場合は、アドレスバーとQRコードも隠してください。

アカウントの期限切れ、通信量上限への到達、サブスクリプションURLのリセットが原因の場合、クライアントで再試行しても利用権限は戻りません。まず提供元のページで状態を確認し、新しいURLで更新してください。ブラウザーでリンクを開いたとき、ログイン画面、認証コード、アクセス拒否、一般的なWebページが表示されても、クライアントが設定データを取得できているとは限りません。そのページをYAMLとして保存して読み込ませても、設定の解析には成功しません。

ネットワークエラー、ステータスコード、形式エラーを区別する

リクエストがタイムアウトする、または接続に失敗する場合は、端末の通常のネットワークとシステム時刻を確認します。設定画面に直接接続またはプロキシ経由でダウンロードする選択肢がある場合は、元の設定を記録してから比較してください。更新にプロキシが必要なサブスクリプションでは、先に利用可能な出口を確保する必要があります。まだ読み込んでいないノードを使って更新することはできません。使える設定が一つもない場合は、現在のネットワークからアクセスできる正規の追加方法を提供元に問い合わせてください。

アクセス権に関するステータスコードではアカウントやリンクを確認し、レート制限の場合は何度も更新せず、提供元の案内に従って待ちます。解析エラーでは、受信したデータの形式を確認します。他のクライアント向けに生成されたノード一覧、単一の共有リンク、Clash設定ファイルは同じものではありません。サブスクリプションページでClashまたはmihomo向けの出力形式を選んだことを確認してから再度追加してください。拡張子だけを変更しても解決しません。

config.yaml：最初に報告されたエラー箇所を調べる

YAMLは階層とインデントに厳密です。まずエラー箇所の前後の行を確認し、タブではなくスペースでインデントしているか、コロンやリストのハイフン、引用符の対応が正しいか調べます。報告された位置はパーサーが異常を検出した箇所で、実際の原因がもっと前にある閉じていない文字列の場合もあります。編集前に元のファイルをコピーし、エラーを一つ修正するごとに再読み込みしてください。設定ファイル全体を一度に並べ替えないでください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
dns:
  enable: true
  listen: 127.0.0.1:1053

この例は階層構造の説明だけを目的としており、ノードやポリシーグループを含まないため、完全なサブスクリプションではありません。トップレベルの項目はdnsと同じ階層にあり、enableとlistenはDNSの子項目です。構文に加えて、ポリシーグループが存在しないノードを参照していないか、ルールが未定義のグループ名を使っていないか、現在のコアが認識しないプロトコル項目を含んでいないかも確認してください。こうした問題は読み込みログを見て判断します。

オーバーライドや自動更新による変化を確認する

サブスクリプションの元ファイルに問題がないのに、適用後の設定でエラーが出る場合は、クライアントの設定マージ、スクリプト処理、オーバーライドを確認してください。まずカスタム設定をバックアップし、一時的に無効にして再読み込みすると、元のサブスクリプションの問題かローカルでの加工の問題かを切り分けられます。キャッシュファイルを直接編集して恒久的な修正にしないでください。次回の更新で上書きされる可能性があります。残したい設定は、クライアントが対応する永続的なオーバーライドの保存先に置いてください。

自動更新に失敗しても、現在の接続が使えなくなったとは限りません。最後に成功した時刻と失敗理由を確認し、まず手動で更新して新しい設定を読み込めるか確かめてから、適切な更新間隔を設定します。端末のスリープ、バックグラウンド制限、ネットワークの切り替えで定期実行が遅れることがあります。詳しい確認手順はサブスクリプションの解析エラーを確認するチェックリストを、追加方法はサブスクリプションの追加手順をご覧ください。

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

Webページの表示が遅い、ダウンロード速度が低い、動画が頻繁に止まるといった症状は、それぞれ名前解決の遅れ、往復遅延、継続的なデータ転送能力の不足が原因かもしれません。クライアントのテスト結果は特定のリクエストへの応答時間を測るもので、ダウンロード帯域と同じではありません。調査では、同じWebページや同じファイルなど再現性のあるタスクを一つ選び、ネットワーク、ノード、時間帯を記録してから条件を一つずつ変えて比較してください。

プロキシ接続と直接接続の速度を比較する

他のダウンロード、クラウド同期、システム更新を停止し、同じネットワーク上の別の端末が帯域を使い切っていないか確認します。直接アクセスできるリソースでネットワークの基本的な状態を調べ、続いて同じか同程度のリソースにプロキシ経由でアクセスしてください。直接接続も遅い場合は、Wi-Fiの電波、ルーターの負荷、ブロードバンド回線を先に確認します。クライアントで回線の帯域を増やしたり、混雑によるパケットロスを解消したりすることはできません。

Wi-Fiの速度テストは距離、周波数帯、周囲の電波干渉に左右されます。パソコンなら一時的に有線接続を使い、スマートフォンならルーターの近くで再テストします。その際は他の条件を揃えてください。異なるWebサイトの瞬間的な最高速度だけを比べてノードの優劣を判断しないでください。サイトのサーバー、コンテンツ配信経路、アカウントの速度制限が異なる場合があります。転送中の安定した速度のほうが、開始直後数秒間の最高速度より参考になります。

読み込みの段階からボトルネックを特定する

リンクをクリックしてから表示が始まるまで時間がかかる一方、表示後の画像読み込みが速い場合は、DNS、接続確立、ハンドシェイクを優先して調べます。ページはすぐに表示されるのに大きなファイルの転送が遅い場合は、出口の帯域や接続先の制限を確認してください。初回アクセスだけ遅く、次回から明らかに速い場合は、名前解決や接続、リソースのキャッシュが関係している可能性があります。再テスト時は初回アクセスかどうかを記録し、キャッシュの違いを設定改善の効果と誤認しないようにします。

クライアントの接続一覧で、遅いリクエストが想定したノードを通っているか確認します。通常、1つのページでも複数のドメインに接続するため、メインサイト、画像、動画のリソースには別のルールが適用される場合があります。ページのメインドメインのルールだけを切り替えても、動画の接続先が変わるとは限りません。実際に遅いリソースのドメインと最終的に適用されたポリシーを調べてから、変更するルールを決めてください。動画一つの問題を直すために、すべての通信をグローバルモードにしないでください。

地理的な近さだけでなく、ノードの経路を比較する

距離が近くても経路が短いとは限らず、応答が速くても継続的なダウンロードが速いとは限りません。利用可能だと確認したノードを2〜3個選び、近い時間帯に同じテストを行い、接続の安定性、パケットロス、継続的な転送速度を比べてください。夜間だけ混雑する場合は時間帯を記録してサービス提供元に伝えます。特定のサイトだけ常に遅く、他のサイトは正常なら、接続先サービス、出口の地域、コンテンツ配信経路が原因の可能性があります。

端末の性能も速度に影響します。システムのタスク管理ツールでCPU使用率やメモリーの負荷を確認し、使っていない接続や重複して起動しているプロキシツールを終了してください。詳細ログは原因特定のため短時間使うと役立ちますが、高頻度のデバッグ出力を長期間有効にすると、ストレージへの書き込みや処理の負荷が増えます。調査後は通常のログレベルに戻してください。すべてのログを無効にすれば速くなるとは限りません。

MTU、IPv6、リアルタイム通信の変更は慎重に行う

TUNを有効にした場合だけ大きなファイルの転送が止まる、または一部のページが固まる一方で、システムプロキシは正常なら、仮想ネットワークアダプター、ルーティング、パスMTUを確認します。まずクライアントの既定値に戻し、クライアントのドキュメントに従って一項目ずつ変更して、元の値を記録してください。MTUが大きすぎると一部の経路で転送に問題が生じ、小さすぎるとオーバーヘッドが増えます。ブロードバンド、テザリング、トンネルのすべてに適した共通の最適値はありません。

IPv6の対応が不完全、UDPが利用できない、リアルタイムアプリの通信経路が異なるといった理由で、Webの速度テストと実際の使用感に差が出ることがあります。アプリの用途ごとに確認し、一度の速度テストだけでシステム全体のIPv6を無効にしないでください。特定の通信取り込み方式でのみ問題が起きる場合は、TUNモードとシステムプロキシの比較を参照し、取り込み範囲を確認してから設定を変更してください。

DNSの問題：どこで名前解決しているか確認する

DNSの障害は、ドメインにアクセスできない、一部のアプリがオフラインと表示される、接続ログに名前解決失敗が繰り返し記録されるといった形で現れます。システムのリゾルバー、ブラウザーのセキュアDNS、クライアント内蔵DNS、ノードサーバーの名前解決が、1回のアクセスに同時に関わる場合があります。まずどの層でエラーが返されたかを特定してから設定を変更してください。システムDNSを特定のパブリックDNSに変えても、クライアントが実際に使う名前解決経路には影響しない場合があります。

システムとクライアントの名前解決結果をそれぞれ確認する

まずターミナルでOSのコマンドを使い、一般的なドメインを検索してシステムが応答を得られるか確認します。次にクライアントのログで同じドメインの処理結果を見ます。以下のコマンドは、現在のシステムの名前解決経路を確認するためのもので、プロキシ経由の通信が正常であることを単独で証明するものではありません。システム検索が成功してクライアントで失敗する場合は、コアのDNS設定を確認してください。システムでも失敗する場合は、ネットワーク認証、リゾルバーへの到達性、ローカルネットワークのポリシーを調べます。

nslookup example.com

検索タイムアウトとドメインが存在しない場合は意味が異なります。前者はリゾルバーが応答していない可能性があり、後者はドメイン自体が存在しない、または応答結果に問題がある可能性があります。ノードサーバーのドメイン名だけが失敗していないかも確認してください。プロキシを確立するには先にサーバーのアドレスを解決する必要がありますが、その名前解決がまだ確立していないプロキシに依存していると、循環して接続できません。ノードのドメイン名を解決する経路はクライアントのドキュメントに従って設定し、DNS設定例を安易に丸ごとコピーしないでください。

fake-ip、キャッシュ、ブラウザーのセキュアDNSを理解する

fake-ipを有効にすると、クライアントがアプリに専用アドレス帯のマッピングアドレスを返し、コアが実際のドメイン名と対応づけることがあります。これは通信取り込みの仕組みの一部です。検索結果がパブリックIPアドレスでないというだけで、名前解決の異常と判断しないでください。重要なのは、その後の接続が同じコアに戻るか、マッピング情報が存在するかです。通信がクライアントを迂回してマッピングアドレスに直接接続すると、アプリで接続エラーが発生することがあります。

ブラウザー独自のセキュアDNSが有効だと、システムの名前解決経路を通らず、ブラウザーと他のアプリで動作が異なることがあります。調査前に現在の設定を記録し、一時的にシステムの名前解決を使って比較してください。ブラウザーのリゾルバー、クライアントの上流DNS、システムDNSを同時に変更すると、どの変更が有効だったか分からなくなります。ローカルネットワークの機器名や内部ドメインには、そのネットワークで必要な名前解決経路を残してください。

設定を切り替えても、既存の接続やキャッシュが以前の結果を使い続ける場合があります。問題が起きているページを閉じて接続を作り直し、必要に応じて該当する層のキャッシュを消してください。Windowsでは下のコマンドでシステムのDNSキャッシュを消去できます。ただし、クライアント内部やブラウザーのキャッシュは消去されず、到達できない上流サーバーも修復できません。他のOSではシステムのドキュメントに従い、出所の分からないネットワークリセット用スクリプトは実行しないでください。

ipconfig /flushdns

GeoIPの更新：DNSデータとは分けて確認する

GeoIPデータはIPアドレスの地理的な位置情報をルール判定に使うためのもので、ドメイン名をIPアドレスに変換する機能ではありません。データのダウンロードに失敗した場合は、ログにデータファイル、ダウンロード先、読み込みエラーが明記されているか確認してから、クライアントのデータ更新機能、保存権限、ネットワークを調べます。ドメインが開けないからといって、すぐに地理データベースを作り直さないでください。ドメインルールのデータ、IPの地理情報、DNSキャッシュを混同しないようにします。

ログにデータベースの不足が記録されている場合は、まずクライアントの対応する更新機能を使い、完了後に設定を再読み込みしてエラーが消えたか確認してください。データの入手元と形式は、現在のコアと設定に合っている必要があります。別形式のファイルの名前だけを変えて置き換えないでください。更新にプロキシが必要なのに現在使える出口がない場合は、先に利用可能な出口を復旧するか、クライアントのドキュメントに従って到達可能なダウンロード方法を使い、同じ失敗を何度も繰り返さないようにしてください。

IPv6とローカルネットワークの名前解決を切り分ける

ドメインはIPv4とIPv6の両方のアドレスを返す場合がありますが、現在のネットワークにIPv6の外向き経路が整っているとは限りません。ログでIPv6接続だけが失敗している場合は、システム、コア、ノードの対応状況を比較してから一時的にテストします。原因の特定をせず、IPv6をすべて無効にしたままにしないでください。プリンター、ネットワークストレージ、組織内のドメインにアクセスできない場合は、プロキシ経由で名前解決されたり、プロキシの出口に送られたりしていないか確認します。

復旧の判断基準は、対象のアプリからアクセスでき、接続が想定したポリシーを通り、内部リソースも使えることです。一度の検索結果だけで判断しないでください。設定項目の階層はconfig.yamlの構成解説で、一般的な疑問はヘルプセンターで確認できます。

システムプロキシが機能しない：待ち受けと通信の取り込みを確認する

システムプロキシは、OSがアプリに提供するプロキシ設定であり、すべてのネットワーク通信を強制的に取り込むスイッチではありません。ブラウザーは設定に従っても、コマンドラインツール、ゲーム、一部のストアアプリは独自のネットワーク機能を使う場合があります。そのため、「ブラウザーでは使えるがターミナルでは使えない」ことが、必ずしも設定の不具合を意味するわけではありません。まず対象のプログラムが対応するプロキシ方式を確認し、クライアントの待ち受けアドレスとOSの設定が一致しているか調べます。

実際の待ち受けポートとシステム設定のアドレスを照合する

クライアントの設定または適用中の設定で混合ポートを確認し、すべての端末で7890が使われていると思い込まないでください。システムプロキシには、現在の端末のループバックアドレスと実際の待ち受けポートを指定します。別のクライアントを起動したことがある場合、古いポートが残ったり、バックグラウンドでシステム設定が繰り返し書き換えられたりすることがあります。まず他のプロキシアプリを終了し、使用中のクライアントのシステムプロキシを一度オフにしてから再びオンにし、OSの設定も連動して変わるか確認します。

プロキシ指定に対応したコマンドラインツールで、システムプロキシのスイッチを介さずにローカルポートを直接テストできます。以下のコマンドはクライアントがローカルの7890で待ち受けていることを前提としています。実際には設定画面で確認したポートに置き換えてください。プロキシを明示した接続は成功するのにブラウザーで失敗する場合は、ブラウザー独自の設定、拡張機能、システムプロキシを確認します。明示的な接続も失敗する場合は、待ち受け、ノード、ルールを確認してください。

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

GUIアプリ、ターミナル、システムサービスを区別する

ターミナルのツールには環境変数を参照するものもあれば、個別の設定ファイルだけを参照するものもあります。Windowsでもプロキシ設定のインターフェースによって対象となるプログラムが異なる場合があります。一つの設定を変更しても、すべてのシステムサービスに反映されるとは限りません。まず対象ツールのプロキシに関する説明を確認し、コマンド単位でテストして有効性を確かめてから、設定を恒久化するか決めてください。プロキシ変数をシステム全体に設定したまま、元に戻すのを忘れないようにしてください。

プロキシを明示すると成功するのに通常のコマンドが失敗する場合は、ツール独自のプロキシ設定、直接接続の例外、古い環境変数を確認します。環境変数に設定されたアドレスが現在のクライアントと一致するか確認し、例外リストで接続先ドメインがプロキシを迂回していないかも調べてください。問題のあるツールの設定だけを変更し、すぐにシステム全体のネットワークをリセットする必要はありません。クライアントを終了した後も、停止したポートを参照する永続設定が残っていないか確認します。

TUNが必要な場合は、まず権限とルーティングを確認する

TUNは仮想ネットワークインターフェースを通じて通信を取り込み、システムプロキシに従わない一部のアプリにも対応できますが、通常は必要なシステム権限、サービスコンポーネント、ルーティングへの対応が必要です。有効化できない場合は、何度もスイッチを押さず、ログに記録された権限、デバイス作成、ルーティングのエラーを確認してください。サービスのインストールやネットワーク拡張の許可はクライアントの正規の手順で行い、完了後にコアが実際にインターフェースを作成したか確認します。

他のVPN、仮想マシンやコンテナのネットワーク、セキュリティソフトがルールと競合する場合があります。まず起動中のネットワーク関連ツールを記録し、問題がない範囲で一つずつ停止して比較してください。システムのファイアウォールをそのまま無効にしたり、正体の分からないネットワークアダプターを削除したりしないでください。リモート接続中は、デフォルトルートの変更でセッションが即座に切れることがあるため、ローカル操作や別の復旧経路を確保してから作業します。

方式	主な対象範囲	失敗した場合にまず確認する項目
システムプロキシ	システム設定に従うアプリ	アドレス、ポート、アプリ独自の設定
アプリで明示的に指定するプロキシ	指定したアプリまたは単一のコマンド	プロキシプロトコルと待ち受け方式の一致
TUNモード	ルーティングにより取り込まれるネットワーク通信	権限、インターフェース、ルーティング、DNS

LAN共有と終了後の復旧

他の端末からパソコンのプロキシに接続する場合、127.0.0.1は指定できません。このアドレスは常に接続元の端末自身を指します。パソコンの現在のローカルネットワークアドレスを指定し、クライアントがLAN接続を許可していること、待ち受け範囲が正しいこと、ファイアウォールで必要なネットワークだけが許可されていることを確認してください。プロキシポートをインターネットに公開しないでください。共有をやめたら関連設定を無効にし、アドレスが変わった場合は接続する端末側の設定も更新します。

通常の方法で終了する前にシステムプロキシとTUNを無効にし、直接接続が復旧したか確認してください。プロセスを強制終了した後にネットワークが切断された場合は、残ったシステムプロキシを手動で無効にし、クライアントを再起動して後処理を完了させます。共有の詳しい手順は混合ポートとLAN接続の説明を、基本設定の場所はシステムプロキシの設定手順をご覧ください。

クライアントがクラッシュする：設定を残して復旧する

ウィンドウがすぐ閉じる、画面が真っ白になる、コアが何度も再起動する、設定を保存できない問題は、それぞれ分けて対応します。GUIは表示と管理を担い、実際のプロキシ処理はコアが担うため、どちらか一方だけに問題が起きる場合があります。まずプロセスが残っているか、トレイから画面を開けるか、プロキシポートが待ち受けを続けているか確認してください。ウィンドウが閉じても通信が続く場合は、画面が非表示になっただけかもしれません。画面が残っていてもコアが終了していれば、すべてのノードが使えないように見えることがあります。

インストール、権限、実行環境を確認する

インストーラーのOSとプロセッサーアーキテクチャが端末に合っており、OSのバージョンがクライアントの要件を満たしているか確認してください。macOSではApple SiliconとIntelを区別し、Linuxではディストリビューションとパッケージ形式、Windowsではシステムのセキュリティ警告とインストール先の権限を確認します。見覚えのないポップアップから修復用のコンポーネントをダウンロードしたり、起動のためにシステムの保護機能を長期間無効にしたりしないでください。クライアントのドキュメントに記載されたインストール方法と認証手順を優先してください。

保護されたフォルダーへのインストール、書き込み不可のポータブル実行フォルダー、ディスク容量不足などが、設定の保存や起動の失敗を引き起こすことがあります。プログラムのインストール先だけでなく、クライアントが実際に使うデータフォルダーも確認してください。組織管理の端末ではバックグラウンドサービスやネットワーク拡張が制限される場合があります。その場合は端末の管理ルールに従ってください。管理者権限での起動は、根拠のあるテストとしては使えますが、誤ったフォルダー権限の修正にはなりません。

画面の問題とコアの読み込み失敗を切り分ける

画面は開くのにコアが起動しない場合は、まず起動ログを確認してください。ポートの競合、設定項目の誤り、無効なポリシーグループ参照、データファイルの不足は、通常ログに明確なメッセージが表示されます。ユーザーデータをすべて削除するのではなく、クライアント内蔵の検証または読み込み機能で設定を確認してから、最近追加したオーバーライド、スクリプト、ルールデータを一時的に無効にします。以前使えていた設定に戻し、変更を一つずつ追加し直してください。

ポートが競合している場合は、旧クライアントや残存するコアが使用していないか特定し、該当するプログラムを正しい手順で終了します。ポートを変更する必要がある場合は、システムプロキシ、ターミナルの設定、共有先端末の設定も合わせて更新してください。設定の待ち受けポートだけを変更して、システム側に古いアドレスを残すと、起動の問題が新たな通信障害に変わります。画面が真っ白になる、描画が乱れるといった場合は、クライアントのドキュメントに従ってグラフィックスの実行環境を確認し、別のソフトウェア向けの起動オプションを流用しないでください。

バックアップして最小限の実行環境を作り直す

リセットや再インストールの前に、サブスクリプション設定をエクスポートし、ポリシーグループの選択を記録して、オーバーライドや必要な設定をバックアップしてください。バックアップにはサブスクリプションの認証情報やノードの認証情報が含まれることがあるため、自分で管理できる場所に保存します。プログラムをアンインストールしてもユーザーデータが残る場合があります。そのため、再インストール後もクラッシュするからといって、インストーラーに問題があるとは限りません。以前の設定やキャッシュが再起動時に読み込まれている可能性があります。

クライアントにリセット機能がある場合は、まず影響範囲を確認してください。説明が明確でない場合は、関連するプロセスを完全に終了してデータフォルダーをバックアップし、一時的に別の場所へ移します。完全に削除する必要はありません。再起動後は初期設定のまま安定して起動するか確認し、問題のない設定を1つだけ読み込みます。読み込み直後に再現する場合は、その設定やデータを重点的に確認してください。何も読み込んでいない状態でもクラッシュする場合は、OSとの互換性やインストール環境を調べます。

メンテナンスが続いているクライアントを選び、問い合わせ情報を整理する

新規インストールにはClash Plusをおすすめします。OSに応じてClash Verge RevやFlClashなどを選ぶこともできます。Clash for WindowsとClashX Metaはすでにメンテナンスが終了しているため、古い環境の問題は再インストールだけで解決しないことがあります。クライアントを切り替える前にサブスクリプション形式との互換性を確認し、ユーザーフォルダー全体をそのままコピーしないでください。設定ファイル、アプリの設定、キャッシュデータは通常、同じものとして移行できません。

問い合わせには、OS、プロセッサーアーキテクチャ、クライアント名、実際のインストール情報、問題が起きる手順、関連するログの末尾を含めてください。一度クラッシュしただけでOSが非対応だと断定するなど、再現できない結論は避けてください。ログにアカウント、サブスクリプション、ノードの情報が含まれる場合は、事前に伏せてください。調査のため詳細ログを有効にした場合は、問題の解決後に通常のレベルに戻し、必要に応じてローカルの診断ファイルを削除します。

モバイル端末の問題：VPNとバックグラウンド動作を確認する

スマートフォンのプロキシ接続は、OSのVPNインターフェースやネットワーク拡張に依存するため、デスクトップOSのシステムプロキシとは動作が異なります。ステータスバーにVPNマークが表示されても、OSが対応するインターフェースを作成したことを示すだけで、サブスクリプション、ノード、振り分けが正しいとは限りません。まずクライアントを前面に表示して接続をテストし、画面ロック、アプリの切り替え、ネットワーク変更後の状態を確認します。初回の接続失敗とバックグラウンドでの切断は分けて記録してください。

Android：権限と他のVPNとの競合を確認する

初回接続時にOSのVPN利用を許可し、対象のクライアントが現在有効になっていることを確認してください。フィルタリングツール、仕事用プロファイル、他のVPNアプリが同じ接続機能を使おうとすると、接続直後に切断されることがあります。まずシステム設定で現在のVPNを確認し、複数のアプリを同時に何度も起動しないでください。組織管理の端末では仕事用と個人用でネットワークポリシーが異なる場合があるため、それぞれの適用範囲を確認します。

画面ロック後だけ接続が切れる場合は、OSによるクライアントのバックグラウンド動作、バッテリー使用、モバイルデータの制限を確認してください。クライアントをバックグラウンドで動作できるアプリとしてOSに登録し、画面ロック中に再テストします。設定名はメーカーによって異なるため、実際のシステム画面で確認してください。すべてのアプリを制限なしに設定したり、通知が消えただけでプロキシが停止したと判断したりせず、クライアントの状態と実際のアクセス結果も確認します。

Androidのアプリ別プロキシ設定では、特定のアプリだけを通信の取り込み対象にしたり、一部のアプリを除外したりできます。一方のブラウザーでは接続できて、もう一方ではできない場合は、まず対象アプリが取り込み範囲に含まれているか確認してからルールを調べてください。アプリの更新や仕事用プロファイルへの切り替え後も、選択内容を再確認します。初期設定と権限の手順はAndroidのセットアップ手順を参照してください。デスクトップ用のシステムプロキシの設定名を、そのままスマートフォンの画面に当てはめないでください。

iOS：ネットワーク拡張と設定の有効化を確認する

iOSではClash Plusをおすすめします。iOSのダウンロードページからApp Storeのリンクを確認してください。クライアントの公式サイトはclashplus.ioです。OSの許可を済ませた後、サブスクリプションが読み込まれ、ポリシーグループで有効な選択がされていることも確認してください。VPN設定を作成しただけでは、利用可能なノードが読み込まれていないため、プロキシ接続はできません。

他のネットワークツールから切り替えた場合は、OSが現在使っているVPN設定が正しいか確認し、以前のツールで自動再接続を無効にしてください。アプリ内で接続成功と表示されたら、同じWebページで再テストします。特定のアプリだけで問題が起きる場合は、そのアプリ独自のネットワーク動作と通信の振り分け結果を確認してください。以前のツールが再び接続を取り込んでいる可能性を確認する前に、システム設定をすべて何度も削除しないでください。

Wi-Fi、モバイルデータ、テザリングを切り替えて確認する

Wi-Fiからモバイルデータに切り替えると、既存の接続が古いアドレスや経路に依存したままになることがあります。ネットワークが安定するまで待ち、クライアントでいったん切断してから再接続し、セッションを作り直してください。モバイルデータでのみ失敗する場合は、クライアントと対象アプリでモバイルデータの利用が許可されているかを確認し、ノードのドメイン名解決とネットワークプロトコルの対応状況を比較します。ネットワーク切り替え直後の一時的な失敗だけで、サブスクリプションが無効だと判断しないでください。

公衆Wi-FiでWeb認証が必要な場合は、まずプロキシを一時停止してネットワークにログインし、その後に接続を再開します。スマートフォンでテザリングしても、接続した端末の通信がスマートフォンのプロキシを自動的に通るとは限りません。共有通信の扱いはスマートフォン本体の通信と異なる場合があります。共有が必要な場合は、クライアントとOSが明示的に対応する方法を使い、LAN経由のプロキシ共有手順でアドレスとセキュリティ上の注意点を確認してください。

元に戻せる設定を残し、最終確認を行う

Androidの常時接続VPN、「VPNを経由しない接続をブロックする」設定、クライアントの自動接続は、サービス停止時に端末が完全に通信できなくなったように見せることがあります。まず現在の設定を記録し、OSの案内に従って一時的に無効にして比較してください。調査後は用途に応じて設定を戻します。アプリを削除したり設定が使えなくなったりした後も、存在しない接続を経由するようOSが指定していないか確認してください。

モバイル端末の最終確認では、アプリを前面に表示した状態でのアクセス、画面ロック後の復旧、Wi-Fiとモバイルデータの切り替えの3つを少なくともテストしてください。毎回同じ接続先を使い、ステータスバーのアイコンだけでなく、実際の出口が想定どおりか確認します。原因を特定できない場合は、端末のOS、ネットワークの種類、クライアント名、エラーの発生時刻、個人情報を伏せたログを整理し、ヘルプセンターでよくある問題を確認してください。再設定する場合は入門ガイドに戻り、手順を一つずつ進めてください。