对了，在补充一点。请不要眼红大容量，用过各种云就知道，存储空间和带宽都非常昂贵，天下没有免费的午餐。首先国内这些网盘在信守承诺方面都没什么说服力，容量说变就变，产品说没就没。此外这么大的容量，这么低的价格必然是超卖。超卖没什么，大家都超卖，但得适可而止，而且技术上也要有这精钢钻不是？否则大规模超卖本身就是对数据的一种威胁。

存储重要资料的话，微云百度云还是不要了吧。个人认为这些云是面向娱乐而不是面向生产的，也不知道他们内部怎么定位自己的产品。主要还是有这些问题：

1. 账号安全。无论 QQ 号，微信号还是百度账号，其安全设计我一直都摸不透，什么密码，安全问题，安全助手，手机号，身份证号，安全邮箱，账号申诉相互嵌套。说到底是手机号为主？但是账号申诉又算怎么回事？对个人而言，反而是只用账号密码更可控。

2. 传输安全。比如微云网页端支持 https，但不强制。所以客户端呢？

3. 数据安全。据网友反应，微云有文件传上去下不来的情况，百度云就不提了。实际上，比如坚果云，除了时间积累的口碑外，在他的主页上还可以看到很多使用他产品的企业，国外知名的网盘也可以看到很多商业实体使用他们的服务。我认为这也是面向生产的一种表现。总不能说你的网盘很好，内部也很重视这个产品，结果没有一个严肃的客户？

4. 重要数据安全功能的缺失，比如说版本控制。营销味道太重，比如微云的保险箱，算什么呢？也不是端对端加密，感觉强行新功能。对待会员和非会员，除了空间比较明确，其他方面的限制都很模糊，比如带宽，非会员可以慢，但到底是多少总该有个数吧？不然怎么拿来用？到时候我要同步工作文件你就给我 5k/s ？

5. 隐私条款，服务条款不被强调。对待用户数据界限暧昧，动手删用户网盘里的文件？！

所以如果以年为单位保存重要数据，并且对隐私还有要求，我觉得使用一款行业认可的商用网盘才行。Onedrive 个人版可以，商用版更好，国内也没被 q。如果有条件稳定出 q，我推荐 Dropbox，用下来还是这款最可靠。

可是我的 S8 港版系统支付宝可以用指纹啊。

另外，googleapis.cn 和 googleapis.com 服务器不一样。美国那边解析出来的 googleapis.cn 可以用，你可以试一下 hosts 解析到美国那边的服务器。

ping 一下 baidu qq 之类的看下丢包和延时的稳定性。你这种情况我怀疑可能是 DNS 不行，换个 DNS 试试。

我个人的看法是，除非清楚自己在做什么，否则自己搭建的这种系统，其安全性远不如商用网盘。首先，可用性和容灾就没法比，这两点是最基本要保证的。其次，就保密来讲，商用系统的管理怕不是甩了个人和小团体 n 条街。而且，自己搭建系统，除非硬件在自己手上，而且数据传输到设备中间不经过任何解密，否则还是要信任第三方，而个人对第三方的控制能力和大公司也没得比。

所以我个人的建议是，选择信誉好的商用网盘。如果保密性要求高，应该选择支持端对端加密的网盘，或者通过第三方软件实现端对端加密。保存好一个强密码，比管理好一整套网盘系统简单多了不是？

我个人的经验是 Current Branch for Business + 功能更新延迟半年以上 + 质量更新尽快安装 就挺稳定的。容易出问题的一般是功能更新，质量更新对于安全至关重要（ >> 杀毒软件），仅供参考。

@acess 对了，WAN 口上默认是有 MASQUERADE 的吧？这可能是 WAN 口成功的原因。

@acess 不行的话，你先尝试一下把其他自己添加的规则删掉，在一个干净的表上单独尝试这个规则，排除干扰的可能。此外你要不试一下把 ! -o lo 删掉？我还是没明白这个规则怎么改的出 Localhost

@acess 还有我没看懂，按说 REDIRECT 应该重定向到 incoming interface，你的第一行命令里已经 ! -o lo，为什么请求包会被定向到 127.0.0.1:5301?

@acess 抱歉没审清楚题目，那么下面这个能工作么？

iptables -t nat -A OUTPUT \! -o lo -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:5301

需要 tproxy 模块

hsts preload 可以在一定程度上缓解这个问题。

我最不能理解的是关了 UAC 然后装杀毒软件，这是假装自己重视安全？

没有允许 related,established 链接吧，重启不行的话，只能控制台了，再没有就重装吧。

使用 U 盾作为认证工具，基本可以消除用户方面凭证管理所引起的安全问题，一般可以认为用户签名必然源于用户对应的 U 盾，所以 U 盾签名是非常权威的，主要也是方便了用户。但这只是安全管理中的一环，验证逻辑、数据保护和设施安全还有很多其他与之独立的问题。

ZFC 公理下，并不存在此种集合构造。而 class 没有“包含于”这一符号。

我建议，推迟功能更新，及时安装安全更新。以及根本的办法：备份备份备份！！！

我觉得这个事情还是要根据场景吧。比如说手机被偷了，这种情况下我认为解锁和 root 对于数据安全没有影响。如果没有全盘加密，那么无论 root 与否原则上都能直接读取数据。如果全盘加密，那么关机或重启就再也没有机会获得数据，唯一可能是到手后手机是开机的，这时候 /data 已经解密挂载，只需要保持开机状态绕过锁屏，但 root 或解锁没道理会让绕过锁屏变得更容易吧。

但如果针对的是恶意应用，那么 root 肯定会为攻击者获得密钥大开方便之门。