照你这种推理逻辑，放在 10.0.0.0/8 下面岂不要突破万兆

已经换了，唯一的小坑是没有公网 IPv4 地址，不过有 IPv6 也就无所谓了。

你这个需求叫做 User Impersonation. ASP.net 传统版本是自然支持的，看这里 https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/aspnet/development/implement-impersonation 。打从 ASP.net Core 之后应该是需要自己写 middle ware 读 ClaimsPrinciple 写代码实现了。

理论应该是 SLAAC 只分配地址。DHCPv6 分配 DNS 和网关。你这些截图只看到 DHCPv6 分配地址和 DNS ，没见过分配网关的选项。具体还得抓 ICMPv6 看看到底 DHCP 响应带了哪些 option 了。

什么魔法方案？

问题 1：不管直连还是坐飞机，是否魔法设备的流量路径都会是 设备<->旁路由<->主路由？（既旁路由如果链路速度有瓶颈，会影响最大速度？）

这个其实比较复杂。流量分上行下行。上行流量是你下面设备的默认网关控制的。所以只要设置网关为旁路由的，上行必然经过旁路由。但下行流量要具体看情况。因为主路由，旁路由，和上网设备都在同一子网，所以拓扑上看是完全直连的。所以下行流量应该是在主路由 NAT 转换回内网 IP 后直接发回设备，不会经过旁路由。但是有例外，旁路由因为有魔法加持，在上行流量经过时有部分魔法加持的流量被装箱飞国外节点了，这个装箱行为会写上标签源地址时旁路由自己，所以相应魔法加持过的流量在下行阶段的目的地址时旁路由地址。然后旁路由再拆箱变成原始下行。正因为这个魔法加持的影响，所以造成了没有魔法加持的流量主路由直接传输到设备，魔法加持的流量必然走旁路由。
所以这里如果要讨论速度影响的话，实际上有点过度考虑。原因有 2 点：1. 上行流量远小于下行，基本上可以认为任何弱鸡设备都能跑得起。2. 因为旁路本身应该有国内国外分流功能，而分流后需要魔法加持的流量更小，所以更不用担心了。

问题 2：如果上面的是对的，那么想要在碰到直连时流量不经过旁路由的话，除了把策略软件安装在需要魔法的设备上，还有别的方法吗？（假想：旁路由：“你这个地址直接去主路由，别找我”）

没必要这么做，如果只论技术上可行性，那可以主路由上再做针对 IP 段的策略路由，提前筛选一遍，把需要魔法加持的流量路由到旁路由。但是针对 IP 段的分流策略远不如目前魔法技能的那些域名+IP 策略方式灵活和精准。所以还不如不做，让旁路由上面的魔法工作起来就好。

我碰到类似的问题。找到的原因是服务端用的唱歌盒子，后来换成换成伦琴射线就没这个问题了。

前两天刚装了上海联通，电信千兆还没退，比较下来联通快得多。

上海联通手机号用户可以加装这个宽带吗？

可惜错过了。我这联通 228 月费套餐想加装宽带都拿不到这个套餐，只有 30M 上传。希望有机会能再次开放吧。

亲测可行。自己买的 8145Q ，只需要 LOID ，其它自己搞定就行了。桥接完美。

IP 和证书均无误。看起来原因似乎是你以前曾经把 DigiCert 的根证书从信任列表里干掉了。

nslookup 看一下这个域名解析到的 IP 地址，还有看一下证书的 subject 是哪个 domain ？

这 Full Table 是 Vultr 来的，我比较好奇它是怎么收集到这么多的？

同上海电信家庭宽带。我这不用自己拨号，接 SDN 光猫用，是不是就没有办法获得 /56 地址了？

推荐 Rancher Desktop 。开源，但有 Rancher 这样级别的公司支持。同样是 electron 的 UI 。内置 k3s 版本的 Kubernetes ，可以直接由 container 一步进化到 pod 。容器运行时也可以选择 containerd ，避免 dockerd 的绑定。

楼上说的不是很精确。WSL2 内的 container 是 linux 提供的，不算 Windows 的容器。Windows 的容器有 2 种类型，一种是基于进程隔离的容器，一种是 hyper-V 提供的内核级别隔离的容器。
这两种容器现在最容易的使用方式还是 Docker for Windows ，看这里： https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container

@dawnh 接这条。
按印象里的搜了一下 SO 找到以前看过的帖子了，随后指向到这个 issue： https://github.com/dotnet/efcore/issues/18571
简单来说，如果你是用了 ToListAsync()，使用 SqlClient ，同时表结构里存在 VARCHAR(MAX)这样的变长列，就会碰到这个性能问题，好多年还没修，因为要修复就牵扯到非常底层的库。引用 issue 里的一条回复：
Workarounds: Don't use VARCHAR(MAX) or don't use async queries.

希望对你有帮助吧。

试试看不要用 ToListAsync()，而是 ToList()之后再返回结果。印象里看到过一些 SO 上关于 ToListAsync 在 EF 莫名其妙慢的问题。