所以，想象一下 Apple Developer 一年只要 688 ，就附送在 Apple 全平台被信任的代码签名证书，是不是很划算 😁

现在 flex grid 感觉已经很简单了
要想当年要兼容 IE6 的时代，用 flex 都要畏畏缩缩的

主动社交。因为工作原因本来圈子就小，一定要把仅存的朋友关系主动维护起来。

homepod 连接 apple tv 并作为默认音响时，apple tv 变成了交换机，homepod 会直连 apple tv ，由 apple tv 转发上网。此时 homepod 会用新的 MAC 地址，所以你的 unifi 控制台提示有新设备接入。

键鼠体验、快捷键、屏幕分辨率等会遇到各种各样兼容性问题，体验很差。

我有明基一代和米家一代屏幕挂灯。放在一起对比还是能看出差别来，明基的灯光明显更加舒适，高显色和全光谱会让光线下的东西看起来更漂亮。
不放在一起对比，很难感受到差别。

自建 recursive ，对于没有缓存的域名那岂不是慢上天了？

@emma3 自建 DNS 一样要解决分流问题，要不然怎么应对 DNS 污染。有分流就有可能产生泄漏。

@szjiehua07 同时拥有 apple tv + homepod 时，如果 homekit 家庭中枢从 apple tv 切走了，会导致 apple tv 失去 ip 转发能力，软路由失效。
这是目前 apple tv 做软路由最大的问题，对于一部分人是完全不可用的。

我很喜欢 Surge ，Surge 是目前所有代理工具里网络栈、规则引擎做的最好的。如果不是这个问题，我也会选择 Apple TV 做软路由。

我和楼主方案差不多。同样是我折腾软路由十年时间下来，选择的最优解。

但还有几个小问题：

1. mosdns 对未知域名，会有 dns leak 。因为我曾经被请过喝茶，对这方面我有些在意。

2. 目前的 proxy tool 比如 clash ，对 NAT type 会有影响（即便是 direct 规则）。所以我把 STUN 相关端口直接在 nftables bypass 了。clash meta 的 endpoint-independent-nat 也许可以解决，但是实测产生了一些其他问题。

这样会使基于 STUN 或类似 p2p 协议的应用走直连，比如 Google Meet / Teams / FaceTime / 各种游戏。不过问题不大，对于游戏可以另外用加速器。对于视频会议应用，一般他们都有针对中国的优化（已知 Teams / Zooms / FaceTime 都有），直连体验也还行。

3. 有些域名做了分区解析，比如 bing.com 在国内解析到北京，会跳转 cn.bing.com 。并且 bing.com 不在 gfwlist 。这时候想要访问全球 bing ，只能手动把它加入到 mosdns 灰名单。

还好这类域名非常少，需要手动维护的规则很少。

4. 针对一些会探测用户 IP 的特定应用要专门处理。

比如 Steam ，只有当检测到用户是中国 IP 时，才会提供国内 CDN 作为下载服务器。所以需要把 api.steampowered.com 放入 direct 名单。

还有 plex 的外网访问服务，需要把 v4.plex.tv 放入 direct ，这样 plex 才能正确地把国内 IP 作为公网直连 IP 。

--

楼上有人说 "Redirect 和 Tproxy 应该是二选一的关系"，我表示支持。在能用 tproxy 时应该都用 tproxy ，这样是最简单的，特别是考虑到 ipv6 （ redirect 不支持 ipv6 ）。

后遗症 咳嗽

遇见这样的同事和项目想必已经是屎上雕花。谁写谁背锅，身为外人当作看不见就对了。

讨厌 .NET 那一坨 runtime ，我选择 shawl
https://github.com/mtkennerly/shawl

只要涉及跨境回源，用户体验都会比较差。比如数据在国内 OSS ，海外用 CF 回源国内；或是数据在海外，国内用阿里云 CDN 回源海外。因为通常 CDN 厂商回源并没有跨境优化，就和咱们普通上网一样，跨境速度和稳定性稀烂。
你可能会说回源只有少数几次，后续都能在边缘缓存。但各个边缘节点都有自己的缓存，但如果你的访问量不大并且地域稀疏，那可能用户很难命中缓存。

最稳定的方式是自己解决跨境这小段的链路。
例如，数据在境内，在 HK 搭建一个 reverse proxy 。分区解析，境内用阿里云 CDN ，海外用 CF ，CF 回源指向 HK 。境内到 HK 这一段，自己通过各种隧道技术来加速（类似平时上网翻墙一样）。