自建 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 ）。

后遗症 咳嗽

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

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

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

这就是 nextjs 广受诟病的地方：强推 SSR / RSC ，为了卖自家 Vercel 的商业服务。
对于很多类型的项目，比如你提到的工具类网站，以及后台管理系统，SSR/RSC 属于最不重要的优化，但会因此让开发和部署变复杂很多（如果不使用 Vercel 的话）。

Nextjs 爆火也就是最近一两年的事情
抛开功能原因，我觉得能火的关键要素是，Vercel 摘了 Meta 的桃子。
这几年正值 Meta 降本增效，react team 在 Meta 内越来越边缘化。Vercel 趁机挖了很多 react team 的人，废了 create-react-app ，重构了 react 官网并借此把 Nextjs 放在头号位置（导致现在新人入门 React 几乎必须从 Nextjs 开始），并几乎控制了 react 未来方向。
React 18 稳定版停更一年多，而 React 19 新功能明眼人都看出来是给 Nextjs 量身定做的。就像楼主说的，“倒也没感觉没有 SSR 就罪恶到要枪毙”，React 痛点那么多，react team 偏偏把主要精力放在了 SSR 。
到头来 React 19 真正的亮点 - React Compiler ，还得是出自 Meta 团队。

目前公司用 grpc + thrift ，甩开了 protobuf 的负担，感觉体验良好。

有 schema 对项目长期维护很重要。
跨语言也很重要。因为保不准团队里就有人想用其他语言来写一部分服务。
我公司内主要是 go ，后来陆续引入了 java/python/nodejs ，大家都在 grpc+thrift 下工作良好。thrift 的代码生成效果也不错。
不过缺点是 thrift 生态还是比 protobuf 差了一些。

玩一玩氪金网游，包治电子 ED

不知道国内安卓推送现在体验如何了，特别是 gmail / slack / teams 这些没有落地中国的 app 。

我是更新狂魔，每周更。okpg update && opkg list-upgradable | awk '{print $1}' | xargs opkg upgrade 一条龙
遇到大版本我是手动更新：手动替换 kernel ，手动 diff rootfs ，把新的东西拷贝过来，旧的 kmod 删掉，手动同步 opkg 状态文件。

我远程的第一第二年很喜欢到处跑。后来时间长了新鲜感褪去，真正能长期舒适办公的地方还是只有家里书房。

有进体制内的想法的话必读

不进体制的话，就观察身边统计而言，硕士学历意义不大，即使是 985 硕

续航下降，不能像过去一样长时间集中精神