最近应该说很久了:用Chrome/Edge 访问部分网站时,总给我弹出“网站想要访问本地网络中的其他设备”。拒绝权限后,网站图片、脚本会加载失败。
我一直没有在意因为运行后就恢复了。
但是我昨天在注册一个vps网站准备买鸡鸡和准备薅羊毛注册umgc的时候一直提示我reCAPTCHA验证错误,这我就忍不了,耽误我薅羊毛这不是闹吗!!!!!
最后用codex一顿检查,问题不是网站账号、浏览器插件或 reCAPTCHA 本身,而是 IPv6 Fake-IP 地址段被 Chromium 当成了本地网络地址。

根本原因
Clash Verge Rev 2.5.2 在开启 IPv6 和 Fake-IP 后,会补充下面的默认配置:
fake-ip-range6: fdfe:dcba:9876::1/64
但 fdfe:* 位于 IPv6 ULA 私有地址范围 fc00::/7。Chromium 的 Local Network Access 会将这个地址空间判定为本地网络。
于是浏览器看到的过程相当于:
公网 HTTPS 页面
↓
域名被 Mihomo 返回为 fdfe:* Fake-IP
↓
Chromium 将 fdfe:* 判断为本地网络地址
↓
触发 Local Network Access 权限
↓
拒绝权限后,相关图片、脚本或验证码请求被拦截
这也解释了为什么问题主要发生在 IPv6:IPv4 Fake-IP 使用的是 198.18.0.0/16 一类测试地址,不属于 Chromium 所识别的 IPv4 本地地址;而旧的 IPv6 Fake-IP 恰好使用了 ULA。
解决方法
不需要关闭 IPv6,也不需要强制 IPv4 优先。只要在 dns 配置中明确指定新的 IPv6 Fake-IP 地址池:
dns:
enable: true
ipv6: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-range6: 2001:2::0/64
也就是把:
fake-ip-range6: fdfe:dcba:9876::1/64
替换为:
fake-ip-range6: 2001:2::0/64
修改后需要:
- 保存并重新应用配置。
- 重启 Mihomo/Clash Verge 核心。
- 完全退出所有 Chrome/Edge 进程,再重新打开浏览器。
- 将测试网站的“本地网络”权限关闭或恢复默认后重新测试。
仅刷新网页通常不够,因为旧的 Fake-IP 和连接仍可能保存在浏览器网络进程中。
为什么使用 2001:2::0/64
2001:2::/48 是 RFC 5180 保留的网络基准测试地址段,不会对应正常公网主机,同时也不属于 fc00::/7 ULA 本地地址空间。2001:2::0/64 是该保留地址段中的一个子网。
更换后,Chromium 不再把 Fake-IP 请求当作访问局域网,因此不再触发这次遇到的 Local Network Access 拦截。
修改结果
修改并完全重启浏览器后:
- 网站不再请求“本地网络”权限。
- 关闭该权限后,图片仍可正常加载。
- 原来异常的网站可以正常注册和登录。
- reCAPTCHA 恢复正常。
- 浏览器看到的相关 Fake-IP 从
fdfe:* 变成了 2001:2:*。
- IPv6 仍然保留并可正常使用。
不用担心!!
这个修改不会改变:
rules 规则顺序
- 节点选择和代理组
- 国内外分流
- IPv4 Fake-IP 地址池
- IPv6 开关
- DNS 的直连或代理策略
它只改变 Mihomo 分配给域名的虚拟 IPv6 地址池。Mihomo 仍会根据 Fake-IP 还原原始域名,并按照原有规则进行分流。
简短结论
如果同时满足以下条件:
- 开启 TUN、IPv6 和 Fake-IP;
- Chrome/Edge 提示访问本地网络;
- 拒绝权限后图片、脚本或验证码加载失败;
- 请求地址中出现
fdfe:*;
可以优先尝试:
fake-ip-range6: 2001:2::0/64
修改后务必重启 Mihomo 核心,并完全退出再启动浏览器。