On this page
If a browser asks to access devices at home while you are only watching a stream or signing in to a website, do not rush to allow it. The prompt may concern a real local service or virtual addresses created by the proxy. Compare the system proxy with virtual-adapter proxying, then inspect the failed request. Change only the relevant settings and keep the browser’s protection for real local-network access.
If the prompt appears only with TUN enabled, the website permission is probably not the root cause
Compare the same page with the Clash Verge Rev system proxy and TUN (virtual-adapter proxying). Does Chrome show “This site wants to access other devices on your local network” only when TUN is enabled, followed by failed images, video, login verification, or third-party components if you deny it, while the system proxy alone usually restores the page?
Chrome's local network access prompt is intended to protect routers, printers, and services on your computer. It classifies IPv6 unique local addresses such as fc00::/7 as local. Permission checks can also be triggered when Fake-IP (virtual addresses used for proxying) resolves a public page's subrequests into this address range.
- 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.
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 | Stop treating it as a Fake-IP misclassification |
| No application can connect | The scope exceeds a Chrome prompt on one site | Return to general node, DNS, and TUN troubleshooting |
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.
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 the Clash settings and save, without changing the node, DNS server, or TUN stack at the same time. Restart the Mihomo core, open the current configuration, and confirm that dns.ipv6 is false. If it remains true, another client switch or override is being merged into the configuration; repeatedly editing the same field in the subscription file alone will not help.
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 You Need IPv6, Return Real IP Addresses Only for Domains Confirmed to Be Affected
This section’s plain domain list applies when fake-ip-filter-mode is blacklist, or when that field is absent and the default blacklist is used. Check the mode in the current configuration before adding entries, rather than looking only at the domains in fake-ip-filter.
In whitelist mode, matching domains still receive Fake-IP addresses; rule mode uses different rule syntax. If either mode is in use, do not paste the list below directly. Follow the official instructions for that mode.
If you need IPv6 and only a few sites fail, exclude confirmed failing domains from Fake-IP. Do not guess domains from a website's name; use the connection records to choose entries.
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"Add filters only for confirmed failing domains
Add only one suffix
Start with the first failing domain in the connection records and append it to the existing fake-ip-filter. Keep the original entries, 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 return real addresses only for confirmed affected 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 |
After changing IPv6, do webpages and LAN access both work?
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 switch, return real addresses only for confirmed affected domains, or use 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 this change and inspect the site's actual 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