强迫自己看完一部旧的再下一部新的

@admin13579 这条严格来说其实也有问题，因为查阅缺乏上位法律的支撑

@uzbox 从前几年浙江的公示来看，实践中只是查看推特油管、哪怕是追星，也足以构成处罚原因。虽然这在理论上其实有问题。

资源收费合理，但作为非固定 IP 卖这么贵不合理 （参考云服务商的价格）

没有用过，只是觉得机器保养、磁带保护、读写延迟、学习试错的成本无法忽略

可能日本对外商投资监管更严

SSH 可以看成是可以走各种信息的隧道，很早就有被阻断的报告了

虽然只是暂时，但有人记录总结规律还是挺好的。

@AlphaTauriHonda 我说的就是针对 Cloudflare IP 的干扰，貌似在 AWS Cloudfront 也出现了。相关规律楼主之前也有研究过。

@XIU2 Github 难以替代，不是因为国内造不出托管平台，而是因为 Github 汇聚了全球大多数的开源代码。现行政策下国内又不太可能出现全球性的社区。（且中国以外手机注册也越来越难）

顺便提供一个线索，大约从 2 月 10 日开始，Cloudfront 的 IPv4 地址也有间歇性阻断的迹象。

按非官方的方式使用本来也不能指望有多靠谱

应该没有，比较接近的是 Port Control Protocol

毕竟 IPv6 已经不再需要网关转发来克服 NAT 了

这是 RFC7217 定义的安全机制 stable privacy addresses 。如果是本来就暴露的纯服务端，SLAAC 的随机性没啥意义，那设成固定就好。

对于 SLAAC 有意义的一般设备，个人还是推荐把防火墙的重点转移到终端而非网关。

@smallparking 用 macvlan 恐怕防火墙更挡不住了。不过也好奇，威联通是怎么挡住的，底层设计是什么。
顺便也想提议，社区应该规定必须标注 AI 回答。

楼主可以先分析一下自己的安全性有多重要，再考虑值得花多少成本、牺牲多少便利性来保护。

有的 App 国外手机号都没法注册，上架的意义也不大了

参见 https://github.com/awesome-selfhosted/awesome-selfhosted

参见 /t/887939

CNAME 式接入 cf 。在自己的 DNS 服务商处把 A 记录设成 cf ，AAAA 设成原来的。