摘要：# 自建高防CDN节点：别急着上配置，先把系统和内核调“对味儿” 前两天有个做游戏联运的朋友找我吐槽，说他们上了某云厂商的高防CDN套餐，一个月小十万，结果上周被一波CC攻击直接打穿了，源站都跟着挂。客服给的回复是“攻击流量超过了套餐阈值”——说白了，就…

自建高防CDN节点：别急着上配置，先把系统和内核调“对味儿”

前两天有个做游戏联运的朋友找我吐槽，说他们上了某云厂商的高防CDN套餐，一个月小十万，结果上周被一波CC攻击直接打穿了，源站都跟着挂。客服给的回复是“攻击流量超过了套餐阈值”——说白了，就是让你加钱升级。

这事儿其实挺典型的。很多中小公司一遇到DDoS，第一反应就是找现成的高防服务，这没错。但如果你业务量起来了，或者对成本敏感，自己动手在云服务器上部署一套高防节点，真没想象中那么玄乎。

今天我就掰开揉碎了，跟你聊聊怎么在云服务器上，从系统和内核这个最底层开始，把自建CDN高防节点给“调教”明白。这活儿，有点像给赛车调校底盘，光堆马力（硬件）没用，得让每个零件都配合到位。

一、 选系统不是选美：稳定和“听话”才是王道

很多人一上来就纠结：CentOS还是Ubuntu？Debian是不是更香？

我的建议可能有点反直觉：别追新，选那个你最熟、社区资料最全的。

我自己折腾过不少，最后长期用的还是CentOS 7（或者它的下游替代，比如Rocky Linux、AlmaLinux）。为啥？不是因为它多先进，恰恰是因为它“老派”、稳定。内核版本保守，意味着很多企业级应用和驱动都验证过，坑少。你要知道，高防节点是拿来扛攻击的，不是给你当新技术试验田的。

（当然，如果你团队对Ubuntu熟得跟自家后院一样，用Ubuntu Server LTS版本也完全没问题。重点是你得能驾驭它，出问题知道去哪儿翻日志、怎么查。）

第一个大实话： 别在线上环境用那些滚动更新的发行版，今天还好好的，明天一个内核更新可能就把你某个自定义模块干废了，找谁说理去？

二、 系统安装后的“瘦身”与加固：关掉没用的，锁紧该锁的

云服务商给的系统镜像，默认都带了一堆你可能用不上的服务。每多一个服务，就多一个端口，多一份被扫描、被利用的风险。

1. 先来个大扫除：

# 停掉并禁用那些绝对用不上的
systemctl stop postfix && systemctl disable postfix  # 邮件服务，节点上要它干啥？
systemctl stop avahi-daemon && systemctl disable avahi-daemon  # 局域网发现，云环境里纯属多余
systemctl stop cups && systemctl disable cups  # 打印服务？你是在逗我？

用 systemctl list-unit-files | grep enabled 扫一眼，把那些名字看着就眼生、跟网络代理/缓存无关的服务，都关掉。

2. SSH加固，这是门面：

• 改端口： 把22端口改成别的，能减少99%的自动化脚本扫描。别听什么“安全不靠隐蔽”，那是大厂有专业安全团队的说法。对我们来说，减少干扰就是胜利。
• 禁用密码登录，用密钥： 这个说烂了，但真还有不少人图方便用密码。
• 用Fail2ban： 必须装。谁尝试暴力破解SSH，就把谁IP拉黑一段时间。配置简单，效果立竿见影。

3. 防火墙配置（以firewalld为例）： 默认全关，只开必要的。高防节点主要就开两个口：

• 管理口（SSH端口）： 只允许你公司的运维IP段访问。
• 业务口（80/443等）： 对所有外网开放，这是它存在的意义。

firewall-cmd --permanent --add-port=你的SSH端口/tcp
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --permanent --remove-service=dhcpv6-client  # 通常用不到
firewall-cmd --reload

关键一步： 把默认区域（zone）的INPUT链策略设为DROP，只允许你上面明确放行的规则。这就叫“白名单”思维。

三、 内核调优：让服务器变成“海绵”而不是“玻璃”

重头戏来了。系统层面的优化是基础，内核调优才是决定你这节点是“海绵”（能吸收、消化异常流量）还是“玻璃”（一碰就碎）的关键。

很多教程一上来就让你改一堆sysctl.conf参数，但很少告诉你为什么。我挑几个最核心的、跟网络高并发和抗攻击相关的讲。

1. 扩大“排队”能力（连接队列相关）： 攻击来了，首先是海量的连接请求。如果队列太小，正常的请求还没被处理就被挤掉了。

# /etc/sysctl.conf 里加上或修改这些
net.core.somaxconn = 65535  # 提高连接队列上限
net.ipv4.tcp_max_syn_backlog = 65535  # SYN队列长度，应对SYN Flood基础
net.core.netdev_max_backlog = 65535  # 网卡设备队列长度

打个比方： 这就好比把超市收银台前的排队通道加宽加长，避免顾客（数据包）因为没地方站（队列满）直接走掉（被丢弃）。

2. 加快“翻台率”（连接回收与重用）： 光能排队不行，处理完的连接得快速清掉，把资源让出来。

net.ipv4.tcp_tw_reuse = 1  # 允许将TIME-WAIT sockets重新用于新的TCP连接
net.ipv4.tcp_tw_recycle = 0  # **注意：这个参数在NAT环境下可能有问题，建议设为0，用下面的快速回收**
net.ipv4.tcp_fin_timeout = 30  # 缩短FIN-WAIT-2状态的超时时间
# 启用TCP快速回收机制（内核4.1+推荐方式略有不同，但思路一致）
net.ipv4.tcp_early_demux = 1

这里有个坑： 网上老教程爱开tcp_tw_recycle，但在现在普遍的公网NAT环境下，容易导致连接不稳定，直接关掉它更省心。

3. 内存管理：别让连接把内存吃光 每个连接都要占用一点内存。攻击者会用海量慢连接拖死你。

# 调整TCP连接内存使用
net.ipv4.tcp_rmem = 4096 87380 67108864  # 最小、默认、最大接收缓冲区
net.ipv4.tcp_wmem = 4096 65536 67108864  # 发送缓冲区
net.ipv4.tcp_mem = 8388608 12582912 16777216  # TCP整体内存使用：低于第一个值不收紧，高于第二个开始收紧，超过第三个拒绝分配

# 关键：限制单个连接的内存占用，防慢攻击
net.ipv4.tcp_slow_start_after_idle = 0  # 关闭空闲后拥塞窗口重置，对长连接友好

4. 对付SYN Flood的“大招”：

net.ipv4.tcp_syncookies = 1  # 开启SYN Cookie，在队列满时应对SYN Flood
net.ipv4.tcp_max_syn_backlog = 65535  # 再次强调，队列要足够大
net.ipv4.tcp_synack_retries = 2  # 降低SYN-ACK重试次数，快速失败

tcp_syncookies是个好东西，它能在不占用连接队列内存的情况下，验证连接请求的合法性，算是抗SYN攻击的最后一道有效防线。

调完记得 执行 sysctl -p 让配置生效。

四、 别忘了文件句柄和进程数：天花板要够高

内核参数调好了，系统本身给单个进程设的限制也可能成为瓶颈。比如Nginx。

# 编辑 /etc/security/limits.conf
* soft nofile 655350
* hard nofile 655350
* soft nproc 655350
* hard nproc 655350

这个意思是，把系统能打开的文件描述符数量（nofile）和用户能创建的进程数（nproc）上限调高。Nginx每个连接都会占用一个文件句柄，并发一高，默认的1024根本不够看。

五、 最后一步：监控与迭代，别设完就忘

调优不是一劳永逸的。你需要在真实攻击或者大流量来临时，观察效果。

• 用 netstat -s 看TCP协议的详细统计，关注attempts failed、timeout、dropped这些关键词。
• 用 ss -lnp 查看监听端口的连接队列情况。
• 用 dstat、iftop、nethogs 看实时流量和连接状态。

如果发现某些参数下，系统出现不稳定或者性能不达标，再回头微调。记住，没有一套参数能通吃所有场景。 游戏业务和视频网站的业务模型，对内核的要求侧重点就不一样。

写在最后

说实话，自建高防节点，系统和内核调优只是万里长征第一步。后面还有软件选型（Nginx还是OpenResty？）、规则配置（怎么区分正常用户和攻击机器人）、流量调度（多个节点怎么互备）等等一大堆事。

但基础打不牢，后面软件再高级也白搭。这就好比盖房子，地基是歪的，你墙面刷得再漂亮，一阵风过来也得晃。

自己动手搭一套，最大的好处不是省了那点钱（当然，长期看确实省），而是你对整个流量处理链条有了掌控感。下次再被打，你不会只能干等着客服回复，至少能登录节点看看，是连接数满了，还是带宽堵了，或者是某个规则误杀了，心里有底。

行了，关于系统和内核的“底盘调校”，就先聊这么多。下次有机会，咱们再聊聊怎么在Nginx上配置防CC的“组合拳”。