遭遇拒绝服务攻击时如何保留真实访客访问，关键不是把所有请求一概放过，而是分清哪些请求可验证、哪些业务必须优先保障。全拦截实施快，但会误伤正常用户；分层放行更细致，也需要持续观察和调整。以下五项做法可按服务能力逐步实施。
先选策略：全拦截还是分层放行
| 策略 | 适用情况 | 主要代价 |
|---|---|---|
| 全拦截或临时关闭入口 | 服务已无法稳定响应，且暂时没有可用的验证、限流或上游清洗能力 | 止损直接，但正常访客也无法访问；无法区分攻击请求与真实需求 |
| 分层放行 | 服务仍能处理部分请求，可以按路径、会话或请求行为设置规则 | 能保留关键功能，但规则配置不当可能造成误拦或防护缺口 |
若外部链路已被流量压满，应用内部的限流无法恢复入口带宽，应尽快联系网络服务提供方处理上游流量。若服务仍可响应，优先采用分层放行；全拦截适合作为短时止损手段，而非默认的长期方案。
保留真实访客的五项做法
1. 列出必须保持可用的功能
先盘点首页、登录、查询、提交订单或预约等入口，按业务影响排序；后台管理、批量导出等非关键功能可暂时关闭或收紧。确认每个入口依赖的服务，再逐项测试，避免关掉一个功能却拖垮其他页面。
2. 对可疑访问分级验证
对短时间内重复访问、行为明显偏离正常流程的请求，先要求完成验证码、浏览器检查或重新登录；已登录且行为稳定的访客可尽量减少额外验证。挑战应设有效期，并观察验证通过率和失败率。不要仅凭一个特征就长期封禁整段地址：家庭网络、公司出口和移动网络都可能由多人共用一个公网地址。
3. 按功能与身份设置限速
登录、搜索、注册和提交表单的资源消耗不同，应分别设限。可先依据攻击前正常时段的请求量设基线，再观察告警；例如，某入口请求量持续达到近期正常峰值的约2至3倍时，可短时启用更严格限制。这个范围只是排查起点，活动高峰、促销或突发新闻都可能改变正常基线。对超限请求返回明确的稍后重试提示，避免用户反复刷新。
4. 缓存可复用内容，减轻后端压力
对不含个人信息、短时间内变化不大的页面或图片，检查缓存是否生效；对账户余额、购物车等个性化内容，不应不加区分地缓存。必要时暂停报表、推荐计算等非核心任务，把数据库连接和计算资源留给关键操作。缓存内容的有效期需结合更新频率设置，不能为了减压展示过期的敏感状态。
5. 设置降级方案并边观察边回调
准备只读页面、简化版查询或延后处理等降级选项，并明确何时启用、由谁确认恢复。每次调整后观察错误率、响应时间、验证通过情况和关键业务完成量；若正常用户失败增多，先缩小规则范围或降低挑战强度，再判断是否需要进一步拦截。保留变更记录，便于攻击缓和后逐项撤销临时限制。
按顺序执行，减少误伤
- 确认服务是入口链路拥塞，还是后端计算、数据库等资源过载；前者联系上游处置，后者优先减轻后端负担。
- 列出关键功能与可暂缓功能，先保护对用户最重要的操作。
- 对重复、高频或异常流程启用分级验证和按功能限速，不要直接封禁所有访客。
- 观察关键指标与用户反馈；规则无效或误伤增加时及时回调。
- 流量恢复后逐项撤销临时规则，并复核日志和降级期间未完成的业务。
简言之，遭遇拒绝服务攻击时如何保留真实访客访问，要先判断故障位置，再把有限资源留给可识别的正常需求。分层放行并非放任流量，而是让关键功能优先运行，同时对风险请求逐步加严。
常见问题
全拦截是不是一定更安全？
它能快速减少进入服务的请求，但也会切断正常访问；如果拥塞发生在上游链路，单靠关闭应用入口未必能解决问题。
可以只允许熟客的地址访问吗？
不宜作为普遍做法。访客地址可能变化，也可能被多人共用；更稳妥的是结合登录状态、访问行为和分级验证判断。
限速阈值应该设多少？
没有适用于所有服务的固定值。先参考该入口在正常时段的请求量、资源消耗和业务峰值，再小步调整，并观察误拦情况。
攻击减弱后要立即取消规则吗？
先确认错误率和关键功能已恢复，再逐项撤销临时限制；保留仍有必要的基础防护，并检查降级期间未完成的操作。
