使用glm 5.2进行一次局域网网络非常缓慢的原因和解决方法，其实这个问题一直都存在使用claude.ai和deepseek都没有解决这个问题，今天尝试使用使用glm 5.2，一开始使用glm 5.2也出现了误判，但是很惊喜的是它发现了自己的误判，最后成功解决了这个网络抖动的问题。
内网 *.int.net.example 访问缓慢 — 故障排查与修复存档
- 日期：2026-07-10
- 环境：主路由 OpenWrt/ImmortalWrt + PassWall 代理，内网 NAS 提供
*.int.net.example服务 - 结论：根因是 DNS 的 AAAA（IPv6）解析超时，与路由器流量卸载及代理配置无关。
1. 环境拓扑
| 设备 | IP | 角色 |
|---|---|---|
| 主路由 | 192.168.50.1 | OpenWrt/ImmortalWrt，运行 PassWall（国内外分流），开启 DNS 劫持（dns_redirect=1、dnsmasq_dns_redirect=1） |
| AP | 桥接模式 WiFi 路由器 | 二层桥接，不做 NAT |
| NAS | 192.168.50.88 | 运行各类内网服务（Nginx 等）；原计划在 Docker 内运行内部 DNS，实测已停止 |
| 客户端 | 192.168.50.105 | 本机，与 NAS 处于同一 192.168.50.0/24 子网 |
域名说明：
*.int.net.example均为内网域名，目标解析至 NAS192.168.50.88。路由器/etc/hosts已静态配置相关子域名映射。
2. 故障现象
- 所有
*.int.net.example站点访问缓慢，每次建立新连接存在约 1.0s 延迟，稳定复现。 curl测试显示time_connect ≈ 1.0s，表现为“首次 SYN 丢失 → 1s 后重传成功”的特征。
3. 排查过程
3.1 误判一：路由器流量卸载（Flow Offload）
- 假设：MediaTek 硬件卸载 Bug 导致首包被丢弃。
- 验证：关闭硬件卸载（保留软件卸载）后延迟依旧为 1.0s，排除该因素。
- 定位纠正：客户端与 NAS 处于同一
/24子网，两者之间的流量为 L2 桥接（ip route get 192.168.50.88显示dev wlan0无网关、ARP 直连），流量不经过路由器 L3forward链。卸载机制与该路径无关。
3.2 误判二：代理与 L3 路由
- 验证：nftables 中
ip daddr @passwall_lan（含192.168.0.0/16）在代理重定向规则之前执行return，内网流量已正确绕行。 - 对比：Client → 路由器（INPUT）1.4ms，路由器 → NAS（OUTPUT）1.4ms，速度均正常。仅 Client → NAS（L2）异常，指向连接建立初期的特定瓶颈。
3.3 根因定位（控制变量测试）
| 测试项 | 结果 |
|---|---|
| 按 IP 访问 https://192.168.50.88 | connect 1.3ms（正常） |
| 按域名访问 https://app.int.net.example | connect 1.0s（缓慢），remote_ip=192.168.50.88 |
| 使用 –resolve 绑定 IP 绕过 DNS 访问 | connect 1.5ms（正常） |
结论：同一目标 IP 下，差异仅存在于 DNS 解析阶段。
dig @192.168.50.1 A app.int.net.example耗时 3ms（正常返回192.168.50.88）。dig @192.168.50.1 AAAA app.int.net.example超时（无响应）。- 原因：客户端解析器并发发起 A 与 AAAA 查询，因 AAAA 查询无响应而阻塞等待 ~1s 超时，随后才使用 A 记录结果进行连接。
3.4 故障根源：DNS 转发器失效
- 路由器 dnsmasq 配置：
server=/*.int.net.example/192.168.50.88，将该内网域名的解析请求转发至 NAS。 - NAS 状态：实际未运行任何 DNS 服务，转发目标失效。
- 解析差异：
- A 记录：因路由器
/etc/hosts存在静态配置，由本地直接响应，故解析迅速。 - AAAA 记录：无本地条目，请求请求投递至已失效的 NAS 转发地址，导致 1s 超时。
- 组件关联：PassWall 开启 DNS 劫持后，客户端的 53 端口请求被 DNAT 至 PassWall 的
dnsmasq_default（监听 11400 端口）。该实例继承了主 dnsmasq 的server=/*.int.net.example/192.168.50.88配置。
4. 修复方案
目标：配置解析器对 *.int.net.example 进行本地应答合成（A 记录返回 192.168.50.88，AAAA 记录返回 NODATA），停止向上游转发。
修改项（均在路由器侧操作）
| # | 目标文件 | 性质 | 修改内容 |
|---|---|---|---|
| 1 | /etc/config/dhcp | 永久配置 (UCI) | 删除 server=’/*.int.net.example/192.168.50.88’添加 address=’/int.net.example/192.168.50.88' |
| 2 | /etc/dnsmasq.conf | 静态配置 | 末尾追加 address=/int.net.example/192.168.50.88 |
| 3 | /tmp/etc/passwall/acl/default/dnsmasq.conf | 运行期生成文件 | 将 server=/*.int.net.example/192.168.50.88修改为 address=/int.net.example/192.168.50.88 |
进程生效
重启 PassWall 的 DNS 实例 dnsmasq_default。此操作仅重载 DNS 进程，不影响代理数据通路，业务无中断。
5. 验证结果
- A 记录：
app.int.net.example→192.168.50.88（正常） - AAAA 记录：即时返回
NODATA（不再超时） - 泛域名支持：任意三级子域名均正确解析至
192.168.50.88 - 实际访问表现：HTTPS 连接建立耗时（
connect）从 1.0s 降至 4–6ms。 - 常规域名回归测试：外部域名与局域网
.lan域名解析均正常。
持久化验证
重启路由器后，UCI 与静态配置文件正常保留；PassWall 生成文件正常构建为 address= 结构，且通过 conf-file 正常包含静态配置。确认修复方案具备持久性。
修复了这个bug后目前发现网络很快，同时外网冲浪也暂时没有出现断流，所以还是众多老司机的那句话，非必要不要开启ipv6,无论域名还是设备上网