目次
TUN が有効な場合だけ確認が表示されるなら、問題の中心は Web サイトの権限ではない可能性が高い
この記事で扱うのは、非常に具体的な現象です。Clash Verge Rev で TUN を有効にすると、Chrome で一般的なインターネット上の Web サイトへアクセスした際に「Web サイトがローカルネットワーク上のほかのデバイスへのアクセスを要求しています」と表示されます。拒否すると、画像、動画、ログイン認証、第三者製コンポーネントの読み込みに失敗します。TUN を無効にしてシステムプロキシだけを有効にすると、通常はページが復旧します。
Chrome のローカルネットワークアクセス確認は、本来ルーター、プリンター、端末自身のサービスを保護するためのものです。fc00::/7 のような IPv6 のユニークローカルアドレスを local と判定します。インターネット上のページが送る子リクエストを Fake-IP がこのアドレス空間へ名前解決した場合も、権限判定が発生することがあります。
四つの比較で範囲を絞る
| 比較結果 | 説明 | 急いで行うべきではないこと |
|---|---|---|
| システムプロキシだけなら正常だが、TUN を有効にすると確認が表示される | 問題は TUN による引き継ぎ後の DNS または IPv6 経路に集中している | サブスクリプションを再インストールしたり、クライアントデータを削除したりしない |
| Clash の IPv6 を無効にすると復旧する | Fake IPv6 と Chrome の権限判定が強く関連している | すべての Web サイトを恒久的に許可へ設定しない |
| TUN を無効にしても確認が表示される | Web サイトが実際に LAN へアクセスしようとしているか、ブラウザ権限に別の原因がある可能性 | この記事の Fake-IP 修正を適用し続けない |
| すべてのアプリで通信できない | 範囲が Chrome の単一 Web サイトに対する確認を超えている | ノード、DNS、TUN の一般的な確認へ戻る |
- Chrome で開いたインターネット上のページメインページ、画像、動画、認証コンポーネントを読み込む
- Mihomo DNSドメインへ IPv4 または IPv6 Fake-IP を割り当てる
- fdfe:dcba:9876::/64アドレスが Chrome で local とみなされる fc00::/7 に入る
- 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 リクエストから証拠を取得する
現在のノードを維持する
同じノードと Rule モードに固定し、まず TUN を無効にしてシステムプロキシで一度アクセスします。その後 TUN を復元し、同じページへアクセスしてください。
最終設定を確認する
現在の設定から ipv6、enhanced-mode、fake-ip-range6 を検索し、最終値を記録します。サブスクリプションの原文を代わりにしないでください。
失敗しているドメインを探す
確認が表示された後に接続記録またはログを開き、読み込みに失敗したメインドメインと CDN ドメイン、fdfe:dcba:9876:: が現れたかを記録します。
DNS を一度比較する
問題を再現できる間に、失敗しているドメインを問い合わせます。AAAA の結果が fdfe:dcba:9876::/64 に入る場合、Fake IPv6 経路と一致する証拠になります。
nslookup www.bilibili.comTUN が有効で 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 は変更しないでください。
IPv6 が不要な場合は、Clash の IPv6 スイッチを無効にする
IPv6 固有の要件がない利用者の多くは、まず Clash の設定で IPv6 を無効にできます。Web サイトへ LAN 権限を付与したり、アドレス範囲を変えたりするよりも復元しやすい方法です。Clash Verge Rev issue #7564 では、複数の利用者が TUN を維持したままこのスイッチを無効にすると、Bilibili のライブ配信とほかの Web ページが復旧しました。
保存後に Mihomo カーネルを再起動し、現在の設定を開いて dns.ipv6 が false になったことを確認します。引き続き true と表示される場合は、別のクライアントスイッチまたはオーバーライドが設定へマージされています。サブスクリプションファイル内の同じフィールドだけを繰り返し変更しないでください。
最小限の変更を一度完了する
元の状態を記録する
Clash の IPv6 スイッチ、TUN の状態、現在の設定値をスクリーンショットまたはメモに残し、完全に元へ戻せるようにします。
IPv6 を無効にする
Clash の設定で IPv6 を無効にし、保存してからカーネルを再起動します。このとき、ノード、DNS サーバー、TUN スタックを同時に変更しないでください。
古い名前解決キャッシュを消去する
Chrome のウィンドウをすべて閉じ、Windows のシステム DNS キャッシュを消去してから、ブラウザを開き直します。
元のページへアクセスする
同じ Web アドレスで元の操作を再現し、権限確認、画像、動画、認証コンポーネントがすべて正常に戻ったか確認します。
ipconfig /flushdnsIPv6 を維持する必要がある場合は、影響が確認できたドメインだけを除外する
IPv6 を維持する必要があり、問題が一部の Web サイトだけで起きる場合は、影響が確認できたドメインを Fake-IP の対象外にできます。まず接続記録から、実際に失敗しているメインドメインと CDN ドメインを特定し、既存の fake-ip-filter へ追加してください。サイト名だけを手掛かりに、多数のドメインを推測して追加しないでください。
以下は issue #7564 で Bilibili を再テストするために使われた最小構成の例です。ページによって利用する CDN は異なるため、接続記録にこれらのサフィックスが実際に現れる場合に限って使用してください。クライアントがマージまたはオーバーライドに対応している場合は、既存のフィルター項目を残したまま、オーバーライドへ追加します。
dns:
fake-ip-filter:
- "*.bilibili.com"
- "*.hdslb.com"ドメインごとに対象を絞り込む
サフィックスを一つだけ追加する
最初に失敗したリクエストのドメインから追加し、保存してカーネルを再起動した後、ページを再読み込みします。
実際の名前解決結果を確認する
そのドメインが fdfe:dcba:9876:: の範囲にあるアドレスを返さなくなり、同時に想定どおりのルールと出口へ引き続き一致することを確認します。
必要な CDN を追加する
ページのリソースがまだ欠けており、接続記録に新たな失敗ドメインが現れた場合に限って、二つ目を追加します。
サブスクリプション更新後を確認する
サブスクリプションを手動で一度更新し、オーバーライドが上書きされていないか確認します。消えていた場合はバックアップを復元し、クライアントが対応するマージ方式へ切り替えてください。
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 を無効にするか、確認済みのドメインだけを対象にフィルターを設定する |
| データを上書きして旧バージョンへ直接戻す | サブスクリプション、オーバーライド、サービス状態がすべて変わる | 先に設定をエクスポートし、ロールバックは最後の選択肢にする |
元の設定を復元し、Web ページと LAN を個別に検証する
IPv6 を無効にしても、フィルターを追加しても改善しない場合は、記録しておいた元の値を復元し、今回追加したフィルター項目を削除してカーネルを再起動します。その後は一般的なトラブルシューティングへ戻り、失敗したリクエストが Clash に入っているか、DNS が利用できるか、ルールが想定したポリシーへ一致しているかを確認してください。変更範囲をさらに広げないでください。
修正後も、公開 Web ページと実際の LAN は分けて検証してください。Web ページが復旧しても、プリンター、ルーター、IPv6 専用サービスが正常とは限りません。反対に LAN 権限が機能しても、すべての CDN リクエストが Fake IPv6 のアドレス範囲を離れたとは限りません。
利用要件に合わせてロールバック方法を選ぶ
| 修正後に発生した新たな問題 | ロールバック手順 | 残しておく証拠 |
|---|---|---|
| IPv6 専用 Web サイトへアクセスできない | IPv6 の設定を元に戻し、対象を絞ったフィルターまたはシステムプロキシを使用する | 現在の設定と失敗したドメイン |
| サブスクリプション更新後にフィルター項目が消える | オーバーライドのバックアップを復元し、リモートのサブスクリプションは直接変更しない | 更新前後の設定差分 |
| ルーターまたはキャストへのアクセスに異常がある | 実際の LAN に必要な設定を復元し、権限を個別にテストする | 対象のローカルアドレスとアプリケーション名 |
| fdfe アドレスがないのに、確認が引き続き表示される | 本稿の変更を取り消し、Web サイトが実際に要求している接続と Chrome のサイト権限を確認する | 開発者ツールまたは接続記録に表示された接続先アドレス |
調査完了の確認リスト
- Chrome で元の問題ページへアクセスしても、ローカルネットワーク権限を繰り返し要求されない
- 権限を拒否しても、画像、動画、ログイン認証、サードパーティー製コンポーネントが読み込まれる
- 現在の設定で dns.ipv6 が想定どおりになっており、別のオーバーライドによって元へ戻されていない
- 接続記録で、失敗したドメインが fdfe:dcba:9876:: の範囲へマッピングされなくなった
- 必要なルーター、プリンター、キャスト、ローカルサービスへ引き続きアクセスできる
- IPv6 が必要な場合は、IPv6 専用サービスも個別のテストに合格している
- 元の設定とオーバーライドのバックアップを残しており、今回の変更を取り消せる