@Tumblr

那挺好，能着手解决自然是比放任不管的好。

@v2tudnew

您可能理解错我的意思了，我指的是整个 100.64.0.0/10 段映射给一个公网 IP 可能会不够，一般会做负载均衡到几个不同的公网 IP 上。还有要指正是 172.16.0.0/12 。其实值得吐槽的应该是国内部分云厂商把公网上没广播的地址用作内网，例如美国国防部的 21.0.0.0/8 。

@Tumblr

1.0.0.0/8 和 167.0.0.0/8 这两个网段是有所有者且在公网上有广播有路由的，贵司这并不是“正常操作”，是不合理且不应该的，至于为什么这么做了，可能是贵司没有 IT 审计吧。


@v2tudnew

虽然楼上那位老哥问题有点多，但是也要淡定。还有运营商内部一般是用一个 IP 池里若干不同 IP 来对应 100.64.0.0/10 ，一个 IP 对应整个段的话可能确实有点不够。。

代理的 IP 被 Google 拉黑了，这种情况在机场节点的 IP 上经常出现。

@christin
@cz5424

不需要 Win 实例，随便哪个 Linux 发行版都行，用 cURL 即可：

curl -X POST "https://api.bilibili.com/pgc/activity/shanghai316/receive" -H "origin: https://www.bilibili.com" -H "accept-encoding: gzip, deflate, br" -H "accept-language: zh-CN,zh;q=0.9" -H "user-agent: Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1" -H "content-type: application/x-www-form-urlencoded" -H "accept: application/json, text/plain, */*" -H "referer: https://www.bilibili.com/blackboard/activity-a1mp6FZCjI.html" -H "authority: api.bilibili.com" -H "cookie: [放入你的 b 站 cookie ，浏览器 F12 可以看到] "

一样 13pm ，移动+电信，电信好好的，移动经常突然消失然后重连，我还以为是我 SIM 卡问题，晚点去营业厅换卡试试。

同 020 电信但是不同区，不可能不变的，我最长的纪录也是一个多月没变。

长时间没变的原因可能是你家附近的 IP 池分配完了，所以短时间断开重拨都会是同 IP ，你试试关闭光猫电源等十分钟在拨就很可能不是同一个了。

提供另外一个思路，最近我也在啃很多英文文献：

推荐一下沙拉查词这个扩展 （免费无广告且开源: https://github.com/crimx/ext-saladict ），支持 pdf 划词翻译，但要手动设置一下 ： https://saladict.crimx.com/manual.html#pdf 。

原理就是劫持 Edge 的 pdf 阅读器到沙拉查词自带的阅读器。
翻译质量可以同时几个一起参考，值得一用。


我用的这个，挺好用的，供参考：

https://github.com/jeessy2/ddns-go

@A01514035
不是必须的，思路就是创造一个 wifi 且能 POST 的 api server ，参考如下几个教程

https://www.right.com.cn/forum/thread-5328443-1-1.html
https://www.right.com.cn/forum/thread-4389756-1-1.html
https://www.right.com.cn/forum/thread-8205016-1-1.html

刚看到的视频，供参考：

https://www.bilibili.com/video/BV1ga411m7ix

放过 7621 吧 +1 。

如果确实要在路由上跑又不想折腾软路由的话可以考虑性能强的硬路由。比如 AX3600 、AX6 等，跑千兆科学问题不大。

广州电信 AWS 推荐新加坡，但是某些网段也存在绕路的情况，我这能拨出三个段 113.111/21 113.67/22 116.21/22 中就是 116.21 会绕路：

116.21/22

113.111/21

113.67/22

太长不看版：单独对 B 站系列域名解析 IPv6 即可解决问题。

经过大半个月的测试，我觉得我有一点发言权：

B 站的 video host 有四种类型：（我将其添加个称呼好标注，非官方称呼）
upos-sz-mirrorkodo.bilivideo.com / upos-sz-mirrorcos.bilivideo.com / Mirror 型
cn-gdgz4-cmcc-v-09.bilivideo.com / cn-gdst-cmcc-bcache-02.bilivideo.com / Cache 型
xy112x48x59x98xy.mcdn.bilivideo.cn / xy110x85x55x73xy.mcdn.bilivideo.cn / MCDN 型
a93lt21v.v1d.szbdyd.com / hz6xy5t6.v1d.szbdyd.com / PCDN 型
以上几种是在广东移动的场景下测的，其他运营商应该也差不多。

在有无 IPv6 的情况下有很大区别：

无 IPv6 时：
PCDN 型 的概率很高，但因为是 PCDN ，质量比较一言难尽。
MCDN 型和 Cache 型 一般出现在比较热门的视频或是电影番剧中，质量尚可，高峰期可能会慢点但仍可接受。
Mirror 型分配就很奇怪了，热门视频有可能，但冷门或是几年前的视频也都分配这个，有快有慢不知道 B 站怎么搞的。

有 IPv6 就是两个世界了：
PCDN 型基本就没有了，MCDN 和 Cache 型概率也低很多。
Mirror 型分配的概率大大提高，冷门热门分配的都是这个，而且速度超级快，很少遇到卡顿。

基于我以上的观察，我在自家的 DNS 服务器上屏蔽了 PCDN 的域名，单独允许 B 站系列域名可解析 IPv6 以及屏蔽 203.107.1.1/24 的流量（这是阿里家的 HTTPDNS ，B 站会利用这个 DNS 请求解析，必须屏蔽），自此就基本没遇到卡顿的问题了。

最后，这也只是我家的测试情况，单一样本不具备普适性，所以仅供参考。

最后的最后，个人经验难免错误疏漏，还请大佬们补充纠正。