@adz1181014499 是的，Docker/LXC/PVE/ESXi 等等这些都算，哪怕你直接在路由器系统里跑一堆服务也算。

让服务分散在不同设备上肯定也可以，而且在部署时会更简单。但缺点是设备越多，后期硬件维护越麻烦，性价比也更差。

如果用上虚拟化也就是所谓的 All in boom ，配置越高越划算，每个服务能享受到的峰值性能更高、硬件复用率更高意味着成本可能不增反降、管理也更方便。当然就像它的外号一样，虽然发生故障的可能性比多台设备更低，但发生故障时影响范围会更大。

如果只是单独跑软路由的话，用 N5105 性能是有点过剩了。

5G 目前长板已经足够长，商场门口 N78 随便跑 200Mbps+，这么高的带宽再提高对移动设备来说也不会有明显的体验改善。目前 5G 最大的痛点是短板，每次在商场里排队要饭都只有 N1 覆盖，信号强度也很弱（低于 -100dBm 甚至低于 -110dBm ），导致不仅速度很低，打游戏也会频繁卡顿。

如果能降低成本，在商场这种人多的室内多布些基站甚至是多布些高频段基站，让餐饮店里也能做到商场门口的速度和稳定性就能有非常良好的体验。

如果 6G 成本更高，导致技术上改善的信号质量和覆盖能力都被用于减少基站数量降低成本，那最终到用户身上的实际体验还是会很糟糕。

@phpbird 你路由器统计里这个月上传下载分别跑了多少？倒也不一定是只有上传多了才会进小黑屋，也许会根据其他特征综合判断呢。

还好绿联不做心电监护仪

OpenVPN 支持 TAP 模式，但据 OpenVPN 文档所述，Android 和 iOS 的 VPN API 目前都不支持 TAP ，只支持 TUN 。其他第三方 VPN APP 应该都有相同的情况，不知道系统自带的 VPN （ IPsec/IKEv2 之类的）能不能幸免。

元气骑士的局域网联机也有相同情况，解决方案是在房主设备上指定客户端 IP ，做 广播 -> 单播 转换之后再发给客户端，这样就能使用 TUN VPN 了。可以参考这个不到 30 行的小工具： https://github.com/Sengxian/SoulKnightHelper

如果你现在区分不出真假公网 IP ，说明真假公网 IP 对你来说没区别。

@sonnetbreeze 你这结果明显是被限速了，副宽 istore 往主宽 imm 上传只有 5 Mbps 。

@sonnetbreeze 你说 imm 是主宽带，istore 是副宽带，但你贴的 iperf3 是 imm 往 istore 上传，测的是主宽带的上传而不是副宽带的上传，应该加上 -R 测试副宽往主宽上传。

020 的限速策略对你参考比较小，不同地区策略有区别，尽量找同样是上海电信的帖子看。上海电信限速不会掉公网 IP ，有些帖子甚至说会给内网 IP 用户改成公网 IP 。

30 Mbps 上传算比较高了，一般不会限速到这么高，而且也不可能导致网页都卡，主宽确定有被限速吗？而且你前面 iperf3 测试显示主宽（ imm ）有近 60 Mbps 的上传带宽，会不会是测试方式问题或者其他原因？

218.1 有帖子提到是上海电信的限速段，可能是你副宽被限速后限制只能拨到限速段了，所以现在你的主宽和副宽没法拨到一个 /16 下。

@bjclue 这都不是精品网账号的段，像是用普通账号拨号了，等他们查吧。

@bjclue 是光猫拨号吗？拿到的 IP 前三段是多少？我前面说的不准确，“取消云宽带”意思就是取消云宽带的上网方式改回光猫/路由器拨号，既然你已经改回来了那应该不是这个原因。

@bjclue 精品网和云宽带冲突，取消云宽带就行了，单纯是业务冲突。

WireGuard 本身不是 TLS 流量不携带 SNI ，域名仅用于获取 Endpoint 的 IP ，Endpoint 改成域名自然没效果。

去试试 OpenVPN 吧，说不定上海电信对 OpenVPN 也有白名单不限速呢？

不服就先报障，电信不解决就去投诉，投诉不解决就起诉。反正同城传输不影响运营商利益，最晚到起诉估计就和解了。

是不是只能拨到 218.80 段？不止 58.32 ，连 58.41 也拨不到。估计是进精品网专属的小黑屋了，论坛里之前有几篇帖子讨论过，你可以搜搜。

将 Tailscale 部署在内网的测试服务器上进行了以下试验：

禁用 NAT66 时：分别用 “AWS + iperf3” 和 “上海联通 5G 蜂窝网络 + 全球网测” 进行了一些测试，没有观察到 Tailscale 有绕过限速的能力。

Tailscale 、IPv6 直连、家宽端口 41641 、客户端端口 41641：限速 5 Mbps 。
Tailscale 、IPv6 直连、家宽端口 443 、客户端端口 41641：限速 5 Mbps 。

启用 NAT66 时：Tailscale 会使用 NAT 地址打洞进行连接，进而享受到 WAN 口 IPv6 地址不限速的待遇。同时 Tailscale 还会尝试用本机的 IPv6 地址再打一个洞作为备用链路，如果打洞成功且 Tailscale 选择使用这个备用链路则会被限速 5 Mbps 。

如果 Tailscale 被直接安装在负责拨号的路由器上，而非我这样安装在其他内网设备上：只要 Tailscale 选择使用 WAN 口 IPv6 地址进行连接，不论是否启用 NAT66 都不会被限速。

总结：Tailscale 本身不能触发白名单，IPv6 + Tailscale 能绕过限速的主要原因是上海联通目前对 WAN 口 IPv6 地址不限速，与 Tailscale 关系不大。

@superhero007 如果与你观察到的情况不符还请指出。感谢你先前的分享帮助发现了 WAN 口 IPv6 地址这一白名单策略。（也有可能是漏洞？）

@tril #26 订正：iperf3 是上行限速 5 Mbps 。

@jyeric 是指什么类型的流量？

HTTPS 流量：我额外测试了一下，https://speed.sbcu.xxx.yyy:442 这种低位端口仍然会被上行限速 10 Mbps 。

iperf3：跟上海腾讯云的 443 端口进行测试仍然会被上行限速 10 Mbps 。

我目前没有观察到低位端口就不限速、只限速高位端口的情况。

@superhero007 很好的建议，我之后会考虑要不要进一步测试 IPv6 下的 Tailscale 。它过于智能，反而对测试造成了较大的影响，另外我的 NAT66 环境也对测试造成了不小的麻烦。目前先简单测试了一下 IPv4 网络下的 Tailscale ，限速 5 Mbps 。

更重要的是，在测试 Tailscale 的过程中意外发现 WAN 口 IPv6 地址不会被限速，只有 IPv6-PD 地址段会被限速。目前测试了 iperf3 和 WireGuard ，只要使用 WAN 口 IPv6 地址均不会被限速。

@weixulin 这只有上海联通自己才知道了，运营商这种偷偷摸摸的限速一直是黑箱操作。