接続トラブルシューティング · Clash 技術ブログ

Clash で TUN を有効にすると「Web サイトがローカルネットワークへのアクセスを要求しています」と表示される場合は?

Clash Verge Rev で TUN を有効にした後、Chrome に Web サイトからローカルネットワークへのアクセスを求める確認が表示され、画像、動画、認証コンポーネントが失敗する場合は、fdfe IPv6 のログを確認します。そのうえで Fake IPv6 を無効にするか、影響を受けるドメインだけを除外してください。

  • Clash Verge Rev
  • Chrome
  • TUN
  • IPv6
  • Fake-IP
目次

配信を見たりサイトにログインしたりするだけなのに、家庭内の機器へのアクセスをブラウザーに求められても、すぐ許可する必要はありません。本物のローカルサービスに関係する場合と、プロキシが生成した仮想アドレスに関係する場合があります。システムプロキシと仮想アダプター方式を比較し、失敗するリクエストを確認します。該当設定だけを調整し、実際のローカルネットワークを守るブラウザーの機能は残してください。

TUN が有効な場合だけ確認が表示されるなら、問題の中心は Web サイトの権限ではない可能性が高い

同じページで Clash Verge Rev のシステムプロキシと TUN(仮想アダプターによるプロキシ)を比較します。Chrome が「このサイトはローカルネットワーク上のほかのデバイスへのアクセスを求めています」と表示するのは TUN が有効なときだけか、拒否すると画像、動画、ログイン認証、外部コンポーネントが失敗するか、システムプロキシだけでは通常復旧するかを確認してください。

Chrome のローカルネットワークへのアクセス確認は、本来ルーター、プリンター、本機のサービスを保護するものです。fc00::/7 のような IPv6 のユニークローカルアドレスを local と判定します。公開ページの追加リクエストが Fake-IP(プロキシ用の仮想アドレス)でこの範囲に解決される場合も、権限確認が発生することがあります。

Chrome のローカルネットワーク確認と IPv6 Fake-IP の関係
  1. Chrome で開いたインターネット上のページメインページ、画像、動画、認証コンポーネントを読み込む
  2. Mihomo DNSドメインへ IPv4 または IPv6 Fake-IP を割り当てる
  3. fdfe:dcba:9876::/64アドレスが Chrome で local とみなされる fc00::/7 に入る
  4. Local Network Access子リクエストを送る前に権限確認を表示するか遮断する

ページ自体はインターネット上の提供元ですが、子リクエストの一つが IPv6 のユニークローカルアドレスへ名前解決されると、Chrome は public から local へのアドレス空間をまたぐアクセスとして扱います。

現在の設定と接続記録から Fake IPv6 を確認する

サブスクリプションファイル内の dns.ipv6 だけを見ないでください。クライアントはサブスクリプション、グローバルスイッチ、オーバーライドを組み合わせて最終実行設定を作るため、実際に反映されるのは「現在の設定」です。Clash Verge Rev の詳細設定で現在の設定を開き、DNS モード、IPv6 スイッチ、IPv6 Fake-IP のアドレス範囲を照合します。

確認をもう一度表示させ、接続記録またはログから chrome.exe のリクエストを探します。Clash Verge Rev issue #7564 の再現ログには fdfe:dcba:9876::1 が何度も現れ、このプレフィックスは Chrome がローカルネットワークとして識別する fc00::/7 の範囲に入っています。

現在の設定で確認すべきフィールド。この部分を変更用テンプレートとして扱わないでください
dns:
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range6: fdfe:dcba:9876::1/64

同じ Web リクエストから証拠を取得する

  1. 現在のノードを維持する

    同じノードと Rule モードに固定し、まず TUN を無効にしてシステムプロキシで一度アクセスします。その後 TUN を復元し、同じページへアクセスしてください。

  2. 最終設定を確認する

    現在の設定から ipv6、enhanced-mode、fake-ip-range6 を検索し、最終値を記録します。サブスクリプションの原文を代わりにしないでください。

  3. 失敗しているドメインを探す

    確認が表示された後に接続記録またはログを開き、読み込みに失敗したメインドメインと CDN ドメイン、fdfe:dcba:9876:: が現れたかを記録します。

  4. DNS を一度比較する

    問題を再現できる間に、失敗しているドメインを問い合わせます。AAAA の結果が fdfe:dcba:9876::/64 に入る場合、Fake IPv6 経路と一致する証拠になります。

Windows で実際に失敗したドメインを問い合わせる。接続記録のドメインへ置き換えてください
nslookup www.bilibili.com

TUN が有効で dns.ipv6 が true、ログに fdfe:dcba:9876:: が表示される

次の節へ進み、まずロールバック可能な IPv6 スイッチで検証します。

現在の設定がすでに dns.ipv6: false である

カーネルとブラウザを再起動して再テストします。引き続き失敗する場合は、別の DNS オーバーライドまたは古いキャッシュがないか確認してください。

IPv6 Fake-IP がないのに、Web サイトが実際に 192.168.x.x またはルーターのアドレスを要求している

実際の LAN 権限として扱い、Clash が原因だと判断しないでください。

リクエストが Clash へまったく入っていない

システムプロキシまたは TUN の接続確認へ戻り、fake-ip-filter は変更しないでください。

四つの比較で範囲を絞る

比較結果説明急いで行うべきではないこと
システムプロキシだけなら正常だが、TUN を有効にすると確認が表示される問題は TUN による引き継ぎ後の DNS または IPv6 経路に集中しているサブスクリプションを再インストールしたり、クライアントデータを削除したりしない
Clash の IPv6 を無効にすると復旧するFake IPv6 と Chrome の権限判定が強く関連しているすべての Web サイトを恒久的に許可へ設定しない
TUN を無効にしても確認が表示されるWeb サイトが実際に LAN へアクセスしようとしているか、ブラウザ権限に別の原因がある可能性Fake-IP の誤判定としての対処を続けない
すべてのアプリで通信できない範囲が Chrome の単一 Web サイトに対する確認を超えているノード、DNS、TUN の一般的な確認へ戻る

IPv6 が不要な場合は、Clash の IPv6 スイッチを無効にする

IPv6 固有の要件がない利用者の多くは、まず Clash の設定で IPv6 を無効にできます。Web サイトへ LAN 権限を付与したり、アドレス範囲を変えたりするよりも復元しやすい方法です。Clash Verge Rev issue #7564 では、複数の利用者が TUN を維持したままこのスイッチを無効にすると、Bilibili のライブ配信とほかの Web ページが復旧しました。

最小限の変更を一度完了する

  1. 元の状態を記録する

    Clash の IPv6 スイッチ、TUN の状態、現在の設定値をスクリーンショットまたはメモに残し、完全に元へ戻せるようにします。

  2. IPv6 を無効にする

    Clash の設定で IPv6 を無効にして保存し、同時にノード、DNS サーバー、TUN スタックを変更しないでください。Mihomo コアを再起動して現在の構成を開き、dns.ipv6 が false になったことを確認します。true のままなら、別のクライアント設定や上書きが合成されています。サブスクリプションの同じ項目だけを何度も変更しないでください。

  3. 古い名前解決キャッシュを消去する

    Chrome のウィンドウをすべて閉じ、Windows のシステム DNS キャッシュを消去してから、ブラウザを開き直します。

  4. 元のページへアクセスする

    同じ Web アドレスで元の操作を再現し、権限確認、画像、動画、認証コンポーネントがすべて正常に戻ったか確認します。

Windows のシステム DNS キャッシュを消去する
ipconfig /flushdns

IPv6 が必要な場合は、影響が確認されたドメインだけは実際の IP アドレスを返すよう設定する

この節の通常のドメイン一覧は、fake-ip-filter-mode が blacklist の場合、または指定がなく標準の blacklist を使う設定で適用できます。追加する前に現在の設定のモードを確認し、fake-ip-filter に並ぶドメインだけで判断しないでください。

whitelist モードでは、一致したドメインにも Fake-IP が返されます。rule モードは別のルール構文を使います。いずれかのモードを使っている場合は、下の一覧をそのまま貼り付けず、そのモードの公式説明に従って調整してください。

IPv6 が必要で、異常が少数のサイトに限られる場合は、失敗を確認できたドメインを Fake-IP の対象から外せます。サイト名からドメインを推測せず、接続記録をもとに項目を選んでください。

以下は issue #7564 で Bilibili を再テストするために使われた最小構成の例です。ページによって利用する CDN は異なるため、接続記録にこれらのサフィックスが実際に現れる場合に限って使用してください。クライアントがマージまたはオーバーライドに対応している場合は、既存のフィルター項目を残したまま、オーバーライドへ追加します。

接続記録で該当ドメインへのアクセスを確認できた場合のみ、既存のリストへ追加する
dns:
  fake-ip-filter:
    - "*.bilibili.com"
    - "*.hdslb.com"

失敗が確認されたドメインだけにフィルターを追加する

  1. サフィックスを一つだけ追加する

    接続記録で最初に失敗したドメインから始め、既存の fake-ip-filter に追加します。元の項目を残したまま保存し、コアを再起動してページを読み込み直してください。

  2. 実際の名前解決結果を確認する

    そのドメインが fdfe:dcba:9876:: の範囲にあるアドレスを返さなくなり、同時に想定どおりのルールと出口へ引き続き一致することを確認します。

  3. 必要な CDN を追加する

    ページのリソースがまだ欠けており、接続記録に新たな失敗ドメインが現れた場合に限って、二つ目を追加します。

  4. サブスクリプション更新後を確認する

    サブスクリプションを手動で一度更新し、オーバーライドが上書きされていないか確認します。消えていた場合はバックアップを復元し、クライアントが対応するマージ方式へ切り替えてください。

fake-ip-range6 だけを変更したり、ブラウザの保護機能を無効にしたりしない

fake-ip-range6 を fdfe:dcba:9876::/64 から一見グローバルに見える範囲へ変える方法は、そのまま適用できる修正ではありません。Mihomo issue #3064 には、DNS のアドレス範囲だけを変更しても TUN の IPv6 アドレスとルートが自動では同期されず、権限確認の問題が IPv6 経路全体の利用不能へ変わる可能性が記録されています。

同様に、Chrome のローカルネットワークアクセス検査を無効にすることも推奨しません。この確認は実際のルーターや LAN デバイスを保護するものです。ブラウザの保護を無効にすると、すべての Web サイトに対する権限範囲が広がる一方、Clash の最終設定は修正されません。

リスクの高い近道と、より安全な代替策

手軽に見える方法新たに生じるリスクより安全な代替策
Web サイトごとに許可を選ぶ公開 Web サイトにローカルネットワークへのリクエスト権限が付与されるキャストまたはデバイスへのアクセスを実際に必要とするサイトだけに許可する
Chrome の LNA 検査を無効にする実際の LAN リクエストでもブラウザの確認が表示されなくなるClash の IPv6 またはフィルター設定を修正する
fake-ip-range6 だけを変更するDNS、TUN のアドレス、ルートが不整合になる可能性があるFake IPv6 を無効にするか、影響が確認されたドメインだけは実際のアドレスを返すよう設定する
データを上書きして旧バージョンへ直接戻すサブスクリプション、オーバーライド、サービス状態がすべて変わる先に設定をエクスポートし、ロールバックは最後の選択肢にする

IPv6の設定を変えた後も、WebページとLANにアクセスできる?

IPv6 を無効にしても、フィルターを追加しても改善しない場合は、記録しておいた元の値を復元し、今回追加したフィルター項目を削除してカーネルを再起動します。その後は一般的なトラブルシューティングへ戻り、失敗したリクエストが Clash に入っているか、DNS が利用できるか、ルールが想定したポリシーへ一致しているかを確認してください。変更範囲をさらに広げないでください。

修正後も、公開 Web ページと実際の LAN は分けて検証してください。Web ページが復旧しても、プリンター、ルーター、IPv6 専用サービスが正常とは限りません。反対に LAN 権限が機能しても、すべての CDN リクエストが Fake IPv6 のアドレス範囲を離れたとは限りません。

利用要件に合わせてロールバック方法を選ぶ

修正後に発生した新たな問題ロールバック手順残しておく証拠
IPv6 専用 Web サイトへアクセスできないIPv6 のオン・オフ設定を元に戻し、影響が確認されたドメインだけは実際のアドレスを返すよう設定するか、システムプロキシに切り替える現在の設定と失敗したドメイン
サブスクリプション更新後にフィルター項目が消えるオーバーライドのバックアップを復元し、リモートのサブスクリプションは直接変更しない更新前後の設定差分
ルーターまたはキャストへのアクセスに異常がある実際の LAN に必要な設定を復元し、権限を個別にテストする対象のローカルアドレスとアプリケーション名
fdfe アドレスがないのに、確認が引き続き表示される今回の変更を戻し、サイトの実際のリクエストと Chrome のサイト権限を調べる開発者ツールまたは接続記録に表示された接続先アドレス

調査完了の確認リスト

  • Chrome で元の問題ページへアクセスしても、ローカルネットワーク権限を繰り返し要求されない
  • 権限を拒否しても、画像、動画、ログイン認証、サードパーティー製コンポーネントが読み込まれる
  • 現在の設定で dns.ipv6 が想定どおりになっており、別のオーバーライドによって元へ戻されていない
  • 接続記録で、失敗したドメインが fdfe:dcba:9876:: の範囲へマッピングされなくなった
  • 必要なルーター、プリンター、キャスト、ローカルサービスへ引き続きアクセスできる
  • IPv6 が必要な場合は、IPv6 専用サービスも個別のテストに合格している
  • 元の設定とオーバーライドのバックアップを残しており、今回の変更を取り消せる

参考資料