Network Forensics · 连接跟踪分析

路由器 nf_conntrack
连接跟踪报告

基于 Padavan 固件 /proc/net/nf_conntrack 输出,还原家庭网络拓扑、识别全部在线设备、定位网络异常。结论:整体健康,无入侵迹象,主要问题集中在 DNS/IPv6/DoH 路由不统一。

DEVICE Redmi AC2100 · Padavan 3.4.3.9
TIME 2026-05-23 21:19:36
LAN 192.168.31.0/24
WAN 192.168.1.3(双重 NAT)
OVERVIEW · 01

网络整体状态:健康

NAT 表使用率仅约 3%,路由器没有过载,没有连接风暴,没有明显木马外联迹象。

472
nf_conntrack_count
当前追踪连接数
16384
nf_conntrack_max
最大连接表容量
~3%
NAT 表使用率
472 / 16384
✓
安全状态
无连接风暴/无木马外联

NAT 表占用

当前使用
3%
警戒线
70%
最大容量
16384
结论

NAT 表只用了约 3%,路由器完全没有过载。最重要的是——没有连接风暴,没有明显木马疯狂外联。这是最重要的整体安全指标。

TOPOLOGY · 02

网络拓扑结构

双重 NAT 环境 + IPv6 直连,中国移动宽带。

INTERNET 中国移动宽带 光猫 / 上级路由 192.168.1.1 红米 AC2100 · Padavan WAN: 192.168.1.3 · LAN: 192.168.31.1 双重 NAT 管理设备 .124 DoH 异常 .73 WebRTC .197 Apple 设备 .83 IoT 设备群 .213 .84 .206 其他设备 .57 .72 .174 等 IPv6 直连(不经过 NAT) 2409:8a60:c024:364c::/64
拓扑要点

路由器 WAN 口 IP 为 192.168.1.3(所有 NAT 回复方向的 dst),说明上层还有一台光猫/路由器。双重 NAT 环境会导致 P2P、端口映射等功能受限。IPv6 不经过 NAT,设备直接获得全球单播地址(中国移动前缀)。

CRITICAL · 03

最明显的问题:192.168.31.73 的 DoH 失败

数百条 SYN_SENT 堆积,目标 1.1.1.1 和 8.8.8.8 的 443 端口全部无回应。

192.168.31.73
DoH 阻断 · SYN 堆积
反复出现的失败连接

大量 dst=1.1.1.1 dport=443 [UNREPLIED] 和 dst=8.8.8.8 dport=443 [UNREPLIED],源端口从 60200 连续编号到 60400,是典型的应用程序反复尝试建立 DoH 连接但持续被拒绝。

这不是普通网页访问失败——而是安全 DNS / DNS over HTTPS 被网络环境或代理结构阻断。

TCP 443 → 1.1.1.1 TCP 443 → 8.8.8.8 UDP 53 → 223.5.5.5 ✓ UDP 53 → 114.114.114.114 ✓
来源大概率
这个设备可能开启了 Chrome 安全 DNS、Edge 安全 DNS、Clash DNS 或 Windows DoH。SYN 发出后没有任何回应,说明这些连接在路由器或上层网络被拦截了。

实际影响

影响严重程度说明
首次打开网页慢中DoH 超时后 fallback 到普通 DNS
APP 短暂卡顿低-中某些 APP 等待 DNS 响应
SYN_SENT 堆积低占少量 NAT 表条目但不致命
功能完全中断无系统最终会 fallback 到 UDP 53(223.5.5.5 正常工作)
不严重

系统最终还是会 fallback 到普通 DNS。你这里 223.5.5.5:53 工作正常,所以日常上网不会完全中断,只是首次访问可能有几秒延迟。

IDENTIFIED · 04

192.168.31.197 的 3478 流量已确定

大量 UDP 3478 → 全球多个 IP,是标准的 WebRTC / STUN / P2P 行为。

192.168.31.197
WebRTC / STUN
全球 STUN 节点探测

固定源端口 64857 向大量公网 IP 发送 UDP 3478(STUN/TURN 协议)。目标遍布全球:

49.13.x.x · 45.159.x.x · 208.83.x.x · 172.237.x.x · 199.38.x.x 等

和你之前的使用情况高度一致:Mac mini + VSCode + 代理环境。Electron 应用(如 VSCode、Slack、Discord)内置的 WebRTC 会自动探测 STUN 节点。

UDP 3478 · STUN/TURN UDP 5351 · NAT-PMP UDP 123 · NTP UDP 1900 · SSDP
不像恶意流量的原因

特征非常标准:都是 UDP 3478、会话时间短、数量不夸张、没有高上传、没有异常扫描。更像是 Electron / VSCode / WebRTC / 实时连接框架的正常行为。

IPv6 · 05

IPv6 状态:正常工作,但有"半残"迹象

有时通,有时失败——国内宽带非常典型的 IPv6 问题。

✓ 正常工作的证据
AAAA? assets.msn.com 成功返回 2600:140b...
多台设备成功通过 IPv6 访问 Google、Facebook、Microsoft 等
IPv6 DNS(2400:3200::1 阿里 DNS)正常解析
✗ 问题迹象
反复出现 IPv6 SYN_SENT [UNREPLIED]
例如 dst=2001:4860...(Google IPv6)连接超时
部分 IPv6 连接建立失败,fallback 到 IPv4
实际影响
会导致某些网页首次慢、某些 APP 延迟。本质是 IPv6 优先后尝试失败再 fallback IPv4,多了一轮超时。这是国内宽带 + 代理 + Hyper-V 混合环境下的典型问题。
DNS · 06

DNS 结构已完全暴露

核心结论

真正的问题不是 DNS 完全坏了,而是"额外的 DoH 尝试失败"叠加在正常 DNS 之上。基础 DNS 工作正常。

223.5.5.5
主 DNS(阿里)
正常工作 ✓
114.114.114.114
备用 DNS(114)
正常工作 ✓
2400:3200::1
IPv6 DNS(阿里)
正常工作 ✓
1.1.1.1 / 8.8.8.8
DoH 尝试
全部 UNREPLIED ✗
SERVICES · 07

其他识别出的服务与设备

clerk.openrouter.ai
DNS 查询
有设备正在访问 OpenRouter
clerk.openrouter.ai 是 OpenRouter 的登录认证 / Web 前端相关域名。说明某设备正在使用或访问 OpenRouter 平台。
TCP 1883 / UDP 1883
MQTT 协议
MQTT 物联网通信
1883 是标准 MQTT 端口,常见于智能家居设备、IoT 传感器、设备云平台。多个设备使用此端口,说明家中有活跃的物联网设备群。
TCP 1883 · MQTT TCP 7883 · MQTT TLS
TCP 5222 / 5223
即时通信
即时通信长连接
5222 是 XMPP 标准端口,5223 是 Apple Push Notification 端口。这些是手机推送和即时通讯的正常长连接。
TCP 5222 · XMPP TCP 5223 · Apple Push
Realtek loopback
正常
Realtek 网卡广播检测包
realtek_loopback_detect_packet 是 Realtek 网卡驱动发出的环回检测广播包,用于检测网络环路。不是异常,几乎所有 Realtek 网卡都会发。
DEVICES · 08

全部在线设备一览

IP 推断类型 关键特征 状态
192.168.31.124 管理员设备 SSH 路由器 + 访问管理页 + 外网 HTTPS ✓ 正常
192.168.31.73 DoH 异常设备 大量 SYN_SENT → 1.1.1.1/8.8.8.8:443 ⚠ 需修复
192.168.31.197 WebRTC 设备 大量 UDP 3478 + NAT-PMP + NTP ● 正常(视频/VSCode)
192.168.31.83 Apple 设备 Apple Push 5223 + iCloud 443 + QUIC ✓ 正常
192.168.31.213 IoT 网关 MQTT 1883 + MQTT TLS 7883 ● 正常(注意安全)
192.168.31.84 IoT 设备 MQTT + NTP + UDP 8000/7885 ● 正常(注意安全)
192.168.31.206 IM / 推送设备 XMPP 5222 + 5260 + 8080 ✓ 正常
192.168.31.127 IM 设备 8080 + XMPP 5222(与 .206 相似) ✓ 正常
192.168.31.57 P2P / 游戏加速器 UDP 打洞(同一源端口 → 多 IP 多端口) ⚠ 需确认
192.168.31.72 常规设备 443 + UDP 53 + 与 .73 相似流量 ✓ 正常
192.168.31.174 网页浏览设备 大量 HTTP 80 到 CDN/广告服务器 ✓ 正常
192.168.31.19 常规设备 443 + DNS ✓ 正常
192.168.31.204 WebRTC + 浏览 UDP 3478 + HTTP 80 + 443 ✓ 正常
192.168.31.16 电视盒子 / APP 8080 + 443 ✓ 正常
VERDICT · 09

核心结论:只有一个真实问题

最终判断
你现在真正的问题其实只有 DNS / IPv6 / DoH 路由不统一。不是被入侵,不是木马,不是网络攻击。整体网络健康,NAT 表仅用 3%,所有设备行为可解释。
安全状态

没有入侵迹象。没有异常扫描、没有连接风暴、没有可疑的反向 Shell 连接、没有加密隧道到未知 IP。所有连接都有合理的业务解释。

RECOMMENDATIONS · 10

最建议优化的四个点

1
关闭浏览器安全 DNS
尤其是 Chrome 和 Edge 的"使用安全 DNS"选项。这是 .73 设备大量 SYN_SENT 堆积的直接原因。关闭后,浏览器会直接使用系统 DNS(223.5.5.5),连接立即恢复。
2
代理统一 DNS
不要让浏览器 DoH、系统 DNS、Clash DNS、VM DNS 同时存在。选择一个 DNS 策略统一使用,避免"多层 DNS 冲突"导致的延迟和 SYN 堆积。
3
Hyper-V 用 Default Switch NAT
不要桥接。桥接模式会导致额外的 IPv6 地址和路由冲突,加剧"半残 IPv6"问题。使用 Default Switch 的 NAT 模式更稳定。
4
如果仍卡顿:临时禁用 IPv6 测试
你明显存在 IPv6 半通状态——有时通有时失败,每次失败都多等一轮超时。临时禁用 IPv6 可以立即排除这个变量,确认卡顿是否由此引起。
一句话总结
网络安全无问题,网络健康无过载。唯一的性能瓶颈来自 DNS/IPv6/DoH 三层路由策略不统一——关掉浏览器安全 DNS + 统一 DNS 策略 + 禁用 IPv6 测试,大概率能解决你感知到的所有"卡顿"。