云监控显示公网出带宽持续打满，但访问量并没有明显增长，求排查思路。以下是社区整理的排查方法，供遇到同样问题的同学参考。
不少团队在「求助：ECS 公网带宽跑满但业务量没涨，怎么查？」上走过弯路，根源通常是只优化了局部、却忽视了全局。VPC 网络与安全组规划的价值恰恰体现在端到端的协同：从资源申请、网络互通，到弹性与容灾，每一步都需要统一的规范和口径。
先看是谁在用带宽
在实例上用 iftop / nethogs 按进程和目的 IP 看实时流量，快速定位是哪个进程、往哪个地址发大流量。
排查异常
确认是否有被入侵后对外发包 / 挖矿 / 沦为 DDoS 肉鸡的迹象（可疑外连、陌生进程）；是否被恶意刷下载或盗链（大文件、图片被外站直接引用）。
也可能是正常业务
是否有备份 / 同步任务、大文件下发、爬虫抓取；静态资源是否本该走 CDN，却全压在源站公网出口上。
处置
确认盗链就配 Referer 防盗链 + CDN；静态资源迁到 CDN 卸载源站压力；发现异常进程按入侵应急流程处理；必要时临时升带宽或限流顶住。
长期预防
加带宽监控告警、静态资源上 CDN、收敛公网暴露面。
小结：带宽异常先"按进程和目的 IP 拆流量"，再判断是攻击、盗链还是正常业务，对症下药。
先止血、再定位，两步不要混在一起
带宽被打满时业务已经在丢请求了，此时最忌讳一边找原因一边等结论。正确的顺序是先用成本最低、可回退的手段恢复可用性，再从容排查根因，最后把处置过程沉淀成预案。
- 止血手段：临时提升带宽上限、对可疑来源或接口限速、把静态资源切到 CDN 卸载源站出口，这几类操作通常能在几分钟内生效，并且随时可以撤回。
- 拆流量方向：区分是入方向还是出方向打满、集中在哪个端口与目的地址。出方向大流量多指向下载、盗链或对外发包，入方向则更可能是攻击或爬虫抓取。
- 留存证据：开启流日志或抓包保存样本，记录时间窗与流量特征；如果怀疑被入侵，进程列表、外连地址、登录记录与计划任务也要一并留存，事后再取证往往已经晚了。
- 暴露面复盘：可直链下载的资源、未加签的对象存储地址、公网暴露的管理端口，都是被刷的常见入口，处置完成后要逐项收敛而不是只恢复流量。
预防层面建议把公网带宽使用率、流量来源排行、CDN 命中率纳入常规监控，并对突发流量设置告警。很多盗刷在早期只是小幅抬升，早一天发现，损失就小一个量级。涉及攻击防护与流量清洗的场景，具体防护能力和费用以实际方案报价为准，需要先评估业务体量再选型。
把VPC 网络与安全组规划放回架构全局来看
单点的最优解，叠加起来未必是全局最优。评估VPC 网络与安全组规划时，建议先明确业务的峰值模型与故障容忍度，再倒推资源与网络该怎么设计：哪些负载是稳定基线、哪些是突发流量、哪些可以容忍短暂中断，答案不同，架构取向也完全不同。
在此基础上再谈规格与参数，才有意义。否则很容易陷入「先买资源、再找用途」的被动局面，成本与复杂度都会随之上升。
落地前的自检清单
- 容量与规格：是否用真实压测数据而非经验估算来定规格，是否预留了弹性空间。
- 网络与边界：网段划分是否留有扩展余地，安全组是否遵循最小开放原则。
- 弹性与容灾：扩缩容策略是否经过演练，故障切换路径是否清晰、可回退。
- 可观测性：关键链路是否有指标、日志与告警覆盖，出问题能否快速定位。
这四件事做到位，VPC 网络与安全组规划才算真正「落地」，而不是停留在方案文档里。