网站突然打不开，先别急着封禁大量来源地址。网站无法访问的流量攻击排查，关键是把用户看到的错误、服务器连接状态和访问日志放在同一时间线上核对：带宽是否耗尽、连接是否堆积，还是少数请求拖慢了应用。不同原因对应的处置措施并不相同。
先确认故障发生在哪一层
从多个网络和设备访问网站，记录故障时间、页面表现及浏览器提示。若首页和静态文件都超时，同时服务器外部监控也无法连接，优先检查网络链路、负载均衡器和主机资源；若静态文件能打开，登录、搜索或提交表单失败，则更应检查应用和数据库。返回码也能提供线索：502通常表示网关未能从上游取得有效响应，503表示服务暂不可用，504则常见于等待上游超时；它们是定位线索，不是攻击的直接证明。
同时查看云平台或主机监控中的入站流量、CPU、内存、磁盘和网络连接数，并与故障前的正常时段比较。带宽接近线路上限但应用负载不高，可能是链路拥塞；CPU持续繁忙、特定接口响应变慢，则要继续追踪请求和应用日志。
用日志和连接特征缩小范围
访问日志看请求模式
检查 Nginx 或 Apache 的 access log，按分钟统计请求量，并对比来源地址、请求路径、方法、状态码和响应时间。关注短时间集中访问少数动态接口、重复请求明显增多、错误码同步上升等现象。若网站前有 CDN 或反向代理，应确认日志记录的是访客地址还是代理地址；没有正确恢复真实访客地址时，来源统计可能失真。
连接状态看拥塞位置
在 Linux 主机上可用 ss 查看 TCP 连接状态及本机监听端口，并结合 top 或系统监控观察进程资源。大量连接停留在等待或已建立状态，可能提示连接压力，但必须同时核对网络流量、应用线程和服务日志。单凭某个连接数或单个来源地址不能定性：共享网络可能让许多真实用户显示为同一出口地址。
按故障特征选择处置方案
- 线路流量接近上限：先联系云平台或网络服务商核实入口流量与丢包情况。若流量在到达主机前已堵塞，主机内限流通常不能恢复链路；可评估由上游清洗或接入 CDN 分担流量，具体效果取决于业务协议和接入方式。
- 少数路径请求异常密集：在 WAF 或网关为对应路径设置限速、挑战或临时拦截。先对照正常业务调用频率和用户来源，逐步收紧规则，并观察误拦、错误率和响应时间；登录、搜索等接口的容许频率可能不同。
- 主机连接或应用资源耗尽：检查 Web 服务、应用进程和数据库连接池的日志，找出耗时请求及资源瓶颈。扩容可以缓解短时容量不足，却无法替代对异常请求的识别；变更配置前应保留原值和回滚办法。
网站无法访问的流量攻击排查应形成“发现—验证—缓解—复查”闭环。先保存相关时间段的访问日志、监控曲线和规则变更记录，再实施范围尽可能小的措施；每次调整后确认正常页面、关键业务和错误率是否恢复。
常见问题
访问量变高就一定是攻击吗？
不一定。活动推广、搜索引擎抓取或正常业务增长也会带来请求上升，应结合路径分布、响应结果、来源特征和资源消耗判断。
可以直接封禁请求最多的地址吗？
不建议只按请求量封禁。先确认代理记录方式，并判断地址是否代表共享网络；误封可能影响同一出口下的正常用户。
网站恢复后还要做什么？
保留故障期间证据，复核限流规则是否仍需保留，并检查服务容量、告警和日志字段是否足以支持下一次定位。若入口链路仍不稳定，应继续向上游核实。