带宽占用居高不下，如何结合流量监控与连接记录排查香港服务器？

监控面板上的带宽曲线持续贴近上限，网站却没有明显增加访问量；下载变慢、接口偶尔超时，服务器CPU和内存又看不出异常。遇到这类香港服务器故障，不能仅凭“连接很多”就判断遭到攻击，也不宜直接重启服务。正常的大文件传输、CDN集中回源、任务同步、客户端重试，以及异常连接，都可能表现为带宽居高不下。

排查的核心，是把机房侧流量、服务器网卡计数、连接记录、进程、访问日志和业务链路放到同一时间窗口中，逐层回答：流量在哪个方向产生，经过哪个接口，属于什么连接和进程，最终对应哪类业务。先用只读检查缩小范围，再选择止损措施，才能避免把正常业务一起切断。

一、确认现象：占满的是哪条链路、哪个方向

固定排查窗口，不把不同时间的数据直接比较

开始排查时，先记录异常出现的时间、持续长度，以及此前发生过的变更。发布、备份、资源刷新、CDN缓存调整和定时任务，都应加入同一条时间线。

建议先取异常期间的5至15分钟，再选择一个相近业务时段作为对照。这个窗口既要覆盖带宽升高，也要覆盖用户超时或下载变慢的时刻。

香港服务器面对不同地区用户时，日志时区可能与监控面板不同。Linux主机可以先进行只读核验：

date -Is
date -u -Is
timedatectl status

预期是系统时间准确，并且时间同步状态正常。若时间存在偏差，应先记录偏移量用于对齐；不要在业务运行期间未经评估就突然调整时钟，以免影响证书校验、任务调度和日志排序。

还要确认：流量图上的时间点表示区间起点、终点，还是一个区间的平均值。主机上的瞬时峰值，不能直接与服务商的五分钟平均值比较。

区分Mbps、MB/s和统计范围

带宽利用率应按实际限速值计算，而不是按虚拟网卡显示的链路速率计算。 网卡显示10Gbps，并不代表实例拥有10Gbps公网带宽。公网限速、独享或共享方式、是否有单独的入口限制，应以实例交付信息和服务商统计口径为准。

方向也要分别确认：通常服务器接收为入站、发送为出站，但服务商端口图可能按交换机视角标注方向。

以下按十进制单位换算：

• 100Mbps相当于12.5MB/s。
• 10分钟发送6GB，平均速率为：6 × 8 × 1000 ÷ 600 = 80Mbps。
• 若实际出口上限为100Mbps，则上述平均出口利用率约为80%。

文件大小和监控工具可能使用MiB、GiB等二进制单位，不能直接套用同一组数值。还要注意，公网IP流量、整张网卡流量和容器内部流量不一定是同一统计范围。

二、由外到内：先查入口与网卡，再查主机协议栈

服务商侧与主机侧是否同时升高

先查看实例或对应公网IP的入口、出口曲线，再到服务器确认网卡计数。

以下命令适用于具备iproute2的Linux环境，不修改网络配置：

ip -br addr
ip route show default
ip -s link show dev eth0

eth0只是示例，应替换为承载该业务流量的实际接口。默认路由接口通常是排查入口，但多网卡、策略路由、容器和隧道封装环境需要结合地址与路由判断。

间隔30秒再执行一次ip -s link，计算同一接口的差值：

平均出口Mbps = TX字节增量 × 8 ÷ 30 ÷ 1,000,000。

例如TX增加337,500,000字节，平均出口就是90Mbps。RX按相同方法计算入口速率。如果计数下降，应检查网卡是否重建、主机是否重启，不能继续按普通增量计算。

不同结果对应不同分支：

• 服务商和主机同方向升高：流量确实经过该接口，继续查连接与进程。
• 服务商入口高，主机接收较低：核对是否存在上游清洗、丢弃、限速，或面板统计包含其他对象。
• 主机流量高，公网图较低：检查是否统计了内网、容器、存储复制等流量，或两边采样窗口不同。
• 网卡丢包计数同步增加：存在队列或接收处理压力，但这些计数不能单独定位公网拥塞位置。

服务器位于香港，并不意味着所有用户共享同一条访问路径。若只有某个地区访问异常，而出口并未持续接近上限，应另查对应运营商路径和往返时延。反过来，如果多个地区同时变慢，且出口贴近限制，出口拥塞的解释更有支持。

同时观察字节速率与包速率

已安装sysstat时，可以短时查看：

sar -n DEV 1 10
sar -n TCP,ETCP 1 10

第一条用于观察接口收发、包速率；第二条用于观察TCP连接活动和重传变化。字段与单位以当前版本输出为准。若命令不可用，不必为了排障立即变更软件环境，网卡计数差值仍然可用。

判断时不能只盯着Mbps：

• 字节速率很高、包速率相对平稳，常见于下载、备份或批量响应。
• 字节速率未满，但包速率和新建连接持续升高，可能是大量小请求或异常探测。
• 重传显著增加，业务有效吞吐下降，说明部分容量消耗在重复传输上。

重传不是“服务器性能差”的直接证据。它也可能来自路径丢包、出口排队、对端接收不及时。需要结合网卡、业务延迟和不同访问路径继续判断。

三、从连接定位到进程：数量不等于流量

先看连接状态，再看主要业务端口

以下命令同样适用于具备iproute2的Linux。查看其他用户的进程信息通常需要相应权限：

ss -s
ss -Htn state established
ss -tinp state established
ss -Htn state syn-recv
ss -unp

每条命令的用途不同：

• ss -s查看连接整体状态，适合发现状态分布变化。
• ss -Htn state established列出已建立的TCP连接。
• ss -tinp state established补充进程及TCP内部信息。
• ss -Htn state syn-recv观察尚未完成握手的连接。
• ss -unp查看UDP套接字及所属进程。

ss是连接快照，不是流量排行榜。几千条空闲长连接可能流量很低，几条持续下载连接却可能占满出口。UDP套接字也不一定列出全部通信对端，因此不能只靠这组结果判断UDP流量来源。

对于已建立的TCP连接，可以关注以下信号：

部分内核和工具版本会显示bytes_sent、bytes_acked等TCP字段。连续采样同一连接时，其增量比单次累计值更有意义。字段缺失不代表没有流量，也不能把Send-Q直接换算成Mbps。

如果安装了iftop或nethogs，可以短时观察接口上的通信对或进程流量；但它们的统计方式、权限和容器可见性不同，应把结果当作定位线索，而不是最终计费依据。

不要把远端IP直接等同于最终访问者

香港服务器可能接收CDN回源、负载均衡转发或经过地址转换的请求。此时，连接记录中的远端地址通常是中间节点。

因此，“某个IP连接多”至少需要核对三件事：

1. 该地址是否属于已配置的CDN、负载均衡或内部服务。
2. 多条连接是否对应正常回源、长连接或多个用户复用。
3. 应用日志中的客户端地址是否来自可信入口。

不能直接相信任意请求携带的转发头。只有对可信入口配置了地址还原规则，日志中的真实客户端地址才适合用于访问分析和访问控制。

确认进程后，可继续只读检查：

ps -fp 12345
readlink -f /proc/12345/exe

将示例PID替换为实际值。查看可执行文件、启动参数及所属服务，核对它是否是预期程序。输出可能包含令牌、数据库地址等敏感信息，不应原样公开。

对于容器服务，主机PID、容器内部PID和网络命名空间可能不同；对于主机内核代转发的流量，也未必存在可直接对应的用户态进程。不要因为工具没有显示进程，就直接认定流量异常。

四、把访问日志、链路与业务现象接到同一时间线上

用响应字节解释带宽，而不只统计请求数

“请求量没有明显增加”并不能排除正常业务占满带宽。每个请求返回的内容变大，同样会造成出口增长。

分析访问日志时，应同时聚合：

• 每分钟请求数与响应体字节总量；
• 路径、来源、状态码及平均响应大小；
• 请求耗时、上游耗时和客户端中断情况；
• 大文件下载、分段请求、缓存未命中和重试行为。

连接回答“谁与服务器通信”，日志回答“通信在做什么”；两者要在同一窗口内交叉验证。

以Nginx为例，$body_bytes_sent记录响应体字节，不包含响应头、TLS开销和TCP重传。它适合解释应用层出口，但不应与网卡发送字节要求完全相等。长请求通常结束后才写访问日志，持续下载中的流量可能暂时没有出现在日志汇总里。

现有日志字段不足时，可考虑临时增加观测日志。以下片段适用于支持相应变量的Nginx，必须放在http上下文；escape=json要求Nginx 1.11.8及以上：

log_format bandwidth_json escape=json
    '{"ts":"$time_iso8601",'
    '"request_id":"$request_id",'
    '"peer":"$remote_addr",'
    '"method":"$request_method",'
    '"uri":"$uri",'
    '"status":$status,'
    '"body_bytes":$body_bytes_sent,'
    '"request_time":$request_time,'
    '"upstream_time":"$upstream_response_time"}';

access_log /var/log/nginx/bandwidth_access.log bandwidth_json;

这里使用$uri，避免直接记录查询参数，但路径仍可能包含敏感信息。新增日志也会增加磁盘写入，应确认日志目录存在、空间充足，并限制保留周期。高请求量环境下应先评估日志开销。

修改前核验版本，并备份实际需要修改的文件。下面只适用于已确认编辑文件为/etc/nginx/nginx.conf、服务由systemd管理的环境：

nginx -v
conf=/etc/nginx/nginx.conf
backup="/root/nginx.conf.before-$(date -u +%Y%m%dT%H%M%SZ)"
cp -a "$conf" "$backup"

编辑完成后，先测试再重载：

nginx -t && systemctl reload nginx

测试失败时不要重载，应按报错修正。若新增日志引起异常，可在同一Shell会话中恢复备份：

cp -a "$backup" "$conf"
nginx -t && systemctl reload nginx

如果修改的是站点配置，则应备份和恢复那个文件，而不是照搬上述路径。重载通常不强制中断已有连接，但配置会影响后续请求；应在低峰或受控窗口操作，并检查服务状态与错误日志。

用时间线判断因果，不只看曲线相似

下面是一组用于说明方法的示例数据，不代表读者环境的实测结果：

按十进制计算，80次/秒 × 140,000字节 × 8 ÷ 1,000,000，约为89.6Mbps的响应体流量。计入协议开销及其他业务后，这与接近95Mbps的出口有较好的量级对应。

此时，连接数量只小幅增加，响应大小却明显增大，“新资源变大或集中下载”的解释比“连接暴增”更合理。进一步查看发布记录、资源版本和缓存命中情况，就能缩小范围。

若已有分布式追踪，可用可信的关联标识连接入口请求、应用处理和下游调用。单独记录一个Nginx请求ID，并不会自动形成完整调用链。

重点观察异常的先后顺序：

• 缓存未命中先增加，出口随后升高：优先查CDN缓存、刷新任务和回源策略。
• 下游超时先出现，出站请求随后增加：优先查重试次数、并发和退避机制。
• 出口先贴顶，随后RTT和错误率上升：拥塞更可能是错误增加的原因。
• 业务响应减少，但主机发送字节仍很高：继续查非Web进程、持续下载、重传或其他端口。

曲线同步只能说明相关性。还应确认该业务具备产生对应流量的机制，并在受控调整后观察结果。

五、根据结果分支止损，避免“一封了之”

分支一：正常业务确实需要大量带宽

若响应字节、进程流量与网卡增量基本对应，应优先处理容量和业务节奏，而不是封禁连接。

大文件可评估缓存分发、分时同步、断点续传，以及针对下载业务的并发或速率限制；备份和同步任务可调整运行时段。涉及跨地域数据传输时，还需核对数据访问权限与处理要求。

限制应只覆盖目标任务或路径。对整个网卡限速，可能同时伤及健康检查、管理连接和正常接口。

验证时不仅看带宽下降，还要看任务是否按期完成、下载是否明显变慢、队列是否持续积压。若只是把任务无限延后，故障并没有真正解决。

若任务不能继续错峰，且正常业务的持续出口需求已超出现有额度，就需要评估更合适的带宽套餐。A5数据的香港大带宽分类列有20至100Mbps、40至100Mbps等CN2选择范围，可用已测得的持续流量和峰值需求初筛容量是否匹配。这些范围不代表每款产品均提供100Mbps，实际带宽及可选升级项应以对应产品页和下单确认结果为准。

分支二：CDN回源或客户端重试放大流量

远端连接集中到CDN节点，并不自动意味着异常。应结合缓存命中率、刷新记录、资源版本和回源请求路径判断。

如果属于重试放大，处理重点是限制重试次数、控制并发、增加退避，并核对操作是否允许安全重试。如果属于资源缓存失效，应调整符合业务要求的缓存策略，而不是把含用户私有数据的响应直接改成长时间公共缓存。

每次只修改一类策略，保留原配置和生效时间。验证要同时查看回源字节、错误率、内容正确性和用户体验，不能只看出口曲线。

分支三：异常访问、扫描或攻击流量

异常访问可能表现为请求集中、路径重复、错误率升高；网络层异常则可能表现为高包速率、握手未完成、入口异常，但应用日志增长有限。

此时应先保留时间窗口、来源和目标端口等证据，再结合服务商边界能力或现有安全控制止损。源站规则无法消除已经占满上游线路的流量，不能把主机防火墙当作所有带宽攻击的解决方案。

必须调整防火墙或访问规则时，应备份现有规则，确认管理入口、健康检查和可信回源地址，使用最小范围、带有效期的规则，并准备撤销方式。共享出口地址可能承载多个正常用户，按单个IP粗暴封禁容易误伤。

分支四：非预期进程或可疑主机行为

若持续流量来自非预期程序，应先保存进程信息、连接记录、任务配置和相关日志，再评估隔离。不要立即删除文件，否则可能破坏调查线索。

终止进程、禁用任务或隔离主机都会影响业务，必须明确负责人、依赖关系和恢复方案。涉及凭据泄露时，应从可信环境轮换相关凭据，并评估是否需要从已验证镜像重建。

若连接与日志仍不足以解释流量，才考虑短时、限量抓包。抓包需限制接口、端口、持续时间、包数和保存权限；HTTPS内容通常不可直接读取，但仍可观察通信对象、包长和重传。捕获文件可能包含敏感信息，应按安全要求保存和处置。

六、修复后复测：证明问题消失，而不是暂时看不见

任何限流、缓存、任务或网络调整完成后，都应使用与故障期间相同的接口、统计口径和时间窗口复测。

验收至少覆盖以下几组信号：

1. 流量：入口、出口及包速率是否回到预期范围，服务商与主机计数是否能合理对应。
2. 连接：目标连接是否减少，发送队列、RTT和重传是否改善。
3. 业务：错误率、响应时间、下载完成率和任务积压是否恢复。
4. 副作用：是否误伤正常用户、CDN回源、管理入口或后台任务。

第一次复测可观察15至30分钟，但还应覆盖下一次业务高峰或任务周期。定时同步引起的问题，仅观察任务结束后的低流量阶段并不能证明修复有效。

持续监控时，带宽告警应结合套餐上限和正常峰值设置。对于100Mbps出口，可将“持续接近上限”与响应耗时、错误率或重传共同作为升级条件；具体阈值需要根据业务基线调整，不能把某个固定百分比当成所有实例的标准。

最后保留一条可复查的故障时间线：何时出现带宽升高，哪些连接和业务贡献了流量，采取了什么修改，修改后哪些指标恢复。这样下一次香港服务器带宽再次居高不下时，就能从已有基线快速判断变化，而不是重新从“连接很多”开始猜测。