Clash トラブルシューティング完全ガイド：インターネット接続不可・ノードのタイムアウト・DNS・システムプロキシ

01 · 再現条件を整える

基本チェック：まず障害が発生している層を確認する

接続経路を6段階に分ける

Clashのアクセスは「クライアントからWebサイト」への単純な2点間接続ではありません。完全な経路には、アプリ、システムプロキシまたはTUN、ローカル待受ポート、Clashのルール判定、プロキシノード、接続先サイトという少なくとも6つの段階があります。ブラウザーでページを開けないことから分かるのは、どこか1つ以上の段階が失敗しているという事実だけで、ノードの停止やサブスクリプション破損を直接意味するわけではありません。正しくは、端末に近い段階から確認します。まず通常のネットワークが使えること、次にClashのプロセスが存在することを確認し、その後ポート、プロキシグループ、ルールのマッチ、ノード接続、接続先サイトの状態を調べます。近い箇所から遠い箇所へ進めることで、リモートノードを何度も切り替えながらローカルポートの競合を見落とす事態を防げます。

開始前に現在の環境を記録します。少なくともOS、クライアント名、ネットワークの種類、プロキシモード、選択中のプロキシグループ、問題が1つのアプリだけに起きるのか全アプリに起きるのか、Clashを終了すると通信が戻るのかを書き留めてください。WindowsとmacOSのデスクトップではClash Plusを優先して利用できます。その他のクライアントとシステム要件はダウンロードセンターを確認してください。初回接続直後に問題が出た場合は、まずクイックスタートチュートリアルで基本設定を済ませてから、該当するトラブル分岐へ進みます。以前は使えていた場合、OS更新、サブスクリプション更新、Wi-Fiの切り替え、セキュリティソフトの導入、設定ファイルの変更など、直近の変更も記録してください。

最小限のテスト環境を作る

最小限のテスト環境には、ブラウザー1つ、正常動作が確認できている設定ファイル1つ、プロキシノード1つだけを残します。他のプロキシ、VPN、ネットワークフィルター、パケットキャプチャーツール、ローカル開発用プロキシは終了し、複数のプログラムがシステムプロキシを書き換えたり同じポートを使ったりしないようにします。ブラウザーの独立したプロキシ拡張機能も一時的に無効にし、通常ウィンドウでテストしてください。拡張機能がシステム設定を迂回したり、古いポートを保持したりすることがあります。一時的にルールモードへ切り替え、プロキシグループでは具体的なノードを1つ選びます。最初から自動選択や負荷分散グループは使わないでください。自動グループはバックグラウンドで接続先を切り替えるため、テストごとの条件が揃わず、原因がノードなのかポリシーなのか判断しにくくなります。

基本設定はシンプルに保ちます。よく使う待受項目は、まず混合ポート、LAN許可、ルールモード、ログレベルに絞ります。変更前に元のファイルをバックアップし、変更後はテキストを保存するだけでなく、クライアントから再読み込みしてください。以下の断片はローカル確認用です。クライアントのGUIでこれらの項目を管理している場合は、GUIが生成した設定を優先し、画面設定と手書きファイルが互いに上書きしないようにします。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

mixed-portはHTTPとSOCKSの接続を同時に受け付けるため、ポートの混同を減らせます。allow-lan: falseでテスト範囲をローカル端末に限定し、mode: ruleで実際のルール経路を維持します。log-level: infoなら、通常はルールのマッチと接続エラーを確認できます。トラブルシューティングが終わってから、LAN共有、スクリプト、上書き、複雑なDNS設定を戻してください。最初からログを過度に詳細にすると、重複した出力が最初の重要なエラーを埋もれさせ、モバイル端末のストレージとバッテリーも余計に消費します。

最初に発生した失敗をログで確認する

ログは時刻、接続先、ルール、ポリシー、ノード、エラーの順に読みます。まずログを消去するか現在時刻を記録し、アクセスを1回だけ実行します。ログに新しい記録がまったくない場合、問題はアプリとClashの間で起きていることが多いため、システムプロキシ、ブラウザーのプロキシ、TUNを確認します。接続先ドメインとルールは記録されているのに外向き接続が確立しない場合は、プロキシグループとノードを調べます。接続が開始された後に証明書エラー、リセット、拒否、タイムアウトが返る場合は、時刻、DNS、ネットワーク制限、リモート側の状態を確認します。最後の1行だけを切り取らないでください。直前の行に、使用したルール、プロキシグループ、実際の接続先が記録されていることがよくあります。

1回の確認で変更する変数は1つだけにし、結果を「復旧」「変化なし」「症状が変化」に分けて記録します。たとえば、まずノードを変更し、結果を確認してからモードを変更します。ノード変更、サブスクリプション更新、DNS変更、ルーター再起動を同時に行わないでください。症状の変化にも意味があります。ログがまったく出ない状態から接続タイムアウトに変わったなら、システムプロキシ経路は復旧し、次はノードとネットワーク層を確認すべきだと分かります。1回の確認が終わったら、最も目立つ症状に対応する後続の章へ進みます。複数の症状がある場合は、プロセスが起動しない、ログがない、全ノードが失敗するといった上流の問題を優先してください。

02 · すべてのページを開けない

Clashでインターネットに接続できない：ローカルネットワーク、プロキシ経路、ルールの出口を切り分ける

Clashの終了と起動で比較する

インターネットに接続できないとき、最初にノードを次々と変更するのではなく、2つの状態を比較します。Clashを完全に終了し、システムプロキシが無効になっていることを確認してから、普段安定しているWebサイトへアクセスします。それでも開けないなら、問題は基礎ネットワーク、ルーター、通信事業者、システムDNSにあり、Clashを調整しても解決しません。終了直後に復旧した場合、異常はプロキシ経路以降にあります。クライアントを再起動しますが、まずシステムプロキシは有効にせず、設定が正常に読み込まれるか、解析エラーがないか、管理画面にプロキシグループが表示されるかを確認します。クライアント自体が正常になってからシステムプロキシを有効にし、2回目のアクセスを行います。

「終了」とはウィンドウを閉じるだけでなく、プロセスを終了することです。デスクトップクライアントによっては、メインウィンドウを閉じてもトレイに残り、システムプロキシを維持します。Windowsでは通知領域とタスクマネージャー、macOSではメニューバーとアクティビティモニタを確認してください。プロセスを強制終了すると通信が戻るのに、通常終了では切断されたままなら、終了時にシステムプロキシが復元されていない可能性があります。まずシステムのネットワーク設定でプロキシサーバーを無効にし、その後クライアントを再起動します。不明なネットワーク設定をいきなり削除しないでください。元の値を記録しておきます。企業ネットワークや開発環境では、固定プロキシを本来使用している場合があります。

ローカル待受ポートを確認する

システムプロキシの接続先は、Clashが実際に待ち受けているアドレスと一致していなければなりません。一般的なローカルアドレスは127.0.0.1で、混合ポートには7890を設定できますが、具体的な値は現在の設定に従います。システムが古いポートを指していると、ブラウザーは存在しないサービスへリクエストを渡すため、すべてのページが直ちに失敗します。別のプロセスがポートを使用している可能性もあり、クライアントログにはアドレス使用中や待受失敗が表示されます。その場合は占有しているプログラムを終了するか、Clashの待受ポートとシステムプロキシのポートを両方変更します。片方だけ変更してはいけません。

# Windows：7890ポートを確認
netstat -ano | findstr :7890

# macOS / Linux：待受プロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

コマンドに出力がない場合、ポートの待受に成功していません。プロセスが現在のClashクライアントではない場合は、まず用途を確認します。ポートが待ち受けていても、トラフィックが外部へ出られるとは限りません。リクエストがログに入っているかも確認してください。ブラウザーからアクセスしたときログが完全に静止しているなら、システムプロキシが適用されていないか、アプリがシステム設定を迂回しています。ログにリクエストがあり、すべてDIRECTへ進むなら、モードとルールを確認します。プロキシグループに入った後で失敗する場合は、ノードのタイムアウトの章へ進みます。

モードを切り替えて範囲を絞る

診断のため、一時的にグローバルモードへ切り替え、具体的なノードを1つ選びます。グローバルモードではアクセスできるのにルールモードでは失敗するなら、ノードとローカルポートはおおむね正常で、ルールの順序、ルールセットの取得、最終的なMATCHを重点的に確認します。ルールは上から順に評価され、最初に一致した時点で後続の判定は終了します。範囲が広すぎるDOMAIN-SUFFIX、誤ったGEOIPの出口、早い位置にあるMATCH,DIRECTなどにより、対象トラフィックが誤ったポリシーへ送られることがあります。ルールを修正したらルールモードに戻し、設定ミスをグローバルモードで隠したまま運用しないでください。

グローバルモードでも失敗する場合は、同じノードを別のネットワークでテストします。たとえば自宅のWi-Fiからスマートフォンのテザリングへ切り替えます。テザリングでは使えるのに元のネットワークでは使えないなら、設定とノードはおそらく正常で、ルーター、ファイアウォール、IPv6経路、現在のネットワークによる特定接続の制限を確認します。両方のネットワークで失敗する場合は、別回線のノードを試します。1つのノードだけ失敗するなら問題はそのノードに限定されます。すべてのノードが失敗し、直結は正常なら、サブスクリプションの内容が完全か、システム時刻が正確か、クライアントのコアが正常に読み込まれているか、セキュリティソフトが通信を遮断していないかを確認します。

アプリによってはUDP、QUIC、独自のネットワークスタックを使用するため、ブラウザーが正常でもすべてのアプリが正常とは限りません。まず対象アプリのQUICを無効にするか、TCPでテストし、その後ノードがUDPをサポートしているか確認します。LAN共有では、アクセスする端末のプロキシアドレスをClashが動作しているホストのLANアドレスに設定し、127.0.0.1を指定しないでください。後者は常にアクセス端末自身を意味します。共有設定ではallow-lanを有効にし、適切なアドレスで待ち受け、システムファイアウォールでも通信を許可する必要があります。ポートの関係は混合ポートとLAN共有の解説を参照してください。

03 · ノードがタイムアウトする

ノードのタイムアウト：テスト先、ハンドシェイク段階、ネットワーク経路を確認する

遅延テストは完全な速度テストではない

クライアントに「タイムアウト」と表示されるのは、制限時間内にテスト先への接続またはHTTPリクエストが完了しなかったことを示す場合が多く、ノードがすべての接続先で使えないとは限りません。テストはローカルネットワーク、ノードの入口、ノードの出口、DNS、テストサイトを経由するため、どこか1つが遅いだけでもタイムアウトになります。クライアントによってテスト先、タイムアウトのしきい値、接続再利用の有無が異なるため、同じノードでもClash Plus、Clash Verge Rev、その他のクライアントで結果が完全に一致するとは限りません。遅延の数値はダウンロード速度でもありません。詳しい仕組みはノード遅延テストの仕組みを参照してください。

まずノードを1つ選び、異なる2つの接続先へ実際にアクセスします。通常のWebページと、小さな静的リソースを1つ使います。実アクセスは正常なのに管理画面のテストだけタイムアウトする場合は、テストURLがそのノードの出口から利用できるか、サブスクリプションのヘルスチェック設定を確認します。実アクセスも失敗するなら、ログに記録された失敗段階を確認します。接続拒否は対象ポートにサービスがないか入口で拒否されていることを示し、接続タイムアウトはパケットに応答がない状態に近い傾向があります。TLSハンドシェイクエラーでは、システム時刻、証明書チェーン、SNI、中間ネットワークを確認します。名前解決に失敗した場合は、まずDNSの章へ進みます。

単一ノード、プロキシグループ、ネットワークを比較する

自動選択グループのタイムアウトは、グループ内の全ノードがタイムアウトしていることを意味しません。プロキシグループを展開して具体的なノードを手動選択し、同じネットワークで2回続けてテストします。1回目にはDNSとハンドシェイクのコストが含まれることがあり、2回目で安定性を確認できます。その後、異なる地域または異なるプロトコルのノードに切り替えて再テストします。同じグループの一部だけが失敗するなら、サブスクリプション側の回線メンテナンス、入口アドレスの変更、プロトコルパラメータの不一致が考えられます。すべてのノードが同時に失敗する場合は、ノードを1つずつ削除するのではなく、ローカルファイアウォール、ネットワーク制限、システム時刻、設定の解析を優先して確認します。

次にスマートフォンのテザリングでネットワークを比較します。テザリングで復旧するなら、クライアント、設定、ノードは少なくとも接続を確立できており、元のWi-Fi経路を確認する必要があります。公共ネットワークでは、先にWeb認証を完了しなければならない場合があります。プロキシを有効にする前に通常のHTTPページへアクセスし、認証後にClashを起動してください。企業ネットワークは外向きポートを制限していることがあり、家庭用ルーターにはIPv6、MTU、DNS転送の問題がある場合があります。「テザリングなら使える」を単なるノードの変動と決めつけないでください。障害が接続ネットワークに関係することを示す重要な証拠として残します。

時刻、IPv6、MTUを確認する

TLS接続には正確なシステム時刻が必要です。端末の時刻が大きくずれていると、証明書がまだ有効でない、または期限切れと判定され、ログにハンドシェイクや証明書エラーが出ます。システムの自動時刻合わせを有効にし、クライアントを再起動して再テストします。IPv6環境では、ドメインがAAAAアドレスを優先して解決されても、現在のノードやローカルネットワークに安定したIPv6出口がない場合があり、一部の接続が長時間待機した後に失敗します。診断時は設定のIPv6を一時的に無効にし、再読み込みしてDNSキャッシュを消去します。問題が消えたら、無効のままにするか、ローカルとノードのIPv6対応を修正するか判断します。

小さなページは開けるのに大きなファイルや一部のアプリが止まる場合、MTUが関係している可能性があります。TUNモードはカプセル化層を追加し、ネットワークによっては分割パケットを正しく処理できないため、大きなパケットが失われます。まずTUNを無効にし、システムプロキシだけでテストします。システムプロキシは正常でTUNだけタイムアウトするなら、クライアントのMTU設定、システムの仮想ネットワークアダプター、他のVPNドライバーを確認します。MTUを感覚で大幅に変更せず、少しずつ下げて同じ接続先で再テストしてください。復旧したら有効値を記録し、LANとテザリングで異なる設定が必要かも確認します。

ログの状況	優先して確認する項目	次に行うこと
connection refused	ノードアドレス、ポート、リモートサービス	同じサブスクリプションの別ノードに切り替え、サービス提供元へ連絡する
i/o timeout	接続ネットワーク、ファイアウォール、ルーティング	テザリングへ切り替え、異なるプロトコルのノードを比較する
TLS handshake error	システム時刻、SNI、証明書、中間ネットワーク	自動時刻合わせを有効にし、ノードパラメータを確認する
no such host	DNS上流とドメイン名の綴り	DNSの章に沿って名前解決経路を確認する

ヘルスチェックの設定も誤判定の原因になります。テスト先は安定して応答し、サイズが小さく、ログインを必要としないものにします。チェック間隔を短くしすぎてモバイル回線を継続的に占有しないようにし、タイムアウトも現在のネットワークで通常のハンドシェイクに必要な時間を下回らないようにします。設定提供元が複数の自動グループを配布している場合は、各グループが参照するノード集合とテスト先を個別に確認します。ヘルスチェックを変更できるのは検出精度だけで、実際に故障したノードを修復することはできません。最終判断は、実際のアクセス、ログの失敗段階、異なるネットワークでの比較、同じグループ内の他ノードの結果を組み合わせて行います。

04 · 設定を更新できない

サブスクリプション失敗：リンク、レスポンス、解析、設定の上書きを確認する

ダウンロード失敗と解析失敗を分ける

サブスクリプションの更新には、独立した2つの段階があります。クライアントがネットワーク経由で内容をダウンロードし、その後コアが設定として解析します。ダウンロード段階では、接続タイムアウト、異常なステータスコード、証明書エラー、サブスクリプションのドメインを解決できないといった症状が一般的です。解析段階では内容を受信済みですが、YAMLの構文、フィールドの型、ノードパラメータ、ルールプロバイダーの形式が要件に合っていないことが多くあります。両者では対処方法がまったく異なります。ログで最初のエラーを見つけ、HTTPステータス、レスポンス本文のサイズ、YAMLの行番号が出ているか確認してください。「更新失敗」としか表示されない場合は、詳細ログまたは設定管理画面で具体的な原因を確認します。

サブスクリプションリンクをコピーするときは、クエリパラメータを含む完全なリンクを保持します。チャットアプリがリンクを途中で切ったり、特殊文字をエスケープしたり、末尾に句読点を追加したりすることがあります。最も安全なのは、サービス提供元の管理画面にあるコピー機能を使い、プレーンテキストエディターへ貼り付けて確認する方法です。リンクはhttps://で始まり、空白や改行を含まない必要があります。一時トークンを使うサブスクリプションでは、リセット後に古いリンクが無効になることもあります。サブスクリプションリンクを公開ログ、スクリーンショット、オンライン解析ツールに貼り付けないでください。通常、アクセス認証情報が含まれています。

リンクを公開せずネットワークレスポンスを確認する

ブラウザーでサブスクリプションリンクへ直接アクセスし、テキストがダウンロードされるか、ログインページへ移動するか、エラーページが返るかを確認できます。ブラウザーでもアクセスできない場合、問題はクライアントの解析ではなく、基礎ネットワーク、ドメイン解決、アカウント状態、サーバー側の制限にあります。ブラウザーではダウンロードできるのにクライアントではできない場合、クライアントがサブスクリプションを更新するとき、直結するのか現在のプロキシを通るのか確認します。現在のネットワークから到達できないサブスクリプションドメインは、既存の設定で接続を確立してから更新すると取得できる場合があります。逆に、誤ったプロキシルールによってリクエストが故障したノードへ送られることもあるため、その場合は一時的にプロキシを無効にして更新します。

コマンドラインで確認するときは、完全なリンクを共有端末の履歴に残さないでください。ローカルの一時環境でリクエストを実行し、レスポンスヘッダーと先頭数行だけを確認します。通常はYAML設定またはエンコードされたサブスクリプションが返り、HTMLのログインページではありません。成功ステータスでも内容がWebページなら、クライアントは解析段階で失敗します。リダイレクトが何度も発生する場合は、最終ドメインの証明書が正常か、端末の時刻が正確か、ネットワーク認証ページがリクエストを横取りしていないかを確認します。

YAMLの行番号とフィールド型を特定する

解析エラーには通常、行番号が示されます。テキストエディターでその行だけでなく直前の行も確認してください。引用符の不足、インデントの誤り、コロンの後の空白不足は、次の行で初めて検出されることがあります。YAMLのインデントにはスペースを使い、タブを混在させないでください。コロン、シャープ記号、特殊文字を含むテキスト値には引用符を付けます。真偽値はtrueまたはfalse、ポートは数値にします。プロキシグループが参照するノード名は、ノード一覧と完全に一致させます。大文字小文字や空白も違いとして扱われます。

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "自動選択"
      - "DIRECT"

rules:
  - DOMAIN-SUFFIX,example.com,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

サブスクリプションの元ファイルは解析できるのに、クライアントの上書き後に失敗する場合は、スクリプト、設定のマージ、ルール上書き、カスタムテンプレートを一時的に無効にし、元のサブスクリプションを再インポートします。クライアントによって上書きの適用順が異なり、古いテンプレートが削除済みのプロキシグループを参照していることもあります。復旧したら項目を1つずつ有効にし、有効化するたびに再読み込みしてログを確認します。これにより、上流のサブスクリプションに問題があるのか、ローカルの上書きが構造上の衝突を起こしているのかを特定できます。複数端末で設定を共有する場合は、パス、外部ルールファイル、プラットフォーム固有のフィールドにも注意し、詳しくは複数端末での設定同期方法を参照してください。

更新後も古い設定が有効な場合の対処

更新に成功しても、実行中の設定が切り替わったとは限りません。クライアントによっては「設定のダウンロード」と「設定の有効化」が別の操作です。サブスクリプション一覧に新しい時刻が表示された後、その設定を選択して再読み込みする必要があります。画面に古いプロキシグループが表示され続ける場合は、現在の設定名、ファイルパス、更新時刻を確認し、同名の別項目を更新していないか調べます。テスト用設定のグループ名を一時的に分かりやすい名前へ変更し、コアが実際に読み込んでいるファイルを確認できます。完了後は元に戻します。

サブスクリプションの自動更新が頻繁に失敗する場合は、更新間隔を適切に延ばし、複数の端末が同じ時刻に繰り返しリクエストしないようにします。モバイルOSがバックグラウンドのクライアントを停止し、定期タスクが予定どおり実行されないこともありますが、それはリンクが無効という意味ではありません。最終的には、手動更新で有効な内容を取得できるか、内容を解析できるか、現在のコアが新しい設定を読み込んでいるかで判断します。サーバーが権限エラーや利用量の上限を明示的に返す場合は、サブスクリプション提供元が対応すべき問題です。クライアント側の変更でサーバーの認証を回避することはできません。

05 · 接続できるが速度が遅い

速度が遅い：遅延、スループット、パケットロス、ルール経路を分けて測定する

「遅い」の具体的な症状を定義する

速度の問題は、初回表示の遅さ、継続ダウンロードの遅さ、動画のバッファリング、ゲームの揺らぎ、断続的な切断などに分けられます。それぞれ関係する指標が異なります。初回表示はDNSとハンドシェイクの遅延、継続的なダウンロードは帯域幅と輻輳、リアルタイムアプリはパケットロスとジッターの影響を受けやすくなります。クライアントに表示されるミリ秒だけでは、これらの違いを判断できません。同じ端末、同じネットワーク、同じ接続先、近い時間帯を使い、直結、固定ノード1つ、別の固定ノード1つを比較します。自動選択グループは出口を変更するため、基準測定には適しません。

テスト前に、システム更新、クラウド同期、動画再生、他の端末による大容量通信を一時停止します。ブラウザーの速度測定は拡張機能、キャッシュ、QUICの影響を受けるため、プライベートウィンドウで2〜3回繰り返します。高頻度で連続測定しないでください。回線を占有し、その後の結果が歪みます。最初の1バイトまでの時間、安定したダウンロード中の速度、突然ゼロになるかどうかを記録します。直結でも遅い場合は、まずローカルWi-Fi、ルーターの負荷、通信事業者の問題を解決します。プロキシだけが遅い場合は、ノード、プロトコル、ルール経路を比較します。

実際にどの出口を通っているか確認する

ルールモードでは、ドメインごとに異なるプロキシグループへ進む可能性があります。Webページのメインドメインがプロキシ経由でも、画像、動画の分割データ、APIが同じ出口を使うとは限りません。接続記録を開き、対象ドメインを検索して、マッチしたルールとポリシーを確認します。誤ったルールにより、静的リソースが直結になったり、本来直結すべきサービスが遠回りになったり、大容量通信のドメインが混雑したノードへ送られたりします。ルールは上から順に評価されます。具体的な書き方と順序はClashのルール分流実践を参照してください。

一時的にグローバルモードへ切り替え、同じノードを固定すれば、ルールによる差を確認できます。グローバルモードが明らかに速い場合でも、そのまま常用せず、接続記録を比較して、ルールモードで異なるポリシーへ送られているドメインを特定します。どちらのモードも遅いなら、主因はルールではありません。同じ地域の別ノードに切り替え、1つだけ遅いならその回線の混雑または出口品質の問題です。現在のWi-Fiではすべてのノードが遅く、テザリングでは正常なら、ローカルネットワーク、MTU、IPv6、ルーターのトラフィック管理を確認します。

DNS、接続再利用、プロトコルの違い

DNSの応答が遅いと、新しいドメインを開くたびに待ち時間が発生します。一方、確立済みのダウンロード接続は正常に維持されることがあります。初回表示だけ遅い、更新すると速い、ページ内の一部リソースだけなかなか表示されない場合は、この可能性があります。ログでドメイン解決にかかった時間を確認し、Clash DNSとシステムDNSを比較します。相互に転送するローカルDNSツールを複数同時に有効にしないでください。リクエストが長い連鎖になったり、ループしたりすることがあります。Fake-IPモードでは、アプリが予約アドレスを受け取り、Clashが実際のドメインへマッピングします。マッピングキャッシュの異常や、アプリがシステムの名前解決を迂回することでも、断続的な遅延が発生します。

ネットワークによってはUDPが不安定で、ブラウザーがQUICを優先的に使うことがあります。ブラウザーのQUICを一時的に無効にするか、該当トラフィックをTCPへフォールバックさせ、安定性が改善するか確認します。改善するなら、問題はUDP経路に集中しています。ノードにUDP対応と表示されていても、現在の接続ネットワーク、ルーター、出口経路が安定しているとは限りません。ゲームや音声アプリでは、最低遅延だけでなく継続的なパケットロスを確認します。TUNモードはより多くのトラフィックを取り込みますが、仮想ネットワークアダプターと追加のカプセル化も導入します。システムプロキシは速くTUNだけ遅い場合は、MTU、ネットワークアダプターのドライバー、除外ルートを確認します。

自動選択グループに適切なパラメータを設定する

自動選択は通常、ヘルスチェックの結果に基づいてノードを選びます。しかし、テスト先と実際の利用経路は異なるため、テスト遅延が最小のノードが最高スループットとは限りません。Web閲覧に適したノードが、大容量ファイルやリアルタイムアプリにも適しているとは限りません。用途ごとにプロキシグループを分けると効果的です。日常の閲覧には自動選択、ダウンロードや動画には手動固定、直結サービスにはDIRECTを使います。品質差の大きいノードを数十個、頻繁に検査する1つのグループへ詰め込まないでください。継続的なテストがリソースを消費し、出口が何度も切り替わる可能性があります。

特定の時間帯だけ速度が低下する場合、回線の混雑やローカル無線の干渉がよくある原因です。有線ネットワークまたはルーターに近い場所で再測定し、Wi-Fiとリモート経路を切り分けます。同じノードを混雑していない時間帯にも比較してください。大容量ファイルの開始直後は速いのに、その後継続的に低下する場合は、出口の速度制限、輻輳制御、サーバー側の帯域制限が考えられます。速度が周期的にゼロになって復帰するなら、パケットロス、ネットワーク切り替え、接続の再確立に近い症状です。時刻、ノード、接続先を記録してから回線変更を判断し、1回の測定だけで設定全体を書き換えないでください。

06 · ドメイン解決の異常

DNSの問題：解決経路、モード、キャッシュ、フォールバックを確認する

DNS障害の特徴を見分ける

DNSの問題は、ドメインを入力しても開けない、既知のアドレスへ直接アクセスすると応答がある、一部のドメインだけ正常で他は失敗する、ネットワークを切り替えても古い結果が残る、といった形で現れます。ログにはno such host、名前解決タイムアウト、上流へ到達できない、Fake-IPマッピングがないなどが表示されることがあります。証明書名の不一致も誤った解決結果が原因の可能性がありますが、システム時刻とネットワーク認証ページも除外してください。まず失敗するドメインを1つ選び、システムの解決結果とClashログの解決過程を個別に記録します。多数の異なるドメインを同時にテストしないでください。

DNS経路には、ブラウザーのセキュアDNS、システムのリゾルバー、ローカルフィルター、Clash DNS、ルーター、上流サーバーが含まれることがあります。経路が長いほど、ループ、キャッシュの不一致、分流ミスが起きやすくなります。確認時はブラウザー独自のセキュアDNSと他のローカルDNSツールを一時的に無効にし、リクエストがシステムとClashだけを通るようにします。ブラウザーだけが復旧し、他のアプリは元から正常なら、原因はブラウザー独自の名前解決にある可能性が高いです。すべてのアプリで失敗する場合は、Clash DNSの待受、TUNによるリダイレクト、上流への到達性を確認します。

redir-hostとFake-IPを理解する

redir-hostは通常、実際の解決アドレスを返し、その後ルールで接続を処理します。Fake-IPは予約アドレス範囲から一時的なマッピングアドレスを返し、Clashがドメイン情報を保持して早い段階でルールを適用できるようにします。Fake-IPはリモートノードのアドレスではなく、hostsへ手動で書き込むものでもありません。一部のLAN機器、ゲーム、企業アプリ、特殊なDNS動作をするソフトウェアはFake-IPとの互換性が低いため、フィルターリストへ追加して実アドレスを返すようにできます。フィルターは再現が確認できたドメインだけを対象にし、広すぎるワイルドカードで大部分のリクエストを除外しないでください。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

この例はフィールドの関係を示すもので、すべてのネットワークで同じ上流を使うべきだという意味ではありません。ipv6: falseは診断用の切り替えとして利用できます。IPv6経路が安定していることを確認したら、再び有効にできます。上流DNSは現在のネットワーク条件で到達できなければなりません。上流自体がプロキシを必要とし、そのプロキシの確立にも同じDNSが必要なら、起動ループになる可能性があります。複雑な設定では、プロキシノードのドメイン解決専用の上流を用意できますが、プロキシがまだ確立していない状態でも動作することを確認してください。

キャッシュと待受の競合を確認する

DNSを変更した後は、Clashのキャッシュ、システムキャッシュ、ブラウザーキャッシュを同時に考慮します。まず設定を再読み込みしてクライアントを再起動し、次にシステムの名前解決キャッシュを更新し、最後にブラウザーを終了して再起動します。Webページを更新するだけでは、古い接続やブラウザー内部のキャッシュが使われ続けることがあります。Windowsではipconfig /flushdnsを使用できます。macOSではシステムコマンドでキャッシュを更新し、モバイル端末では機内モードの切り替えやネットワーク接続の再起動で一部の状態を消去できます。キャッシュ消去は確認のために使うもので、接続のたびに必要な固定手順にしてはいけません。

Clash DNSがローカルの53番ポートで待ち受ける場合、システムサービス、コンテナツール、別のDNSプログラムがすでにそのポートを使用している可能性があります。ログにはバインド失敗が表示され、TUNでリダイレクトされた名前解決が応答しなくなります。実際に待ち受けているプロセスを確認し、入口の名前解決をどのプログラムが担当するか決めてください。2つのサービスが互いを上流に指定する構成は避けます。たとえば、システムDNSがローカルフィルターを指し、フィルターがClashを指し、Clashが再びシステムのデフォルトDNSを指すと、ループが発生します。最小限の経路には明確な入口と外部上流が必要です。

IPv6と分流DNSを処理する

ドメインがAとAAAAの両方を返すと、アプリがIPv6を優先して試すことがあります。ローカルにIPv6アドレスがあっても出口が不完全なら、リクエストはタイムアウトまで待ってからIPv4へ戻るため、DNSが遅いように見えます。Clash DNSでIPv6応答を一時的に無効にすれば、この可能性を確認できます。無効化で復旧した場合は、上流DNSの障害と決めつけず、ルーターのプレフィックス、システムのデフォルトルート、ノードのIPv6対応を確認します。

分流DNS設定はドメインに応じて異なる上流を選び、誤った解決を減らすのに役立ちますが、ルールとプロキシ出口は一致していなければなりません。あるドメインを直結DNSで解決し、最終的にはプロキシ経由でアクセスすると、返されたアドレスがプロキシ出口に適さない可能性があります。逆も同様です。接続記録でドメイン、解決アドレス、ルールポリシーを確認し、3者が期待どおりか調べます。1つのドメインだけに異常がある場合は、まず正確なルールを追加して検証し、すぐにグローバルDNSを変更しないでください。特定のサービスだけが継続的に失敗する場合は、アドレスバーのメインドメインだけでなく、関連する複数のドメインに依存していないかも確認します。

07 · スイッチは有効なのにアプリが直結する

システムプロキシが機能しない：ポート、バイパスリスト、アプリのプロキシ方式を確認する

システムプロキシの影響を受けるのは、システム設定に従うアプリだけ

システムプロキシを有効にすると、クライアントはOSのHTTP、HTTPS、SOCKSプロキシアドレスをローカルClashポートへ向けます。その設定を使うかどうかはアプリが決めます。主要なブラウザーは通常システムプロキシに従いますが、ゲーム、コマンドラインツール、ストアアプリ、仮想マシン、一部のクロスプラットフォームアプリは完全に無視することがあります。そのため「ブラウザーは使えるが、特定のアプリは直結する」ことは、システムプロキシのスイッチが無効という意味ではありません。まずシステムプロキシに従うブラウザーで基本経路を確認し、その後対象アプリが明示的なプロキシに対応しているか、TUNモードによる取り込みが必要かを調べます。

システム設定のサーバーアドレスとポートを確認します。アドレスは通常127.0.0.1で、ポートは現在のmixed-portまたは対応するHTTPポートと一致させます。設定の更新やクライアントの切り替えでポートが変わっても、システムには古い値が残ることがあります。Clash PlusやClash Verge Revなど複数のクライアントを使う場合、システムプロキシを同時に有効にしないでください。後から起動したプログラムが設定を上書きし、終了順によってはさらに古い値へ戻ることがあります。確認中は1つのクライアントだけを起動します。

ブラウザーとコマンドラインを別々に確認する

ブラウザーに独立したプロキシ拡張機能が入っていると、その設定がシステムプロキシを上書きすることがあります。拡張機能を一時的に無効にし、ブラウザーを再起動します。プライベートウィンドウでもすべての拡張機能が無効になるとは限らないため、拡張機能の管理画面で確認してください。コマンドラインツールは通常、HTTP_PROXY、HTTPS_PROXY、ALL_PROXYの環境変数を読み取ります。GUIのシステムプロキシ設定が自動的に引き継がれるとは限りません。変数を設定するときはHTTPとSOCKSのプロトコルを区別し、現在のターミナルだけに適用するのか、グローバル環境に適用するのかにも注意します。

# 現在のshellにだけHTTPプロキシを設定
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

# テスト完了後に削除
unset HTTP_PROXY
unset HTTPS_PROXY

Windows PowerShell、開発ツール、コンテナにはそれぞれ独自のプロキシ設定があります。1つのコマンドを動かすために、システム、Git、パッケージマネージャー、コンテナ、エディターの設定をすべて変更しないでください。復旧後に元へ戻しにくくなります。まず現在のターミナルだけに一時設定し、リクエストがClashログに入ることを確認します。成功してから永続化するか判断します。ログにリクエストがないなら、そのツールは指定したプロキシをまだ使っていません。ログにリクエストがあり失敗するなら、ルールまたはノードの問題へ進みます。

バイパスリストと自動設定を確認する

システムプロキシには通常、プロキシを経由しないホストのリストを設定できます。localhost、LANアドレス、企業内ネットワークはバイパスされることが多い一方、範囲が広すぎるワイルドカードは通常のドメインまで除外する可能性があります。Windowsでは自動検出やPACスクリプトも同時に有効にでき、macOSではネットワークサービスごとにプロキシ設定が保存されます。Clashを終了してもシステムにプロキシが残る場合は、自動プロキシスクリプト、管理ポリシー、別の常駐プログラムを確認します。変更前に元の設定を記録し、組織が管理する端末ではポリシーを強制的に削除しないでください。

LANアドレスは通常直結にし、ルーター、プリンター、ファイル共有へのアクセスがプロキシノードへ迂回しないようにします。TUNを有効にしてLANリソースが消えた場合は、除外ルート、プライベートアドレスのルール、厳格なルーティング設定を確認します。システムプロキシとTUNは異なるトラフィックを取り込むため、単純に両方を有効にしてから判断しないでください。診断ではまずシステムプロキシだけ、次にTUNだけを個別にテストします。両方が個別に正常と確認できてから、同時に有効にする必要があるか判断します。

終了後に残るプロキシを処理する

クライアントのクラッシュ、強制終了、システムのシャットダウン時には、プロキシ設定を復元する時間が足りないことがあります。再起動後、Clashがまだ起動していないのに、システムプロキシに従うすべてのアプリがすぐ接続失敗するのが典型例です。まずシステムのネットワーク設定で手動プロキシを無効にし、その後クライアントを起動してシステムプロキシを一度正常に切り替えます。頻繁に起きる場合は、クライアントのサービスモード、デーモン、スタートアップ権限を確認し、現在も保守されているバージョンを使ってください。再インストール前に必要な設定をエクスポートし、対応プラットフォームのインストーラーをダウンロードセンターから選びます。

企業向けセキュリティソフトがプログラムによるシステムプロキシの変更を阻止することがあります。画面上のスイッチが有効に見えても、システム値が変わっていない場合があります。このときはクライアントのボタンより、システムのプロキシ設定画面を直接確認する方が確実です。逆に、システム値は変更されても、セキュリティソフトがローカル待受ポートの通信を遮断することもあります。ポート確認コマンドでClashが待ち受けていることを確認し、ブラウザーのリクエストがログに入るか観察します。システム設定、ポート待受、ログへのリクエストの3つが同時に成立して初めて、システムプロキシ経路が確立したと判断できます。

08 · 起動できない／繰り返し終了する

クライアントがクラッシュする：画面、コア、設定、システムコンポーネントを分けて確認する

まずクラッシュした段階を確認する

クライアントのクラッシュは、起動画面、設定の読み込み、コアの起動、TUNの有効化、サブスクリプション更新など、さまざまな段階で発生します。段階によって調べる方向が変わります。ダブルクリックしてもウィンドウがまったく表示されない場合は、システムイベントログ、アプリのログディレクトリ、セキュリティソフトの遮断記録を確認します。ウィンドウ表示後、設定読み込み時に終了するなら、設定構文、大きすぎるルールセット、上書きスクリプトを疑います。TUNを有効にしたときだけ終了するなら、仮想ネットワークアダプター、サービス権限、他のVPNドライバーを重点的に確認します。「開けない」とだけ記録せず、最後に表示された画面と最後のログ行を書き留めてください。

前回の設定の自動復元やスタートアップ起動をまず無効にし、起動直後に故障状態を繰り返し読み込まないようにします。クライアントにセーフモードや設定パス指定機能があれば、最小設定で起動します。セーフモードがない場合は、まずプロセスを終了し、設定ディレクトリをバックアップしてから、現在有効な設定を元の場所から移動します。空の状態で起動できたら、すぐにディレクトリ全体を戻さないでください。基本設定を1つだけインポートし、コアが動作することを確認してから、サブスクリプション、上書き、画面設定を段階的に戻します。

GUIとコアの問題を分ける

GUIクライアントは設定管理とシステム統合を担当し、実際のプロキシ処理は通常、mihomoなどのコアプロセスが行います。画面は表示されるのにコアが繰り返し停止する場合は、コアログで設定エラー、ポート競合、権限の問題を確認します。画面自体が応答しなくてもコアが動作している場合は、ネットワークが一時的に使えることがあり、問題は画面のキャッシュ、描画コンポーネント、設定一覧の大きさに偏っています。タスクマネージャーまたはアクティビティモニタで、どのプロセスが終了したか確認できます。コアが動作中に複数のGUIインスタンスを繰り返し起動しないでください。制御ポートや設定ファイルのロックを奪い合う可能性があります。

設定の検証では、まず構文、次にリソース規模を切り分けます。大規模なルールセット、多すぎるプロキシノード、頻繁なヘルスチェックは、起動時間とメモリ使用量を増やします。プログラムが一時的に応答しなくても、すぐにクラッシュしたとは限りません。CPU、メモリ、ログが変化し続けているかを確認します。毎回同じルールプロバイダーの読み込み後に停止するなら、そのプロバイダーを一時的に無効にするか、キャッシュを消去して再試行します。リモートルールファイルのダウンロードが不完全で、破損したキャッシュが残ることもあります。削除前に、サブスクリプションからファイルを再取得できることを確認してください。

ポート、権限、ドライバーの競合を確認する

混合ポート、制御ポート、DNSポートが使用中だと、コアの起動に失敗することがあります。前述のコマンドで占有プロセスを確認し、設定で同じ待受アドレスを誤って重複定義していないか調べます。1024未満のポートやTUNデバイスには追加権限が必要な場合がありますが、常に管理者権限で実行することを唯一の解決策にしないでください。まずクライアントのサービスコンポーネントが正しくインストールされているか、システム拡張が許可されているか、仮想ネットワークアダプターが存在するか確認します。macOSではOS更新後にネットワーク拡張の再認証が必要になることがあり、Windowsではセキュリティポリシーがドライバーの読み込みを阻止することがあります。

他のVPN、仮想マシンのネットワーク、コンテナプラットフォーム、ゲームアクセラレーター、セキュリティソフトがネットワークフィルタードライバーをインストールしていることがあります。これらのプログラムを開いていなくても、バックグラウンドサービスが動作している場合があります。TUNモードでだけクラッシュまたは切断するなら、関連サービスを完全に終了して再テストします。通常のシステムプロキシが安定するなら、基本的なコアとノードは利用でき、問題は仮想ネットワークアダプター経路に集中しています。他のネットワークソフトを1つずつ戻し、具体的な競合項目を特定してください。すべてを一度にアンインストールする必要はありません。

リセットと再インストールの正しい順序

プログラムを再インストールしても、ユーザー設定が自動的に削除されるとは限りません。破損した設定が再インストール後も有効になることがあります。正しい手順は、サブスクリプションリンク以外の必要情報を先にエクスポートし、カスタムルールとポートを記録してから、クライアントを終了し、設定ディレクトリをバックアップすることです。元のディレクトリ名を変更し、新しいインストールでクリーンな設定を初回生成させます。空の状態が安定したことを確認してから、サブスクリプションを再インポートします。古いディレクトリ全体を新しい場所へ直接コピーしないでください。キャッシュ、ウィンドウ状態、故障した設定まで復元されます。

システムイベントログに実行コンポーネントの不足、ファイル権限の異常、プログラムの隔離が記録されている場合は、システムの指示に従って修復します。インストーラーはプロセッサのアーキテクチャとOSに適合していなければなりません。Apple SiliconとIntel、Windows x64とその他のアーキテクチャを混用しないでください。現在のクライアントの選択肢とプラットフォーム対応はダウンロードセンターで確認でき、デスクトップではClash Plusを優先できます。復旧後は、スタートアップ起動とTUNを1つずつ有効にし、そのたびに再起動して確認します。起動順序や権限の復元がクラッシュを再発させていないことを確かめてください。

09 · AndroidとiOS

モバイル環境：バックグラウンド制限、VPN権限、ネットワーク切り替え

VPN設定とシステム状態を確認する

AndroidとiOSのClash系クライアントは、通常システムのVPNインターフェースを通じてトラフィックを取り込みます。初回接続ではユーザーによる明示的な許可が必要で、システムステータスバーにVPN表示が出ます。画面上は接続済みなのにステータスバーに表示がない場合は、システムのVPN設定を再確認し、別のVPN、企業向けセキュリティ接続、システムレベルのネットワークツールが同じインターフェースを占有していないか調べます。モバイルOSでは通常、アクティブなVPNは1つだけです。別のアプリを起動すると現在の接続が切れ、クライアント画面への状態反映に数秒かかることもあります。

iOSではClash Plusを利用でき、ダウンロードセンターのiOS入口からApp Storeへ移動できます。AndroidではダウンロードセンターでClash Plus、Clash Meta for Android、FlClash、Surfboardを比較できます。クライアントを移行するときは、自動接続設定を2つ同時に残さないでください。まず古いクライアントを切断し、オンデマンド接続を無効にしてから新しい設定をインポートします。サブスクリプションは再インポートできますが、カスタムルールと上書きは個別に記録し、プラットフォームが対応していないフィールドをそのままコピーしないでください。

バックグラウンド停止と画面ロック後の切断に対処する

Android端末メーカーのバッテリー制御によって、画面消灯後にクライアント、コア、VPNサービスが制限されることがあります。画面点灯中は正常なのに、数分ロックすると通信できなくなり、アプリを開くとすぐ復旧するのが典型例です。システムのバッテリー設定でクライアントのバックグラウンド実行を許可し、そのアプリへの省電力制限を解除し、自動起動やバックグラウンド動作を許可します。メーカーによって項目名は異なりますが、判断基準は同じです。ロック中にVPN表示が消えるか、システムがアプリを制限した記録を残しているか、通知領域の常駐サービスが削除されているかを確認します。

iOSはバックグラウンド実行を厳格に管理しますが、確立済みのシステムVPNは通常ネットワーク拡張が維持します。頻繁に切断する場合は、オンデマンド接続ルール、低電力モード、システムVPN設定、ネットワーク拡張の権限を確認します。アプリスイッチャーからクライアントを何度も強制終了し、その後に画面が定期的にサブスクリプションを更新することを期待しないでください。サブスクリプションの更新はアプリを開いたときに手動で行い、接続の安定性はシステムVPNの状態で判断します。ストレージ不足やシステム更新中も、設定の書き込みや拡張機能の起動に影響することがあります。

Wi-Fiとモバイルデータを切り替える

Wi-Fiからモバイルデータへ切り替えると、ローカルアドレス、DNS、MTU、IPv6環境がすべて変わり、既存の接続を再確立する必要があります。短時間の切断は通常の切り替え動作ですが、長時間復旧しない場合はVPNを手動で切断して再接続し、新しいネットワークでノード接続が再確立されるか確認します。モバイルデータでは使えるのに特定のWi-Fiで使えない場合は、そのWi-FiにWeb認証が必要か、VPNを制限しているか、IPv6やDNSに異常がないかを調べます。公共Wi-Fiでは、まずプロキシを切断してブラウザーで認証を完了し、その後クライアントへ接続します。

モバイルデータでだけ失敗する場合は、クライアントのモバイルデータ利用が禁止されていないか、データセーバーが有効でないか、サブスクリプションやノードのドメインをモバイル回線のDNSで解決できるか確認します。デュアルSIM端末では、現在のデータSIMとネットワーク切り替えポリシーも確認します。信号変化時にデータSIMを自動で切り替え、既存接続が無効になるシステムもあります。診断時は1枚のデータSIMに固定し、スマート切り替えを無効にして同じノードをテストします。復旧後に自動切り替えを段階的に戻し、ネットワーク変更のたびに再接続が必要か判断します。

アプリ別プロキシとLANアクセス

Androidクライアントには、指定したアプリだけをプロキシする、または指定したアプリを除外する機能があることが多いです。設定を誤ると、ブラウザーは正常なのに対象アプリが直結したり、システムコンポーネントが通信できなくなったりします。確認時はアプリ別ルールを一時的に無効にし、すべてのアプリを同じ接続で使います。正常になったら、除外項目を1つずつ追加します。アプリの更新、パッケージ名の変更、仕事用プロファイルによって以前の選択が無効になることがあります。個人プロファイルと仕事用プロファイルでVPN権限が異なる場合もあります。接続ログで対象アプリのリクエストがコアに入っているか確認してください。

家庭用ルーター、キャスト機器、LANサービスへアクセスするときは、プライベートアドレスを直結にします。VPN接続後にLAN機器が見つからない場合は、クライアントに「LANアクセスを許可」する設定があるか、設定のプライベートアドレスルール、システムのローカルネットワーク権限を確認します。iOSではローカルネットワークへのアクセス許可が個別に求められます。拒否してもプロキシ自体は動作することがありますが、機器の検出とLAN接続は失敗します。Androidでは、LANサービスのスキャンに付近のデバイスや位置情報に関する権限が必要な場合もあります。これはプロキシノードの利用可否とは別の問題です。

モバイルでの最小限の復旧手順

モバイル端末で継続的に通信できなくなった場合は、固定した順序で確認します。まずクライアントを切断し、VPNを無効にした状態で基礎ネットワークが正常か確認します。次に機内モードを一度切り替えてネットワークを復旧します。クライアントを開き、具体的なノードを選び、ルールモードで再接続します。システムのVPN表示とクライアントログを確認し、それでも失敗する場合はWi-Fiまたはモバイルデータへ切り替えて比較します。アプリデータの消去とサブスクリプションの削除を同時に行わないでください。元の障害の証拠が失われます。設定を読み込めない、またはアプリの状態が破損していると確認できた場合だけ、必要な設定をバックアップしてリセットします。

再インストール後も失敗するなら、原因はアプリファイルではなく、システムVPN設定、ネットワーク環境、サブスクリプションやノードにある可能性が高いです。システム設定に残った古いVPN構成を削除し、端末を再起動してから、現在のクライアントに権限を再申請させます。1つのアプリだけが異常なら、そのアプリのプライベートDNS、データ権限、アプリ別プロキシを確認します。すべてのアプリが異常なら、ノード、DNS、ネットワーク切り替え経路へ戻ります。モバイルでの確認でも重要なのは変数を1つに保つことです。クライアント、ノード、ネットワークを固定して1回の接続を成功させ、その後に自動選択、バックグラウンド設定、アプリ別ルールを段階的に戻します。

このページの手順でも原因を特定できない場合は、最小限の問題報告を作成します。端末とOS、クライアント名、発生したネットワーク、現在のモード、TUNの有効・無効、再現できる接続先、正常から失敗に至る具体的な手順、サブスクリプション情報を伏せた関連ログを含めてください。クライアントを終了すると復旧するか、テザリングへ切り替えると復旧するか、他のノードは正常かも明記します。これらの比較結果は、「接続できない」という一言だけよりも障害の層を判断する助けになります。また、サブスクリプションリンクや個人のネットワーク情報の漏えいも防げます。