最终不还要翻译到 SELECT ？
这种还好，就是不知道条件那里怎么写，如果写成 String sql = "SELECT * FROM xxx WHERE id='"+id+"'"，那就真蜜汁自信了。

@feast 那是否意味着 2.4G 频段应当同样的问题？或者说 WAP 的机制是两个 SSID，两套“驱动”，互相不会干扰，所以 5G 频段歇菜了，并不影响 2.4G 频段。然后这是一个 WAP 的 BUG，甚至说是 Linux 系统做软 AP 的底层缺陷？

附个图
https://wx1.sinaimg.cn/mw1024/62d5abefly1gjwszk42szj216h0ksdnm.jpg

按错了键，具体内容在此：
基本网络架构：使用 NAS 虚拟机安装软路由，实现 NAT ；使用自带虚拟交换机完成交换机功能；配合官方无线网卡以及 WAP 软件实现 AP 功能（这个是运行在系统底层 docker 容器中），开通了 5G 和 2.4G 两个频段。人使用的终端（手机、平板、电脑等）使用 5G 频段，自动设备使用 2.4G 频段。

症状情况：正常情况下，5G 频段接入后，speedtest 测速，信号良好的情况下，能够达到 500Mbps （运行商签约 500Mbps ），一切都良好。但是说不清什么时候后，speedtest 会只能测到 5Mbps，在 NAS 上做了 10MB 的测试包，curl 的速度也确实只有 500KB/s 左右，iperf 一样，而与此同时 WIFI 设备的协商速率仍然是 866 、433 等正常值，而且 2.4G 频段同期协商速率、实际速率没有问题。目前只在 5G 频段有这个毛病，也许跟 2.4G 频段的设备较少有关系。
解决方式：关掉 SSID，再开，短时间恢复，一个小时内可能又歇菜了；重启 WAP 的底层运行环境 docker 容器，一段时间内确实恢复，但是仍然会出现；重启整个 NAS，那会相对长一些的时间再次遇到速度被卡的情况。

问题：什么情况下，协商速率没有问题而实际速率产生这么大的问题？物理层和数据链路层上？ IP 层上？还是 WAP 本身有 BUG 或者性能缺陷？
我琢磨着是不是某个接入的设备与这套网络结构不匹配，那按道理一旦接入就会搞崩，但是一直没有找到这个设备，症状无法手动复现，而且时间复现上，似乎也没有规律。
各位了解无线网络深层次结构、原理的，给诊断诊断。

想起了前两天看到的说投资民宿就是找死的视频

当副屏

@Cielsky firefox 在一旁画圈圈，safari 表示你们开心就好

@just1 3# 赛尔核心到运营商核心出现问题了

udpxy，直接绕过 iptv 盒

关掉两个路由的 DCHP，全都手动，或者关掉路由 B 的 DHCP，只开路由 A 。但是最好都关掉，全手动。
然后 A 和 B 的 LAN 和 PC 在一个网段。
PC 设置出口路由表，如果不需要做均衡流量之类的，0.0.0.0 全都走 A 就行了，如果需要做，那就设置多份路由记录，并且在 metric 上做文章。
至于外网映射，既然 PC 是唯一的 IP，没关系喽。

软路由 lede，域名 aliyun，光猫桥接
crontab 5 1,4,7-22 * * *
分配置脚本和更新脚本
使用 dig 检测远端 IP，然后使用 ip addr 获取本端 IP，比较差异。支持 A 记录和 AAAA 记录。

北京联通，500M+一主两副=199

@Raynard #9，不用软路由，华硕的就只是连个 WAN，只不过第二个 WAN 他支持的是 USB 手机网卡，不是第二条 PPPoE

图啥？

@oakland 买过一个 Wall-E，买过一个蝙蝠侠战车，还有一个大 G，目测严丝合缝、质量良心。也许我买的是假假 LEGO