网站被攻击无法访问？从应急抢通到长期防护的运维手册

凌晨两点半，手机上的监控警报把运维群炸醒了：“首页连续5分钟返回502，所有探活节点都失败”。打开浏览器，域名转圈、超时、最后只剩一句“无法访问此网站”。那一刻脑子里会同时闪过好几个念头：是云厂商故障？是代码被人改了？是备案又出问题？还是服务器被打爆了？

这篇文章要聊的，就是网站因攻击而无法访问时，从收到告警到恢复访问、再到事后复盘，这一整条链路该怎么走。内容覆盖应急判断、临时抢通、攻击类型识别、长期防护选型以及恢复后的收尾工作，适合自己管服务器的小团队、独立开发者和在云上跑业务的一线运维。看完之后，你可能不会立刻成为安全专家，但至少能在网站被打挂后的前30分钟，做出最不后悔的判断和操作。

1. 网站突然打不开：先分清是攻击、故障还是线路抖动

1.1 先判断：是“你访问不了”还是“大家都访问不了”

遇到网站打不开，很多人的第一反应是打开SSH连服务器，或者直接去问云厂商客服“是不是机房挂了”。其实最该先做的是判清楚故障范围：先在本地 ping 一下域名，再用 nslookup 看解析结果；接着用手机流量访问一遍；然后找不同地区的朋友或在线监测工具确认一下。这一步的核心目的，是区分“你本地网络的问题”“DNS解析的问题”“机房线路的问题”还是“服务器真的被攻击了”。

如果域名解析不出来，大概率是DNS被劫持或者解析配置被改动；如果只有部分地区访问不了，可能是某个运营商线路被黑洞，或者机房的BGP线路出问题；如果所有地域都访问不了，才轮到怀疑服务器本身。判断完这一点，后面的处理方向会完全不同。我见过不少人在这一步慌不择路，直接去重启服务器，结果把一次简单的DNS故障复杂化了。

1.2 登录服务器，看三个关键指标：负载、带宽、连接数

确认服务器确实无响应之后，通过云控制台的VNC/远程终端功能，或者机房提供的带外管理通道进去。这一步非常关键——攻击发生时SSH大概率是连不上的，不要死磕公网SSH通道。

进去之后，依次做三件事：uptime 看平均负载，free -h 看内存，df -h 看磁盘；然后 sar -n DEV 1 3 看网卡流量，有条件的用 iftop 看实时连接。三种典型情况帮你快速归类：

• 负载很高但带宽不大：多半是应用层攻击（CC），或者程序本身被拖死；
• 带宽打满、入方向流量异常大：基本就是流量型DDoS，服务器可能已经被黑洞；
• 页面文件被改、有异常进程、CPU长时间100%：可能已经被入侵，网站被人拿下之后乱来。

把这三个维度的现象记下来，对后面选应急方案非常重要。我见过不少人把流量型攻击当成代码故障去排查，重启了三四次才反应过来——流量一恢复，照样挂。

1.3 把非攻击因素先排掉

在归因到攻击之前，先快速排除几个常见坑：CDN或云厂商本身是否故障、域名证书有没有到期、安全组/防火墙规则是不是被人改过、云磁盘是不是写满了。这些信息大多能在云控制台的监控页和事件中心看到，比你自己瞎猜快得多。快速对应关系可以参考这张表：

2. 应急抢通链路：用最小改动让网站先能打开

2.1 做减法：先把服务从攻击目标的位置挪开

应急处理的原则不是“硬扛”，而是“先恢复访问”。如果架构里已经接了CDN，最快的操作是在CDN控制台开启“攻击防护”或“防DDoS模式”，或者直接启用“仅静态页”的降级模式，让网站暂时返回一个简单的静态页面，把所有动态请求挡在CDN层。没有CDN的话，可以把DNS临时解析到一个静态维护页，或者用对象存储托管一个“维护中”页面。

这一步对用户感知的影响最小。千万别想着一边应对攻击一边让完整业务在线，在攻击量很大的时候，真实用户也是在受苦的，一个体面的“维护中”页面，比一直超时打不开要好得多。等流量清洗完成、服务恢复正常，再把完整站点切回来。

2.2 用快照回滚代替现场“战斗”

如果服务器已经出现明显入侵痕迹，我的建议很明确：不要抱着“边打边修”的念头。最稳妥的做法是去云控制台给当前机器打一个只读磁盘快照，保留现场证据，然后基于最近一个干净快照创建一台临时机器，把数据恢复过去，再切换流量。这套流程大约10分钟，能避免在可能已经被植了后门的机器上继续做任何危险操作。

具体步骤大致是：打快照 → 用快照新建云盘或实例 → 挂载到隔离机器上检查数据完整性 → 修改本地配置（数据库连接、域名绑定） → 用临时IP验证服务正常 → 再改DNS切换流量。整个过程不要让原机器继续承担业务流量，不然攻击者可能通过后门再次进入新环境，等于白忙活。

2.3 短期救火动作：防火墙限流、连接限制、白名单

如果暂时没办法切换流量，只能在原服务器上做临时限制。这些手段对付CC和应用层攻击比较有效，对纯流量型DDoS作用有限，但能在关键时刻拖几分钟。

bash复制# 临时封禁明显的攻击源IP
iptables -A INPUT -s 1.2.3.4 -j DROP

# 查看当前连接状态分布
ss -antp | awk '{print $6}' | sort | uniq -c | sort -rn

Nginx层可以加请求频率限制：

nginx复制limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

server {
    location / {
        limit_req zone=one burst=20;
    }
}

如果服务的用户群体很固定，可以直接把端口访问白名单限制到几个IP段。注意，这些临时措施做完之后，要立刻回到“联系机房/云厂商开启流量清洗”这条主线上，不要以为在服务器上挡一挡就完事了。

2.4 应急恢复清单

把上面的操作整理成一张可以打印出来贴在屏幕边的清单，真到紧急时刻不用重新想：

3. 常见攻击类型识别：DDoS、CC、入侵篡改的差别与判断

3.1 DDoS：流量把带宽和连接池打满

DDoS的本质很好理解：用大量机器同时向你的服务器发送不必要但合法的流量，把带宽、防火墙连接表、交换机端口全部塞满。表现就是：服务器CPU可能不高，但网络入流量暴涨，SSH都连不上，外网彻底无响应。常见类型有SYN Flood、UDP Flood、ICMP Flood，以及DNS/NTP反射放大攻击。

判断方法：云控制台流量监控里，入带宽远远超过你购买的最高峰值；iftop 里能看到大量来自陌生IP的连接，连接状态大多是 SYN_RECV。这类攻击不用跟它“拼带宽”，拼不过的。唯一现实的做法是找上游：云厂商的高防IP、机房的流量清洗服务，让攻击流量在进入服务器之前就被过滤掉。攻击量特别大的时候，机房可能先“黑洞”掉你的IP，即直接断开公网约30分钟到2个小时，这是保护整体网络的正常手段，只能等它解封，或者把流量切到备用IP。

3.2 CC攻击：用业务逻辑把人拖死

CC攻击是DDoS的应用层变种，打得是业务本身。比如不断请求首页、搜索接口、验证码接口，每次请求看起来都正常，但频次极高，把PHP-FPM、Java线程池或者数据库连接数拖垮，CPU一路上到100%。网站表现为“能ping通但打开极慢”，或者直接502。

判断方法：看Web日志，会发现同一IP、同一UA、同一URL的请求量异常高，QPS可能从平时的几十涨到几万；top 里php-fpm或Java进程数量爆炸。应对思路是限流加验证码：Nginx的 limit_req 和 limit_conn 可以先顶一阵，更好的方案是接WAF，开启访问频控策略，对高并发请求返回验证码或直接拦截；对于固定的攻击UA和路径，直接在WAF里写死规则。

3.3 入侵篡改：已经被“拿下”的情况

有些攻击不是让你进不来，而是进来之后乱来：首页被改成黑页、数据库被删、文件被加密勒索、服务器被种了挖矿程序。这类情况特征明显：页面内容变了、磁盘写满、云监控显示CPU长时间高占用、登录审计里出现陌生IP。一旦确认入侵，第一步是把服务器从交换机侧断开，或者在云控制台安全组里把端口全部拒绝，避免攻击者继续操作、销毁证据；第二步是联系云厂商看能否提供镜像或快照用于取证；第三步才是恢复业务。

入侵事件里“保存现场”优先于“恢复业务”。如果直接把机器重装了，日志全没了，后续想定位漏洞就难了。实际处理时，建议先用云控制台打磁盘快照，再断网。后面即使重新搭建环境，也能从快照里慢慢找证据，把攻击手法还原出来。

3.4 三种攻击类型的快速判别

这张表看着简单，但应急的时候真的能救命。之前处理过一个案例，一开始只看到“网站打不开”，团队吵了半小时是硬件问题还是代码问题，最后拿这张表一对照，十分钟就锁定了是CC攻击，处理路径瞬间清晰。

4. 长期防护体系：CDN、WAF、高防IP的钱怎么花才不白花

4.1 CDN不只是加速，还是第一层挡箭牌

很多人把CDN当成“让访问更快”的工具，其实它更大的价值是隐藏源站IP、分散访问压力、承接一部分攻击流量。配置CDN之后，用户在域名上看到的是CDN节点的IP，真正的源站IP被隐藏，攻击者想直接打源站就得先摸到真实IP，难度高不少。

配置要点主要有三个：回源方式选HTTPS回源，源站只在防火墙里放行CDN节点的回源IP白名单，这样即使攻击者拿到源站IP，也无法直接访问；图片、JS、CSS这些静态资源全部走CDN缓存，动态请求才回源，命中率高的时候源站压力瞬间小很多；最后把CDN自带的DDoS/CC防护开关打开，很多服务商在CDN套餐里已经带了基础防护，比裸奔强太多。我见过不少项目，连CDN都不加，域名直接A记录到服务器，相当于把家门钥匙放在门口地毯下面。

4.2 WAF规则别乱开，容易误伤真实用户

接了CDN之后，下一层可以接WAF。WAF的核心能力是识别并拦截SQL注入、XSS、恶意爬虫，同时对高频访问做频控。配置时有几个容易踩的坑。

频控阈值要按业务真实QPS来定，不要从网上抄一个“10次/秒”就套上去，否则正常用户多点几下就会被弹验证码；敏感路径（后台、API）可以单独配置更严格的校验，比如强制二次验证；不要把安全规则全部一上来就开“拦截”，先开“记录/告警”观察一天，看看误杀率，再逐步升级为拦截。电商和活动页这类高流量场景尤其要注意，WAF规则太激进，把正常用户拦了，真实损失比攻击还大。

4.3 高防IP：什么时候必须买，买多少够用

如果业务已经被DDoS打挂过多次，或者攻击峰值超过10Gbps，基本上要考虑高防IP。高防IP的原理，是让域名先解析到高防节点，流量经过云端清洗之后再回源到真实服务器，攻击流量在进入服务器之前就被处理掉了。防护带宽按需选择，常见档位有30G、60G、100G甚至更高，价格随带宽和攻击类型浮动。

一个常见误区是买了高防IP就万事大吉。实际上，一旦攻击量超过你购买的保底带宽，高防节点也会对IP做黑洞。所以购买时建议留出20%到30%的余量；业务最好能容忍临时切换备用IP，防止清洗期间IP被黑洞导致长时间失联。预算有限的小团队可以先上CDN加基础WAF，真被打到受不了再加高防，按天、按次计费的方案比直接包年划算不少。

4.4 架构层面的纵深防御，别只靠单点硬扛

单台服务器抗攻击的天花板很低。想长期安稳，除了上防护产品，架构也需要做一些事：数据库与Web服务分离，数据库只用内网IP，不暴露公网；静态资源放对象存储，由CDN分发，动态源站只承担小部分流量；有条件上负载均衡加多可用区部署，一台被打挂另一台还能顶；维持一份“黄金镜像”或者“干净快照”，每次部署完就更新一次，应急恢复时直接拉最新的一份。

这些做法都是老生常谈，但真的用的时候才觉得香。遇到攻击时，多一个备份节点、多一份干净镜像，就能少慌十分钟。

5. 恢复之后不等于结束：日志取证、漏洞修补和复盘清单

5.1 从日志里还原攻击过程

攻击结束不代表故事结束。重新打开网站之后，必须回去翻日志，搞清楚攻击者是怎么进来的。不同攻击类型，看日志的位置不一样：

• Web访问日志：nginx或apache的access log，按时间过滤出攻击时段，找高频IP、高频URL、可疑UA；
• 错误日志：动态语言的error log，看有没有SQL报错、文件包含报错，这些可能是注入尝试留下的痕迹；
• 系统日志：/var/log/secure（或auth.log）看有没有SSH暴力破解记录，防火墙日志看有没有异常放行；
• 云厂商流量日志和安全告警：很多云平台会记录攻击流量的类型和来源分布，对溯源很有帮助。

常用命令无非是 grep 加 awk 统计IP访问量，找出Top IP；用 tcpdump 抓包看攻击包特征；用 md5sum 和之前的文件校验值做对比，找出被改动过的文件。

5.2 漏洞修补：把后门一个一个堵上

从日志里定位到攻击入口之后，按优先级修补。

• 弱密码：SSH、数据库、后台管理员的密码全部改成强密码，并开启密钥登录；
• 未修复漏洞：把Nginx、PHP、Java框架、CMS升级到最新版本，尤其是公布过RCE或注入漏洞的版本；
• 暴露面收窄：后台管理地址不要用默认路径，限制管理IP白名单；不必要的端口（Redis、MySQL、Elasticsearch）不要监听公网；
• 密钥轮换：数据库密码、API密钥、JWT secret全部重新生成；
• 防御加固：安装云安全Agent或杀毒软件，设置文件完整性监控，比如每天把关键目录的md5列表备份一份。

不要只修补一个点就完事，攻击者常常在系统里留了好几个后门。建议把已知项全部补完之后做一次全盘扫描；如果团队人力不足，可以找云厂商做一次有偿安全评估，这个成本的性价比，比出事之后再花大量时间处理要高得多。

5.3 复盘清单：把“处理过”变成“能更快处理”

每次攻击处理完，都应该做一次复盘，回答几个核心问题：我们是怎么发现攻击的？发现后用了多长时间定位？应急动作是否符合预演流程？哪些步骤做慢了？备份是否在关键时刻派上了用场？

把答案写进事故报告。一份事故报告至少包含：事件时间线、攻击类型与规模、影响范围、处置过程、根因分析、改进措施、责任人与完成时间。这样过半年再翻出来，还能作为培训新同事的素材。我更推荐把常见攻击类型的应急手册写成固定文档放在团队Wiki里，标明每一步操作的工具和截图，危机时刻不用重新想。

5.4 备份策略：恢复了，还要防下一次

不管你做了多好的防护，都要默认“总有一天会被打进”。备份策略是整个安全链路的最后一环。我的建议是：

• 每天自动做数据库备份，至少保留三天，并同步一份到不同可用区或异地对象存储；
• 每周做一次实例快照或整机镜像，部署重要变更之后立刻更新一次快照；
• 每月做一次恢复演练：真的从快照里建一台机器，把数据导回去，确认业务能正常启动。

日常备份都做了、但从来没验证过恢复流程的项目，我遇到过不止一个。真到恢复的时候发现快照损坏或备份不完整，那种绝望感，还是别体会第二次了。

最后分享一个我自己带团队的体会：网站被打这件事，真到发生的时候，最贵的不是那几万块钱的高防IP，而是团队的判断力和冷静。把“判断、恢复、防护、复盘”这套流程提前跑通，比临时抱佛脚有效太多。下次再遇到凌晨的报警，你至少知道第一步该打开哪块控制台、点哪个按钮、该联系谁——那二十分钟里少走点弯路，就是这篇文章最大的价值。