我认为 #2 正确。

@neteroster #28
参考 https://docs.cfw.lbyczf.com/contents/tun.html#windows

使用 Tun 可以接管所有系统流量，无需配置每个组件的代理设置。

只需使用 Clash for Windows (Win/Mac 都有) 的 Tun 模式。

@beijiaooff 很显然他是在服务端测的。请注意测速方式：CLI 。

@stanchn 你要测的是本地到机场的链路，测服务器有啥用...... 随便弄个 Vultr 都能跑出 1Gbps 来。

> -b, --bandwidth n[KM]
> Set target bandwidth to n bits/sec (default 1 Mbit/sec for UDP, unlimited for TCP). If there are multiple streams (-P flag), the bandwidth limit is applied separately to each stream. You can also add a ’/’ and a number to the bandwidth specifier. This is called "burst mode". It will send the given number of packets without pausing, even if that temporarily exceeds the specified bandwidth limit.

来自 https://iperf.fr/iperf-doc.php

个人也算 B 站忠实用户了，用了这么久，总体还是令我满意的：没广告、用户原创内容丰富、互动感不错。弹幕文化算是仁者见仁智者见智吧，我自己基本不发，但是看看其他人发的弹幕还有点意思。
当然也有许多缺点：CDN 差劲，高清视频容易卡，真的非常烦人；部分番剧删减内容（这是我不能忍受的，但是也不能全怪 B 站），以及很多番的翻译质量欠佳，所以现在还是选择本地片源（自己找字幕组的资源）。
推荐这方面，感觉 B 站明显不如 YouTube，感觉算法完全是靠热度推的，难以发现真正优秀的 UP 。
另外也听说 B 站原创视频收益相比 YouTube 差很多，但是没具体了解过。

8k60p 绝对不会大于 100Mbps，建议先看看丢帧看是不是硬件问题。另外，测速很快不代表到 YouTuBe 也有那么快。

@Keyes 请问是丢失部分数据还是整个文件系统都炸了？

@delpo 两边都是 Windows 的话，用 robocopy （是一个 Windows 内置的命令行工具，类似 rsync，专注于稳定的文件复制），有断点续传选项（/Z ）。

#17 说的方案也很有意思。其实都是利用强大的「第三方」做一种「保证」。对于我的例子，利用的是计算的复杂性，对于 #17，则是光速这个物理边界。

随便想的：可以考虑一种基于算力的密码。将文件数据以一种指定的复杂度进行「加密」（当然这里不是指传统意义的加密），目前人类的算力不足以解密文件，但是随着单位价格算力的增大，可以完成「在未来解开」的功能，不过具体时间难以把握。

FFmpeg

备份方案有很多，楼上也基本都提了，可以总结一下：
1. 多份，多介质，多地点存放重要数据。本地数据做好冗余（ RAID / Mirror ），远端数据定期更新 / 检查。
2. 对于在互联网上保存的数据，做好加密工作。
3. 保证数据完整性。（本地可以使用 ZFS 或者 SnapRaid，对于互联网存的数据每份备份最好记录对应的 SHA256 校验和。）

KDE Plasma

两端公网就好了，直接 WireGuard + SMB，安全 + 简单。

t/741275

Chrome 控制台看一下请求了哪些域名，加到 Clash 规则里。

@dingdangnao #39 简洁而稳定，好用。