登录接口不断收到未完成的请求，而已进入对局的玩家仍能正常操作，这两种现象可能同时出现。处理游戏联机服务遭遇应用层慢速攻击的处置，先要分清受影响的服务层：Steamworks、PlayFab 等平台相关的登录、匹配接口通常与实时对局的网络通道不是一回事；不少游戏对局使用 UDP，而慢速 HTTP 请求主要占住处理 HTTP 的连接和资源。
因此，先别把所有玩家踢下线，也别只按来源地址封禁。以下五步从确认范围到验证恢复，尽量缩小对正常连接的影响。
第一步：画清受影响的连接路径
把玩家流程拆成登录认证、组队或匹配、房间分配、实时对局几段，分别查看其入口和承载协议。通过服务端日志、网关记录与客户端报错时间，确认异常集中在哪个接口、区域或版本；再核对对局中的延迟、丢包和断线反馈是否同步恶化。
如果登录和匹配受阻、对局流量基本正常，优先处理对应的 HTTP/API 入口，不要把措施直接套到 UDP 对局服务上。若匹配成功率下降但没有明显请求堆积，也要排查依赖服务或正常流量突增，不能仅凭玩家排队就认定是攻击。
第二步：留证并判断请求是否真的“慢”
保存相关时间段的原始访问日志、请求头到达情况、连接关闭原因和网关侧记录，并校准各系统时间。重点看请求是否长时间只发送部分 HTTP 头或请求体、是否反复占着连接却迟迟不完成，以及这些请求是否集中在少数接口。日志中应尽量避免记录密码、令牌等敏感内容。
慢速请求与突发的大量短请求不同：前者可能以较低的到达频率持续占用连接，后者则更像短时间流量洪峰。把两者区分开，才能决定是调超时、做请求速率控制，还是扩充容量并检查依赖。
第三步：先对入口做局部保护
- 按接口设限。对登录、匹配等入口分别设置请求频率、并发和未完成请求上限；公开查询与需要身份校验的操作应使用不同规则，避免用一条全局限制误伤所有玩家。
- 限制不完整请求。在能够解析 HTTP 的网关或服务端设置请求头、请求体的接收时限和大小上限。具体数值应结合正常客户端、移动网络状况和请求类型压测确定；时间过短会让网络较差的玩家频繁失败，过长则可能继续留下占用连接的空间。
- 谨慎处理来源。优先结合账号、会话、接口行为和来源网络判断。校园网、运营商网络等可能让许多玩家共用出口地址，仅凭单一地址封禁容易造成连带影响。
如果请求经由反向代理或 CDN，先确认它实际代理了哪些协议和端口。只支持 HTTP 的代理不能自动保护独立的 UDP 对局通道；有些平台提供 UDP 转发能力，也须确认产品配置确实覆盖目标流量。游戏联机服务遭遇应用层慢速攻击的处置应落在受影响的入口，不宜未经验证就切换整套网络路径。
第四步：分层收紧，保留玩家恢复通道
先对受影响接口启用临时规则，再观察登录完成、匹配排队、正常请求被拒情况和对局断线反馈。若可疑请求仍占用资源，逐步收紧对应的未完成请求上限或接收时限；若正常玩家错误增加，回退最近一项改动，并检查规则是否覆盖了共享网络或特定客户端版本。
避免同时改动网关、认证、匹配和对局节点，否则出现问题时难以判断原因。需要扩容时，先确认瓶颈是否确实在入口服务；单纯增加后端实例，未必能解决前置连接被长期占用的问题。
第五步：验证恢复并安排复查
用受控测试账号走完登录、匹配、进入房间和退出流程，再通过小范围玩家或分批放量观察。确认正常请求能够完成、异常连接会按规则释放，并检查规则调整后是否出现新的客户端兼容问题。解除临时限制前保留原始配置和变更记录；如果异常反复，按时间线比较接口行为，而不是只看某一时刻的连接数。
游戏联机服务遭遇应用层慢速攻击的处置不是一次封禁动作，而是识别入口、限制异常占用、验证正常玩家体验的闭环。平时记录各接口的正常请求特征，并准备可回退的规则，能让突发处理更快，也更少波及对局。
常见问题
慢速攻击会直接让 UDP 对局断线吗？
不一定。若被占用的是独立的 HTTP 登录或匹配入口，对局通道可能仍正常；但认证、房间分配等依赖受阻时，玩家可能无法进入或重新连接。
能不能直接封禁所有可疑来源地址？
不建议。共享出口可能对应许多正常玩家。先结合接口、账号或会话行为判断，并优先采取范围更小、便于回退的限制。
超时设置得越短越安全吗？
不是。过短可能误伤高延迟或网络不稳定的客户端。应按接口类型和真实客户端表现设定，并在变更后检查正常请求失败情况。
处置时要不要关闭登录或匹配服务？
只有在局部限流和超时措施无法控制影响、且继续开放会扩大故障时，才考虑临时关闭具体入口；优先保留不受影响的对局连接，并明确恢复条件。
