扫描流量不等于攻击：搜索引擎、监控探测和配置错误都可能产生异常请求。网站主机遭持续扫描时的自动封禁规则设计，重点不是“见到 404 就封”，而是判断请求是否集中、重复且明显偏离业务，再分层处置。以下方法适用于常见的 Linux 主机和网站服务，阈值应先观察日志再调整。
先定义什么行为值得封
从 Nginx 或 Apache 访问日志中，留意同一来源在短时间内反复访问不存在的管理入口、备份文件或敏感配置路径，例如 /wp-login.php、/.env、/phpmyadmin/。这些路径只是识别线索；如果网站确实提供对应功能，就不能仅凭路径命中封禁。
将信号组合起来更稳妥：单位时间请求数、不同路径的数量、连续 404 或 403、请求是否触及登录接口，以及来源是否同时尝试多类常见文件名。单一 User-Agent、一次 404 或访问 robots.txt，都不足以单独触发封禁。可按客户端 IP 和路径分别统计，并排除健康检查、已知搜索引擎验证流量及内部监控地址。
用分级阈值控制误封
先限速，再临时封禁
对普通页面设置较宽松的速率限制，对登录、搜索等容易被反复请求的路径单独设限。以访问量不高的普通网站为例，可先观察每个来源 10 秒内的请求分布，再把明显高于正常访问的来源送入短时封禁名单。具体起点可能落在每 10 秒十余次至数十次请求，但页面复杂度、代理缓存和共享出口会改变正常范围，不能照搬成通用标准。
连续多次触发后，可用 Fail2ban 按日志匹配条件执行临时封禁；Nginx 的限速适合在请求到达应用前削峰，主机防火墙则适合拦截已确认的恶意来源。若前面还有反向代理或 CDN，先确认日志记录的是访客真实地址，而非代理地址，否则可能把大量用户一起封掉。规则也要考虑 IPv6，避免只处理 IPv4。
封禁时间逐级增加
首次命中可先限制请求或封几分钟；短时间内重复触发，再延长到几十分钟或数小时。对反复出现且证据充分的来源，才考虑更长时间的封禁。长期封禁应保留人工复核和解封途径；共享网络、企业出口和移动网络可能由许多人共用同一公网地址，永久拉黑的误伤成本较高。
按步骤上线并验证
- 收集基线：查看至少数天的访问日志，区分正常高峰、爬虫流量、监控请求和明显的路径探测。
- 写清匹配条件：限定统计时间、请求路径范围、状态码组合和重复次数；不要把所有 404 都算作违规。
- 先观察后执行：初期只记录“若启用将封谁”，检查是否包含代理、监控或正常用户，再开启自动处置。
- 设定回滚：记录封禁原因和到期时间，保留管理员解封方式，并确认规则重载失败时不会影响现有网站服务。
- 定期复盘：检查误封申诉、访问日志和服务器资源变化；网站改版或新增入口后，重新评估路径名单与阈值。
需要主机托管、网络防护与运维支持配合的场景，可了解德讯电讯的相关服务，再按自身架构确认日志获取、规则管理和故障处理边界；具体能力与服务范围应以实际沟通为准。
常见问题
只有 404 请求，要自动封禁吗？
不建议。先看请求频率、路径分散程度及是否涉及敏感入口；正常链接失效也会产生 404。
封禁规则应该放在网站还是主机层？
限速可放在 Nginx 等 Web 服务层；需要阻止来源继续连接时可用主机防火墙。使用 CDN 或代理时，应先确认真实客户端 IP 的传递与校验方式。
封多久比较合适？
从短时限制开始，按重复触发逐步延长，并结合误封情况调整。网站主机遭持续扫描时的自动封禁规则设计，应以可观测、可撤销为前提，而不是追求最长封禁时间。
