@az22c 如果这都要考虑，那 A 上应用更可能有漏洞，导致 B 也可以攻击到 A 。
对比一下：

1. C 直接部署笔记服务，https 暴露外网
如果笔记服务有重大漏洞（比如登录界面可以访问到主机文件），会威胁整台机器

2. C 直接部署笔记服务，https 暴露外网，nginx 额外加一层密码
即使有重大漏洞，外界绕不过外层密码也难办（但有些 App 可能会不兼容额外的访问控制）

3. C 使用虚拟化部署笔记服务，https 暴露外网
如果笔记服务被攻破，虚拟环境可访问的信息会沦陷。
宿主的风险取决于虚拟化技术。对于虚拟机，逃逸是价值很高的漏洞，对于民用场景不太会遇到。Docker 可能需要加固。

4. C 直接部署远程桌面访问仅限本机的笔记服务，远程桌面暴露外网
如果远程桌面有重大漏洞，那会威胁整台机器。如果套一层隧道，那进一步取决于隧道协议和虚拟局域网的安全性。

5. B 部署远程桌面访问 C 仅限局域网的笔记服务，远程桌面暴露外网
首先取决于远程桌面的安全性。如果被攻陷，且局域网内有不设防 /高危漏洞的服务，可能会让运行该服务的机器进一步沦陷（除非额外限制）。B 本身的使用痕迹也可能成为跳板（比如保存了密码）。另外，局域网内其它设备也可能威胁笔记服务（除非额外限制）。

6. C 部署虚拟机运行远程桌面通过共享访问笔记，远程桌面暴露外网
如果远程桌面被攻破，虚拟环境可访问的信息会沦陷。是否能访问局域网其他设备取决于虚拟机网络的配置。
如果虚拟机存在逃逸等漏洞，会威胁到宿主机。

综合看下来，其实就是估计笔记服务出漏洞、远程桌面被攻破、虚拟机发生逃逸、隧道被攻破的可能性（同时考虑 ABC 自身以及虚拟局域网中其他设备等风险），组合出安全系数满足需求、同时不至于太麻烦的方案。个人认为民用场景下，虚拟机的隔离已经够安全了，实在不行加一层密码 /隧道。过于复杂的方案比较难以坚持，而且可能会增加新的风险点。

@wy315700 准确地说是健康度指标掉得快，更容易超出保修限制。但看到几个实测，用到损坏寿命的写入量相比别家并没有更少。

远程桌面的话虚拟机就行了吧，独立物理机的必要性没那么明显。虚拟机可以通过虚拟化软件的共享文件夹功能访问特定宿主机文件。

非远程桌面方案，部署网页服务的笔记放在虚拟化环境，然后 https 向外网公开不就行了。不放心的话在 nginx 反代再加一层密码验证。

如果丢了有所谓，那还是要填真实的

@liveoppo 条款上都要求提供真实信息。一个是事前监管，如果不实名验证，用都不让用。一个是事后监管，不真实一般没事，出了问题就麻烦了。

> 最坏的情况下，国内的注册商我们至少还能找到人，至少还能打官司
这可不是最坏的情况

在合规的前提下同时备好境内外的域名倒是有益的

SSD 体积小、读取基本没有噪音，随着单价下降，家用肯定会逐渐多起来
至于担心数据恢复的，好奇氦气盘坏了有多少人会去恢复？
当然，关键数据不管啥盘都得要 3-2-1 备份

合并这个特性微软很多年前就想推了，但对于桌面端用户一直是徒增麻烦。没解决问题就强推就成了迷惑行为。

路由器相比内网主机更容易被外网发现。但总体上没有太大区别。

官方 tg 频道 NAStool Wiki 有相关教程

如果已经放通了光猫和路由防火墙，那不应该出现服务器可以但手机不行
可以看看路由追踪断在哪里。
另外会不会是手机的防火墙会阻断公网的 ICMPv6 ，换成 TCP 试试？

想稳定的话还是推荐自建

抽几个 Copilot X ？

个人认为适合这种超冷备的场景：原始存储大概率不会坏，就算坏大概率也只影响个别文件，加个备份满足 3-2-1 法则。

不收流量费的几家对象存储试过了么？

@fengyaochen 如果申过单域名 SSL 证书就很容易发现

gpt-3.5-turbo-0301 的最大 token 数是 4096