@cnbatch @RobinHuuu 经过排查，不是 MTU 的问题，但是感谢提供 ping 的思路，通过 ping 发现具体的问题了。

通过 ping ，发现只有 icmp_seq 序号为偶数（ 0 、2 、4……）的 ping 包才能收到响应，而奇数的包都是超时。就去排查 nftables 规则，发现问题所在：

我给指定服务器做转发，是在 nat 的 prerouting 链上判断目标地址为 17 服务器的包打上 meta mark ，然后在 ip rule 里匹配 fwmark lookup 表，default 路由到 Wireguard 的 wg0 出口。

看了下文档，nat 链只在第一个包会命中，后续包就跳过了。因为有 conntrack 跟踪数据包信息，所以 UDP 包也是只在第一个包会命中，后续包不会命中，导致只有第一个握手包发给了 Wireguard ，后续包都从物理网卡直接出去了，导致了 conntrack 同一个内网 IP + 端口对应不同的出口，触发了 conntrack 的 destroy ，所以服务端响应的包就找不到 NAT 回复的目标了。

我自己写的 UDP 测试程序之所以没问题，是因为每次电脑端每次发送都是用的随机 UDP 端口发一个包，conntrack 只跟踪第一个包，所以正常。如果给客户端代码也加上 bind ，使用相同端口来请求，就会发现和 ping 一样的，一次通，一次不通，分别是 conntrack 的 NEW 和 DESTROY 。

解法是在 meta mark set 的同时加上 ct mark set meta mark 给 conntrack 也打上标记，然后加了个 filter prerouting 的 mangle 链，匹配 ct mark 也设置上 meta mark set 就好了。

软件的数字签名，开发者用私钥签名，用户使用公钥验证软件来源且未被篡改。

@lxh1983 #2 我觉得网盘数据本身就得分两类：
一类是大文件影视作品这些，本身需要秒传且没必要加密，且加密耗时长、资源消耗大。
另一类是用户相册备份，包括照片、视频，这一类文件本身就几乎不存在文件去重的，每个手机里的相册都是独一份的，而这一部分才是需要加密存储的。

所以完全可以做到区分存储容量，相册备份和共享存储。通过相册备份的，加密且不可分享，要分享，就解密挪到共享存储里面去，既然都要共享了，也就没有加密的必要了。
当然，也可以进一步，相册共享加密，分享的时候用端到端加密共享密钥，但就不允许回收权限了，

@hiboshi #16 貌似说不太通。目前看到的复现案例，有多个数据一样的，甚至顺序都一样。
如果是国内 ID 和新加坡 ID 冲突，导致新建的国内相册 ID 碰撞到了新加坡相同 ID 的数据。那就解释不通多个人能碰撞到完全相同的相册了，国内新建相册 ID 不至于都重复吧？

WebAssembly 了解一下？可以把各种语言 C/C++, Rust, Go 等编译到浏览器运行。
在浏览器环境下，JS 需要由 HTML 来加载，WebAssembly 需要由 JS 来加载，这都是为了向前兼容。
古旧浏览器不支持 JS 的，在 HTML 里可以打印降级提示，旧浏览器不支持 WebAssembly 的，也可以用 JS 写降级逻辑。

我记得以前玩 dota2 的时候，游戏更新的时候是不会打断正在玩的人的，一局结束之后，需要退游戏更新客户端才能开下一局。
不过也有崩服务器的时候，但貌似大部分情况貌似也不影响进行中的游戏，只是结束的时候加载不出结果。

第 5 条，自建的话，也支持 DNS ECS 的吧？

抱歉抱歉，确实没仔细看假设。
不过，对于 Web 业务，如果服务端被攻破，那么就完全有能力改造用户端的登录页面，直接去除 hash 逻辑，把明文带上来。
当然，这里假设服务端被攻破是指能控制前端代码的服务端被攻破。

HTTPS 下面传明文就足够，其他轮子意义都不大。
在不破坏 HTTPS 的情况下，明文不会有问题。
在 HTTPS 被破坏了，比如中间人，或者 HTTPS 用了过时不安全的算法，那么：
传 HASH：直接截取重放即可。
传带时间戳的 HASH：要求服务端明文存储用户密码。
用加密算法加密：不管对称还是不对称，都需要给客户端下发加密密钥，HTTPS 被破坏的情况下，中间人可以替换下发的密钥，做代理。
客户端预置密钥/公钥：你重新实现了 TLS 。

感觉跟文件系统关系比较大，或者没控制变量，测试的时候有其他较大 IO 进程在跑。
不然光 内核优化啥的，性能不至于差这 3 倍多

我看到的系统，windows 的多，其次就是想 android 了。纯 linux 的几乎没见过

是不是 1.1.1.1 的缓存时间比较长，等了多久了？我记得最多可能要等 72 小时。你域名之前是默认销售页，估计 1.1.1.1 就缓存时间长了？

通用的广告屏蔽应该不好做？简单的想办法把 ADB 或者 ABP 的代码放进去跑一下，带上几个规则，不知道是否可行。
如果加载的是固定的几个页面的话，针对性地拦截一下广告域名的加载应该就行？或者注入脚本针对性地处理一下？

@iminto 有没有可能，第一步用脚本从后往前把代码里的常量全部替换成字面量，比如 __LINE__ 啥的，再格式化？

首先，没有绝对的安全。如果真到了可以到你服务器上进行任意代码执行了，那基本上对你的密码是啥也就没啥兴趣了。都能直接进到你家翻箱倒柜了，也就没有必要知道你家防盗门上的密码了。
安全防护通常是很多层，对密码的保护只是其中一层。
代码是很多人都可以访问到的，比如公司里的程序员，几乎人手一份代码，代码泄漏的风险本身就很高。而密码不放在代码里，那么即便是你泄漏了代码，在不考虑其他漏洞的情况下，生产数据库还是安全的。
当然，即便是保护了密码的安全，生产数据库通常也都是网络隔离不能公网访问的，这是另一道安全防线。但也不能说既然不能公网访问，那就不设置密码了吧？