1

同意你的看法，我也是不喜欢 fakeIP

3

FakeIP 被应用超期缓存，应用没有严格尊重 TTL 是原因。DDNS 与 FakeIP 同理。那么到底是 DDNS 和 FakeIP 设计的错，还是应用的错呢

4

5

cdn 会导致很多域名共用 ip 地址，fakeip 是解决 realip 无法根据域名分流的问题。

6

fakeip 只适合于不关代理的情况的

7

@yinmin 对的，fakeip 当时的出现我记得就是为了解决 redir-host 的 dns 解析问题的，延迟不是主要需要。dns 延迟需求其实很小的，大多数人日常访问的网站都很难遇到延迟的情况。

8

不用 fakeip 就没法跟据域名分流,不管是嗅探还是 mitm 都不靠谱，但是我的实现方式是，对能直连的域名返回真实 ip ，对要处理的才返回 fakeip

9

@heiher #4 代理 DNS 请求不也能实现“在服务器端进行域名解析”吗，为此引入 FakeIP 和一系列问题感觉时不值得的

10

@yinmin 不用 fakeip ，也不用 redir-host ，mihomo 还支持 normal 模式，取消 IP 和域名映射，之后通过 sniffer 获取域名进行路由但是不覆写，直接先代理服务器发送 IP 进行连接，不存在你说的问题。
但是需要在客户端处理好 DNS 分流

11

Service Worker 对资源的缓存，怎么成了和 IP 耦合而不是和域名耦合的了，感觉像是 Chrome 的 BUG 。

12

@lnbiuc #9 代理 DNS 请求需要知道代理服务器端的 DNS 服务器地址，否则只能用公共 DNS 。公共 DNS 解析出的 IP 体验没有 ISP 提供的好。

13

@choury 嗅探要准确需要禁用 ECH ，禁用 type64/65 类型解析

14

1

非 http/sni 的流量使用 fakeip 可能會出現問題，例如玩遊戲時有可能會出現無法連線伺服器的情況。因為 fakeip 某種意義上也相當於一次 nat 了。

15

修正，是 http/tls 流量

16

非 http/tls 的流量使用 fakeip 可能會出現問題，例如玩遊戲時有可能會出現無法連線伺服器的情況。
此外 fakeip 某種意義上也相當於一次 nat 了。

17

专机专用 从来不考虑分流 不用 fakeip

19

@lnbiuc #18 举个实际的例子：机场服务器的 ISP 提供的 DNS 是 a.a.a.a ，机场服务器系统默认是用 a.a.a.a 解析域名的。用户不知道 a.a.a.a 的具体地址时，配置为 1.1.1.1 ，DNS 请求送到机场服务器上也是经 1.1.1.1 解析的。这与使用 a.a.a.a 解析的结果可能是不同的。（体验包括 IP 访问延迟，也包括基于 DNS 解析的特征进行代理识别

20

@heiher #19 sorry 我是自己购买服务器自建的，不清楚还有这种需求

21

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

22

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

23

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

24

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

25

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

26

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

27

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

28

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

29

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

30

1

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

31

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

32

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

33

1

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

34

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

35

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

36

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

37

38

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

39

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

40

1

玩游戏只能说是灾难

41

软路由跑 openclash ，开 fakeip 后，ps5 联网经常出一些莫名奇妙的问题，后来就放弃了

42

@iwfd965 sing-box 仅入站 socks 然后节点出站，用 dae 做透明代理，和 sing-box 做透明代理然后用 xray 做出站差不多

43

@ZztGqk 我感觉自己的 dns 分流规则够简单粗暴了：
dns {
upstream {
googledns: 'tcp+udp://8.8.8.8:53'
alidns: 'udp://223.5.5.5:53'
}
routing {
request {
qtype( https) -> reject
qname(geosite:geolocation-cn, geosite:cn) -> alidns
fallback: googledns
}
}
}

44

CDN 分流这个问题大部分人其实不需要，毕竟只需要国内外分流，这类 CDN 是不可能一样的。大众点的分流需求比如 ai ，这种基本都是大厂，也会有自己的 ip 。

45

你说的对，但是他快啊

46

不喜欢 fakeip ，就这 clash 在跑路之前还一度要仅保留 fakeip 模式，甚至宣称要把留下的口子也去掉。

47

fakeip 是最烂的设计，ping 一个域名全是 1ms 内网地址，请求一个域名全是保留 ip ，看到都烦死

48

坚决不用 fakeip

49

fake-ip 原本希望通过加一层，来解决 DNS 污染问题并可以提供更精准的分流能力
但 fake-ip 的实现不够透明，让本层的细节蔓延到了其它层
除非用户非常清楚自己在干什么，否则用 fake-ip 会出现很多莫名其妙的问题

50

需要使用域名分流时使用 fakeip 。因为假 ip 无法通过 ping 测试联通性，造成某些情况排障时的困扰，除了域名分流场景其他没必要用。

51

从不用 fakeip ，mosdns 分流+缓存，速度一样没啥多少，但不会有 fakeip 那种问题

52

不懂，用了三年了没觉得有啥问题啊，如何感知呢🤔

53

@lnbiuc 大佬，你这是 openclash 的配置吗？

54

fakeip 就是一大坨奥利给

55

@frankilla #53 是 mihomo 内核的配置，不清楚 openclash 使用的是不是 mihomo 内核

56

@lnbiuc 是的，openclash 上面写的 powered by mihomo 。
感谢。

57

58

其实 sing-box 主推的不是 FakeIP 模式，而是 RealIP 模式。FakeIP 模式是 clash 主推的。我感觉 sing-box 开启 FakeIP 和 clash 模式是一个很奇怪的用法

59

fakeip 开持久化，至少我用了 3 年还没出过啥问题，除非是 clash 那边的持久化丢了。现在 fakeip 没做好的最大问题是，他没有对域名做 hash 映射到 fakeip 段的固定 ip ，只是简单粗暴的 fifo 。而普通用户又不会开持久化，导致每次重启 service 时丢失映射。

60

我不用 fakeip 一会就全部 1.1.1.1 请求超时，进而阻塞所有 proxy 请求，完全不知道为啥

61

FakeIP 只有 IPV4 ，也是目前它的一打缺陷

62

我的解决方案，使用 nikki-openwrt ，使用 redir-host 模式，自建部署于 docker 的 DNS 服务器，所有国内外 DNS 请求，均使用内网 DNS 服务器。用了几个月，暂时没有发现有什么问题。由于内网 DNS ，一并解决了泄露、污染、还有 DNS 分流等问题。

63

fakeip 只应当对需要代理的域名生效，而不是所有目标，这需要一个正确配置的 dns 。你文章说的问题，sukka 在评论中已经回复你了。真要说 fakeip 的缺陷，我认为是当软件有自己的 dns 逻辑时，例如使用内置的 doh ，而不是系统的 dns 服务器，你无法对其结果进行劫持时，纯 fakeip 的方案就失效了。btw ，fakeip 的 pool 可以用假公网地址，例如（分配给美国国防部的/8 块列表），而不是保留地址，可以避免客户端认为在请求本地网络的问题。

65

@Serino 别断章取义，我后面说了，用其他方式都有缺陷，要么无法应对解析到 cdn 的情况，要么解决不了非 http 的情况,我自己就是做网络协议栈开发的，就不用给我普及这种网络知识了

66

67

@zhoumff sing-box 和 mihomo 全部支持 fakeip v6 了。

68

fakeip 的价值在于流量分流，而不是延迟。比如你可以设置只有代理的网站返回 fake ip ，直连的返回真实 ip ，这样直连的网站就不经过你的代理软件了(前提是代理软件或设备没有接管所有流量)，性能更高；在家庭环境中也可以实现全设备无感翻墙。

69

70

71

@q000q000 #68 除了关闭 Fack IP 以外，有其他解决办法吗？我也被这个坑无语了好长时间。