登录入口既要挡住异常请求，也不能把正常用户一起拦在门外。大流量攻击下如何维持登录服务可用，关键是先判断压力来自哪里，再逐层保护认证流程，并为合法用户保留清晰的降级通道。
第一步：确认是访问高峰还是恶意流量
先查看负载均衡器、Web 服务器和认证服务的请求量、错误率、响应时间及来源分布，并与平日同一时段比较。流量突然上升但登录成功率稳定，可能是活动或业务高峰；失败请求、重复尝试或少数路径占比明显升高，则需要重点排查自动化请求。不要只看总流量：登录页请求量增加，不代表密码校验请求也同比增加。
- 按登录页、提交认证、验证码和找回密码等接口拆分统计。
- 同时观察数据库连接、认证服务队列和外部身份提供方的响应状况。
- 记录异常开始时间、受影响接口和已采取动作，避免不同团队重复操作。
第二步：在边缘和入口处削减无效请求
先利用 CDN 或 Web 应用防火墙过滤明显异常的请求特征，再在反向代理层限制请求速率。对重复访问登录提交接口的来源可实施短时限制；对共享办公网络、校园网等大量用户共用出口的环境，不宜只按来源地址严厉封禁。
可采用令牌桶实现平滑限速，并为正常突发留出少量余量。阈值应根据历史峰值和压测结果设定；临时调整后观察误拦截率，避免一次性扩大限制范围。必要时优先限制高风险请求，而非关闭整个登录入口。
第三步：保护认证链路，避免登录请求拖垮后端
登录提交通常比展示登录页更消耗资源。把静态页面、图片和样式交由缓存服务处理，减少请求进入应用；不要缓存个人认证结果、验证码答案或会话凭据。对密码校验、短信发送和找回密码等操作分别设置限额，防止某一项被滥用后挤占全部资源。
可逐步启用登录限流：按账号、来源和设备信号组合判断，而不是仅凭单一条件封锁。若连续失败次数达到内部设定的风险线，可增加等待时间或要求验证码，再对高风险操作启用额外验证。验证码本身也要限频，避免其接口成为新的压力点。
第四步：扩容并隔离故障，保住核心认证能力
确认应用实例或队列确实达到容量上限后，再按平台能力增加实例，并检查负载均衡是否已把请求分散到新实例。扩容不能解决数据库连接耗尽、慢查询或单一身份服务故障；这类问题要同步限制并发、检查连接池，并对非关键功能实施熔断或暂缓处理。
- 优先保障登录校验与已登录用户的关键操作，暂停非必要的推荐、统计或通知任务。
- 对短时重复读取的数据使用有边界的缓存，设置合理过期时间；认证凭据和个人敏感信息不应因此被公开缓存。
- 若依赖的短信或第三方身份服务变慢，提供明确提示和安全的重试间隔，不要让请求无限堆积。
第五步：小步调整、验证恢复并复盘
每次更改限速、规则或实例数量后，都观察登录成功率、接口延迟、拒绝请求比例和后端队列。若正常用户失败明显增加，先回退最近的高影响规则，再逐项定位原因。流量回落后不要立刻撤掉所有防护，应分阶段恢复功能，并确认告警、日志和容量余量恢复正常。
事后整理有效规则、误拦截来源、扩容瓶颈和恢复耗时，形成值班清单。大流量攻击下如何维持登录服务可用，最终依赖可观测、可回退的分层措施，而不是单独增加服务器或无限提高验证码难度。
常见问题
流量高时，是否应该直接封禁来源地址？
不建议作为唯一措施。共享出口可能承载大量正常用户；优先组合请求频率、接口行为和账号风险判断，并设置短时、可撤销的限制。
登录页面能打开，为什么仍然无法登录？
页面加载与认证提交是不同环节。认证服务、数据库连接池、验证码或外部身份提供方任何一处拥塞，都可能让页面正常但提交失败，应按接口和依赖逐项检查。
是否应该在高峰期强制所有人使用验证码？
全面启用可能增加正常用户的操作负担，也可能让验证码服务承受额外压力。更稳妥的做法是对高风险请求逐步加验，并监测误拦截和验证成功情况。
怎样判断处置已经有效？
观察登录成功率和延迟是否回到业务可接受范围，同时确认错误率、后端队列与拒绝比例没有持续恶化；单看流量下降不足以证明服务恢复。