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