CrazyBoyFeng

不知道这个问题还有没有人需要。
我也想在 windows 上用代理模式使用 antigravity ，因为我的电脑上某些软件禁止使用 tun 虚拟网卡。
我试了一些推荐的软件：
* proxifyre 重定向失败，因为不拦截 ipv6 连接。
* proxybridge 能用，但会导致整个电脑的 ipv6 连接失效。
* proxigo 每个（子）进程都需要手动注入，操作麻烦，容易遗漏。
* netch 可以用，但是非常耗费系统资源。
以上都是开源软件，但都不怎么好用。
我用了一圈，最终还是去用 proxifier 了。

#21 虽然 RECEIVE_SENSITIVE_NOTIFICATIONS 这个权限的 protectionLevel 是 signature|role： https://android.googlesource.com/platform/frameworks/base/+/master/core/res/AndroidManifest.xml#8677
意味着除了系统应用，被授予（设备伴生）角色的应用也应获得权限。但经过我的实测仍然获取不到敏感通知。我还没有搞清楚为什么会出现这种差异。
经过我的研究 RECEIVE_SENSITIVE_NOTIFICATIONS 这个权限只有以下两种情况能够获得：
1. 预装在 /system 里且在特权白名单 /system/etc/permissions/privapp-permissions-*.xml 里声明的应用。
2. 与系统 platform key 签名一致的应用。
一个例子：预装了 windows phone link 的安卓设备可以读取验证码但是没预装的默认读取不了验证码。参考 https://www.ithome.com/0/842/770.htm

我写了个 powershell 脚本扫描了 2606:4700::/32 所有 /46 子网地址第一个 IP 的最短 RTT： https://gist.github.com/CrazyBoyFeng/c89009b423066b1dd79993f6b68d6d21#file-ping-ipv6subnets-ps1
移动家宽扫描结果： https://gist.github.com/CrazyBoyFeng/c89009b423066b1dd79993f6b68d6d21#file-ping-ipv6subnets-csv
然后我把最快的 ip 所在的/46 子网展开成/48 子网又测了一遍每个子网的第一个 IP ，得到最快的 IP 段如下：
2606:4700:0068::/47
2606:4700:0090::/48
2606:4700:00a0::/48
2606:4700:00a8::/48
2606:4700:00f4::/48
2606:4700:0100::/48
2606:4700:3030::/45
2606:4700:8390::/45
2606:4700:8398::/46
2606:4700:8ca0::/45
2606:4700:8ca8::/46
2606:4700:90c0::/45
2606:4700:90c8::/46
2606:4700:90d0::/45
2606:4700:90d8::/46
2606:4700:91b0::/45
2606:4700:91b8::/46
2606:4700:9640::/45
2606:4700:9648::/46
2606:4700:9760::/45
2606:4700:9760::/46
2606:4700:99e0::/45
2606:4700:99e8::/46
2606:4700:9a60::/45
2606:4700:9a68::/46
2606:4700:9a90::/45
2606:4700:9a98::/46
2606:4700:9ad0::/45
2606:4700:9ad8::/46
2606:4700:9ae0::/45
2606:4700:9ae8::/46
2606:4700:9b00::/45
2606:4700:9b08::/46
2606:4700:9c60::/45
2606:4700:9c68::/46
2606:4700:ff00::/48
注意上面是网段，例如 2606:4700:3030::/45 包含从 2606:4700:3030:开头到 2606:4700:3037:开头的所有地址。
另外这只是 ping 测试，这些 ip 不一定全都能拿来当作访问节点用，可以自行测试。我也有写 httping 的脚本，如有需要也可以下载使用： https://github.com/CrazyBoyFeng/Find-BetterCloudflareIP/blob/main/Httping-CloudflareIP.PS1
我只扫了/46 子网的第一个 IP ，/47 和/48 子网太多了就没扫，所以应该会有遗漏的可用段没扫到。谁比较闲可以下载脚本自己扫。/48 整个扫完可能需要 2-4 天。没用并发扫描是因为并发丢包率高，不知道是 cf 的限制还是运营商的限制，即便是现在的单例串行扫描丢包率依然很高。

@microka udp456 端口是以前 odhcp6c 使用的端口，但后来不知为何他们又改到 546 了，也许是 456 跟别的什么东西冲突了吧。
所以，用 ssh 进你的路由器看一看，用 `netstat -apun | grep odhcp6c` 查看一下你路由器上的 dhcpv6 客户端端口。这个端口应该与防火墙里 `Allow-DHCPv6` 保持一致，如果不一致，那就修改防火墙设置。

这楼里很多人说小米解锁后 tee 能用（指纹能用）这个结论不知道有没有对小米近两年的机器进行验证？
我们搞机群有个人的 mi13pro 解锁刷机后试过也是没有指纹的。但我不知道这是不是个例。

@0x3036 运营商倾斜 5g 大多是因为政策考核覆盖率，如果将来不再考核覆盖率，估计 5g 基站在线数量马上就下去了，就像当年的 3g 。
5g 本来也是一个过渡性、补充性的技术，而不是革新性、关键性的技术。在国外那些没有太多干扰因素的市场环境中，5g 通常只被用来覆盖在人特别多的地方用于扩充局部的带宽以避免拥堵。在那些人口不密集，网速不拥堵的地方，部署 5g 好处并不大。4g 也能满足 4k 视频的传输，并且比 5g 省电。国外还有少量的毫米波 5g 技术被用来在不方便施工的地方代替线缆。如果将来政策不再考核 5g 覆盖率，估计最终中国的市场格局也会变成这样。

@zmcity 是我没写准确，其实我想写的就是手机。现在发放进网许可的 esim 设备有：可以通话的手表、不能通话的平板、通讯壳，以及一些物联网设备。
我其实并不确定工信部是否禁止 esim 手机进网。没见到明确的文件，但也有可能是因为我不是手机厂商所以不了解这方面的信息。我能见到的限制文件都是运营商这边的。

作为涉足通信圈的人，回答一下本人知道的楼里的一些疑问：

工信部禁止手机用 esim ？
有过内部通知，在公开推广之前不能大规模商用。明面上的理由是怕不成熟，被不法分子利用。
目前国行没有任何具备话音业务的机器硬件上支持 esim ，包括之前被迫关闭“小米防丢失模式”的 mix4 那其实是 softsim 。真正的 esim 用*#06#查询可以看到 eid ，而国行手机即使刷国外系统也看不到 eid 。使用类似技术的还有华为天际通和小米全球上网一元流量。

禁止 esim 是因为怕用户开境外卡？
现阶段用户开境外卡不受阻碍。无论邮寄还是支持 ota （空中发卡）的 esim 、softsim ，用户都可以开境外卡在境内使用。

esim 易被电诈利用？
正经的 esim ，写入之后是不会被导出盗用的。只要控制住开卡和换机流程，就不会有“办理了大量 esim 在一部机上频繁切换用于不法活动”的情况发生。因为一般来说换机是要身份验证的。要是不法分子连身份验证也能通过的话，还有一个终极的解决办法——禁止 ota ，只能现场实人发卡。
不过，某些国产设备的 esim 实现不太正经——写号软件+内置的实体 sim 卡。这种方式虽在写号密钥没泄露之前也没什么问题。虽然能通过拆机轻易做到机卡分离，但是分离后也只是一个普通 sim 卡。办卡难度也并没有比普通卡更低。但是写号密钥泄露之后，这类卡就可以被轻易导出、复制、换号。这就是为什么之前一段时间 esim 被紧急叫停。不过没有叫停苹果表，因为苹果用的是正经 esim ，导不出来。叫停之后的修补办法是在运营商处加个判断——是否为开卡时绑定的卡 id 和设备 id 。
我的观点是，esim 如果注重规范就不会被不法利用，反而能遏制不法利用。无法轻易拔卡换机的 esim 反而能极大遏制电诈。因为无法进行号卡转卖。

esim 能实现无限流量？
没听说过这种漏洞。可能有人转卖物联网卡？但是物联网卡也不是无限流量啊。而且机卡绑定的鉴权漏洞修补后，转卖卡都用不成了。

最后，我推测的为什么这个业务不推广的原因：
工信部不排斥这个业务，但是怕出纰漏（如前所述已经出过一次纰漏了），所以缓慢推进。
而对于运营商及通信产业链来说，esim 不能带来收入的增长，反而要投入很多成本建设维护开卡和管理系统，所以没有什么投入的意愿。跟 ipv6 类似。除非工信部强推这个业务，运营商才愿意去干。

我找到了一个和我一样的案例： https://www.nodeseek.com/post-136177-1
他是一个月前证书失效的。也是各种折腾都无法恢复证书的签发。最后开通了 [自定义主机名] 解决。
我学着他的做法，添加自定义主机名 cdn.a.com 回退源 cdn.a.com ，也成功给 cdn.a.com 签发了证书。
虽然目前还不清楚是什么原因导致的这个问题，不过目前这样就算是解决了。
我猜可能是因为 partner 的 cname 接入是被废弃的业务，所以 cf 忘了给这个业务配置 certbot 。