分享一次 FakeIP 的踩坑记录

@lnbiuc 流览器还行，很多应用不给 sni 或者随便写的

除了更快，还有一种情况，本地代理 tproxy 非常好用，只要 nft 一个网段。
可以使用 CGNAT) 保留地址段 100.66.0.0/16 ，不要和当前运营商的冲突。

@yinmin 现在核心都有 tls sniffing ，就算不开 sniffing ，只要 dns 流量经过核心，都会建立映射表，已经没有域名分流问题了。

fakeip 最大的问题在于， 很多时候第一次访问某个域名会失败， 如果用的软件内部没有重试机制，那就会直接失败

常用网站国内网站禁用 fakeip 其余的一概走 tun

我理解如果使用 sing-box 的 DNS rule ，可以使用代理服务器来解析域名，是比较稳妥的办法。可以解决 DNS 污染问题，也不会有 DNS 缓存的问题。不好的一点是解析速度上可能会有一些延迟。

我同事在公司折腾所谓的旁路由+clash ，因为公司有 ipv6 ，结果这主机把自己声明为路由，同时又开了 fakeip ，导致公司内机器 dns 被污染，间歇性不能上网，全公司折腾一上午。

日经问题了。我的看法是，当你认识到它不好的时候就可以自己动手写一个了

sing-box 已经弃用 fakeip ，已被迫使用 dns 分流，不过就我个人而言用起来也没多大差别。

@m1nm13 为什么呀，我遇到过，浏览器第一次打开网页失败，重试一下就好了

你这个访问 local 的原因是因为 host 域名解析与部分请求域名不一致吧，是不是做了 dns 分流或者什么别的配置导致的，因为只要 host 是 private 就不会有这种问题才对

然而事实上商业代理软件都是用的 fakeip

不要折腾 DNS ，省不下多少时间，反而一旦出问题会花几倍乃至几十倍时间排查

不是很了解计算机网络，看完后有点疑惑，如果解析到的 IP 地址是被 Service Worker 持久化了的话，那么是不是意味着任何曾经访问过的域名更换 IP 地址后都会产生这个无法访问到的问题呢？

我之前就说过了，这玩意引入的问题比解决的问题多

单纯用 sing-box 的 Tun+FakeIP 日常使用基本没遇到过问题，没有特别的需求，用 sing-box+dae 不是徒增烦恼吗😂

这个看上去是因为 Chrome 缓存「是否本地」这件事情没有遵从 DNS TTL 的（正常 fake ip 都会把 TTL 设置成一个极短值）

另外，绝大多数软件系统级 HTTP 代理和 TUN 代理都是同时开的，因此也不会出现访问网站时每一个都提示是内网的情况

主路由是 routeros ，做透明代理只能使用 fakeip 分流

我家里有个 24 小时运行的 macmini 运行 Surge ，接管家里的网络请求。作为旁路网关，需要用的 surge 服务的设备手动设置网关指向 surge 虚拟网关 ip ，Surge 用的应该也是 FakeIP 。
到极少出问题，就是 macmini 升级时网关不可用，需要设备在手动改为 DHCP 自动，临时用家里路由器作为网关。

玩游戏只能说是灾难