Clashのトラブル対処ガイド

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

プロキシを終了し、まず通常のネットワークを確認する

すべてのWebページが開けない場合は、まずクライアントのシステムプロキシとTUNを無効にし、メニューから通常の手順で終了してください。システムプロキシの設定が残っていないことを確認してから、普段プロキシなしで開けるサイトにアクセスします。それでも失敗する場合は、Wi-Fi接続、ゲートウェイ、学校や職場の認証、ブロードバンド回線を先に確認しましょう。プロキシクライアントは、ネットワークそのものの代わりにはなりません。公衆Wi-Fiではログインが必要なことがあり、認証ページへの接続がプロキシに回される場合もあります。プロキシを終了して認証を済ませてから、再度確認してください。

終了後にネットワークが復旧した場合、原因はプロキシの入口、コア、または設定に絞られます。クライアントを再起動し、最初からすべての機能を有効にするのは避けてください。ログに設定の読み込み成功や待ち受けポートの確立などが記録されているか確認します。ウィンドウが表示されていても、GUIが動いていることしか分からず、コアの起動を示すものではありません。ポートの競合、設定の構文エラー、権限不足があると、画面は表示されてもプロキシサービスが利用できないことがあります。

明示的なプロキシ指定でシステム設定を介さずにリクエストする

設定画面で実際の混合ポートを確認してください。以下ではローカルアドレスとポート 7890 を例にしています。クライアントの設定が異なる場合は、ポートを置き換えてください。このコマンドはHTTPプロキシを明示し、システムプロキシやブラウザー拡張などの影響を一時的に切り離します。Windowsでは、PowerShellの環境によって curl が別のコマンドとして解釈されることがあるため、curl.exe を使います。その他のデスクトップOSでは通常 curl を使います。

# 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

ローカルポートへの接続に失敗する場合、リクエストはまだリモートノードに届いていません。コアが動作しているか、待ち受けアドレスとポートが一致しているか確認してください。プロキシトンネルが確立した後にリモート接続がタイムアウトするなら、ノードとルールを調べます。HTTPレスポンスが返れば、そのリクエストは通っています。ただし、一つのサイトだけでネットワーク全体の状態は判断できません。実際に開けないサイトでも試し、クライアントの接続ログで適用されたポリシーを確認してください。

ルール、プロキシグループ、復旧手順を確認する

プロキシ画面で現在のプロキシグループを確認し、REJECT が選ばれていないか、すでに存在しないノードを参照していないかを調べてください。設定更新後も画面に古い選択が残っている場合があります。一時的に、動作確認済みのポリシーを選んで比較します。グローバルモードでは接続できるのにルールモードでは失敗する場合、適用されたルールと最終的な出口を確認しましょう。インストーラーを何度も入れ替える必要はありません。テスト後は元のモードに戻し、一時的な状態を恒久的な修正と誤認しないようにしてください。

TUNを有効にしたときだけ接続できなくなる場合は、まずTUNを無効にしてシステムプロキシで確認してください。システムプロキシが使えるなら、サブスクリプションの問題と決めつけず、仮想ネットワークアダプターの権限、ルートの競合、他のVPNを確認します。会社のセキュリティソフト、仮想マシンのネットワーク、別のトンネルツールがルーティングに影響している可能性があります。ネットワークアダプターを一括削除しないでください。競合するアプリを終了し、作業を保存してから再起動し、必要なネットワークツールを一つずつ戻します。

復旧は次の順で試してください：TUNを無効化 → システムプロキシを無効化 → クライアントを通常終了 → システムプロキシの設定が残っていないか確認 → 直接接続をテスト。ネットワークスタックのリセットは最後に行い、先に固定IP、DNS、社内ネットワークの要件を記録してください。

最後の確認では、もともと直接接続できたサイトと、現在のプロキシポリシーが必要なサイトの両方をテストします。時刻、モード、接続先、結果を記録し、サイト側の障害をクライアント全体の問題と誤認しないようにしてください。まだ原因が分からない場合は、よくある質問でシステムプロキシとTUNの役割を確認し、次の章でタイムアウトが発生する段階を特定しましょう。

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

まず、どの段階でタイムアウトするか確認する

ノードの速度テストがタイムアウトしても、ノードが恒久的に使えないとは限りません。テストでは、サーバーのドメイン名解決、サーバーへの接続、プロトコルのハンドシェイク、テスト先へのアクセスなどが行われます。どの段階で失敗しても似た結果になります。まずログを開き、手動で一度テストして、同じ時刻の記録を探してください。一度のテストでノード、ネットワーク、DNSを同時に変更すると、成功しても何が効いたのか判断できません。

dial tcp に続いて i/o timeout が表示される場合、通常はTCP接続の確立が制限時間内に完了していません。ただし、対象アドレスがノードサーバーか最終接続先かを確認してください。ノードサーバーなら、端末からサーバーまでのネットワーク経路を調べます。接続先サイトなら、ノードへの接続はすでに完了している可能性があります。connection refused は接続先ポートから明示的に拒否された状態に近く、パケットが応答なく破棄されるタイムアウトとは異なります。対処方法を混同しないでください。

サブスクリプションとサーバーの接続先を確認する

まず、サブスクリプションが正常に更新できるか、サービスが有効かを確認し、選択中ノードのサーバードメインとポートが提供元の最新設定と一致しているか調べます。経験則でプロトコル項目を追加しないでください。TLSのサーバー名、WebSocketのパス、通信方式などは対応関係があります。一つだけ変更すると、TCP接続はできてもハンドシェイクに失敗する場合があります。サブスクリプション由来のノードは、元の設定を再取得するのが優先です。手動で変更する場合は、事前にコピーを保存し、変更理由を記録してください。

システムツールでポートへの接続を確認できますが、自分にアクセス権のあるサーバーだけをテストしてください。Windowsの Test-NetConnection ではTCPポートに到達できるか確認できます。ただし、プロキシ認証、暗号化パラメーター、接続先サイトまでは検証できません。UDPを主に使うプロトコルもあり、TCPテストだけで正常性は判断できません。同様に、サーバーがpingに応答しなくてもプロキシポートが使えないとは限りません。ICMPの結果だけで結論を出さないでください。

ネットワークとノードを個別に確認する

クライアント、設定、ノードはそのままにして、PCの接続先だけを元のWi-Fiからスマートフォンのテザリングに切り替え、同じサイトにアクセスします。テザリングでは使えて元のネットワークでは失敗する場合、元のネットワークの出口ポリシー、UDP制限、認証状態を確認してください。どちらでも失敗する場合は、同じサブスクリプションから接続先サーバーが異なるノードを選びます。複数のノードが同じサーバードメインを使っている場合、独立したテスト対象ではありません。すべて失敗しても、共通の接続先に問題がある可能性があります。

速度テストに失敗してもWebページを正常に開ける場合は、テスト先にアクセスできるか、ルールで直接接続されていないか、アクセス制限がないかを確認してください。ヘルスチェックで調べるのは指定された接続先であり、インターネット上のすべてのサービスではありません。タイムアウト時間を延ばし続けて、安定した障害を覆い隠すのも避けましょう。ネットワークが実際に遅い場合には待ち時間の延長が有効なこともありますが、ポートの誤り、認証エラー、サーバードメインの名前解決失敗には効果がありません。

TLS証明書エラーが出た場合は、まずシステムの日付、時刻、タイムゾーンを同期し、設定内のサーバー名を確認してください。証明書検証のスキップを通常の解決策にしないでください。接続先の身元確認が弱くなります。ログを読む順序については、Clashの実行ログから原因を特定する方法を参照してください。提供元に問い合わせる際は、発生時刻、接続ネットワーク、個人情報を隠したエラー内容を伝え、サブスクリプションURLや認証項目全体は送らないでください。

サブスクリプションを更新できない：ダウンロード、形式、設定の読み込みを確認する

取得の失敗と設定の解析エラーを切り分ける

サブスクリプションの追加に失敗する原因は、主に2種類あります。クライアントが内容を取得できない場合と、取得した内容を設定として解析できない場合です。まず、エラーがダウンロード段階と読み込み段階のどちらで発生したか確認します。HTTPステータスコード、接続タイムアウト、証明書エラーは取得時の手掛かりです。行番号、インデント、未知の項目、存在しないプロキシグループへの参照は、解析時の問題を示す可能性があります。画面に更新失敗とだけ表示される場合は、すぐに設定をすべて削除して再追加せず、ログで詳細を確認してください。

提供元からサブスクリプションURLを完全な形でコピーしてください。チャットアプリによっては、末尾に空白、改行、句読点が混入することがあります。リンクにアクセス資格情報が含まれる場合があるため、URL全体を機密情報として扱い、公開フォーラム、検索フォーム、スクリーンショットに載せないでください。すでに公開してしまった場合は、提供元で無効化または再発行してください。個人用サブスクリプションを、よく知らない変換サイトに安易に送信しないでください。変換サービスからノード情報や認証情報を閲覧できる可能性があります。

レスポンスに応じて次の手順を選ぶ

401 または 403 が返る場合は、アカウントの状態、リンクの有効性、提供元が定めるアクセス条件を確認します。404 の場合は、URLが変更されていないか、コピーが途中で切れていないかを調べます。429 の場合は、連続して操作せず、サービスの案内に従って待ってください。ステータスコードは手掛かりにすぎないため、レスポンスの内容も確認する必要があります。成功を示すステータスが返っても、設定ファイルとは限りません。通常のWebページとしてログイン画面、認証画面、エラーメッセージが返る場合もあります。

ブラウザーではダウンロードできるのにクライアントでは失敗する場合、両者の通信経路が同じか確認してください。ブラウザーは独自の拡張機能、ログイン済みセッション、システムプロキシを使っている一方、クライアントの更新処理は直接接続している可能性があります。逆の場合もあります。更新リクエストにプロキシが必要だと確認できた場合に限り、クライアントのサブスクリプション取得用プロキシ設定を有効にしてください。利用可能なノードが一つもない状態でノード経由の更新を設定すると、循環して更新できなくなります。信頼できるネットワークから直接取得できるか試してください。

YAMLの構造とコアの対応状況を確認する

ファイルをダウンロードできたら、それがClashのYAML設定なのか、ノード共有リンクの一覧なのかを確認してください。両者はそのまま置き換えられません。YAMLではインデントにスペースを使い、タブを混在させないでください。特殊文字を含む文字列は適切に引用します。エラー行が表示された場合は、その数行上も確認してください。コロン、引用符、リスト記号の不足が、エラー行より前にあることがあります。

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false

これはトップレベルの基本項目だけを示す例であり、ノードやプロキシグループを含まないため、このままではリモートプロキシを設定できません。統合する際は、同じトップレベルキーがファイル内にすでにないか確認し、rules や dns を二重に定義しないでください。ルールから参照するポリシー名はプロキシグループ名と一致させます。名前に含まれる空白や大文字・小文字もそのまま保ってください。YAMLの構成に不慣れな場合は、設定ファイルの構造を項目ごとに解説を参照してください。

未対応のプロトコルや設定項目がエラーとして示された場合は、クライアントのウィンドウ名だけで判断せず、実際に動作しているコアの種類を確認してください。GUIとコアにはそれぞれ機能の範囲があり、古いコアでは提供元が追加した設定に対応していない場合があります。コアを更新する場合は、クライアント一覧から、システムに合ったインストーラーを選んでください。まずはClash Plusをおすすめします。クライアントが明確に対応している場合を除き、新しいコアのファイルを古いクライアントのフォルダーに入れないでください。

自動更新によって手動変更が上書きされることもよくあります。サブスクリプションの設定ファイルは通常、リモートの内容から再生成されます。変更を維持したい場合は、ダウンロードキャッシュを繰り返し編集するのではなく、クライアントが対応するオーバーライドやマージ機能を使ってください。修正後に手動更新を実行し、コアを再起動して、設定を取得・読み込みできることを確認します。直近の正常な設定を保管しつつ、失効したサブスクリプションがバックグラウンドで何度も更新され、レート制限を別のネットワーク障害と誤認することのないようにしてください。

接続速度が遅い：遅延、帯域幅、アプリの動作を切り分ける

まず、どの種類の遅さかを確認する

Webページを開くまで時間がかかる、ダウンロード速度が低い、動画が途中で止まる、ゲームの操作に遅延があるといった症状は、それぞれ別の問題です。再現できる状況を整理してください。初回アクセスだけ遅いのか、すべてのサイトが遅いのか、夜だけ発生するのか、Wi-Fiを切り替えると改善するのかを確認します。ノードの速度テストは、特定のリクエストの完了状況を測るもので、持続的なダウンロード速度を直接予測できません。一つの遅延値ですべてのアプリの使用感を説明することもできません。

ノードと接続先を変えずに、まず通常のネットワークを確認してください。ルーターから離れた場所での使用、混雑したWi-Fiチャネル、バックグラウンドのクラウド同期やシステム更新が帯域幅を消費していることがあります。同じ端末から、利用可能な接続先に直接アクセスした場合と、プロキシ経由でアクセスした場合を複数回測定してください。異なるサイト、ファイル、時刻のダウンロード速度をそのまま比較しないでください。接続先サーバーの地域、速度制限、キャッシュ方式によっても結果は変わります。

接続ログをたどり、実際の出口を確認する

アプリのリクエストが想定したポリシーを本当に通っているか確認してください。Webページの本体、画像、動画のセグメント、ログイン用APIは異なるドメインから配信され、別々のルールに一致することがあります。トップページが速く開いても、動画も同じ経路とは限りません。接続ログでアプリやドメインを絞り込み、最終的なプロキシグループと出口を確認します。一部のリソースだけ経路が誤っている場合はルールを修正し、一つのリソースが遅いからといってすべての接続をグローバルプロキシにしないでください。

自動選択グループの結果が誤解を招くこともあります。プロキシグループのチェック先、確認間隔、利用可能性の判定方法によって選択結果が決まるため、現在の用途に合うとは限りません。テスト中に自動切り替えが起きないよう、利用可能なノードを一つ選んで短時間比較してください。ノードを切り替えても、アプリの既存の長時間接続は古い出口を使い続ける場合があります。該当ページを閉じるかアプリを再接続し、新しい接続を確認してください。選択ボタンの表示だけでは判断できません。

プロトコル、UDP、通信経路の違いを理解する

ブラウザーや動画アプリの一部はQUICを試し、UDPで通信します。接続ネットワークやノードが必要なUDP転送に対応していないと、切り替え待ちが発生したり、一部のリソースの読み込みが遅くなったり、接続が繰り返し再試行されたりすることがあります。まずログで使われているプロトコルを確認し、ノードとクライアントが対応しているか調べてください。Webページ一つを検証するために、UDPを一律にブロックしないでください。制御できるアプリで該当プロトコルを一時的に無効にして比較し、テスト後に元の設定へ戻します。

TUNを使う場合に限って明らかに遅くなるなら、ルーティングループ、パスMTU、ネットワークアダプターの競合に注意してください。小さなページは開けるのに大きなファイルの転送が止まる、あるネットワークでは使えて別のネットワークでは異常になる、といった症状が手掛かりです。他のVPNを終了し、システムプロキシとTUNの経路を比較してください。MTUを変更する前にクライアントとコアのドキュメントを確認し、元の値を保存します。ネット上で見つけた固定値をそのまま適用すると、別のネットワーク経路が悪化し、安定した解決にならないことがあります。

サーバーとの距離、ネットワーク間の接続状況、ピーク時の混雑も速度に影響します。同じノードが複数の端末・接続ネットワークから同じ接続先に対して遅く、他のノードでは正常な場合は、回線の問題として提供元に問い合わせる根拠になります。発生時刻、接続先、接続方法、再現可能な症状を伝え、「速度がとても遅い」とだけ報告しないでください。実測していない速度を伝えたり、一時的なピーク値を安定した帯域幅として扱ったりしないでください。

最後に、テスト用に加えた一時的な変更を元に戻します。グローバルモード、アプリのプロトコル設定、手動で固定したポリシーなどが対象です。問題を説明できる最小限の変更だけを残し、実際の用途で継続して改善しているか確認してください。DNSの一括変更、ネットワークアダプターの設定変更、コアの切り替え、クライアントの再インストールを同時に行うと、一見早く直ったようでも再現性が失われ、次にネットワークを切り替えた際の原因特定が難しくなります。

DNSの問題：名前解決リクエストの経路を特定する

ドメインに接続できない場合も、まずすべてのDNSサーバーを変更するのは避ける

DNSの問題は、ドメイン名を解決できない、一部のサイトで初回アクセスが止まる、ノードサーバーのアドレスを解決できない、といった形で現れます。まず、失敗しているのが接続先のドメインかノードのドメインかを確認してください。両者で名前解決の経路が異なる場合があります。システムDNS、ブラウザーのセキュアDNS、クライアント内蔵のDNS、アプリ独自のリゾルバーが同時に使われることもあります。システム設定を変更しても変化がないからといって、設定が反映されていないとは限りません。アプリがその経路を使っていない可能性があります。

Windowsでは nslookup example.com、対応ツールがあるmacOSやLinuxでは dig example.com を使って、システムのDNS問い合わせ結果を確認できます。ただし、分かるのはそのツールが今回使った経路だけで、ブラウザーやTUNの名前解決動作を直接証明するものではありません。問い合わせに使われたサーバー、結果、エラーを記録し、クライアントのログと照らし合わせてください。経路によって異なるIPアドレスが返っても、必ずしも異常ではありません。コンテンツ配信ネットワークは、地域に応じて異なる結果を返すことがあります。

Fake-IPと実際のIPアドレスの違いを理解する

Fake-IPモードでは、ドメインに予約済みアドレスを割り当て、コアに対応表を保存します。その後、この対応表を使って接続先ドメインを復元し、ルーティングします。そのため、予約済みアドレスが表示されても、Webサーバーが実際にそのネットワークにあるわけではありません。問題になるのは、接続を開始するアプリが対応表を管理するコアを引き続き通っているかどうかです。クライアント終了後にシステムやアプリが古い合成アドレスをキャッシュしていると、一時的に接続できなくなることがあります。通常の名前解決経路に戻し、関連するキャッシュを削除してください。

LAN内の機器検出、プリンターサービス、実際のアドレスを必要とする一部のアプリでは、すべてに合成アドレスを使うのが適切とは限りません。まず該当するドメインと失敗の状況を確認し、すべてのドメインを除外するのではなく、コアが対応している方法で fake-ip-filter に追加してください。フィルターの書式と利用可能な機能は、使用中のコアに合わせます。仕組みと使い分けについては、Fake-IPとredir-hostの比較をご覧ください。

設定、上流DNS、起動時の依存関係を確認する

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

この例は、ローカルDNSの待ち受けと上流DNSの設定を示しています。上流サーバーに到達できるかどうかは、利用中のネットワークによって異なります。1053 で待ち受けても、システムの全DNS問い合わせが自動的にそこへ送られるわけではありません。システム設定、TUNによるDNSの引き受け、その他の転送方法を別途設定する必要があります。アクセス制御なしにDNSの待ち受けをインターネットへ公開しないでください。また、別の端末のDNSサーバーとしてローカルのループバックアドレスを指定しないでください。

暗号化DNSでは起動時の依存関係にも注意が必要です。上流サーバーのドメイン名を先に解決する必要がある一方、そのサーバーへの接続には、まだ利用できないプロキシが必要な場合があります。循環依存が起きる場合は、コアが対応するブートストラップ用DNSとノードのドメイン名解決設定を分けて指定し、まず上流サーバーに到達できるか確認してください。多数のDNSサーバーを当てずっぽうに追加するのは避けましょう。選択肢が増えても変数が増えるだけで、誤った経路の問題は解決しません。社内ドメインには通常、組織で指定された名前解決経路を使います。

IPv6も個別に確認してください。ドメインからIPv4とIPv6の両方が返る場合、端末が実際には使えない経路を優先して試すことがあります。まずアドレスファミリーごとの接続結果を比較し、ルーティング、ノードの対応状況、クライアントの設定を確認します。IPv6の無効化を、あらゆるDNS問題に対する標準的な解決策にしないでください。一時的な確認のために無効化する場合は、元の状態を記録し、LANや他のサービスに影響しないか確認してください。

キャッシュの削除は、名前解決経路を修正した後に行います。まずアプリの再試行を止め、システムの手順に従ってキャッシュを更新し、アプリを開き直して新しい問い合わせを発生させてください。キャッシュを何度消しても、到達できない上流DNSや誤ったDNSの引き受けは直りません。

最後に、一般的なドメイン、以前失敗したドメイン、必要な社内ドメインをそれぞれ確認します。名前解決に成功しただけでは十分ではありません。正しいポリシーに接続が振り分けられ、リクエストが完了することも確認してください。ブラウザーだけで問題が起きる場合は、セキュアDNSと拡張機能の設定を一時的に比較します。TUNだけで問題が起きる場合は、DNSの引き受けとルーティング経路を見直し、関係のないサブスクリプションノードの変更は続けないでください。

システムプロキシが機能しない：入口、アプリ、ルーティングの範囲を確認する

システムのスイッチをオンにしても、すべての通信がプロキシを通るわけではない

システムプロキシは、システム設定に従うアプリにプロキシの接続先を知らせる仕組みです。一部のコマンドラインツール、ゲーム、バックグラウンドサービス、独自のネットワーク設定を持つアプリは、この設定を読み取りません。そのため、ブラウザーでは接続できてもターミナルでは失敗することがありますが、必ずしもクライアントの異常ではありません。まず1章のプロキシを明示するコマンドでローカルの入口を確認してください。入口が正常なら、対象アプリがシステムプロキシに対応しているか、個別の設定が必要か、TUNで通信を引き受ける必要があるかを確認します。

Windowsではシステムのネットワーク設定から手動プロキシのアドレスとポートを確認します。macOSでは現在使っているネットワークサービスのプロキシ設定を確認してください。Linuxのデスクトップ設定は、デスクトップ環境やアプリによって異なります。Wi-Fiと有線ネットワークで設定対象が別の場合があるため、ネットワーク切り替え後に古い画面だけを見て判断しないでください。自動プロキシ設定スクリプトを使う環境では、スクリプトのURLと手動HTTPプロキシを区別し、二つの方式が同時に働いて結果が不一致にならないようにします。

ローカルの待ち受けと環境変数を確認する

通常、ローカル端末からクライアントのポートへ接続するには 127.0.0.1 を使います。LAN内のアドレスとは用途が異なります。他の端末から接続する必要がある場合に限り、allow-lan と待ち受け範囲を設定してください。ローカル端末でシステムプロキシが機能しない場合、LANアクセスを許可しても誤ったポートは直りません。アクセス範囲を広げるリスクもあるため、まずローカルの通信経路を正しく設定し、信頼できるネットワーク内での共有は別途構成してください。

# 現在のmacOS / Linuxシェルとその子プロセスにのみ適用
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 に http:// を指定しても、接続先サイトが通常のHTTPにダウングレードされるわけではありません。ローカルのHTTPプロキシに接続し、そのプロキシ経由でトンネルを確立するという意味です。

複数のプロキシ設定の競合を解消する

ブラウザー拡張、以前のクライアント、会社のプロキシスクリプト、スタートアップ項目がシステムプロキシ設定を書き換えることがあります。スイッチをオンにしてもすぐ元に戻る場合は、他のプロキシツールを終了し、バックグラウンドプロセスとスタートアップ一覧を確認してください。ブラウザー拡張は一時的に無効にして比較できますが、会社から強制インストールされたネットワークコンポーネントは削除しないでください。管理対象端末では組織のポリシーに従い、既存の制限を回避するためにセキュリティサービスを無効にしないでください。

TUNが必要な場合は、まずクライアントが対応しているか、サービスがインストールされているか、システムが要求する権限を取得しているか確認してください。TUNはシステムプロキシとは異なり、仮想ネットワークインターフェースとルーティングを通じて通信を処理しますが、ルール、DNS、除外ルートの影響は受けます。あらゆる問題を自動的に解決するスイッチと考えないでください。有効にした後、ローカル機器に接続できなくなった場合は、LANのルートと除外ルールを確認し、LAN全体をリモートプロキシへ送らないようにします。

仮想マシン、コンテナー、サブシステムには、それぞれ独立したネットワーク境界があります。コンテナー内の 127.0.0.1 はコンテナー自身を指し、ホストではありません。仮想マシンのシステムプロキシも、ホストの設定を引き継ぐとは限りません。その環境でサポートされているホストへの接続先アドレスを使い、必要に応じて待ち受け範囲とファイアウォールを設定してください。ネットワークモードによって接続方法が異なるため、ホスト向けのコマンドをすべてのコンテナーにそのまま適用することはできません。

スマートフォンやテレビからPCのプロキシを使う場合は、まず両方が同じ信頼できるネットワークに接続されているか確認してください。PCでLANアクセスを許可し、ファイアウォールでは必要な接続元だけを許可します。接続する端末にはループバックアドレスではなく、PCのLANアドレスを指定してください。詳しい手順は、混合ポートとLAN共有の設定を参照してください。テスト後は不要になった共有用の待ち受けを無効にし、アクセス範囲を開放したままにしないようにします。

最終的には、対象アプリの新しい接続がクライアントのログに表示されるか、どのポリシーに一致するかで判断します。ログにリクエストがまったくない場合は、アプリの接続経路を調べます。リクエストが記録されても出口が違う場合は、ルールを確認します。出口が正しいのに失敗するなら、ノードを調べてください。この3つの段階に沿って確認すると、システムプロキシのスイッチを何度も押すより原因を特定しやすくなります。

クライアントがクラッシュする：GUI、コア、システムコンポーネントを切り分ける

まず、どの部分が終了したかを特定する

ウィンドウが消える、ウィンドウが応答しなくなる、タスクトレイには残っているのにプロキシが使えない状態は、それぞれ異なる問題です。GUIが終了してもコアがバックグラウンドで動いている場合があります。コアが終了してもGUIが表示されたままの場合もあります。まずタスクマネージャーまたはアクティビティモニタで関連プロセスを確認し、クライアントログの最後の数行を調べてください。起動時、設定の読み込み時、TUNの有効化時、サブスクリプションの更新時、スリープからの復帰後のどこで発生したかを記録します。漠然とした「クラッシュした」という説明より、発生のきっかけが原因特定に役立ちます。

作業内容を保存し、クライアントを通常の手順で終了して、バックグラウンドにプロセスが残っていないか確認してください。古いプロセスが終了する前に何度も起動し、複数のインスタンスを実行するのは避けましょう。ポートの競合や設定ファイルのロックが発生することがあります。プロセスを強制終了する必要があった場合は、その後システムプロキシの設定が残っていないか確認してください。サービスが停止したのにローカルポートを参照し続けてネットワークが切断されるのを防ぎます。直接接続を復旧してから情報を集めて修復を始めてください。オフラインの状態でダウンロードを繰り返すと混乱を招きます。

OS、インストール先、依存コンポーネントを確認する

インストーラーはOSとプロセッサーのアーキテクチャに合ったものを選んでください。Apple SiliconとIntel、Windowsの各アーキテクチャ、Linuxのパッケージ形式は、ファイル名が似ていても互換性があるとは限りません。クライアントのダウンロードページでOSに合ったものを選択してください。一般的なGUIユーザーにはClash Plusがおすすめです。Linuxではページに記載された一覧から適切なクライアントを選びます。古いチュートリアルと同じ画面を使うために、メンテナンスが終了したソフトを優先してインストールしないでください。

初回起動に失敗する場合は、システムのレポートに表示された不足コンポーネント、権限、インストール先の問題を確認してください。WindowsのGUIではWebViewコンポーネントが必要な場合があります。Linuxでは共有ライブラリの不足、macOSではアプリの権限やセキュリティチェックに関するメッセージが表示されることがあります。クライアントのドキュメントとシステムの案内に従い、不明なサイトから個別のライブラリをダウンロードしたり、一つのアプリを起動するためにシステムのセキュリティ機能を全面的に無効化したりしないでください。

変更を最小限にして設定と状態を切り分ける

特定の設定を読み込んだときだけクラッシュする場合は、設定とクライアントのデータフォルダーをバックアップし、正常に動作する設定に切り替えてテストしてください。最近追加したオーバーライド、スクリプト、外部ルールを無効にし、改善するか確認します。大容量のルールセット、多数の接続ログ、高いログレベルはリソース使用量を増やす可能性がありますが、メモリ使用量が増えただけでメモリリークと断定することはできません。きっかけとなる操作、継続時間、システムリソースの推移を併せて確認してください。

設定エラーでコアが終了した場合は、通常、構文や参照先の問題を特定できるログが残ります。GUIコンポーネントのクラッシュでは、システムイベントやクラッシュレポートが必要になる場合があります。どちらも設定をすべて削除して対処しないでください。クライアントが独立したデータフォルダーを一時的に使える場合は、元のデータを残したまま初期状態と比較できます。対応していない場合は、移行手順に従い、サブスクリプション、オーバーライドルール、ローカルのカスタム設定を誤って削除しないようにしてください。

再インストールしてもユーザーデータが消えるとは限らず、古い設定が直るとも限りません。作業を始める前に、設定フォルダーとプログラムフォルダーを区別してください。サービスのアンインストールやデータ削除の前に、復元できるコピーを保存し、再認証が必要なシステムコンポーネントを記録しておきます。

スリープから復帰した後だけ問題が起きる場合は、ネットワークインターフェースが変わっていないか、システムプロキシが以前のポートを参照していないか、TUNのルートが復旧しているかを確認してください。すぐに再インストールするのではなく、まずコアを停止してから起動し直します。ネットワーク切り替えで毎回再現する場合は、有線からWi-Fiへ、またはテザリングからルーターへ戻すなど、具体的な手順を記録してください。こうした再現条件は、サービスの復旧やルート再構築の問題を特定するのに役立ちます。

問題を報告する際は、クライアント名、システムアーキテクチャ、コアの情報、再現手順、機密情報を隠したログを添えてください。サブスクリプションの認証情報、ノードの認証情報、個人情報を含むファイルパスは削除します。クラッシュレポートにもユーザー名やファイルの場所が含まれる場合があります。デバッグログは短時間の再現確認中だけ有効にし、完了後は log-level: info に戻してください。ログを大量に書き込み続けると、日常利用や後の原因調査に影響します。

修復後は、正常終了、再起動、ネットワーク再接続をそれぞれ少なくとも一度確認し、システムプロキシ、設定の読み込み、コアのサービスが復旧することを確認してください。再インストール後も同じ手順で失敗する場合は、繰り返し再インストールせず、再現条件に戻って調査を続けます。クライアントを次々と入れ替えるより、直接接続でネットワークを復旧できる手順を一つ確保しておくことが重要です。

モバイル端末のトラブル：VPNの許可、バックグラウンド制限、ネットワーク切り替え

まず端末の通信を引き受ける方式を確認する

スマートフォンでは通常、システムのVPNインターフェースを使って通信を引き受けます。デスクトップでローカルのHTTPプロキシを設定する方法とは異なります。初回有効化時は、システムの確認画面でVPN構成を許可し、接続中のVPNが対象クライアントのものか確認してください。ステータスバーにVPNアイコンが表示されても、システムトンネルが確立したことしか分からず、サブスクリプションノード、ルール、DNSがすべて機能しているとは限りません。クライアントで新しいリクエスト、適用されたポリシー、エラーログを確認し、どの層に問題があるか判断します。

OSに合わせてAndroidのダウンロード一覧またはiOSのダウンロード一覧からクライアントを選んでください。まずはClash Plusがおすすめです。iOSでは、App Storeのページから入手できます。公式サイトはclashplus.ioです。対応する設定項目やOSの機能はクライアントによって異なります。デスクトップ用YAMLのTUN設定をすべてモバイル端末でもそのまま使えるとは限りません。

Android：バックグラウンドでの停止とアプリごとの設定

画面点灯中は使えるのに、画面ロック後しばらくすると接続できなくなる場合は、システムのバッテリー設定、バックグラウンドでの動作、メーカー独自のプロセス管理を確認してください。使用中のクライアントだけ、必要に応じて制限を緩和します。端末全体の省電力機能を無効にしないでください。ノードを変えずに、画面をロックしてから再度点灯し、ログの時系列を確認します。アプリがシステムに停止されたのか、トンネルは残っているものの接続が失効したのか、Wi-Fiがスリープ状態になったのかを切り分けてください。

Androidクライアントの一部では、プロキシを使うアプリの範囲を選択できます。ブラウザーは使えるのに特定のアプリで接続できない場合は、そのアプリが除外されていないか、別プロセスを使っていないか、仕事用プロファイルの別アプリとして動作していないか確認します。VPNを常時有効にする設定や、VPNを通らない接続をブロックする設定によって、トンネルが切断されたときに端末全体がオフラインになったように見える場合もあります。これらの設定の動作を理解してから必要に応じて調整し、保護機能をノードの障害と誤認しないようにしてください。

iOS：許可、オンデマンド接続、設定の互換性

iOSでVPNを有効にできない場合は、システムにVPN構成が存在するか、現在のクライアントに紐づいているか、他のアプリがトンネルを確立していないか確認してください。古いインストールやデバイス管理ポリシーによって構成が残っていることがあります。見覚えのない企業用構成をすぐに削除しないでください。個人用端末で再認証する場合は、まずクライアントの接続を停止し、システムの手順に従ってから、アプリで再度認証を開始し、表示される案内を確認します。

システム上では接続済みなのに一部のサービスが使えない場合は、設定を最後まで読み込めているか、プロキシグループを手動で選ぶ必要があるか、サブスクリプション内のプロトコルにクライアントが対応しているか確認してください。モバイル端末の互換性は、実際のアプリの説明を基準に判断します。設定を読み込めても、すべての項目が同じ意味で機能するとは限りません。初回の設定方法は、iPhoneでの設定インポート手順を参照してください。VPNの許可が完了する前に、大量のルールを調整しないようにしましょう。

Wi-Fiとモバイルデータ通信を別々に確認する

同じノードと設定を使い、Wi-Fiとモバイルデータ通信のそれぞれで同じ接続先をテストしてください。特定のWi-Fiだけで失敗する場合は、ポータル認証を済ませ、ネットワークによる端末間通信の遮断や特定の通信方式への制限を確認します。モバイルデータ通信だけで失敗する場合は、通信事業者の経路、IPv6、データ通信の制限に注意してください。ネットワーク切り替え後は古い接続が無効になっていることがあります。切り替え前のページの結果を使い回さず、新しいリクエストを実行し、必要ならトンネルを停止してから再起動してください。

スマートフォンからPCの共有プロキシを使っている場合は、確認方法が異なります。スマートフォンのプロキシ設定には、PCのLANアドレスと、PCの混合ポートと同じポートを指定します。PCがスリープに入らないようにしてください。Wi-Fiのクライアント分離が有効だと端末間で接続できません。また、モバイルデータ通信から自宅PCのプライベートアドレスに直接アクセスすることも通常できません。この方式ではスマートフォン上でローカルVPNが動作しているとは限らないため、VPNアイコンの有無で共有の成否を判断しないでください。

最後に、アプリのキャッシュや既存のセッションを確認します。出口を切り替えると、ログインサービス、動画再生、メッセージアプリの長時間接続を再確立する必要がある場合があります。対象アプリを終了して開き直し、新しい接続ログを確認してください。一つのアプリが復旧しただけで、すべて直ったと判断しないでください。以前失敗したサービスもテストします。サポートを求める場合は、スマートフォンのOS、クライアント名、ネットワークの種類、機密情報を隠したエラーを伝え、このページの該当章に沿って問題を絞り込んでください。