 |
1
win8en 8 天前
同意你的看法，我也是不喜欢 fakeIP
|
 |
2
lnbiuc 8 天前  1
|
 |
3
heiher 8 天前
FakeIP 被应用超期缓存，应用没有严格尊重 TTL 是原因。DDNS 与 FakeIP 同理。那么到底是 DDNS 和 FakeIP 设计的错，还是应用的错呢
|
|
4
heiher 8 天前
> 最后我想说，实际上由于 DNS 缓存没有 FakeIP 体验并不差，大多数 CDN 分发的静态资源域名 TTL 都在数分钟甚至数小时...，实际查询一次后面都是 0 延迟，完全没必要为了 FakeIP 那一丁点收益引入各种复杂性。Real-IP 模式配合现代的分流策略（国内直连 DNS + 国外远端 DNS ），在绝大多数网络环境下已经足够快且极其稳定。
最后这个结论怎么把 FakeIP 归类为解决延迟问题了，应该是 在不知道代理服务器端真实 DNS 服务器地址的情况下实现在代理服务器端进行域名解析。 |
 |
5
yinmin 8 天前 via iPhone
cdn 会导致很多域名共用 ip 地址，fakeip 是解决 realip 无法根据域名分流的问题。
|
 |
6
SenLief 8 天前
fakeip 只适合于不关代理的情况的
|
|
7
SenLief 8 天前
@yinmin 对的，fakeip 当时的出现我记得就是为了解决 redir-host 的 dns 解析问题的，延迟不是主要需要。dns 延迟需求其实很小的，大多数人日常访问的网站都很难遇到延迟的情况。
|
 |
8
choury 8 天前 via Android
不用 fakeip 就没法跟据域名分流,不管是嗅探还是 mitm 都不靠谱，但是我的实现方式是，对能直连的域名返回真实 ip ，对要处理的才返回 fakeip
|
|
10
lnbiuc 8 天前
@yinmin 不用 fakeip ，也不用 redir-host ，mihomo 还支持 normal 模式，取消 IP 和域名映射，之后通过 sniffer 获取域名进行路由但是不覆写，直接先代理服务器发送 IP 进行连接，不存在你说的问题。
但是需要在客户端处理好 DNS 分流 |
 |
11
hronro 8 天前 via iPhone
Service Worker 对资源的缓存，怎么成了和 IP 耦合而不是和域名耦合的了，感觉像是 Chrome 的 BUG 。
|
 |
14
small5 8 天前 1
非 http/sni 的流量使用 fakeip 可能會出現問題，例如玩遊戲時有可能會出現無法連線伺服器的情況。因為 fakeip 某種意義上也相當於一次 nat 了。
|
|
15
small5 8 天前
修正，是 http/tls 流量
|
|
16
small5 8 天前
非 http/tls 的流量使用 fakeip 可能會出現問題，例如玩遊戲時有可能會出現無法連線伺服器的情況。
此外 fakeip 某種意義上也相當於一次 nat 了。 |
 |
17
busier 8 天前 via iPhone
专机专用 从来不考虑分流 不用 fakeip
|
|
18
lnbiuc 8 天前 1
@heiher #12 不需要啊，DNS 设置为 1.1.1.1 ，然后对 1.1.1.1 进行代理就行了。
至于你说的公共 DNS 不如 ISP ，做好 DNS 分流就行了，可以看下我对 DNS 分流的处理 https://vio.moe/posts/wo-de-dns-pei-zhi-ji-qiao |
|
19
heiher 8 天前
@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 解析的特征进行代理识别
|
 |
22
fish3125 8 天前
除了更快，还有一种情况，本地代理 tproxy 非常好用，只要 nft 一个网段。
可以使用 CGNAT) 保留地址段 100.66.0.0/16 ，不要和当前运营商的冲突。 |
 |
24
m1nm13 8 天前
fakeip 最大的问题在于， 很多时候第一次访问某个域名会失败， 如果用的软件内部没有重试机制，那就会直接失败
|
 |
25
someonesnone 8 天前 via Android
常用网站国内网站禁用 fakeip 其余的一概走 tun
|
 |
26
yuezk 8 天前
我理解如果使用 sing-box 的 DNS rule ，可以使用代理服务器来解析域名，是比较稳妥的办法。可以解决 DNS 污染问题，也不会有 DNS 缓存的问题。不好的一点是解析速度上可能会有一些延迟。
|
 |
27
darrh00 8 天前
我同事在公司折腾所谓的旁路由+clash ，因为公司有 ipv6 ，结果这主机把自己声明为路由，同时又开了 fakeip ，导致公司内机器 dns 被污染，间歇性不能上网，全公司折腾一上午。
|
 |
28
povsister 8 天前
日经问题了。我的看法是，当你认识到它不好的时候就可以自己动手写一个了
|
 |
29
Mar5 8 天前
sing-box 已经弃用 fakeip ，已被迫使用 dns 分流，不过就我个人而言用起来也没多大差别。
|
 |
31
ZztGqk 8 天前 via iPhone
你这个访问 local 的原因是因为 host 域名解析与部分请求域名不一致吧，是不是做了 dns 分流或者什么别的配置导致的，因为只要 host 是 private 就不会有这种问题才对
|
 |
32
mangmaimu 7 天前 via iPhone
然而事实上商业代理软件都是用的 fakeip
|
 |
33
Greatshu 7 天前 1
不要折腾 DNS ，省不下多少时间，反而一旦出问题会花几倍乃至几十倍时间排查
|
 |
34
Mantext1989 7 天前 via iPhone
不是很了解计算机网络，看完后有点疑惑，如果解析到的 IP 地址是被 Service Worker 持久化了的话，那么是不是意味着任何曾经访问过的域名更换 IP 地址后都会产生这个无法访问到的问题呢？
|
 |
35
Lightbright 7 天前
我之前就说过了，这玩意引入的问题比解决的问题多
|
 |
36
iwfd965 7 天前
单纯用 sing-box 的 Tun+FakeIP 日常使用基本没遇到过问题，没有特别的需求，用 sing-box+dae 不是徒增烦恼吗😂
|
 |
37
SingeeKing PRO 这个看上去是因为 Chrome 缓存「是否本地」这件事情没有遵从 DNS TTL 的（正常 fake ip 都会把 TTL 设置成一个极短值）
另外，绝大多数软件系统级 HTTP 代理和 TUN 代理都是同时开的，因此也不会出现访问网站时每一个都提示是内网的情况 |
 |
38
yuki6761 7 天前
主路由是 routeros ，做透明代理只能使用 fakeip 分流
|
 |
39
FringJX 7 天前
我家里有个 24 小时运行的 macmini 运行 Surge ，接管家里的网络请求。作为旁路网关，需要用的 surge 服务的设备手动设置网关指向 surge 虚拟网关 ip ，Surge 用的应该也是 FakeIP 。
到极少出问题，就是 macmini 升级时网关不可用，需要设备在手动改为 DHCP 自动，临时用家里路由器作为网关。 |
 |
40
miyuki 7 天前 1
玩游戏只能说是灾难
|
 |
41
Elietio 7 天前
软路由跑 openclash ，开 fakeip 后，ps5 联网经常出一些莫名奇妙的问题，后来就放弃了
|
 |
43
Chairs0 OP @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
crysislinux 7 天前 via Android
CDN 分流这个问题大部分人其实不需要，毕竟只需要国内外分流，这类 CDN 是不可能一样的。大众点的分流需求比如 ai ，这种基本都是大厂，也会有自己的 ip 。
|
 |
45
y1y1 7 天前
你说的对，但是他快啊
|
 |
46
PrinceofInj 7 天前
不喜欢 fakeip ，就这 clash 在跑路之前还一度要仅保留 fakeip 模式，甚至宣称要把留下的口子也去掉。
|
 |
47
Domado 7 天前
fakeip 是最烂的设计，ping 一个域名全是 1ms 内网地址，请求一个域名全是保留 ip ，看到都烦死
|
 |
48
itechify PRO 坚决不用 fakeip
|
 |
49
fkdtz 7 天前
fake-ip 原本希望通过加一层，来解决 DNS 污染问题并可以提供更精准的分流能力
但 fake-ip 的实现不够透明，让本层的细节蔓延到了其它层 除非用户非常清楚自己在干什么，否则用 fake-ip 会出现很多莫名其妙的问题 |
 |
50
ricardo 7 天前 via Android
需要使用域名分流时使用 fakeip 。因为假 ip 无法通过 ping 测试联通性，造成某些情况排障时的困扰，除了域名分流场景其他没必要用。
|
 |
51
Jacksu 7 天前
从不用 fakeip ，mosdns 分流+缓存，速度一样没啥多少，但不会有 fakeip 那种问题
|
 |
52
frankilla 7 天前 via iPhone
不懂，用了三年了没觉得有啥问题啊，如何感知呢🤔
|
 |
54
momooc 7 天前
fakeip 就是一大坨奥利给
|
 |
57
wenerme 7 天前
有时候真的是没有别的选择。
macos ，通过修改 dns 就能全局正常工作。 有一个办法是允许 FakeIP 返回一个固定的正常外部 IP 然后拦截，然后通过 SNI 方式检测域名。 但是 mihomo 不支持返回固定 IP ，之前有用过 dnsmasq 来做这样的事情，这样的 SNI 方式不支持 mysql 这种非 http 请求。 如果能接受这种返回固定 IP ，那直接本地创建一个 interface 给 IP ，然后 gost 启动一个 sni 代理，就能随便处理了，但是这种情况支持的端口有限。 |
 |
58
yolee599 7 天前 via Android
其实 sing-box 主推的不是 FakeIP 模式，而是 RealIP 模式。FakeIP 模式是 clash 主推的。我感觉 sing-box 开启 FakeIP 和 clash 模式是一个很奇怪的用法
|
 |
59
Ipsum 7 天前
fakeip 开持久化，至少我用了 3 年还没出过啥问题，除非是 clash 那边的持久化丢了。现在 fakeip 没做好的最大问题是，他没有对域名做 hash 映射到 fakeip 段的固定 ip ，只是简单粗暴的 fifo 。而普通用户又不会开持久化，导致每次重启 service 时丢失映射。
|
 |
60
ThisDay 7 天前 via Android
我不用 fakeip 一会就全部 1.1.1.1 请求超时，进而阻塞所有 proxy 请求，完全不知道为啥
|
 |
61
zhoumff 7 天前
FakeIP 只有 IPV4 ，也是目前它的一打缺陷
|
 |
62
emma3 6 天前
我的解决方案，使用 nikki-openwrt ，使用 redir-host 模式，自建部署于 docker 的 DNS 服务器，所有国内外 DNS 请求，均使用内网 DNS 服务器。用了几个月，暂时没有发现有什么问题。由于内网 DNS ，一并解决了泄露、污染、还有 DNS 分流等问题。
|
 |
63
zwlinc 6 天前
fakeip 只应当对需要代理的域名生效，而不是所有目标，这需要一个正确配置的 dns 。你文章说的问题，sukka 在评论中已经回复你了。真要说 fakeip 的缺陷，我认为是当软件有自己的 dns 逻辑时，例如使用内置的 doh ，而不是系统的 dns 服务器，你无法对其结果进行劫持时，纯 fakeip 的方案就失效了。btw ，fakeip 的 pool 可以用假公网地址，例如（分配给美国国防部的/8 块列表），而不是保留地址，可以避免客户端认为在请求本地网络的问题。
|
 |
64
Serino 6 天前
|
|
65
choury 6 天前 via Android
@Serino 别断章取义，我后面说了，用其他方式都有缺陷，要么无法应对解析到 cdn 的情况，要么解决不了非 http 的情况,我自己就是做网络协议栈开发的，就不用给我普及这种网络知识了
|
 |
66
ygvj 6 天前
看大家都不喜欢 fakeip ， 我也不喜欢，奈何国情环境就这样， 折腾了好几天代理的事情，最终我依然使用 fakeip ，猜测当初设计 fakeip 是为了无需国外 dns ，不受国内 dns 干扰，实现了：
DNS 是问路的，不是决策的。 它不决定走代理还是直连。 规则才是决策者。 它决定某个域名属于国内还是国外。 代理节点才是真正解析国外域名的人。 它保证访问 Google 、OpenAI 、Shopify 不被污染且高速。 本地 DNS 只需要做到：不超时、不乱跑、不出错。 所以全部用国内 DNS 是最优方案。 |
 |
68
zbatman 5 天前
fakeip 的价值在于流量分流，而不是延迟。比如你可以设置只有代理的网站返回 fake ip ，直连的返回真实 ip ，这样直连的网站就不经过你的代理软件了(前提是代理软件或设备没有接管所有流量)，性能更高；在家庭环境中也可以实现全设备无感翻墙。
|
Select Language