网站突然无法访问时，直接登录服务器封几个 IP，往往不是处理 DDoS 的正确起点。真正需要先回答的是，链路是否已经被流量占满、连接队列是否耗尽、Nginx 是否仍能接收请求，以及故障究竟发生在网络层、传输层还是应用层。攻击位置不同，能够生效的防护措施也完全不同。
DDoS 不能只按流量大小理解
DDoS 是分布式拒绝服务攻击的统称，目标是消耗某种有限资源，让正常用户得不到服务。被消耗的资源可能是公网带宽、连接跟踪表、TCP 半连接队列、Nginx 工作连接、应用线程、数据库连接或第三方接口配额。因此，服务器 CPU 不高并不能证明没有攻击，带宽没有跑满也不能排除应用层资源已经被拖住。
容量消耗型攻击主要冲击公网链路。其显著现象是入站流量异常增大，并逐渐接近运营商或云平台为实例提供的带宽上限。当拥塞发生在机房或云平台到服务器之前，数据包甚至无法完整到达操作系统。此时在服务器里配置 iptables 或 firewalld，只能处理已经进入主机的数据，无法把被占用的上游带宽还给正常用户。
协议与状态消耗型攻击不一定需要把带宽完全占满。大量异常连接可能消耗 SYN 队列、连接跟踪表或负载均衡设备的会话容量。应用层 DDoS 则表现得更像真实访问，请求可以完成 TCP 握手并进入 HTTP 服务，但持续请求动态页面、搜索、登录或复杂 API，使 PHP、Java、Node.js、数据库等后端逐渐排队。CC 攻击通常属于这个范围，但应用层流量异常不能仅凭请求数量下结论。
先判断故障边界，再给攻击命名
排查时应同时保留三个时间线：云平台或运营商提供的入站流量曲线，Linux 主机的连接与资源指标，以及 Nginx 访问日志中的请求变化。三者在同一时间窗口发生转折，才容易建立可靠的因果关系。只看某一张截图，可能会把爬虫、业务活动、程序死循环或数据库故障误判为 DDoS。
在 Debian、Ubuntu 和 CentOS 上，可以先执行只读命令 ip -s link 查看网卡累计收发量、丢包与错误计数，再用 ss -s 查看连接状态摘要。它们的作用是建立当前网络状态快照，不会修改配置，风险较低。验证方法是间隔一段时间重复执行并对照监控趋势；由于没有产生配置变更，也不需要回滚。累计计数自开机后持续增长，不能把一个很大的累计值直接当成当前攻击速率。
若系统已经安装 sysstat，可使用 sar -n DEV 1 10 观察各网卡十个采样周期的收发速率，使用 sar -n TCP,ETCP 1 10 观察 TCP 活动与重传变化。Debian、Ubuntu 可通过发行版软件包 sysstat 提供该工具，CentOS 同样通常由 sysstat 软件包提供。安装软件会改变系统软件包状态，不应在故障高峰未经审批临时安装；更稳妥的做法是优先查看现有监控。若确需安装，验证应包括命令能否运行以及采样网卡是否正确，回滚则使用对应包管理器移除软件包，并恢复此前调整过的 sysstat 服务设置。
ss -ant state syn-recv 可列出当前处于 SYN-RECV 的 TCP 连接，适合判断半连接是否异常聚集。这个命令仍是只读的，但输出可能很长，应通过终端限流或保存到受控文件，避免排障操作反过来增加负载。SYN-RECV 数量上升可能来自访问激增、网络丢包或客户端连接质量问题，必须结合历史基线、监听端口和上游流量判断，不能单独作为攻击证据。
抓包应当小范围、短时间、有退出条件
当连接状态无法解释异常时，可以在获得授权后进行短时抓包，例如 timeout 20 tcpdump -ni any -c 2000 -w /tmp/network-sample.pcap。它的作用是保存有限数量的数据包，供后续分析协议、目标端口和来源分布。风险包括额外 CPU 与磁盘开销，以及数据包中可能包含地址、请求头或业务敏感信息。执行前要确认临时目录空间、文件权限和留存要求，验证抓包进程已按时间或数量退出，并检查文件大小。回滚不是修改网络配置，而是按安全流程转移或删除抓包文件，确认没有残留 tcpdump 进程。
不要为了看得更清楚而进行无限时长的全量抓包，也不要把原始抓包上传到不受控的公共分析网站。证据保全与数据保护同样属于网络安全工作。
服务器内的封禁为什么常常不够
若攻击已经占满公网入口，源站防火墙再精准也无法解决链路拥塞。此时需要联系云服务商、机房或运营商确认清洗、牵引、黑洞和扩容策略，必要时使用具备相应抗流量能力的 CDN、流量清洗或高防接入服务。具体容量和能力必须以供应商合同、控制台说明及实际架构为准，不能假定普通 CDN 自动具备无限清洗能力。
接入代理或 CDN 后，源站防护的重点会转向隐藏并收紧源站入口。理想状态是业务端口只接受可信回源地址，管理端口通过固定管理网络、VPN 或堡垒机访问。不过在执行防火墙变更前，必须确认回源地址范围、健康检查来源、证书续期方式和运维出口 IP。错误的白名单可能直接让网站离线，动态变化的 CDN 地址也不能靠一次性复制解决。
Debian 和 Ubuntu 常见的是 nftables、iptables 或 UFW，CentOS 常见 firewalld，但实际启用哪套组件应以 nft list ruleset、iptables-save、ufw status 或 firewall-cmd --state 的结果为准。不要同时堆叠多套规则管理工具。任何变更前都要导出当前规则、保留一个已验证的管理会话，并准备云控制台或带外登录。变更后的验证至少包括外部访问、CDN 回源、健康检查和管理登录；回滚应使用事先导出的规则恢复，而不是在失联后临时猜测原配置。
主机调优只能解决边缘问题
增大连接队列、调整连接跟踪容量或缩短超时，有时能缓解合法突发流量下的排队，但这些设置不是通用的 DDoS 防护模板。参数过大可能增加内存消耗，参数过小可能伤害慢速网络中的正常连接。调整前需要记录当前值、内存余量、内核日志和历史峰值，在低风险窗口做小步变更，再通过业务探测和系统指标验证。回滚就是恢复记录的原值并重新确认服务健康。
应用层异常还应从缓存、静态化、接口限流、查询成本、异步任务和数据库保护入手。限流规则要按业务接口设计，不能把全站用户压进同一个阈值。登录、搜索和导出等高成本入口可以采用更严格的访问控制，而支付回调、API 客户端和搜索引擎抓取需要独立识别，避免为了挡攻击制造新的可用性事故。
一套可复用的处置顺序
发现异常后，先保存监控时间窗口和服务状态，确认 DNS、CDN、负载均衡、源站与数据库哪一层失效；再用只读命令建立连接和网卡快照，对照 Nginx 日志判断 HTTP 请求是否真正到达。若上游链路拥塞，立即把处置重点移到运营商或云平台；若流量已经进入应用，则按 URL、状态码、来源网络和后端成本缩小范围。所有临时封禁、限流与内核调整都要记录作用、风险、验证结果、负责人和回滚条件。
DDoS 攻击防护不是一条封禁命令，而是一套分层容量设计。上游负责吸收或清洗超过源站承受范围的流量，系统防火墙缩小暴露面，Nginx 和 WAF 处理能够到达应用层的异常请求，应用自身则控制昂贵操作。把攻击发生的位置判断准确，通常比盲目增加规则更重要。
延伸阅读