1. 如果不是必需，不要开启 IPv6 。国内的 IPv6 互联状态依然是非常糟糕的。
2. 如果可以接受 /128 ，那么请开启 OpenWrt 防火墙的 IPv6 NAT 伪装，同时本地分配 ULA fd00::/64 并开启 SLAAC ，这样本地可以用固定的 IPv6 进行通信，同时也，唯一的缺点就是 IPv6 公网访问经过了 NAT 。如果需要入站，那么也可以设置防火墙规则进行 IPv6 的端口转发；但是前提是你的光猫是桥接模式，路由模式基本上光猫的 IPv6 防火墙都是入站关闭的。
3. 没有必要使用 DHCPv6 ，安卓也不支持 DHCPv6 ，使用 SLAAC 即可。这种情况下 OpenWrt 拿到的上级 PD Prefix 为 /64 也是可以往下分的。同时，SLAAC 的子网必需是 /64 ，比 /64 更大或更小都是不符合协议规范的。

管的 电信出境流量过大会对出境流量限 5Mbps

国内不要用 cloudflare ，又卡又慢

我记得之前有段时间宣传过 这部分多买的你可以在到达站退钱来着

限速时用官方测速平台测试并录屏，然后截图发给客服试试看

802.11 kvr

有没有一种可能 只是路由原因
1.1.1.1 也有这个问题
8888 的话 如果你从不同地区测试 也有这个问题

B 站的 CDN 调度很奇怪。
试试强制把 CDN 改为 cn-jxnc-cmcc-bcache-06[.]bilivideo[.]com 这个地址

使用 rsync 部署
静态没必要上 CI

从用户的角度来说，IPv6 确实是相当失败的（嗯，安卓至今不支持 DHCPv6 ）

而且用户也习惯了 NAT 的存在

但其实从 ISP 的角度来说 IPv6 反而更省事，基于 V6 的各种新技术也层出不穷

其实 RouterOS 不如 OpenWrt 可玩性高……
隧道基本上都是需要至少一端有公网的标准协议，要不就是折腾 RIP / OSPF / BGP 这类路由协议
主副路由都支持的话可以跑 VRRP 做故障转移

原来写入 sysctl.conf 的，需要写入 sysctl.d/自定义文件名.conf
然后使用 sysctl --system 生效
你是我今天看到第 8 个遇到这个 sysctl 问题的人

首先，开源本身维权就非常困难
其次，就算对方也开源，你要证明「代码逻辑的相似度」也很困难
最后，你没有对方的源代码而只有二进制，那么你自己都没有可信的证据证明「对方使用了你的代码」

1. 「二十四节气」确实是农历专有，或者说「中国历法」专有。西方也有「黄道十二宫」的说法，从科学原理上其实是同一种地理现象，但是由此衍生的文化和在生活中产生的作用是不同的
2. 「 24 节气其实是由公历决定的」是错误的说法，应该是「由太阳历决定的」
3. 「春秋分夏冬至在公历上一直都是 3/6/9/12 月的 20-22 号。反倒是在农历上东一个西一个」，是因为农历的「月」和「月相」挂钩导致的

1. CF Enterprise Support 方面的回复是路由配置错误。现在 IP 黑洞已经解除，但是部分省市运营商依然对该 IP 进行 SNI 屏蔽（相比其他 CF IP 的 SNI 屏蔽更加严格）。
2. 「如果把域名从 Cloudflare 删掉再添加回来，有救吗？」 CF 的域名删除是异步的，需要等刷新，表现为再次添加时需要你更换 NS 服务器，如果是需要更换 NS 服务器就有可能有用。
3. 论坛内有其他人通过重新注册 CF 账号解决。
4. 还是建议不重要的业务优选；重要的业务上 Pro 吧。

我听说有几个说法

1. 账号被标记了
2. Free plan 完全随机分配
3. 流量大了就切

目测是风控，所以都是黑盒。

感觉其实 CF 这个措施其实没什么用。该优选的人还是会去优选，如果你用来跑代理你会选择不优选吗？如果你做产品的话肯定上加钱 Pro 。也就欺负老实人了。

哈哈，美版跨网限制

不会跑路，但是性能很差，跑服务可能会跑一半卡死