很多游戏服、App 后端真正被打崩，并不是因为服务器 CPU 不够强，也不是因为带宽一开始就太小，而是架构上把所有入口都暴露在同一个公网 IP 上：游戏官网、登录接口、支付回调、游戏网关、数据库连接、后台管理，全都走一台机器或一个公网地址。平时访问量不大时看不出问题，一旦遇到 DDoS、CC、UDP Flood、SYN Flood 或恶意刷接口，整个业务就会一起掉线。

所以防御 DDoS 攻击不能只问“买多大防护值”，而要先拆清楚：攻击打的是带宽，还是连接数，还是应用接口？业务最怕的是游戏掉线，还是 App 登录失败？源站 IP 有没有暴露？后端服务有没有分层？这些问题比单纯堆防护值更重要。

一、游戏/App 后端常见的 DDoS 攻击，不是一种打法

游戏后端和普通网站不一样，它通常同时存在 TCP、UDP、HTTP API、WebSocket、数据库连接、支付回调等多种入口。不同攻击方式，对服务器的影响完全不同。

1. UDP Flood：游戏服最常见的带宽型攻击

很多游戏网关、实时对战、语音、房间同步、状态上报都会用到 UDP。如果攻击者直接向游戏端口打 UDP Flood，会快速吃满公网带宽。

比如服务器本身只有：

这种情况下，CPU、内存再强也没用，因为流量在进入服务器前就已经堵住了。

2. SYN Flood：把连接队列打满

如果游戏/App 后端使用 TCP 连接，比如登录服、长连接网关、WebSocket、API 服务，SYN Flood 会制造大量半连接，让服务器连接队列被占满。

表现通常是：

• Ping 可能正常；
• 服务器 CPU 不一定很高；
• 端口连接不上；
• App 登录转圈；
• 游戏客户端提示连接超时；
• Nginx 或业务服务日志里没有明显请求记录。

这类攻击看起来像“服务器没响应”，但本质上是连接层被耗尽。

3. HTTP CC 攻击：App API 最容易被拖垮

App 后端最怕的不是单纯大流量，而是攻击者模拟真实用户访问接口。

例如：

/api/login
/api/user/profile
/api/order/list
/api/game/room/list
/api/pay/status

如果这些接口后面会查数据库、查 Redis、请求第三方接口，那么攻击者只需要用几千并发持续访问，就可能让后端资源被吃满。

典型表现是：

所以 App 后端防 DDoS，不能只看高防带宽，还要看接口限流、缓存、WAF、业务鉴权。

4. 源站 IP 暴露：很多防护失效的根本原因

不少客户前面接了 CDN、高防 IP 或 WAF，但源站 IP 仍然暴露，比如：

• 游戏客户端配置里写死了源站 IP；
• App 安装包里能反编译出 API 地址；
• 历史 DNS 解析记录暴露；
• 管理后台和业务接口共用一个 IP；
• 支付回调、对象存储回源、测试环境暴露真实 IP；
• 服务器直接对外开放所有端口。

一旦攻击者拿到源站 IP，就可以绕过 CDN 或高防入口，直接打源站。

二、先明确：游戏/App 后端防护不能只靠一台高防服务器

很多人理解的防御方式是：买一台高防服务器，把业务全部放进去。这个方法能解决一部分问题，但不是最稳的方式。

更推荐的结构是：

用户访问
  ↓
高防 IP / 高防 CDN / WAF / 游戏加速入口
  ↓
业务入口层：Nginx / 网关 / SLB / 反向代理
  ↓
应用服务层：登录服 / API 服务 / 游戏逻辑服
  ↓
数据层：MySQL / Redis / MongoDB / 日志服务

这套结构的核心是：公网攻击流量不要直接碰到真正的业务源站。

三、不同业务应该用不同防护方案

1. App 后端：重点防 API CC 和登录接口刷爆

App 后端通常以 HTTP/HTTPS API 为主，攻击重点一般是接口层。

推荐架构：

用户 App
  ↓
高防 CDN / WAF
  ↓
Nginx API 网关
  ↓
业务 API 服务
  ↓
Redis 缓存 / MySQL 数据库

适合的服务器配置可以这样规划：

如果部署在香港服务器，可以选择类似下面的组合：

这里的重点不是一开始就买最高防，而是把 API 入口和数据库拆开，避免攻击接口时直接把数据库拖死。

2. 游戏后端：重点防 UDP、TCP 连接和网关暴露

游戏业务和 App 不一样，很多游戏对延迟非常敏感。香港服务器适合亚洲用户访问，但香港普通线路不适合直接承受大规模 DDoS 攻击。

推荐结构：

玩家客户端
  ↓
高防游戏入口 / 高防 IP / 游戏清洗节点
  ↓
游戏网关服
  ↓
登录服 / 匹配服 / 房间服 / 逻辑服
  ↓
数据库 / Redis / 日志服

游戏服务器建议不要把所有服务放在一台机器上，至少要分成：

适合游戏后端的服务器配置示例：

如果游戏协议走 UDP，建议优先确认高防是否支持 UDP 清洗。很多普通 Web 高防主要保护 HTTP/HTTPS，对游戏 UDP 协议支持并不一定理想。

四、服务器配置怎么选？不能只看 CPU，还要看带宽和连接模型

1. CPU：App 看接口计算，游戏看主频和并发

App 后端如果有大量接口计算、加密、订单处理、数据聚合，CPU 核心数比较重要。

游戏后端则要看业务模型：

例如：

如果业务有明显的高并发连接，AMD EPYC 高主频平台通常比老旧低频多核平台更适合做入口服务。

2. 内存：防止业务被攻击时先把自己拖死

很多 CC 攻击不是马上打满带宽，而是让业务进程堆积请求。

例如：

正常情况下：
200 QPS，接口响应 80ms，服务器压力正常

被刷接口时：
5000 QPS，接口响应变成 2s，连接堆积，内存上涨，数据库连接耗尽

这时候内存太小，会出现：

• PHP-FPM 进程堆满；
• Java 堆内存压力上升；
• Node.js 事件循环阻塞；
• Redis 被打爆；
• MySQL 连接数耗尽；
• 系统开始使用 Swap，整体雪崩。

所以中型 App 或游戏后端，不建议只用 8G 内存长期跑生产环境。比较稳妥的是：

3. 磁盘：DDoS 不只打网络，也可能拖垮日志和数据库

被攻击时，日志量会突然放大。如果所有访问日志、错误日志、数据库、业务文件都写在同一块普通 SSD 上，很容易出现 IO 抖动。

建议：

Nginx 在被 CC 攻击时，如果每个请求都完整写 access.log，磁盘也可能成为瓶颈。可以对健康检查、静态资源、被拦截请求做日志降级。

4. 带宽：普通 CN2 线路适合访问体验，不等于抗攻击

很多香港服务器会使用类似：

100M BGP + 15M/25M CN2 直连
1G 三网直连回国
3G 国际带宽

这些线路的重点是访问质量、回国延迟、国际带宽能力，不是无限抗 DDoS。

比如 25M CN2 很适合国内用户访问 App 后台、游戏官网、业务 API，但如果遭遇 2Gbps、10Gbps、几十 Gbps 的 UDP Flood，普通业务带宽一定会被打满。

所以要分清：

不要把“访问线路好”误解成“能抗大流量攻击”。

五、推荐的防御架构：把公网入口和真实源站拆开

方案一：App 后端防护方案

适合：电商 App、工具 App、会员系统、支付系统、API 服务、小程序后端。

推荐架构：

用户 App
  ↓
高防 CDN / WAF
  ↓
API 网关 Nginx
  ↓
业务服务集群
  ↓
Redis / MySQL

服务器配置建议：

关键设置：

• 登录接口单独限流；
• 短信验证码接口单独限流；
• 支付回调只允许白名单 IP；
• 管理后台不对公网开放，或只允许固定 IP；
• 源站 IP 不直接解析到公网；
• 数据库端口禁止公网访问；
• Redis 禁止公网访问；
• Nginx 层做请求频率限制；
• 应用层做用户、设备、IP、Token 多维度限流。

方案二：游戏后端防护方案

适合：手游、页游、棋牌、轻量竞技、房间制游戏、私有游戏后端。

推荐架构：

玩家客户端
  ↓
高防游戏入口
  ↓
游戏网关服
  ↓
登录服 / 匹配服 / 逻辑服
  ↓
Redis / MySQL / 日志服

服务器配置建议：

关键设置：

• 游戏客户端只连接高防入口，不暴露源站 IP；
• 登录服和游戏网关分离；
• 数据库只允许内网访问；
• 管理后台单独域名，限制访问 IP；
• 游戏端口不使用默认或容易被猜测的端口；
• 对异常连接、空连接、重复握手做丢弃；
• 对单 IP 连接数、单设备请求频率做限制；
• UDP 游戏协议要做包格式校验，不能所有 UDP 包都进入业务逻辑。

方案三：高防 IP + 香港源站方案

如果业务主要用户在国内或亚洲，希望访问延迟低，又担心 DDoS，可以采用：

用户
  ↓
高防 IP
  ↓
香港源站服务器

适合：

• 游戏登录服；
• App API；
• 官网后台；
• 会员系统；
• 支付接口；
• 中小型游戏网关。

源站服务器可以选择香港节点，例如：

这类方案的重点是：高防 IP 负责清洗，香港源站负责低延迟业务处理。

六、Nginx 层应该怎么做限流？

对于 App API 和 Web 后台，Nginx 是第一道非常重要的防线。

示例配置：

http {
    limit_req_zone $binary_remote_addr zone=api_limit:20m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=conn_limit:20m;

    server {
        listen 443 ssl;
        server_name api.example.com;

        location /api/ {
            limit_req zone=api_limit burst=30 nodelay;
            limit_conn conn_limit 20;

            proxy_pass http://backend_api;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /api/login {
            limit_req zone=api_limit burst=10 nodelay;
            proxy_pass http://backend_login;
        }
    }
}

这段配置的作用是：

但要注意，Nginx 限流不是万能的。如果攻击流量已经把带宽打满，请求根本到不了 Nginx，这时必须依赖高防清洗。

七、系统层参数也要调，但不能指望它硬抗大流量

对于 TCP 服务，可以适当优化 Linux 内核参数，提升连接处理能力。

示例：

# 提高连接队列
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=65535

# 开启 SYN Cookies
sysctl -w net.ipv4.tcp_syncookies=1

# 缩短 FIN 等待时间
sysctl -w net.ipv4.tcp_fin_timeout=15

# 提高本地端口范围
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

# 提高文件句柄
ulimit -n 1048576

可以写入 /etc/sysctl.conf：

net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.ip_local_port_range = 1024 65535

这些优化能提升服务器抗连接冲击能力，但它解决不了几十 Gbps 的流量型攻击。系统参数优化属于“增强体质”，不是“替代高防”。

八、游戏 UDP 协议要做包校验，不要让所有包进入业务逻辑

如果游戏服使用 UDP，建议在协议层做基础校验：

• 包头必须合法；
• 版本号必须匹配；
• Token 必须存在；
• 时间戳不能过期；
• 包长度不能异常；
• 未登录用户不能访问游戏逻辑端口；
• 单 IP 高频异常包直接丢弃；
• 非法包不要写大量日志。

错误做法：

所有 UDP 包 → 业务逻辑 → 解包 → 查用户 → 写日志 → 返回错误

推荐做法：

UDP 包 → 基础校验 → Token 校验 → 频率判断 → 合法包进入业务逻辑

攻击时，越早丢弃无效请求，服务器损耗越小。

九、数据库一定不要暴露公网，这是后端防护底线

很多游戏/App 后端被打崩，不是因为公网服务不行，而是数据库被拖死。

常见错误包括：

• MySQL 3306 对公网开放；
• Redis 6379 对公网开放；
• MongoDB 无访问限制；
• 后台管理和业务 API 共用账号；
• 数据库和 Web 服务在同一台小配置服务器上；
• 所有接口都实时查数据库，没有缓存。

正确做法：

对于中型业务，建议至少做到：

公网入口服务器
  ↓ 内网
业务服务器
  ↓ 内网
数据库服务器

不要把公网入口、业务程序、数据库全部放在同一台机器上。

十、攻击发生时应该怎么排查？

遇到攻击时，不要只看“服务器卡了”。可以按下面顺序判断。

1. 看带宽是否被打满

iftop
nload
sar -n DEV 1

如果入口流量远超正常业务，基本是流量型攻击。

2. 看连接数是否异常

ss -ant | wc -l
ss -ant state syn-recv | wc -l
ss -ant | awk '{print $1}' | sort | uniq -c

如果 SYN-RECV 很多，可能是 SYN Flood。

3. 看单 IP 请求频率

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

如果少量 IP 请求特别高，可能是普通 CC 或爬虫。

4. 看接口是否被集中攻击

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

如果 /api/login、/api/order/list、/api/room/list 排在前面，就要针对接口限流。

5. 看数据库连接是否耗尽

SHOW PROCESSLIST;
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';

如果数据库连接爆满，说明攻击已经穿透到业务层。

十一、不同预算下的防护组合建议

1. 低预算起步型

适合：小型 App、游戏官网、测试服、初期项目。

建议配置：

适合业务量不大、攻击风险较低的项目。

2. 中型业务稳定型

适合：正式 App、手游后端、会员系统、支付接口。

建议配置：

这个阶段最重要的是拆分入口、业务、数据库。

3. 游戏高并发防护型

适合：在线游戏、长连接业务、实时通信、房间服。

建议配置：

游戏业务不要只追求单台服务器高配置，更应该重视多节点分层。

十二、几个容易被忽略的安全细节

1. 不要让客户端直接写死源站 IP

App 或游戏客户端里尽量不要直接暴露真实源站 IP。可以使用域名、调度接口、高防入口，并做好证书校验和接口签名。

2. 管理后台不要和用户入口放一起

后台建议单独域名，例如：

admin.example.com

并限制：

• 固定 IP；
• VPN；
• 双因素验证；
• 独立端口；
• 登录失败次数限制。

3. 支付回调接口要做白名单

支付回调接口不要对全网无限开放，应该校验：

• 支付平台 IP；
• 签名；
• 时间戳；
• 订单状态；
• 重放请求。

4. 日志不要无限写

攻击时日志量可能比业务请求更可怕。可以对被拦截请求做采样记录，不要每个非法请求都写详细日志。

5. 备份和灾备要提前做

DDoS 防护不是只为“不断网”，还要保证攻击后可以恢复。

建议：

• 数据库定时备份；
• 异地备份；
• 配置文件备份；
• 镜像快照；
• 高防切换预案；
• DNS TTL 提前设置合理值。

十三、A5IDC 场景化选型建议

如果是游戏/App 后端，可以按下面思路选型：

比较稳妥的一套中型方案可以这样设计：

高防入口：
负责清洗 TCP/UDP/HTTP 攻击流量

香港源站网关：
AMD EPYC 4584PX / 64G 内存 / 960G NVMe / 1G 带宽

业务服务节点：
Xeon Gold 6138 / 64G 内存 / NVMe SSD

数据库节点：
AMD EPYC / 128G 内存 / 双 NVMe SSD / 内网访问

缓存节点：
8核 / 32G 内存 / Redis 内网部署

这套方案的优势是：

• 攻击流量不直接进入源站；
• 香港节点保证亚洲访问延迟；
• 高主频 CPU 适合网关和 API；
• 数据库不暴露公网；
• 后续可以横向增加业务节点；
• 遇到攻击时可以只扩入口防护，不必整体迁移业务。

十四、游戏/App 后端防 DDoS，本质是“架构防护”而不是“单机硬抗”

游戏/App 后端防御 DDoS 攻击，不能只看一台服务器配置，也不能只看高防值。真正稳定的方案，应该同时解决四个问题：

第一，公网入口要有防护，不能让攻击流量直接打到源站。

第二，业务服务要分层，登录、网关、API、数据库不要全部挤在一台机器上。

第三，接口要有限流，尤其是登录、短信、支付、房间列表、用户信息这类高消耗接口。

第四，源站 IP 要隐藏，数据库和 Redis 必须走内网，不能暴露公网端口。

对于游戏业务来说，要重点关注 TCP/UDP 清洗能力、连接数、游戏网关和源站隐藏。对于 App 后端来说，要重点关注 API CC、WAF、Nginx 限流、Redis 缓存和数据库保护。

简单说，DDoS 防护不是“买一台高防服务器就完事”，而是要把高防入口、服务器配置、业务架构、系统参数、接口限流、数据库隔离一起设计好。只有这样，游戏/App 后端在遇到攻击时，才不会从入口一路崩到数据库。