观察过 facetime 并不会利用 upnp
有 ipv6 即使开着防火墙，也能大大提升 facetime 打洞成功率

@jacksonj297 我是美区 id ，上面说的几十 KB/s 就是在开代理的情况下。有理由相信是 apple 自己的服务器出了问题，也许挤爆了

从 icloud 备份恢复，我也一样卡在最开始位置。路由器上看到在从 gateway.icloud.com 龟速拉取数据，几十 KB/s 的速度

@laydown 请重新阅读这个帖子的标题

我升级 ios17 后，iCloud 联系人无法同步了，为此我重置了系统，依然无法同步
然后我 safari 的 tab group favorites 也全部被同步丢了，iCloud 数据恢复也找不回来了

手机、微单、运动相机各自有不一样的创作思路，不能相互替代

虽然很反直觉，只支持 USB2.0 却能传输 Gbps 级的 DP 信号
但是仔细一想，只要双方协商完走 USBC DP Alt Mode ，后续传输 DP 信号确实不关 USB Controller 什么事

虽然这两个机型对比很不科学，但是结论是合理的，实现同样功能的 app ，ios 需要的内存会比 android 小。

原因除了楼上提到的内存压缩，还有语言层面，ios 的 swift/oc 天生比 android 的 java 更容易写出内存占用低的代码

“难道在 dnsAdds 的 ListenerHandler 处理的吗？如果是一个普通的监听服务器，如果 198.18.0.2 没有对应的网口则监听失败，和我 append 中的情况一样”

注意这里不是监听，不是 socket/bind 。而是虚拟网卡，流经网卡的所有 packet 都会由程序捕捉到，无论 src/dst ip/port 是什么。
哪些 packet 会经过虚拟网卡，则是由系统路由表决定的

netstat -rna 你会发现还有很多其他动态生成的路由，不仅局限于 198.18 段

“198.18.0.2 的 flag 其中有 H, 说明是个 HOST 点对点的地址，不需要经过路由”
这个说法不完全对。所有 /32 路由都会被标记为 H 。他们还是会经过路由，需要查路由表确定发送到哪个 gateway

“198.18.0.2 在哪里被添加成 HOST 的”
正如我之前解释，198.18.0.2/32 这是一条由系统动态生成的 route ，用于缓存加速（匹配一条 /32 比匹配 128.0/1 效率更高，所以系统首次匹配完后，会生成一条 /32 路由缓存）。因为它是一条 /32 路由，所以标上了 H flag

@yov123456 正解，198.18.0.2 和 dns-hijack 走的都是同一套逻辑

"检查到 dst ip 是 198.18.0.2 之后，认为这是一个 dns 请求"
在 clash meta 的实现：
https://github.com/MetaCubeX/Clash.Meta/blob/53f9e1ee7104473da2b4ff5da29965563084482d/listener/sing_tun/dns.go#L38
并且这里只检查 dst ip ，不检查 port 。因此 dig @198.18.0.2 baidu.com -p 12345 这样使用任意 port 都可以得到 DNS 响应。

@FaiChou
clash-meta 相关代码在这里：
https://github.com/MetaCubeX/Clash.Meta/blob/53f9e1ee7104473da2b4ff5da29965563084482d/listener/sing_tun/server.go#L145
取了 options.Inet4Address 的下一位地址作为 DNS 地址。
options.Inet4Address 来源在这里：
https://github.com/MetaCubeX/Clash.Meta/blob/Alpha/config/config.go#L1343
是从 fake-ip-range 配置项取出来的第一个地址。


route -n get 198.18.0.2 结果可以看到有个 flag `WASCLONED`，简而言之这是 macOS 动态生成的一条路由，缓存用途
https://etutorials.org/Networking/Integrated+cisco+and+unix+network+architectures/Chapter+8.+Static+Routing+Concepts/Route+Cloning/

收回我上一条评论。查了下，回收铝材对比全新生产，确确实实能大量减少碳排放。

苹果是只字不提回收材料过程的碳消耗🫣

东亚区网间结算费用普遍偏贵，不只是国内。

surge/clash 没有选择直接 bind 198.18.0.1:53 ，应当是出于兼容性考虑，如果本机有其他程序 bind 0.0.0.0:53 ，会导致一方失败。

dns server 没有 listen on 198.18.0.2
198.18.0.2 走的也是 128.0/1 这条路由，被当成普通流量送往了 utun10
utun10 是虚拟网关，它检查到 dst ip 是 198.18.0.2 之后，认为这是一个 dns 请求，给与 fake ip dns 响应