不知道这个问题还有没有人需要。
我也想在 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 。

@YekongTAT 驻马店移动。光猫 zn-m160g 拨号。我试过自己改光猫桥接，速度很慢，原因未知。光猫上的防火墙我也关了。不过我没删 tr069 。听说不删 tr069 会被局端重置，但我刚才上去看，防火墙的选项目前仍然还是关闭状态。

运营商并不仅仅是以省为单位运营的，甚至不同城市、有的同城不同区域也会因为市场环境的差异执行不同的运营策略。
限制上传带宽这个问题主要取决于当地运营商对外带宽是否紧张。如果比较紧张，那么他们就会下大力气整治家宽占用上传带宽的问题。这是因为总带宽是有限，家宽如果占用了大头，那么同一个网络里的商宽（服务器）就不够用了。商宽比家宽贵多了，所以运营商就会为了保商宽抛弃家宽用户，即使被投诉，甚至解约也都在所不惜。

要么是开 web 了，要么是上传大了。
一般是因为开 web 的可能性比较高。你用群晖，那么极有可能就是因为 web 服务。我所使用的河南移动宽带已经完全禁用了 ipv6 的 tcp 入站。
上传大（ pcdn ）不会仅仅停公网，要么限速要么断网。这是因为有的 pcdn 在 nat 后面也能继续运行。
后面看小哥上门怎么说吧。可能会让你关掉 web ，签保证书之类的。

当然也不排除故障、维护、或者是区域政策的可能性。比如你们这一带的 ipv6 正在交割，或者为了打击 pcdn 临时关闭 ipv6 。

@pcslide #55 已经解释过了。现在的低端猫，桥接用的是 brctl 软件桥，非常耗费 cpu 。而 nat 和 pppoe 是硬解优化过的。所以软件桥性能甚至不及两层 NAT 。我在 v2 随便一搜就能找到很多说桥接之后变慢的帖子。比如这几个：
https://www.v2ex.com/t/825676
https://www.v2ex.com/t/838192
https://www.v2ex.com/t/768516
https://www.v2ex.com/t/853287
https://www.v2ex.com/t/822833
https://www.v2ex.com/t/712965
https://www.v2ex.com/t/887345

@txydhr #54 光猫拨号二级路由能获取 ipv6 ，除非光猫没配置好。我之前已经试验过，我给光猫地址获取方式设置为混合模式，也就是 slaac 和 dhcpv6 都打开，二级路由后的 windows 能获得 slaac 和 dhcpv6 两种地址，android 能获得 slaac 一种地址。所以我才在主贴中说只有公网 v4 才需要路由拨号。你在你的光猫上找找 ra 、dhcpv6 之类的选项打开试试。注意 android 只支持 slaac 这一种地址获取方式。所以地址获取方式要么选自动，要么选 slaac 。前缀获取方式则选择 dhcpv6 。

@cwbsw #53 你的光猫应该不是那种常见的低端猫。现在运营商的光猫大多都是定制的，基本不会额外设计桥接加速。所以就会有很多人（上面链接的帖子）发生桥接降速的情况。

@xxb 开头说了啊，1234 是装维（也就是运营商代理）提供的信息。
后面“用运营商的猫跑桥接不如不桥接”是我的结论。

很多人误会了我的结论。我想说的是：如果你用的运营商给的低端光猫的话，改桥接的效果会比两层 NAT 更差。因为即使是低端光猫，拨号和 nat 也是优化过的，但是桥接没有经过优化。很多人以为桥接后变慢是被运营商限速，实际上很有可能是低端猫桥接性能不行。有桥接需求的应当自备光猫，并尽量避免使用软桥接的“智能”光猫。这类“智能”光猫的主要特征就是具有 vlan 功能。

另外，我所说的情况可能并不普遍，不适用于所有区域。如果你那里的师傅不喜欢改桥接，或机房设置了远程自动重置，八成这个区域的这个运营商对装维终端就有相关考核。

@clf 新装户是额外加成。平常工资是按在网用户给。总不能没新户就没工资了吧。
装维的工作是保障用户在线，所以运营商用“用户是否在线”来考核也是比较合理的。
具体考核比较复杂，有在线时长的要求。“考核路由模式”只是其中的一个方面。
桥接模式我估计也有有工资的，但是从师傅的意愿来推断，跟路由模式有差距。

@systemcall 就是为了互不影响，所以才是用 vlan ，也就是软交换实现，在光电调制解调器后面用 brctl 虚拟了一个交换机。这就是现在的光猫不同于硬光猫的地方。性能瓶颈就在这个虚拟交换机上。pppoe 用额外的电路缓解了这个瓶颈，但是大流量的桥接并没有硬件来优化，所以就成为了 cpu 的拖累。古代的硬光猫没有这些东西，是纯粹的光电信号转换。

一般是上网少或消费低的用户会经常收到赠送流量。这里面的逻辑，一是留存流失风险高的用户（ 8 元保号党）；二是对一些消费低、上网少的用户，培养其上网习惯。甚至还有激励策略，用够多少再送多少。
如果赠送的流量，你连续稳定地用了两个月以上，那么后面赠送就会慢慢变少。但你可以通过用一个月闲一个月这种方式来让系统一直赠送。它的逻辑其实不是很智能。