应该换个思路：bug 其实一直都很多，只是最近你碰到的 bug 恰好都是影响了你经常使用的功能，例如 wsl，例如网络。
其实不怕 bug 多，就怕 bug 没人管。你提到的这几个确实最近很多人讨论，而且也确实一直在想办法修。

1000M 套餐，春节后新装的精品网。一开始给了 218.80 ，重拨，变成 58.41 ，再重拨，变成 58.32 。用到现在位置没有掉过线。

上海电信的 IPTV 除了专网直播和组播 2 个 VLAN 外，还要 DHCP option 125 。你这老的光猫貌似还是只能接 iptv 口才有正确 VLAN，不换光猫改桥接的情况下，搞起来怕是比较痛苦 。

@semglassie VLAN51 的流量是转发到 VLAN85 的，这个 untagged 还是在的。另外非 4k 的 IPTV 还是用单独的 VLAN51

原理上可行，实际看你下面设备支持了。基本上 IPTV 配置的难点就在于 VLAN 和 DHCP option，这俩你下面设备能配置好都可以工作。
VLAN 的话要求是 native untagged VLAN，专网走 VLAN 85，组播走 VLAN 51 。你路由只要能配好这俩流量能过就不成问题。
DHCP option 125 这个看你路由的 DHCP 能不能配，如果是 OpenWRT 这种支持 dnsmasq 的改一下配置文件都能搞定。

其实加一个路由最大的问题在于你路由下面的设备经过了 2 层 NAT，这个处理起来特别麻烦。换个思路的话，你这个路由不做第二层 NAT，SDN 接它 LAN 口，其它设备包括 IPTV 也接它 LAN 口，那基本上 DHCP 这块就不需要了，VLAN 只要配好就一切搞定。

目前给 PC 用的外置指纹最多的大都是 elan 的方案，免驱但是可靠性比较一般，常年插着还爱发热。我买过一个用了几次就弃用了。换个思路非要用 Windows Hello 做认证的话，那个联想出的红外摄像头更靠谱一些。

@PESH 我看到这个也是不信，然后自己测了一下发现是真的，基本上 traceroute 出了上海到骨干网 59.43 就直接 hit 1.1.1.1 了。应该是这个服务器的 anycast IP 在 CN2 骨干网有部署。

已经是千兆 199 套餐的了，SDN 路由器，办了这个竟然接到电话说还是要上门办理。

确实是理解有误，很多人分不清 port，targetPort 和 nodePort 。参考这篇文章的解释就很容易理解了。

https://matthewpalmer.net/kubernetes-app-developer/articles/kubernetes-ports-targetport-nodeport-service.html
nodePort
This setting makes the service visible outside the Kubernetes cluster by the node’s IP address and the port number declared in this property. The service also has to be of type NodePort (if this field isn’t specified, Kubernetes will allocate a node port automatically).

port
Expose the service on the specified port internally within the cluster. That is, the service becomes visible on this port, and will send requests made to this port to the pods selected by the service.

targetPort
This is the port on the pod that the request gets sent to. Your application needs to be listening for network requests on this port for the service to work.


Learn Kube Faster.
Get the #1 guide.
Get my book on Kubernetes for software developers, used by engineers at Google, Microsoft, and IBM.

简单来说 targetPort 是指 pod 里服务在 podIP 上监听的端口，必须指定； port 是 expose 出来在 svc 上提供对外服务的端口，也必须指定；而 nodePort 是指定了 nodePort 方式后在 node IP 上提供服务的端口，这个不指定则随机分配。

有几个原因会导致 Linux 占着内存不释放，WSL2 加了 Reclaim 内存功能，看一下这篇： https://devblogs.microsoft.com/commandline/memory-reclaim-in-the-windows-subsystem-for-linux-2/

上海电信有个别局如果是自动开通 V6 的话，可能 V4 地址就变成内网 NAT 的了。然而如果打 10000 号申请分配回 V4 公网 IP，V6 就不会下发配置了。

@iccfish 官方文档 https://docs.microsoft.com/en-us/windows/wsl/wsl2-about：
Increased file IO performance
File intensive operations like git clone, npm install, apt update, apt upgrade, and more will all be noticeably faster. The actual speed increase will depend on which app you’re running and how it is interacting with the file system. Initial versions of WSL 2 run up to 20x faster compared to WSL 1 when unpacking a zipped tarball, and around 2-5x faster when using git clone, npm install and cmake on various projects.

Channel9 开发者频道有视频演示实际速度比较，在重 IO 访问情况下保底有 2 倍性能提升，具体就不放链接了。

@iccfish 关于磁盘性能实际上 wsl 的目标和你的结果是相反的，也就是提供更加高的 IO 性能。其实 WSL1 的 IO 反倒是一直被诟病的。WSL2 则是给了 2 个方式:
在根目录下的文件访问是走 utility VM 的原生 ext4 文件读写是.vhdx，性能接近原生 ext4 。支持 POSIX 文件权限和 ACL 。但是如果要在 Windows 下访问则需要\\WSL$\path\to\file 这样走 Plan9 。
/mnt/<drive>是用 Plan9 mount 的 Windows 文件系统，性能一般，但可以无缝在 Windows 下互操作，对于文件系统特性支持有限。

你如果追求 IO 性能，则不应该把 WSL2 的文件放在 /mnt/<drive>下面，而是保持在 ext4 文件系统下。另外好像 WSL2 还有方法 mount 一个新的.vhdx 作为数据盘。

单纯只看连接流量统计的话可以看一下 SysInternals 的 TCPView，它底层是通过 ETW 做 trace 拿到的消息。
如果是要抓包，Network Monitor 可以，但是也是需要单独安装的。目前这个感觉是最稳定好用的 。还有一个是 Message Analyzer，这个复杂但不是很好用。
另外 Windows 10 从 RS5 开始自带一套新的抓包工具，pktmon，貌似也是通过 ETW 弄出来的数据。所以真要自己搞，研究一下 ETW Trace 相关的 API 应该是条不错的思路。

上面提到的所有产品现在都是微软第一方的。

一行命令搞定，建立快捷方式爱放哪里点放哪里：

rundll32.exe powrprof.dll,SetSuspendState 0,1,0

@superhxl 你光猫是什么型号的？貌似现在的上海电信 SDN 的光猫已经不限定 iptv 绑哪个口了吧。

Azure 的上海-香港是怎么做到的？

今天发现也有 ipv6 地址了，不过路由器默认 native 的方式获得不了 LAN prefix，只有 WAN 的 /64 地址。切换到 passthrough 方式所有的机器都能获得一个 /64 地址了。

这么多年了,原来移动还没解决这个缓存服务器经常挂的问题啊。
另外，不要以为有了 HTTPS 就万无一失了，移动的缓存可是有连 SSL 都给你 proxy 的行为的，而且它的缓存服务器也经常炸，表现在 HTTPS 上就是证书拿不到。