JIANGXI 206 · NETWORK DIAGNOSIS REVIEW
先不判定路由器，先把变量隔离出来
现方案“逐级排查”的方向正确，但“服务器 / 1 个交换机 / 多个交换机各做 2000 人并发”仍会同时改变应用负载、网络路径和压测机负载，不能据此直接归因。
当前结论：根因未证实审查日期：2026-08-22人审状态：待确认
一页结论
路由器有嫌疑，但证据不足重启后恢复可能来自会话/NAT/ARP/队列状态被清空，也可能只是全链路短暂中断后的间接恢复。
服务器未被排除5 月非高峰资源与部分 API 样本正常，只能降低“持续性服务器资源不足”的优先级，不能替代故障窗口证据。
2000 并发不是诊断方法本身必须先定义 VU、RPS、业务步骤、思考时间、爬坡和持续时间；Apifox 当前官方上限为 100 VU。
关键缺口：现拓扑没有画路由器/防火墙、应用服务器、数据库、网关、VLAN、链路带宽和端口，所以还不能确认业务流量是否经过被怀疑的路由器。
现有证据怎么读
| 证据 | 支持 | 不支持 |
|---|---|---|
| 高延迟、无丢包、重启路由器恢复 | 优先采集路由器/网关状态 | 不能直接下路由器故障结论 |
| 5 月非高峰服务器/GreatDB 正常 | 当时无持续资源瓶颈 | 不能证明故障窗口正常 |
| 应用到数据库 32 包 RTT 平均约 0.022 ms | 当时链路短样本正常 | 未覆盖 450 到应用服务器、未覆盖故障窗口 |
| 部分 API 尾部样本约 50–280 ms | 样本未显示普遍接口超时 | 不是完整 p95/p99，不能排除局部慢请求 |
| 低人流也有累计 0 元，PC 不一定卡 | 纯高并发/全局服务器过载不是唯一解释 | 设备、业务状态、网络和数据库仍待同步取证 |
正确的测试结构
补全拓扑
网络空载/满载线
同脚本 API 线
异常先采证
单设备重启对照
分层路径
| 层级 | 路径 | 只有什么差异才可归因 |
|---|---|---|
| L0 | 服务器本机回环 API（补充基线） | L0 慢：优先查应用、数据库和本机依赖；不用于网络容量结论 |
| L1 | 独立压测机与服务器同一交换机/同一 VLAN | L0 正常、L1 异常：查 NIC、端口、直连交换机或压测机 |
| L2 | 经过 1 台接入交换机 | L1 正常、L2 异常：嫌疑集中到新增交换机和上联 |
| L3 | 经过多台交换机/最远接入点 | L2 正常、L3 异常：查汇聚拥塞、环路、广播、光链路 |
| L4 | 跨 VLAN 且明确经过路由器/防火墙 | L3 正常、L4 异常且网关指标同步异常：才支持网关方向 |
每级两条线：先用端点间 ping/fping + iperf3 看网络；再用完全相同的 API 脚本和数据看应用。只改变接入位置。
负载与采集规则
阶梯负载
50 → 100 → 200 → 500 → 1000 → 2000，每档爬坡、保压；真实峰值与 1.5 倍峰值优先。长时复现正常容量档 30–60 分钟；若必须“运行一段时间”才异常，再做 2–4 小时 soak。
生产安全不得压测真实扣款、不可逆订单和通知；使用隔离账号、幂等/只读场景、清理方案和停止开关。
同步指标
| 位置 | 必采指标 |
|---|---|
| API/压测机 | VU、RPS、p50/p95/p99/max、失败率、客户端 CPU/内存/NIC/连接数 |
| 应用服务器/数据库 | CPU、load、内存、IO、NIC、TCP 重传、Nginx/PHP-FPM、慢 SQL、锁等待、VIP/复制状态 |
| 路由器/防火墙 | 控制/数据平面 CPU、NAT/会话/conntrack、ARP、ACL/QoS、接口利用率、丢弃、错误、日志 |
| 交换机 | 速率/双工、CRC/FCS、input/output drops、队列、广播、STP、MAC move、端口 flap、光功率 |
| 终端 | 设备编号、业务步骤、请求时间、重试/缓存/网络日志、trace_id |
Word 必改项
- 合并“第一种/第二种”为一套正式方案。
- 删除 84 个空项目符号、3 个
plain占位、空标题和末尾空白页；当前文档渲染为 9 页且版面断裂。 - 删掉“ping 正常即设备无问题”“CRC 一定是物理层”“CPU 70% 判死”“强制千兆全双工”等绝对结论。
- 补齐拓扑中的路由器/防火墙、服务器、数据库、VLAN、端口和链路速率。
- 增加测试记录表：测试 ID、路径、脚本版本、VU/RPS、p95/p99、失败率、吞吐/重传、计数增量和证据路径。
- 增加单设备变更/重启记录表和停止/回滚条件。
可直接转发给周末支撑人员
@赖清涛 @侯世伟：先不要直接瞬时打 2000 并发，也不要同时重启多个设备。先补齐路由器、防火墙、服务器、数据库、VLAN 和端口拓扑；测试按“同一交换机 → 1 台接入交换机 → 多台交换机 → 明确经过路由器/防火墙”逐级进行。每级先跑 ping/iperf3 网络线，再跑同一 API 脚本，只改变接入位置；负载按 50、100、200、500、1000、2000 逐级爬坡。异常出现后先同步采集 API p95/p99、服务器/数据库、路由器会话/CPU、交换机端口丢弃/CRC/STP/MAC 变化 5–10 分钟，再只重启一个设备做同负载对照。没有同步指标和前后对照，不下路由器、交换机或服务器故障结论。
参考与边界
- Apifox 官方性能测试文档：性能测试标注 Beta，最高 100 个虚拟用户。
- iperf3 官方文档：端点间 TCP/UDP 吞吐测试。
- Cisco 路由延迟排障。
- Cisco 交换机端口与接口排障。
本次只审查用户提供的 Word、拓扑和项目既有脱敏证据；未连接现场设备、生产服务器或数据库，未执行压测或重启。最终根因仍待现场同步采证。