黑名单解决的是明确的问题

黑名单适用的场景很清晰：已经确认某段来源在持续做不该做的事，需要直接把它挡在门外。它的优点是见效快、不依赖复杂的判断规则，缺点同样明显，维护完全靠人。

与防火墙的区别值得说清楚。防火墙在更靠前的位置工作，效率高，改动的影响面也大；应用层的黑名单更灵活，可以按路径、按请求特征做判断，但需要程序自己承担这部分开销。选哪一种，看你想在哪一层解决问题。

名单从哪来，是这件事里最需要想清楚的。自己日志里反复出现的来源最可靠；从公开渠道拿来的清单要谨慎，别人的判断标准和你的业务未必一致。

怎么写规则不误伤

单个地址最精确，但挡不住对方换地址；整段地址覆盖广，代价是可能把真实用户一起关在外面。常用的折中是先封单个地址，观察对方是否在同一段里换着来，再决定要不要扩大范围。

有些来源是运营商或云服务的大段地址，里面既有攻击者也有正常用户。把这类整段封掉，短期看问题解决了，长期会不断收到访问不了的反馈。

规则写完之后，最好用一个不在名单里的地址试一下，确认它照常可以访问。只验证被拦住的地址确实被拦住，说明不了规则没有写错范围。

什么时候该解封

黑名单如果没有过期机制，最后一定会变成一张越来越长的清单。给规则设一个期限，比如七天、三十天，到期自动失效，让真正持续的来源重新被观察到，也避免早期的临时封禁一直留着。

用户反馈访问不了的时候，先按时间反查日志，看是命中了哪一条。如果确实是误封，把来源加进例外名单，而不是直接把整条规则关掉，因为规则背后往往还有别的来源正在被挡。

解封也是一个判断机会。同一条规则反复被误封，说明判断条件本身有问题，这时候要改的是规则，而不是不断往里加例外。

把它安排进日常

让这件事有人负责，比用什么工具更重要。每隔一段时间看看名单里有多少条、最近是否还有命中，长期没有命中的规则可以清掉。

命中记录也值得留下来。同一个来源被封之后又回来，说明对方有耐心，这类情况适合把封禁时间拉长，而不是每次都从最短期限开始。

对资源有限的小站点，更实际的顺序是先做好日志、限制频率，再考虑封禁。封禁是最后一道手段，前面几步做得扎实，需要封的来源自然就少了。

最后提醒一句，黑名单解决的是已知的麻烦，它对新的来源没有任何作用。别因为名单很长就以为安全。

和其他手段的配合

黑名单不适合单独使用。同一批来源被封之后换个地址就回来了，配合频率限制才能把成本提上去。

对特征明显但地址不断变化的来源，按请求特征拦截比按地址拦截更有效，比如固定的请求头、固定的访问模式。

有些来源同时有正常业务和恶意行为，简单封掉会牵连业务。这类情况更适合针对具体路径做限制，而不是整段拒绝。

封禁的执行位置也有讲究。防火墙层效率高，应用层灵活但消耗资源，判断依据简单的规则放在前面，复杂的放到后面。

每一次封禁的原因和时间都写下来，过几个月回头看，才知道哪些判断是有效的，哪些只是当时的反应。

名单越长，越需要有人定期回看。没人维护的名单，过一段时间就不再反映真实情况了。

如果同一个来源在多个站点都出现，横向比对能确认这是普遍扫描还是专门针对某个业务。

处理完回头确认效果，封了之后请求确实减少，才算这一步做对了。

把这些动作固定成流程，就不必每次都由同一个人来判断。

名单里的每一条都注明原因，过一段时间回头看，才知道当时的判断有没有依据。

如果封禁由程序自动完成，规则要定期复核，自动化容易把范围越放越宽。

封禁之外也要保留观察的通道，完全看不到对方的行为，就失去了判断的依据。

处理这类问题最怕各做各的，把动作和结论放在同一个地方，团队才知道当前的状况。

把封禁当成一个需要经营的过程，而不是一次性的动作。