现场是这样的。明天有推广活动，预计流量是平时几倍，想临时提升带宽，又不想按月付费。
原因不止一个，得分开看。部分云厂商支持按天或者按时长临时升级带宽；临时升级到期后自动恢复原配置；升级操作需要实例处于运行状态。
先确认当前带宽与峰值
sar -n DEV 1 5接着在控制台选择临时升级时长
echo '按小时或按天选择，以控制台为准'升级后立即压测验证
curl -o /dev/null -w '%{speed_download}\n' https://域名/1m.bin活动结束后核对带宽是否恢复
ethtool eth0 | grep Speed排查用的命令都是临时敲的，没有写成脚本，事后才整理。
手上没有现成的复现脚本，就照着线上请求手工拼了一个。
怎么算真的好了，看的是同一批现象。活动期间带宽满足峰值需求，结束后自动回落，费用符合预算。
临时升级的生效时间通常有几分钟延迟，别等活动开始才操作；公网带宽还受实例规格限制。报错文案容易误导，真正的原因往往在相邻那一层的日志里。