服务器被攻击那天，我先做了四件事
我做的那款简笔画画板小游戏累计跑到 ¥6000 以上的时候，纯前端、零运维、两天写完，看起来是最省心的那种项目。也正因为省心，我从没想过服务器被攻击了怎么办这个问题。
它是每日几十人的自然搜索进量撑起来的。所以那次发现服务器不对劲时，我脑子里的第一反应不是「被攻击了」，而是「今天怎么没人来」。
一、服务器被攻击了怎么办：那天的真实顺序，和我原本以为的不一样
我以为自己会先查代码、看漏洞、找入口。实际发生的是：我先花了很久确认「到底是不是攻击」，那段时间里服务还在被人用。
事后复盘，我浪费掉的不是修复时间，是确认时间。出事的时候人的本能是找一个解释，而不是先止血。后来我把顺序固定成四件事，写下来，不再临场想。
这四件事的顺序不能换，原因在最后一件：如果先动手封堵再回头看，现场就没了。服务器被攻击了怎么办，第一原则是先保命再破案。
二、第一件：先判断是攻击还是我自己写挂了
这一步排第一，因为它决定后面所有动作的方向。
我会按三个角度快速看：是不是只有某一个接口异常、是不是只有某一段时间异常、是不是有我完全不认识的来源。三个都指向同一边，基本就能定性。
别急着定性，但要尽快定性。定错了方向，后面每一步都是反的。
我给自己定的时间上限是十几分钟，超过这个时间还没结论的，按「是攻击」处理，因为两者的应急动作前几步是重合的。
三、第二件：能切就先切，别边挨打边查
确认是攻击之后，我的第一个动作是降低暴露面——限流、关掉非核心接口、必要时直接下线。
这一步最反直觉，因为下线看起来像认输。但服务挂着被打，损失是持续产生的；服务停一会儿，损失是有限的。
单人项目没有流量兜底，停服的心理成本比大公司高得多，这也是我当初犹豫的原因。
不过换个角度算：一个已经不正常、还在持续被人利用的服务，留着它并不能保住流量。它只是在保住我的心理舒适区。
四、第三件：留证据，别把现场擦干净
我最开始的本能是赶紧重启、赶紧恢复。后来才明白，重启会破坏现场。
在动手之前，我会先做一次现状留存：日志、连接、异常请求的样子。这些东西是后面判断「他是怎么进来的」唯一的依据。
恢复服务和保留现场是两件事，顺序不能反。现场没了，同样的攻击下次还会来。
五、第四件：封口子，而不是封 IP
我最初的做法是把攻击来源一个个挡掉。这件事的收益很低，因为来源可以换。
真正要处理的是入口本身：是不是有接口没做鉴权、是不是有参数没校验、是不是有依赖版本该更新了。
堵住一个 IP 是治症状，堵住一个口子才是治因。这四件事做完，才算告一段落。
封口子这件事也分先后：先处理能直接被外部触达的入口，再处理内部逻辑。前者是门，后者是房间。
六、事后我改了什么
这次之后我调整了三件事：给关键接口加了限流，把「留证据」写进了应急清单，以及确认最近的备份可用——万一最坏的情况发生，我还回得去。
有意思的是，攻击本身造成的损失，比我在「确认是不是攻击」上耗掉的时间小得多。复盘下来，我最大的问题是慢，不是弱。这也是我现在对「服务器被攻击了怎么办」最想说的答案。
常见问题
Q：怎么判断服务器是被攻击了还是正常流量涨了？
A：看分布而不是看总量。正常涨量通常集中在几个真实业务的入口，攻击往往集中在单个接口、单个来源，或者伴随大量异常请求。
Q：服务器被攻击了要不要马上关服？
A：取决于业务能不能停。如果停服损失可控，先降暴露面再排查；如果停不了，至少先限流，别边挨打边从容分析。
Q：单人项目有必要做安全防护吗？
A：有必要，但优先级不需要排在最前面。先把鉴权、参数校验、依赖更新这三件基本的事做到位，收益比买任何防护服务都大。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」