On this page
If the prompt appears only with TUN enabled, the website permission is probably not the root cause
This article covers a specific behavior: after TUN is enabled in Clash Verge Rev, Chrome shows “This site wants to access other devices on your local network” on ordinary public websites. If permission is denied, images, video, sign-in checks, or third-party components fail to load. The page usually recovers when TUN is disabled and only the system proxy is enabled.
Chrome's local-network prompt is designed to protect routers, printers, and local services. It classifies an IPv6 unique-local range such as fc00::/7 as local. A public page can therefore trigger the permission check when a subrequest is resolved by Fake-IP into that address space.
Use four comparisons to narrow the scope
| Comparison result | Description | What not to do yet |
|---|---|---|
| The site works with only the system proxy, but the prompt appears after TUN is enabled | The problem is concentrated in the DNS or IPv6 path after TUN interception | Do not reinstall the subscription or delete client data |
| The site recovers after Clash IPv6 is disabled | Fake IPv6 is strongly associated with Chrome's permission decision | Do not permanently allow every website |
| The prompt remains after TUN is disabled | The website may actually request the LAN, or the browser permission may have another source | Do not continue applying this article's Fake-IP fix |
| No application can connect | The scope exceeds a Chrome prompt on one site | Return to general node, DNS, and TUN troubleshooting |
- Public webpage in ChromeLoads the main page, images, video, or verification components
- Mihomo DNSAssigns the domain an IPv4 or IPv6 Fake-IP
- fdfe:dcba:9876::/64The address falls within fc00::/7, which Chrome treats as local
- Local Network AccessShows the permission prompt or blocks the subrequest before sending it
The page itself still has a public origin, but when a subrequest resolves to an IPv6 unique-local address, Chrome treats it as a public-to-local cross-address-space request.
Confirm Fake IPv6 from the current configuration and connection records
Do not look only at dns.ipv6 in the subscription file. The client combines subscriptions, global settings, and overrides into the final runtime configuration; Current Configuration is what actually takes effect. Open Current Configuration in Clash Verge Rev advanced settings and check the DNS mode, IPv6 setting, and IPv6 Fake-IP range.
Reproduce the prompt once more, then find the request for chrome.exe in connection records or logs. Reproduction logs from Clash Verge Rev issue #7564 repeatedly show fdfe:dcba:9876::1, a prefix inside the fc00::/7 range that Chrome identifies as the local network.
dns:
ipv6: true
enhanced-mode: fake-ip
fake-ip-range6: fdfe:dcba:9876::1/64Collect evidence from the same webpage request
Keep the current node
Pin the same node and Rule mode. First disable TUN and access the page through the system proxy, then restore TUN and open the same page.
Inspect the final configuration
Search Current Configuration for ipv6, enhanced-mode, and fake-ip-range6. Record the final values instead of relying on the original subscription.
Find the failing domains
After the prompt appears, inspect connection records or logs. Record the failing primary domain and CDN domains, and whether fdfe:dcba:9876:: appears.
Run one DNS comparison
While the issue still reproduces, query the failing domain. If the AAAA result falls within fdfe:dcba:9876::/64, the evidence matches the Fake IPv6 path.
nslookup www.bilibili.comTUN is enabled, dns.ipv6 is true, and the log contains fdfe:dcba:9876::
Proceed to the next section and validate with the reversible IPv6 setting first.
Current Configuration already has dns.ipv6: false
Restart the core and browser, then retest. If it still fails, check for another DNS override or stale cache.
There is no IPv6 Fake-IP, but the site really requests 192.168.x.x or a router address
Handle it as a real LAN permission request instead of attributing it to Clash.
The request never enters Clash
Return to system-proxy or TUN interception troubleshooting; do not adjust fake-ip-filter.
If IPv6 is not needed, disable Clash IPv6
For most users without an IPv6-specific requirement, disable IPv6 in Clash first. This is easier to reverse than granting a website LAN access or changing the address range. In Clash Verge Rev issue #7564, several users kept TUN enabled and restored Bilibili Live and other webpages by turning off this setting.
After saving, restart the Mihomo core and reopen Current Configuration to confirm that dns.ipv6 is false. If it still shows true, another client setting or override is being merged; do not keep editing the same field in the subscription file.
Make one minimal change
Record the original state
Capture or note Clash's IPv6 setting, TUN state, and Current Configuration values so the original state can be restored completely.
Disable IPv6
Disable IPv6 in Clash settings, save, and restart the core. Do not change the node, DNS server, or TUN stack at the same time.
Clear old resolution data
Close every Chrome window, clear the system DNS cache in Windows, then reopen the browser.
Open the original page
Repeat the original action at the same address and confirm whether the permission prompt, images, video, and verification components recover together.
ipconfig /flushdnsIf IPv6 must remain enabled, filter only confirmed affected domains
If IPv6 must remain enabled and the problem affects only a few websites, exclude only confirmed affected domains from Fake-IP. Find the real failing primary and CDN domains in connection records first, then append them to the existing fake-ip-filter. Do not guess a long domain list from the website name.
The following is the smallest example used to retest Bilibili in issue #7564. Different pages may use different CDN services, so it applies only when those suffixes actually appear in connection records. If the client supports merging or overrides, append them in an override and preserve existing filters.
dns:
fake-ip-filter:
- "*.bilibili.com"
- "*.hdslb.com"Narrow the scope one domain at a time
Add only one suffix
Start with the first failed request, save, restart the core, and reload the page.
Observe actual resolution
Confirm that the domain no longer receives an address in the fdfe:dcba:9876:: range while still matching the expected rule and egress.
Add a required CDN domain
Add a second item only if the page still lacks resources and connection records show a new failing domain.
Check subscription updates
Run one manual subscription update and confirm that the override remains. If it disappears, restore the backup and use the client's supported merge mechanism.
Do not change fake-ip-range6 alone or disable browser protections
Changing fake-ip-range6 from fdfe:dcba:9876::/64 to an apparently public range is not a fix to copy blindly. Mihomo issue #3064 documents that when only the DNS range changes, the TUN IPv6 address and route do not update automatically, potentially turning a permission prompt into a completely broken IPv6 path.
Disabling Chrome's local-network check is also not recommended. The prompt protects real routers and LAN devices. Turning off the browser protection expands every site's permissions without correcting the final Clash configuration.
High-risk shortcuts and safer alternatives
| Seemingly convenient action | Added risk | Safer alternative |
|---|---|---|
| Click Allow for every website | Public websites gain permission to request the local network | Grant access only to sites that genuinely need casting or device access |
| Disable Chrome LNA checks | Real LAN requests lose the browser prompt | Correct Clash IPv6 or filter settings |
| Change only fake-ip-range6 | DNS, TUN addresses, and routes may become inconsistent | Disable Fake IPv6 or narrowly filter confirmed domains |
| Downgrade directly and overwrite data | The subscription, overrides, and service state all change together | Export the configuration first and reserve rollback as the final option |
Restore the original settings and validate public webpages separately from LAN access
If disabling IPv6 or adding filters does not help, restore the recorded original values, remove the filters added in this procedure, and restart the core. Return to general troubleshooting: check whether the failed request enters Clash, whether DNS works, and whether the rule matches the expected policy instead of expanding the scope of changes.
Even after the fix, validate public webpages separately from the real LAN. A recovered webpage does not prove that printers, routers, or IPv6-only services still work; conversely, working LAN permissions do not prove every CDN request has left the Fake IPv6 range.
Choose rollback based on the usage requirement
| New issue after the fix | Rollback action | Evidence to retain |
|---|---|---|
| IPv6-only websites are unreachable | Restore the IPv6 setting and use narrow filtering or the system proxy | Current Configuration and the failing domain |
| Filters disappear after a subscription update | Restore the override backup; do not edit the remote subscription directly | Configuration diff before and after the update |
| Router or casting access fails | Restore the settings required for the real LAN and test the permission separately | Target local address and application name |
| The prompt remains without an fdfe address | Undo the changes from this article and inspect the site's real requests and Chrome site permissions | Destination address in developer tools or connection records |
Troubleshooting completion checklist
- Chrome no longer repeatedly requests local-network permission on the original problem page
- Images, video, sign-in verification, and third-party components still load after permission is denied
- dns.ipv6 in Current Configuration matches the intended value and has not been changed back by another override
- Connection records no longer map the failing domain into the fdfe:dcba:9876:: range
- Required routers, printers, casting devices, and local services remain reachable
- If IPv6 is genuinely required, IPv6-only services also pass a separate test
- The original settings and override backup are retained so the changes can be undone