在流量进入数据库前拦截僵尸网络请求

大多数应用架构天生“很有礼貌”：请求进来，路由交给控制器，控制器打开数据库连接，执行查询，再渲染响应。对真实用户来说，这条链路很正常；但对僵尸网络来说，这简直是送上门的机会。

分布式僵尸网络并不一定需要利用漏洞才能造成伤害。它只需要你的应用不断点头：允许访问登录表单，允许请求搜索接口，允许触发密码重置邮件，允许继续从连接池里拿一个连接。等流量走到 ORM 那一步，你已经为 TLS、会话查询和数据库往返付过成本了——而且这个成本会被每分钟成千上万个节点放大。

最便宜的请求，是你根本不处理的请求。这正是边缘侧 IP 级过滤的核心价值。

从 IP 层看，僵尸网络到底长什么样

僵尸网络流量很少只来自一个地址。它通常分散在大量 IP 上，而这些 IP 大致会落在几个常见类别里：

• 被攻陷的住宅网络设备。 家用路由器、IoT 设备、被感染的个人电脑。单个流量不大，但合在一起规模惊人。
• 租来的数据中心资源。 批量拉起的廉价 VPS。真实消费者几乎不会从 AWS、OVH 或 Hetzner 的网段访问你的结账页。
• 商业代理网络。 按流量售卖的住宅代理和移动代理池，卖点往往就是绕过基于 IP 的拦截。
• 公共 VPN 和 TOR 出口。 对重视隐私的用户有正当用途，但在滥用流量中占比也明显偏高。

这些类别并不天然等于恶意。一个数据中心 IP 可能是你自己配置的监控探针；一个 VPN 出口也可能只是住酒店、连公共 Wi-Fi 的客户。也正因为如此，决策权应该在你手里，而不是交给一张“一刀切”的黑名单——你需要的是分类能力，然后基于分类执行自己的策略。

要在数据库之前拦截，而不是之后

处理顺序比任何单个信号的准确率都更重要。来看同一个登录接口的两种实现方式。

| Stage | Without IP filtering | With IP filtering first | | --- | --- | --- | | Parse request | Yes | Yes | | IP classification | — | ~1 lookup, cached | | Session / user lookup | Yes | Only if allowed | | Password hash verify | Yes (expensive by design) | Only if allowed | | Rate-limit write | Yes | Only if allowed |

密码哈希本来就应该慢——这是它的安全设计目的。但当撞库流量打到一个没有保护的登录接口时，你自己的安全机制反而会变成拒绝服务攻击的放大器。把 IP 判断前置之后，攻击节点只需要一次类似哈希表命中的成本就会拿到 403，而你的数据库连接池仍然留给真正的用户。

同样的逻辑也适用于会打全文索引的搜索接口、会触发事务邮件的注册表单，以及每次尝试都会写审计日志的任何端点。

策略要实用，而不是筑一堵墙

把所有可疑流量一律硬拦，最后往往换来的是一堆愤怒的客服工单。更稳妥的做法是分层响应。只要你能拿到每个 IP 的风险分和类型，这套策略就很容易表达：

• 静默放行。 风险分较低的住宅宽带和企业 ISP 地址。绝大多数真实流量都在这里。
• 增加摩擦。 对 VPN 或 TOR 出口，只在敏感操作上加限制——例如注册、密码重置、修改收款信息。可以展示挑战、要求邮箱确认，或不给予免费试用权益。
• 强力限速。 数据中心和托管服务网段访问面向人的端点时，应当严格限流。合法集成应该走带 API key 的 API，而不是去打你的登录表单。
• 在边缘拒绝。 已知正在攻击认证接口的恶意代理基础设施，或者任何已经超过单 IP 预算的流量。

注意，第 4 类应该是最小的桶，而不是默认策略。目标是让滥用变贵，而不是让你的产品变得难以访问。

检查逻辑应该放在技术栈的哪里

大致有三个位置，按效果从强到弱排列：

• CDN 或反向代理。 越早越好。请求根本不会碰到应用服务器。适合对明显恶意的网段做粗粒度规则。
• 应用中间件。 在路由之前、任何数据库调用之前运行。更细的、按端点区分的策略适合放在这里——例如 /login 严格一些，/pricing 放宽一些。
• 业务逻辑内部。 用于需要账户上下文的判断，比如某个账号过去只从同一家移动运营商登录，突然出现来自数据中心 IP 的登录行为，就可以标记出来。

多数团队应该先做中间这一层。它通常只是放在路由前面的几行代码，却能保护后面的整条链路。

积极缓存，故障时放行

有两条运维规则，可以避免 IP 信誉检查本身变成新的故障源：

按地址缓存。 僵尸网络会反复使用同一批节点。一个很短的内存 TTL——按分钟算，而不是按天算——就能把成千上万次请求压缩成一次查询，并让重复攻击者带来的额外延迟保持在微秒级。Guarda 正是出于这个原因在服务端缓存查询结果，并且缓存窗口可以配置。

故障时放行，但要高声记录。 如果信誉服务不可用，就让请求通过，同时把事件记录下来。一个反滥用组件如果因为第三方服务抖动就拖垮你的结账流程，损失可能比滥用本身还大。只有提现这类真正高风险操作，才值得考虑故障时拒绝。

上线后该看什么指标

先用只记录不拦截的模式跑起来，把一周观察数据和一周拦截数据进行对比：

• 在到达数据库之前被拒绝的请求，占总请求的比例。
• 滥用高峰期间数据库连接池的饱和情况。
• 每小时失败登录次数。
• 提到“无法登录”的客服工单——这是误伤的金丝雀。
• 注册到已验证账号的转化率。一次性数据中心注册被挡住后，这个比例通常会明显改善。

如果最后两项朝错误方向变化，不要直接把整套机制关掉，而是放松对应分层策略。

也要承认边界

IP 信誉只是其中一层，不是万能防火墙。住宅代理池会轮换真实消费者地址，看起来和你的客户几乎没有区别。运营商级 NAT 意味着一个移动 IP 背后可能有成千上万人。有预算的攻击者，永远能找到比低成本攻击者更干净的基础设施。

IP 过滤真正稳定能做的，是清掉那批廉价、高容量的主流滥用流量——跑在租用服务器和废弃代理列表上的脚本洪水。这样一来，你那些更慢、更聪明的防护手段，比如设备指纹、行为分析、MFA、按账号维度的限速，只需要面对一个小得多、也更值得分析的人群。

这才是现实中的收益：不是打造一个永不被穿透的边界，而是在攻击发生时，让数据库仍然能正常回答该回答的查询。

你可以在 Guarda 首页使用免费检测，对任意地址进行 proxy、VPN、TOR、hosting 和风险分信号分类；之后再把同一个调用接入路由前的中间件即可。