随着大语言模型生态的快速扩张，各类 LLM 爬虫、检索增强生成（RAG）数据抓取工具以及 AI Agent 自动化请求正以前所未有的规模冲击生产环境。与传统爬虫不同，LLM 驱动的 bot 往往在短时间内发起海量 HTTPS 连接，每条连接都需要完成完整的 TLS 握手才能进入 HTTP 层处理。这种攻击形态隐蔽且破坏力强 —— 服务器在握手阶段就已耗尽 CPU、文件描述符和临时端口资源，业务层的限流规则根本无法触发。本文将从边缘终止、连接层限流、行为检测三个维度给出可落地的工程方案。

TLS 握手过载的本质伤害

TLS 握手过载与传统 DDoS 攻击的本质区别在于，伤害发生在加密链路建立阶段，远早于应用层逻辑介入。每一次完整的 TLS 1.3 握手需要服务器执行一次密钥协商、一次椭圆曲线运算以及若干次哈希计算，这些操作的 CPU 成本是普通 HTTP 请求的数倍。当数千个 LLM 爬虫同时发起新建连接时，服务器会陷入这样的困境：所有 CPU 核心忙于握手计算，真正的业务请求被迫排队等待，甚至触发 OOM kill。

更棘手的是，LLM 爬虫的请求模式极其符合正常客户端特征：携带合理的 User-Agent、遵守 robots.txt 协议、请求频率看似均匀分布。传统基于频率阈值的防御手段极易产生误判，而基于 IP 黑名单的方案面对爬虫轮换 IP 的行为几乎失效。某中型技术博客平台在 2025 年底遭遇的典型案例就很说明问题 —— 部署在 Cloudflare 后的源站仍因 TLS 握手过载导致响应时间从 200ms 飙升至 15s，排查发现是某主流 LLM 平台的检索 bot 在凌晨时段以每秒 200+ 新建连接的速度抓取站点全量文章。

防御第一层：边缘终止 TLS

解决 TLS 握手过载最根本的思路，是将握手成本从源站转移到具备海量连接处理能力的边缘节点。CDN 或云 WAF 在架构上天然适合承担这一角色 —— 它们部署在用户与源站之间，拥有遍布全球的边缘节点和专门的 TLS 加速硬件，能够以极低成本处理海量握手请求。当所有 HTTPS 流量在边缘节点完成终止后，只有通过验证的请求才会以 HTTP 或 HTTP/2 方式转发到源站，源站承受的握手压力将降低一到两个数量级。

以 Cloudflare 为典型代表，启用 CDN 后源站只需要配置仅允许边缘 IP 访问的安全组规则，所有直接指向源站的外部流量即可被无条件拦截。这种架构改变的核心理念是：将安全边界从应用层下沉到网络边缘，让边缘基础设施成为第一道防线。企业在评估 CDN 方案时需要重点关注两项指标：一是边缘节点是否支持 TLS 1.3 会话恢复（session resumption），这能显著减少重复握手的开销；二是是否提供连接复用（connection reuse）能力，允许边缘节点与源站之间维持少量长连接而非每次请求新建连接。

对于不便使用 CDN 的场景，可采用自建边缘代理的方案。HAProxy 和 Nginx 都支持 TLS 终止功能，将这些反向代理部署在源站前端即可实现类似效果。关键配置要点包括：启用 TLS 会话票据（session ticket）以支持快速恢复、设置合理的空闲超时（idle timeout）以维持连接池效率、配置 OCSP stapling 减少客户端的证书验证延迟。

防御第二层：连接层限流

即便使用了边缘终止，部分需要高安全级别的场景仍需在源站侧部署连接层限流机制。LLM 爬虫的一个显著特征是短时间内发起大量新建连接，而非复用已有连接 —— 这一行为与正常用户的使用模式形成鲜明对比。HAProxy 和 Nginx 提供的连接追踪功能正是针对这一弱点的精准打击。

在 HAProxy 中，可以利用 sticky table 记录每个客户端 IP 的请求速率，并通过 acl 规则动态判定是否超过阈值。核心配置逻辑是：定义一个存储最近 10 秒请求速率的 stick-table，当某个 IP 的每秒请求数超过预设值时返回 429 状态码而非继续处理。这种方案的优势在于，限流判断发生在 TLS 握手完成后的连接层，消耗的资源远低于完整握手，因此即使遭受大规模连接洪水，HAProxy 仍能保持响应。

Nginx 的限流机制则更侧重于应用层。它提供两个核心指令：limit_conn 用于限制单个 IP 的并发连接数，limit_req 用于限制请求速率。两者的典型配置组合是在 http 块中定义共享内存区域，然后在 server 或 location 块中引用。对于 login、search、API 等高频访问端点，建议设置稍严格的阈值（如每秒 10 个请求、突发不超过 20），而静态资源路径则可以设置得更宽松。

需要特别强调的是，连接层限流不应被视为万能方案。它的主要作用是兜底防护，防止极端情况下的资源耗尽，而非替代边缘终止和上层检测。实践中常见的问题是源站直接暴露公网 IP 导致攻击流量绕过了 CDN，此时即便配置了完美的限流规则，服务器仍需先完成 TLS 握手才能执行限流逻辑，防御效果大打折扣。因此最稳妥的部署模式是：CDN / 边缘代理处理绝大多数握手流量 + 源站限流规则作为最后防线。

防御第三层：行为检测与流量分级

传统的基于规则匹配（如 IP 黑名单、User-Agent 过滤）在面对高度拟人化的 LLM 爬虫时往往力不从心。2026 年的 bot 防御趋势转向行为分析和流量分级：不再简单地判定请求是 “正常” 还是 “异常”，而是对流量进行分级处理，为不同类型的客户端提供差异化的服务品质。

行为检测的核心思路是采集客户端的多维度特征，包括 TLS 握手指纹（JA3/JA4）、TCP 窗口行为、首次请求的路径分布、请求间隔的标准差等。正常用户的请求往往呈现高度随机的访问模式，而自动化爬虫则倾向于按照固定节奏遍历站点结构。通过机器学习或规则引擎对这些特征进行评分，系统可以将流量划分为可信客户端、需要挑战的疑似 bot 和直接拦截的恶意流量三个等级。

流量分级带来的工程价值在于：对于被判定为可疑但无法确认的流量，系统可以返回简化的静态页面或缓存内容，而非触发完整的动态渲染；对于确认恶意的流量，则可以直接丢弃连接并记录日志供事后分析。这种分级的理念在 Cloudflare Bot Management、Google reCAPTCHA v3 等产品中已有成熟实现，中小型团队也可以基于开源方案（如 ModSecurity 规则集 + Nginx）构建类似能力。

工程落地的关键参数清单

以下是一套经过生产验证的防御配置基准值，适用于日活数万至数十万级别的中型站点。对于更大规模的业务场景，需要根据实际流量特征进行动态调优。

在边缘终止层面，建议 TLS 会话票据有效期设置为 1 小时、空闲连接超时设置为 120 秒、启用 HTTP/2 和 HTTP/3 以鼓励连接复用。源站侧 HAProxy 的连接限流推荐阈值为每 IP 每秒新建连接不超过 30 个、突发容忍不超过 100、超过阈值后返回 429 并在响应头中携带 Retry-After 字段。Nginx 限流针对 API 和登录端点的推荐配置为每秒 10 个请求、突发 20、超过后返回 503 而非直接关闭连接以避免误伤正常用户。

监控层面需要重点关注三个指标：TLS 新建连接速率（可通过 OpenSSL s_client 或 Prometheus node_exporter 的 TLS 指标采集）、连接队列长度（HAProxy 的 backend 队列和 Nginx 的 accept 队列）、以及握手失败率。如果新建连接速率持续超过 CPU 处理能力的 60%，应触发告警并考虑扩容或启用更严格的限流规则。

总结

LLM 爬虫导致的 TLS 握手过载是 AI 时代运维团队必须面对的新型挑战。应对这一问题的核心思路不是在与爬虫的对抗中试图 “赢在每一回合”，而是从架构层面重构流量路径 —— 让边缘基础设施承担握手成本、让连接层限流作为安全气囊、让行为检测作为智能大脑。三层防御形成的有机整体既能有效化解握手洪峰，又能在不影响正常用户体验的前提下精准识别并处置恶意流量。运维团队在落地时应优先验证边缘终止的部署完整性，再逐步叠加连接限流和行为检测能力，形成纵深防御体系。

资料来源：Reddit 技术社区关于多层次 LLM 爬虫防御的讨论（/r/devops）、HAProxy 官方博客 rate limiting 示例、NGINX 社区博客 rate limiting 最佳实践。