带宽体验波动如何定位？从海外服务器流量、丢包与连接日志关联时间线

遇到海外服务器下载速度忽高忽低、接口延迟上升或用户请求偶发超时，不要先根据一次测速结果判断是共享带宽还是独享带宽的问题。先把故障时间、服务器流量、丢包与重传、TCP 连接状态、应用请求耗时放到同一条时间线上，才能判断是带宽容量不足、共享资源波动、网络路径异常，还是应用本身处理变慢。

“海外服务器的 100M 共享带宽和 20M 独享带宽，哪个实际体验更好？”没有脱离业务负载和链路状态的固定答案：如果业务峰值长期不超过 20Mbps，且服务商所称的“独享”确实对应明确的带宽资源保障，20M 独享通常更容易获得可预测的吞吐和排队表现；如果业务存在突发下载或响应流量，可能超过 20Mbps，100M 共享在资源充足时可能更快，但必须用多个时段的流量、丢包、重传和连接日志验证其实际可用性。

排查顺序建议固定为：

1. 确认实际流量是否接近带宽上限；
2. 检查接口丢弃、网络丢包和 TCP 重传；
3. 检查连接建立、发送队列和超时；
4. 将应用请求耗时与前三类数据按时间对齐；
5. 修复后使用相同测试条件复测，并保留回滚路径。

先统一带宽口径和日志字段

套餐中的“100M”和“20M”通常表示 Mbps，不等同于 MB/s。若带宽单位确实是 Mbps，理论十进制换算约为：

• 100Mbps ≈ 12.5MB/s；
• 20Mbps ≈ 2.5MB/s。

这只是链路速率换算，不代表业务一定能达到该速度。实际吞吐还会受到请求并发、数据包重传、连接建立耗时、客户端接入条件、服务端应用处理时间以及共享资源使用情况影响。

排查时至少记录以下字段：

需要区分“并发连接数”和“每秒请求数”。并发连接数表示某一时刻同时存在的连接数量，不能直接替代每秒请求数；每秒请求数需要根据请求日志中的时间戳和请求数量计算。连接数增加但请求数不增加，可能是长连接或连接未释放；请求数增加但带宽未接近上限，则应继续检查应用处理能力。

例如，出站流量持续接近上限，同时 Send-Q 增长、请求耗时上升，才更像发送方向容量不足或排队。若流量并不高，但 TCP 重传和连接超时在同一时间段增加，则不能简单归因于“带宽不够”。

准备统一时间、节点和测试边界

日志关联最容易出错的地方是时间不一致。服务器监控、服务日志、客户端测试和服务商控制台必须使用同一时区，并明确记录正常时段和故障时段。

在 Linux 服务器上先执行以下只读检查：

date -Ins
timedatectl status
ip -br link
ip -s link

timedatectl 适用于使用 systemd 的 Linux 系统。如果系统没有该命令，以 date -Ins 输出为准，并在记录中标注时区。

同时准备：

• 故障起止时间，最好精确到秒；
• 业务访问的目标 IP 或域名；
• 测试发起节点及其网络环境；
• 服务器对应的网络接口；
• 服务商监控中的入站、出站方向；
• 正常时段的对照数据；
• 测试文件、请求方法和并发方式。

故障时段和正常时段必须使用相同的测试节点、目标地址、文件大小、请求方式和并发设置。一次测速只能反映该测试节点、该时间点和该请求过程的结果，不能单独代表套餐的长期能力。若测试节点、时间或文件发生变化，结果差异可能来自测试条件，而不是带宽方案。

第一步：确认流量是否触及带宽上限

先查看服务商流量监控，再检查服务器接口计数器。服务商控制台重点观察入站和出站方向、时间粒度、峰值持续时间，以及是否有明确的限速或突发流量标记。服务器本地则关注接口字节数、错误和丢弃包。

将实际业务目标 IP 写入变量后执行：

TARGET_IP="业务目标IP"
IF=$(ip route get "$TARGET_IP" | awk '{for (i=1; i<=NF; i++) if ($i=="dev") {print $(i+1); exit}}')

printf 'interface=%s\n' "$IF"
ip route get "$TARGET_IP"
ip -s link show dev "$IF"

ip route get 用于确认访问该目标时实际采用的路由和接口。如果无法得到路由，应先确认目标地址、默认路由和服务器出站路径，不要直接把问题归因于带宽。

ip -s link 中的 RX 和 TX 是累计统计，不能只看一次输出。dropped、errors、overrun 等字段需要记录起始值和结束值，再计算增量。

需要连续采样时，可使用通常由 sysstat 提供的 sar：

sar -n DEV 1 10

如果系统没有 sar，可以间隔记录两次接口计数器：

cat /proc/net/dev
sleep 10
cat /proc/net/dev

速率计算方式为：

速率 Mbps =（结束字节数 - 开始字节数）× 8 ÷ 时间秒数 ÷ 1,000,000

结果可按以下方式解释：

• 出站流量长期接近当前方案上限，Send-Q 同步增加，请求耗时也上升：优先判断为发送方向容量不足或排队。对于 20M 独享，需要确认业务峰值是否已经超过 20Mbps；对于 100M 共享，需要在多个时段对比，判断高峰时是否出现可用速率下降。
• 流量明显低于上限，但接口 errors 或 dropped 增长：这不是普通的带宽打满现象，应继续检查虚拟网络接口、服务商侧实例监控，以及同一时间段的丢包和重传。
• 流量先达到峰值，随后请求耗时上升，但丢包没有明显变化：更接近容量或发送排队问题，应区分是业务突发超过 20Mbps，还是 100M 共享在该时段没有提供稳定的可用速率。
• 流量较低、接口计数器正常，但业务仍卡顿：带宽不是当前首要嫌疑，应进入丢包、TCP 连接和应用日志检查。

不要通过盲目提高队列或修改内核参数掩盖接口错误。先保留原始计数器、服务商监控截图或导出数据，再进行后续处理。

第二步：把丢包和重传放到同一时间线

针对实际业务目标进行连通性测试。以下命令适用于常见 Linux iputils 和 mtr 环境：

ping -n -c 20 -i 0.2 -W 2 "$TARGET_IP"

如果系统已安装 mtr，可以进一步观察路径统计：

mtr -rwzc 50 -i 0.2 "$TARGET_IP"

这些测试应分别在正常时段和故障时段执行，并记录测试发起节点、目标地址、开始时间和结束时间。ping 使用 ICMP，ICMP 可能被限速或过滤，因此不能仅凭 ICMP 丢包断定 TCP 业务一定丢包。mtr 中某个中间节点显示丢包，而后续节点和最终目标正常时，也不能直接认定该中间节点是故障点。

服务器上可查看 TCP 统计：

nstat -az | egrep 'TcpRetransSegs|TCPTimeouts|ListenOverflows|ListenDrops'

不同 Linux 版本支持的统计字段可能不同。某个字段不存在时应记录为“不支持”，不要用零替代。重点是比较正常时段和故障时段的增量，而不是把某个累计值直接当作故障期间的数量。

必要时，可在短时间内抓取连接控制报文：

sudo timeout 60 tcpdump -ni "$IF" -s 96 \
'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0'

该命令需要管理员权限，仅用于观察连接建立、关闭和重置。抓包可能暴露源地址、目标地址和端口信息，文件应保存在受控环境中，生产环境不建议长时间运行。若需要抓取完整数据包，应先获得授权并评估敏感信息风险。

不同结果的含义如下：

• 最终目标丢包，同时 TCP 重传和超时在相同时间段增加：说明网络路径异常已经影响业务，应把服务器流量、nstat 统计和测试输出按时间提交给服务商，而不是先更换带宽规格。
• 只有中间节点显示丢包，最终目标正常：不能据此判定业务链路丢包，可能只是该节点对探测报文限速。
• ICMP 无明显丢包，但 TCP 重传明显增加：可能是 ICMP 与业务流量处理策略不同，也可能是短时拥塞，应以 TCP 统计、请求耗时和连接日志为准。
• 丢包先发生，随后吞吐下降和请求超时：更像丢包导致重传、拥塞窗口收缩和有效吞吐下降，而不是带宽套餐的标称速率本身不足。

第三步：检查连接状态和应用请求日志

总流量相同，连接行为可能完全不同。连接数量突然增加、连接长期处于半连接状态，或已有连接的发送队列持续增长，都可能让用户感受到“带宽变慢”。

先查看连接概况：

ss -s
ss -tan state syn-recv
ss -tan state established

重点关注：

• SYN-RECV：连接请求已到达但尚未完成建立的数量；
• ESTAB：当前已建立连接数；
• Send-Q：本地仍等待发送的数据量；
• Recv-Q：本地已接收但应用尚未读取的数据量；
• TIME-WAIT：连接关闭后的等待状态数量；
• 连接建立、关闭和重置的时间分布。

查看指定目标的 TCP 细节时，可使用：

ss -ti dst "$TARGET_IP"

不同内核和 iproute2 版本的输出字段可能不同。若能看到 rtt、重传和拥塞窗口等信息，应把这些字段与故障时间对应起来，不要用单个连接代表全部业务。

应用日志至少应保留以下时间和字段：

使用 Web 服务时，应检查访问日志和错误日志中的请求时间、请求耗时、响应字节、状态码、上游连接耗时、上游响应耗时和请求编号。日志路径和格式以实际配置为准，不要直接假设固定文件名。

典型组合可以这样判断：

• Send-Q 增加，出站流量接近上限，应用请求耗时同步增加：发送方向排队明显，容量不足的可能性较高。
• SYN-RECV 增加，但流量没有接近上限：应检查连接建立、服务监听、客户端重试和丢包，不能直接归因于共享带宽。
• 已建立连接数量正常，但请求耗时和上游耗时同时增加：网络传输可能不是主因，应优先检查应用处理或后端响应时间。
• 连接被重置或超时集中发生，TCP 重传同步增加：连接稳定性已经受到影响，应将连接日志与丢包测试按秒对齐。
• 并发连接数增加，但每秒请求数没有同步增加：可能是长连接、请求处理变慢或连接释放异常，不能仅凭连接数判断业务流量增加。

第四步：用时间线确认先后关系

建议按秒或分钟建立一张故障时间表，所有记录使用同一时区：

重点不是把所有异常简单相加，而是判断“谁先变化”：

1. 流量先升高并接近上限，随后 Send-Q 和请求耗时上升，丢包不明显：优先考虑带宽容量或发送排队。
2. 丢包和重传先增加，随后有效吞吐下降、连接超时：优先考虑传输路径或接口异常。
3. 新连接数先增加，随后 SYN-RECV 和连接超时增加，但流量不高：优先检查连接建立压力、客户端重试和服务监听状态。
4. 流量、丢包和连接均正常，只有应用耗时上升：现有网络证据不足以支持带宽问题，应转向应用日志。

可以使用 journalctl 查看指定时间范围内的系统或服务日志。该命令适用于使用 systemd 的 Linux 系统，命令本身为只读操作：

START="故障开始时间"
END="故障结束时间"
sudo journalctl --since "$START" --until "$END" --no-pager

如果已明确服务名称：

sudo journalctl -u 服务名 --since "$START" --until "$END" --no-pager

输出中重点搜索超时、连接重置、监听队列溢出和服务重启，并与流量监控、nstat 和访问日志的时间戳逐项对齐。

在相同条件下比较 100M 共享和 20M 独享

比较两种方案时，不能使用不同时间、不同测试节点或不同文件后直接比较最高速度。应保持以下条件一致：

• 使用相同的访问测试节点；
• 指向相同的业务目标或受控测试文件；
• 使用相同的请求方法、文件大小和并发方式；
• 在正常时段和问题时段分别测试；
• 同时记录流量、丢包、重传、连接耗时和应用响应耗时；
• 对比多次结果的稳定性，而不是只看单次峰值。

使用受控测试文件时，可以记录连接、首字节和总耗时：

TEST_URL="受控测试文件地址"

for i in 1 2 3; do
  date -Ins
  curl -L --silent --show-error --output /dev/null \
    --write-out 'code=%{http_code} connect=%{time_connect} starttransfer=%{time_starttransfer} total=%{time_total} speed_Bps=%{speed_download}\n' \
    "$TEST_URL"
done

该方法测量的是一次业务下载过程，不是纯粹的物理带宽。测试文件应由自己控制，并避免在生产高峰期反复下载大文件。持续吞吐压力测试应使用隔离目标，并提前确认流量成本和业务影响。

可以根据日志证据作出条件化判断：

“独享”不自动等于低延迟、零丢包，也不代表所有访问路径都没有拥塞。最终判断应同时参考合同中对带宽资源的定义、服务商监控，以及相同测试条件下的多时段日志。

修复后的验收与回滚检查项

完成带宽调整、服务配置变更或网络问题处理后，应使用与故障前相同的方法复测：

• 业务峰值时段是否仍持续接近带宽上限；
• ip -s link 中的错误和丢弃计数是否继续增长；
• ping、mtr 和 TCP 重传是否恢复到正常时段水平；
• Send-Q 是否在请求完成后及时回落；
• 新连接、已建立连接和超时数量是否恢复；
• 请求耗时、状态码和上游耗时是否恢复；
• 同一测试节点下的下载速度和总耗时是否更稳定；
• 故障时间线中的异常是否不再按原顺序重复出现。

如果修改过服务配置、限速配置、队列参数或访问控制规则，应保留修改前文件、修改时间和变更内容。涉及远程服务器时，不要在未备份的情况下直接覆盖配置，也不要为了验证带宽问题随意重启网络服务或调整防火墙。

以使用 Nginx 的场景为例，恢复旧配置前先确认备份文件存在，再进行语法检查和重新加载：

sudo cp -a /etc/nginx/nginx.conf /etc/nginx/nginx.conf.before-rollback
sudo cp -a /备份目录/nginx.conf /etc/nginx/nginx.conf
sudo nginx -t
sudo systemctl reload nginx

上面的路径仅适用于实际存在 Nginx 和对应备份文件的服务器。nginx -t 失败时不要重新加载；远程操作还应准备服务商控制台或带外登录方式，防止配置错误导致无法连接。

验收标准应包括：故障时段能够被流量、丢包、连接和应用日志解释；修复后在相同测试节点和方法下不再复现；变更前配置已经留存；必要时能够通过备份配置恢复。这样才能判断 100M 共享的波动是否真正影响业务，也能确认 20M 独享是提供了更稳定的可预测性，还是已经无法覆盖实际峰值需求。