起因 chrome 在最近版本中添加了一个叫 Local Network Access Checks 的功能，除了网页服务本身确有访问局域网流量和一些插件以外，只要我开着软路由 fakeip 模式代理就会让所有需代理的网站都触发这个弹窗（如果拒绝就会使得大量 css 和 js 无法在网页中加载，但是单独访问又可以正常打开 css 本身）
虽然可以通过 flags 直接禁用这个权限控制，但这个安全特性还是有启用的必要，所以计划更换成 realip 模式。
fakeip 模式在今天的网络环境中，能起到的作用无非两个：
-
如果本身你的代理插件配置了错误的 dns 流程，因为 fakeip 的关系，真正代理访问的 dns 由服务端发起，这时只要你的路由规则正确，本地的 dns 污染、错误解析那些实质上没有影响
-
消弥本地网络环境和远端网络环境的差异：具体来说比如你本地打开了 ipv6 ，代理服务器 only_ipv4 ，在 realip 模式下，会因为节点试图连接 ipv6 地址而访问失败，而 fakeip 模式下就可以实现服务端自行 fallback 到 ipv4
我主要是因为第 2 点，简单来说，如果想同时启用 ipv6 和 realip ，只有一个方法：确保你所使用的全部代理节点都拥有 ipv6 。
但我的使用场景是部分节点有 v6 ，部分 only_ipv4 ，同时因为单纯在代理插件中屏蔽 AAAA 记录，无法确保 reject 所有 ipv6 流量（有很多软件只要你的 tun 有 ipv6 ，就会坚持连接 ipv6 目标），就算 reject 了也并不能保证可以 fallback 到 ipv4 ；
尝试路由器开启 ipv6 获取和 ra 通告，发现因为 sing-box 的 tun 接口直接去掉了 ipv6 的关系，并不能实现：保持核心仅 v4 的同时，还能通过 dhcpv6 或 slaac 向局域网主机下发公网 ipv6
无它，只有一个解决方案了：彻底关闭 ipv6
之前打开 ipv6 对我的意义只有一个：确保能通过 mstsc+ipv6 远程直连我家里的一台 pc ，这是一个兜底方案，因为我这里的运营商对公网 ipv6 的上传控制非常严格，ipv6 直连上过了 2 分钟就会异常卡顿，因此我的主力方案其实是 rustdesk 中继，影响不大
而关闭 ipv6 并且启用 realip 以后，发现网速不降反增
（ p.s.我的本地宽带仅有 200mbps ）
尤其是国内流量，ipv6 优先时，经常能碰到 b 站网页加载完毕，视频缓冲半天，起初以为是阿 b 的 cdn 太烂了，换成纯 ipv4 环境再也没遇到过，所以很可能是运营商对 ipv6 有更严格的控制导致（就像远程直连那样 2 分钟就卡）
最后附上我在 openwrt 使用的，纯 ipv4+realip 模式的 sing-box 配置模板：
因为 realip 的关系，所以相比于 fakeip 的配置，在 dns.rules 添加了大量规则，主要是为了保证每个分流策略组，都能正确通过策略组自身代理请求 dns ，如图：
1
Select Language