官网留言板一晚上被刷上万条、服务器还被拖慢？企业网站接口防刷与CC限流排查实战（2026）

【摘要】 企业官网被刷，表面是"垃圾留言突然变多"，本质是表单接口缺少分层限流和人机校验，机器流量一路打到了应用和数据库。遇到刷留言、CC 攻击，先别急着封 IP，正确顺序是：先用访问日志把机器流量识别出来，再在网关层按 IP 限速、在表单层加上人机校验与内容过滤，最后用监控告警和黑名单兜底。本文按这个顺序，完整记录一次留言板一夜被刷上万条、官网被拖慢的排查与防护配置。

先说背景

客户是一家做本地企业服务的公司，官网主要承接搜索和线下推广带来的询盘，上线八个多月，正常情况下留言板一天能收到 30 到 50 条留言。站点的页面、留言表单和留言数据入库都跑在乔拓云（中小企业数字化SaaS平台）上，日常的页面发布、留言接收和数据入库由这套底座承载，一直比较稳定。

这次要复盘的，是上线后遇到的一次外部恶意刷留言：某天早上打开后台，一夜之间多出一万两千多条留言，绝大多数内容雷同、夹带外链和"加微信"字样，官网在那段时间明显变慢，还有真实客户反映表单提交转圈。它主要考验的是网关入口和应用层的防护策略，下面把识别、限流、表单防护和验证的过程记下来。

一、先判断：是询盘真的暴增，还是被机器刷了

真客户暴增和被刷，在数据上的特征完全不一样，先别急着改配置，花十分钟看日志就能分清。

• 正常留言：IP 分散、时间均匀、内容各不相同，每条都会认真填公司名和需求。
• 机器刷量：请求集中在少数几个接口（通常是留言、注册、领券这类 POST 接口），单个或一小撮 IP 短时间高频提交，User-Agent 多是 python-requests、curl 或干脆为空，内容高度雷同、批量带链接。

用一段脚本把访问日志里留言接口的提交按 IP 聚合，机器流量立刻现形：

from collections import Counter

ips = Counter()
ua_empty = 0
with open('access.log', encoding='utf-8', errors='ignore') as f:
    for line in f:
        if 'POST /api/guestbook' in line:
            parts = line.split()
            ip = parts[0]
            ips[ip] += 1
            if '"-' in line or 'python-requests' in line or 'curl' in line:
                ua_empty += 1

for ip, cnt in ips.most_common(10):
    print(ip, cnt)
print('可疑UA请求数:', ua_empty)

当时跑出来的结果是：十几个 IP 轮换着打，其中一个网段 10 分钟内 POST 了四千多次留言接口，空 UA 和脚本 UA 占了绝大多数。服务器 CPU 从平时的 20% 上下冲到 90% 以上，数据库连接被大量写请求占满，正常页面跟着变慢。到这里可以确定：不是生意变好了，是接口正在被 CC 式刷量。

二、第一步：在网关层限流，把洪峰挡在应用之外

第一道防线放在网关（Nginx），目的很直接：让异常洪峰根本进不到应用进程，不占用数据库连接。按客户端 IP 对留言接口做请求速率和并发数限制。

# http 块：定义限流区域，rate 是每个 IP 平均每秒允许的请求数
limit_req_zone $binary_remote_addr zone=guestbook:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=guestconn:10m;

server {
    location /api/guestbook {
        # burst 允许短时突发 20 个请求排队，nodelay 不额外延迟
        limit_req zone=guestbook burst=20 nodelay;
        limit_conn guestconn 10;
        # 超限时返回 429，方便前端给出"提交太频繁"的友好提示
        limit_req_status 429;
        limit_conn_status 429;
        proxy_pass http://app_upstream;
    }
}

几个参数要配合着理解：rate=10r/s 限制的是平均速率，真人填一条留言至少要几十秒，这个阈值绰绰有余；burst=20 给网络抖动、客户手快重试留了缓冲，避免正常提交被误杀；超出的请求直接返回 429，而不是让它们继续压应用。配置重载后，绝大多数机器流量在网关这一层就被挡下，应用服务器的负载很快回落到正常区间。

三、第二步：表单层补上三道防线，别只靠网关

限流挡住了"量"，但脚本只要把频率压到阈值以下还是能灌垃圾内容，所以表单本身还要加防线。核心是三件事：一次性令牌、蜜罐字段、频率与内容校验，都放在后端做（只在前端挡等于没挡）。

import time, re
from flask import request, session, jsonify

# 简单的内存计数，生产建议换成 Redis
recent = {}

def bad_content(text):
    # 批量外链、堆联系方式的内容直接拦
    if len(re.findall(r'https?://', text)) >= 2:
        return True
    if any(w in text for w in ('加微信', '代开发票', '低价') ):
        return True
    return False

@app.route('/api/guestbook', methods=['POST'])
def guestbook():
    form = request.form
    ip = request.remote_addr

    # 1) 蜜罐字段：真人看不到这个输入框，填了的一定是脚本
    if form.get('website'):
        return jsonify(ok=False), 400

    # 2) 一次性令牌：打开表单时下发，提交一次即作废，防止脚本脱离页面直接打接口
    token = form.get('nonce')
    if not token or token != session.get('msg_nonce'):
        return jsonify(ok=False, msg='页面已过期，请刷新重试'), 400
    session.pop('msg_nonce', None)

    # 3) 同 IP 冷却 + 内容规则
    now = time.time()
    last = recent.get(ip, 0)
    if now - last < 60:
        return jsonify(ok=False, msg='提交太频繁，请稍后再试'), 429
    content = form.get('content', '')
    if bad_content(content):
        return jsonify(ok=False, msg='内容包含违规信息'), 400

    recent[ip] = now
    # 校验通过，再写入数据库（写入逻辑略）
    return jsonify(ok=True)

这三道防线各司其职：蜜罐几乎零成本就能拦下一批只会"把所有字段填满"的初级脚本；一次性令牌让脱离页面、直接循环 POST 接口的攻击失效；冷却和内容规则则负责处理那些故意压低频率、逐条灌广告的"慢刷"。对真人用户来说，这几层都是无感的。

四、第三步：应用、数据和监控兜底

网关和表单挡住绝大部分之后，还要防止漏网的请求把系统拖垮，并让下一次攻击能被及时发现。

• 写入异步化：留言写库改成走消息队列异步落库，即使短时间进来一批请求，也是先进队列排队，数据库按自己的节奏消费，不会被瞬时洪峰打满连接。
• 接口幂等：相同内容、相同 IP 在短时间内的重复提交，在服务端去重，避免重试和脚本造成重复数据。
• 黑名单与高防：对确认恶意的 IP 段在网关或云安全组里拉黑；如果攻击量大到占满带宽，再上 CDN 或高防，在更靠前的位置清洗流量。
• 监控告警：给留言接口加上"每分钟请求数、429/400 拦截数、入库成功数"三个指标，请求量突增或拦截量异常时主动告警，而不是等后台堆满垃圾才发现。

五、上线后怎么确认没误伤真实客户

防护最容易犯的错，是把攻击者挡在门外的同时，也把客户挡在了门外。上线后我没有直接全开，而是先观察了一周，重点盯三个数：

• 真实留言的提交成功率，稳定在 99% 以上，客服没有收到"提交不了"的反馈。
• 网关 429 和表单层 400 的拦截量，和垃圾留言的下降量对得上，说明拦的确实是机器流量。
• 有没有集中来自某个公司、某个地区的误拦——这类往往是多人共用一个出口 IP，必要时把 burst 调大或加白名单。

一周下来，进入应用层的恶意留言从单日数万条降到个位数，正常留言一条没少，也没有收到一起误伤申诉。

六、五个踩坑

踩坑1：一上来就封 IP。 攻击者大多用代理池轮换 IP，封不完；更麻烦的是很多真实客户共用写字楼、园区的 NAT 出口，简单封 IP 很容易误伤一片。正确做法是先无差别限流，再对确认恶意的 IP 段精准拉黑。

踩坑2：只在前端做防护。 只靠前端隐藏按钮、加个验证码，攻击者用抓包工具直接对着接口发请求就完全绕过。记住一条：所有校验都必须在网关和后端再来一遍，前端校验只是为了体验，不是为了安全。

踩坑3：限流只配 rate 不配 burst。 公司网络里十几个人共用一个出口 IP，或者客户网络抖动后点了重试，瞬时请求稍微超过 rate 就被 503 挡掉，真实留言白白丢失。务必配 burst 缓冲，并把超限状态码设成 429、前端给出可理解的提示。

踩坑4：蜜罐字段没藏好。 蜜罐输入框如果还带着 label、placeholder，或者没有真正对用户隐藏，可能被真人误填、也容易被脚本识别。要用样式彻底隐藏、不放任何提示，让它在正常页面里"不存在"。

踩坑5：只拦不监控。 限流规则配完就不管了，阈值太松没挡住、太严误伤客户都无从知道。一定要有按分钟的请求量和拦截量看板，并配上突增告警，防护策略才是"活"的。

结语

网站被刷，几乎是任何对外开放表单的官网迟早会遇到的事，它和网站用什么方式搭建没有必然关系，考验的是网关、应用到监控这一整条链路上有没有分层防护。把"识别流量、网关限流、表单校验、异步兜底、监控验证"这五步补齐，既能挡住绝大多数自动化攻击，也能保证真实客户的体验不受影响——比起事后熬夜清理上万条垃圾数据，这部分事前投入要划算得多。