异常带宽占用排查：从网络链路追踪到具体进程
用 PRTG、Zabbix、NetFlow、FortiView、Wireshark 和 Resource Monitor 排查异常流量，并结合环路、备份、更新和应用日志定位原因。
网络变慢，第一反应往往是升级带宽。 但原因也可能是计划外备份、云同步、内部环路或重复传输。购买更大容量之前，应先确认压力从哪里开始、流向哪里、由什么活动产生。
本文沿着从网络全景到单个进程的路径展开。操作步骤与判断标准属于编辑建议；工具能力及限制已对照原始文档。文中的案例并不表示曾在读者的实际网络上进行过测试。
先定义什么叫异常
流量高不一定异常。预期内的备份高峰，与空闲时段持续向外发送数据并不是一回事。记录开始时间、持续时长、方向、受影响范围及用户感受。应与相近日期和时段比较，而不只是与故障前的几分钟低流量比较。
区分速率与传输总量。Mbps 是速率，GB 是容量。在十进制单位中，1 MB/s 等于 8 Mbps。业务链路的有效容量也可能低于端口协商速率。对于全双工链路，应分别将各方向流量与该方向容量比较；直接相加入站和出站流量，不能证明某个方向已饱和。
根据问题选择工具
| 问题 | 主要工具 | 需要保留的证据 |
|---|---|---|
| 哪条链路，何时发生？ | PRTG / Zabbix | 速率历史、错误和丢弃 |
| 哪个设备连接哪里？ | NetFlow / IPFIX | 源、目的地、方向与总量 |
| 哪条策略或哪个应用？ | FortiView | 实际经过防火墙的流量 |
| 传输中发生了什么？ | Wireshark | 会话、速率与重传线索 |
| 哪个 Windows 进程？ | Resource Monitor | PID 与发送、接收速率 |
1. 使用 PRTG 或 Zabbix 监控接口
从 WAN、分支链路、上联及与受影响服务相关的接口开始。入站和出站是相对于该接口而言。PRTG 可从 SNMP Traffic 传感器入手；Zabbix 应使用适合设备的模板，并检查监控项输出单位。
若监控项返回原始累计 Octet 计数器，需要用计数器随时间的变化计算速率。在 Zabbix 中，可使用 Change per second 并进行适当的单位转换。若模板已经输出 bit/s，不应再次执行同一转换。原始计数器的关系式如下：
bit/s = (counter_now - counter_previous) * 8 / elapsed_seconds
设备支持时应使用 64-bit 计数器。过长的轮询周期可能把短暂突发隐藏在平均值里；过短的周期也会增加监控开销。我们的建议是同时保留各方向速率、错误、丢弃与包速率。给所有链路使用同一阈值，不能替代各自的基线。
PRTG / SNMP · Zabbix / SNMP · Zabbix / Preprocessing
2. 使用 NetFlow 查找高流量设备与目的地
接口图表能指出哪里拥挤，却通常不能直接指出使用者。如果设备支持，可从相关观察点向兼容收集器导出 NetFlow 或 IPFIX。在故障时段内，按 Bytes 排序源和目的地，再检查方向。仅凭会话数或包数不能衡量传输总量。
记录导出设备、观察接口、NAT 前后位置、采样方式及收集器时间。使用采样时，收集器设置应与导出端一致，结果也应按估算值理解。在多个位置观察到同一流，并不意味着数据被多次生成；直接累加所有观察结果可能重复计数。
我们的实用建议是将头部使用者与设备负责人、DHCP/IPAM 记录和服务角色关联。一个公网 NAT 地址或代理可能代表多个用户。流记录通常不提供解密后的请求内容；要归因到具体业务活动，还需要应用或终端证据。
Cisco / NetFlow · IPFIX · PRTG / Sampling
3. 使用 FortiView 检查经过 FortiGate 的流量
在 FortiView 中先选择正确的时间范围、设备或 VDOM，以及相关流量路径。在版本与功能支持范围内，沿来源、目的地、应用和策略逐层查看。按 Bytes 排序回答的是总量问题，按 Bandwidth 排序回答的是速率问题。
看到空图表时，先检查日志覆盖范围及数据来源。历史视图依赖实际保留的日志及存储位置；没有记录不等于没有流量。没有经过该防火墙的流量，也不在其视野内。应用分类的可信程度需要结合工具实际可见性判断。
应用名称或目的地国家本身，不足以成为封禁理由。我们的建议是从高流量源追踪到策略、目的地及服务负责人，再评估限制是否影响必要业务。FortiOS 各版本菜单可能不同；本节不是修改生产防火墙配置的指令。
FortiView / Monitors · FortiView / Logging · FortiOS / Log settings
4. 使用 Wireshark 分析传输行为
设备和路径已明确、原因仍不清楚时，可进行短时且范围受限的抓包。抓包点必须真正看得到目标流量。在交换式以太网中，普通电脑开启混杂模式，并不能看到其他主机的所有单播流量。应使用合适的观察位置或经授权的 SPAN、TAP。以下捕获过滤器使用文档示例地址：
host 192.0.2.25
将示例地址替换为经授权的终端地址。在 Statistics 中按 Bytes 和方向查看 Conversations，再用 I/O Graphs 比较相同时段的速率。以 1 秒为间隔查看 Bits，有助于理解速率。下面两行是各自独立的显示过滤器，并非前面的捕获过滤器：
ip.addr == 192.0.2.25
tcp.analysis.retransmission
抓到的字节不一定等于应用有效载荷，也不一定等于 WAN 计数器。抓包丢失、SPAN 重复流量及观察位置都可能影响判断；单独出现重传标记，不能证明路径故障。查看流量大小及模式，通常无需解密 TLS 内容。抓包应限制范围、时长和访问权限。
Wireshark / Capture · Conversations · I/O Graphs · Display filters · TCP analysis · Switched Ethernet
5. 使用 Resource Monitor 定位 Windows 进程
如果源是 Windows 主机，打开 Resource Monitor 并进入 Network。按 Total、Send 或 Receive 排序具有网络活动的进程，再选中进程查看相关目的地。B/sec 是字节速率，不能直接与链路的 Mbps 数值比较。
记录进程名称、PID、观察时间及目的地。以下 PowerShell 示例用于把一个示例 PID 与当前 TCP 连接关联；需要替换 4321。它不会测量各进程带宽，也不是全部 UDP 流量清单：
$trafficProcessId = 4321
Get-Process -Id $trafficProcessId
Get-NetTCPConnection -OwningProcess $trafficProcessId |
Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State
Resource Monitor 描述的是这台主机，并非整个组织的互联网使用情况；其中也可能包括本地 LAN 流量。TCPView 可补充终端与所属进程信息。结束进程前，应先确认服务及其工作内容。仅有 System 或 svchost 这样的名称，不能证明恶意软件，也不能作为终止依据。
Microsoft / Resource Monitor · Microsoft / TCPView · Get-NetTCPConnection
6. 将网络环路和广播问题与下载区分开
如果 LAN 严重受影响，但 WAN 使用量与症状不匹配，应检查二层网络。结合拓扑，比较相关端口的入站包速率、广播及组播情况。内部流量可能根本不会到达互联网防火墙。
拓扑变化日志和 MAC 移动只是线索，不能证明环路起点。我们的建议是沿异常入站速率追踪，并检查近期物理连接。不要随意拔掉不熟悉的上联；只对已确认的网段采取限制，并准备回退方案。
7. 将流量与备份、更新任务关联
将流量开始时间与备份、复制、云同步、软件分发及 Windows Update 对照。即使传输经过授权，不合适的时间安排或带宽分配仍可能拖累主要服务。
对于 Delivery Optimization，可使用 Windows 自身的报告及诊断工具；仅凭共享服务名称不能确认具体活动。我们的建议是与负责人确认任务，再测试仅针对该任务的时段或速率调整，而不是永久关闭备份和安全更新。
Microsoft / Delivery Optimization
8. 将应用日志接入网络证据链
如果 Web 服务或 API 排在高流量列表前列，应在访问日志或应用日志中比较请求时间、路径、状态及响应大小。在 NGINX 中，$body_bytes_sent 等变量涉及响应正文大小；请求数量本身无法解释字节消耗。
我们的建议是只收集必要元数据，并查找重复下载、持续重试或超出预期的大响应。没有考虑压缩及测量位置时，应用层大小不能直接等同于链路流量。在认定遭受攻击前，应将服务负责人提供的证据、实际请求模式与流数据相互验证。
NGINX / Access logs · NGINX / Variables
假设案例：下载尚可，通话却不断受影响
假设业务链路为 100 Mbps，出站流量接近 90 Mbps，通话质量下降，但下载仍然可以接受。先检查出站方向及其容量；端口协商速率更高，并不会消除业务带宽限制。
在这个教学案例中，流数据将示例主机 192.0.2.25 排在前列。FortiView 在相同时段确认对应流量。终端上的备份进程与任务日志也与故障时间一致。经负责人同意，临时降低该任务传输速率，再测试通话及出站图表。改善是有用证据，但形成可靠结论前，仍应检查可重复性及其他同时运行的活动。
故障期间的建议流程
- 记录时间、时区、受影响范围及衡量用户影响的指标。
- 利用速率、基线及错误定位拥挤接口和方向。
- 在相同时段内追踪流记录与防火墙记录，并找到设备负责人。
- 必要时收集终端证据或受限抓包，再实施可回退的变更。
- 验证真实用户操作与图表是否恢复，并明确原因负责人及预防措施。
结论：流量最大不等于就是故障源
我们的建议不是追逐最大的数字，而是建立接口、设备、目的地、进程和实际活动之间的证据链。这样才能区分合法但时间安排不当的任务、意外传输、网络故障及可疑行为。
