服务器遭受DOS攻击后，第一要务不是排查攻击源头，而是先切断攻击链路恢复业务，再谈后续的溯源与加固。只要攻击流量还在持续，任何排查动作都是徒劳，这个过程中，流量清洗、黑洞路由、紧急扩容是三个最核心的操作手段。
服务器被攻击了怎么处理：先做减法再做加法
很多运维人员接到告警的第一反应是登录服务器看日志，这是极其危险的习惯，每秒几十万的SYN包随时可能让CPU跑满，你连登录的机会都没有，正确的顺序是先让服务器活下来,再考虑谁在打你。
第一步：确认攻击类型，但别花超过三分钟
通过控制台或IDC提供的流量监控图,快速判断是四层流量型攻击还是七层应用型攻击。
- 四层攻击：带宽被占满，流量图是平的直线，多见于SYN Flood、UDP Flood
- 七层攻击：带宽正常，但CPU和内存飙升，多见于CC攻击、HTTP慢速攻击
这个判断决定了后续操作方向，如果是四层攻击，直接走流量清洗；如果是七层攻击,优先考虑限频和WAF规则。
第二步：止血操作要按这个顺序执行
第一优先级是启用黑洞路由或流量清洗服务。 多数云厂商提供免费的基础DDoS防护，但默认阈值较高，此时应立即在控制台手动调整防护阈值到较低水平，哪怕会误伤正常用户,也要先保住服务器不宕机。
第二优先级是紧急扩容。 如果服务器还能登录，先加带宽临时包，提升到攻击流量的预估峰值以上，这个操作的意义在于给自己争取十分钟的缓冲时间，同时通过安全组或防火墙，临时封禁来源IP段,尤其是海外IP段。
第三优先级是切换解析。 如果攻击量极大，超过机房总带宽，直接修改DNS记录，将域名指向高防IP或CDN服务商提供的临时CNAME地址,这一步能快速将攻击流量分散到多个节点。
行业共识认为，完成了这三个操作，业务基本可以恢复在线状态，此时再去查看攻击来源,才有实际意义。
服务器被DDOS了怎么查攻击源
攻击源排查不是让你去反向追踪黑客的物理地址，这既不可能也没有实际价值，你需要做的是梳理攻击特征,为后续防御提供依据。
通过流量日志定位攻击特征
登录服务器或防火墙设备，获取攻击时段内的netflow或sflow数据,使用tcpdump抓包看数据包特征：
tcpdump -i eth0 -nn -c 10000 > attack.pcap
用tcpdump分析攻击来源IP分布、源端口分布、TCP标志位特征,常见的规律包括：
- 源IP分散但源端口集中在某几个固定端口，大概率是僵尸网络
- 源IP集中来自某个C段，可能是同行竞争或个人恩怨
- 攻击包大小非常均匀，说明是工具化攻击
- 攻击时间有规律性，比如每天固定时段，可能是自动任务触发
七层CC攻击的溯源思路
如果判定是CC攻击，优先看Web访问日志,用awk等工具分析请求频率最高的IP和URL：
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -20
重点关注请求集中在某个动态接口（比如搜索接口、登录接口）还是一堆随机字符串路径，集中攻击业务接口的，说明攻击者对业务逻辑做了前期探测,需要重点排查是否存在信息泄露渠道。
业务恢复后的系统加固方案
攻击停止不代表安全. 如果不做系统性加固，下一次攻击的代价只会更大,这部分按照从外到内的顺序操作。
基础设施层的防护配置
高防IP和CDN的接入是性价比最高的方案。 国内主流云厂商的高防IP包年费用从几千到几万不等，具体看保底带宽和弹性峰值，对于中小网站，选
20Gbps保底+100Gbps弹性的配置基本够用。
DNS层面启用解析限速和泛解析过滤。 多数DNS服务商后台都有免费的基础DDoS缓解功能，记得手动开启，同时关闭DNS递归查询,避免被用作放大攻击的跳板。
操作系统层面的参数调优
修改内核参数,提升TCP连接队列容量和SYN队列长度：
sysctl -w net.ipv4.tcp_max_syn_backlog=65536 sysctl -w net.core.somaxconn=65536 sysctl -w net.ipv4.tcp_syncookies=1
生产环境建议在/etc/sysctl.conf中持久化这些参数，SYN Cookie机制能有效应对小规模SYN Flood,但大规模攻击还得靠上层清洗。
应用层的限频与验证
- Nginx层配置limit_req模块，对单IP做请求频率限制
- 对登录、注册、搜索等敏感接口，强制开启图形验证码或滑块验证
- 动态请求与静态资源分离，将图片、CSS、JS等资源迁至CDN
这里有一个容易被忽略的点：API接口的鉴权逻辑要改造。 很多CC攻击专门打无鉴权的查询接口，一个几块钱成本的脚本就能让服务器CPU打满，给所有接口补上身份校验和参数校验,攻击成本会成倍增加。
服务器防御方案怎么选：自建还是云防护
关于服务器防御DDOS怎么做,不同规模的业务有完全不同的最优解。
| 方案类型 | 适用场景 | 投入成本 | 防御效果 |
|---|---|---|---|
| 自建防火墙+流量清洗设备 | 大型企业，有专业安全团队 | 数十万到数百万 | 可控性强，但运维成本高 |
| 云厂商高防IP | 中小型网站和APP | 数千到数万每年 | 接入简单，弹性扩容快 |
| CDN+WAF组合 |
电商、资讯类网站 |
数千元每年 | 防护七层效果明显 |
| IDC硬防机房 | 对延迟敏感的游戏业务 | 依赖机房套餐 | 带宽大，但灵活性差 |
对于大多数企业和个人站长，云高防IP+CDN+WAF的组合最省心，不需要自建机房，也不需要专业安全运维人员，控制台点几下就能完成接入，游戏类低延迟业务更适合自建防护或选带硬防的BGP机房，如果预算有限且业务流量不高，CDN基础防护也够用，但遇到大流量攻击时容易被回源打穿,需要配合源站IP隐藏操作。
地域选择也会影响防御效果
国内业务建议优先选华北、华东的BGP高防节点，带宽资源充足且清洗能力更强，面向海外用户的业务，则要考虑海外高防节点,否则跨境延迟会明显影响用户体验。
常见问题
服务器被攻击了，报警有用吗？
报警后警方通常要求提供详细的攻击日志、流量报表和损失评估，且立案标准较高，个人站长遇到的绝大多数攻击，最终都难以追踪到具体行为人，更实际的方案是通过云服务商或IDC的应急响应服务来处理,同时保留日志以备后续法律需求。
服务器防御怎么做才能避免再次被攻击？
没有绝对的安全，但可以通过三层措施大幅提升攻击成本：基础设施层接入高防IP和CDN隐藏源站IP，系统层定期更新补丁并关闭不必要的端口，应用层做好接口鉴权和访问限频，每季度做一次安全巡检,关注云平台的安全公告也很重要。
攻击导致数据丢失，能恢复吗？
取决于数据丢失的原因，如果是攻击导致磁盘写入异常，通过文件系统修复工具或云盘快照还有较大恢复可能，如果是被黑客恶意删除且没有异地备份，恢复概率极低,平时启用自动化异地备份是唯一可靠的保险措施。