如何通过TCP/IP协议栈参数调优缓解CC攻击影响？
摘要：# 当CC攻击来袭，别急着加钱，先调调你服务器的“内功” 前几天和一个做电商的朋友吃饭，他愁眉苦脸地说：“最近网站老卡，加了高防CDN，钱是哗哗地花，但感觉效果也就那样。攻击一来，该慢还是慢。” 我多问了一句：“你服务器本身的TCP/IP参数，动过吗？”…
当CC攻击来袭，别急着加钱，先调调你服务器的“内功”
前几天和一个做电商的朋友吃饭，他愁眉苦脸地说：“最近网站老卡，加了高防CDN，钱是哗哗地花，但感觉效果也就那样。攻击一来，该慢还是慢。” 我多问了一句：“你服务器本身的TCP/IP参数，动过吗？” 他一脸茫然。
这场景你应该不陌生吧？很多团队一遇到CC攻击，第一反应就是“加钱上高防”——找高防IP、高防CDN、云WAF，这当然没错。但就像你给一辆老爷车装上最贵的防弹玻璃，发动机却还是老掉牙的，真跑起来能快吗？
说白了，很多CC攻击造成的业务卡顿、连接失败，根源不在于带宽被打满，而是你服务器自身的协议栈“太老实”，被攻击者用海量慢速连接给“耗”死了。 今天，咱不聊那些宏大的方案，就聊聊怎么给你服务器的“内功心法”——TCP/IP协议栈参数——动动刀子，花小钱甚至不花钱，扛住更多压力。
你的服务器，可能正在“礼貌”地自杀
先搞明白CC攻击是怎么让你服务器“憋屈”死的。它不像DDoS那样狂轰滥炸流量，而是模拟大量正常用户，慢悠悠地和你服务器建立TCP连接，建完还不干正事，就挂着，或者慢速地发请求。
这时候，你服务器（尤其是Linux系统）默认的TCP/IP行为，简直像个有礼貌的绅士：
- 它会为每一个新连接分配资源（内存、CPU时间片）。
- 它会耐心等待数据（默认设置可能等很久）。
- 它发现连接异常断开，还会彬彬有礼地保留一段时间（TIME_WAIT状态）。
攻击者要的就是这个效果。他们用几千、几万个“绅士连接”，把你的连接池占满，把内存耗光，让真正的用户连不上来。很多所谓防护方案，PPT很猛，真被打的时候就露馅了，因为它们可能只在外围清洗流量，没解决服务器内核自己“作茧自缚”的问题。
几个关键参数的“油门与刹车”
调优不是玄学，是针对攻击手法的“对症下药”。咱们直接上干货，说说几个核心参数（以Linux为例）该怎么调。记住，调优没有银弹，得根据你的业务实际来，最好在测试环境先折腾。
1. 连接追踪表（net.netfilter.nf_conntrack_max）：别让“登记处”先爆了
这玩意儿像大楼的前台登记簿。所有进出网络的连接都要在这儿记一笔。默认值往往就几万，CC攻击一来，瞬间填满。登记簿满了，新客人（正常用户）就别想进了。
- 该怎么做：大幅调高这个值。比如调到
655360或更高。同时注意配套调整net.netfilter.nf_conntrack_tcp_timeout_established（已建立连接的超时时间），别让废连接占着茅坑太久。说白了，就是给登记处换本超厚的册子，并且规定访客发呆太久就请出去。
2. 本地端口范围（net.ipv4.ip_local_port_range）：让反击更有力
当你的服务器作为客户端去请求后端服务（比如数据库、Redis）时，需要占用本地端口。默认范围大概就3万个。如果CC攻击导致你的服务器需要频繁重建到后端的连接，端口可能很快耗尽。
- 该怎么做：把它扩大。比如从
32768 60999改成1024 65000。这相当于给你的士兵（服务器进程）发更多可用的“枪械编号”（端口），避免他们因为没编号而无法出战。
3. TCP半连接队列与全连接队列（net.core.somaxconn, net.ipv4.tcp_max_syn_backlog）：守好“握手”的大门
这是防御SYN Flood（CC常用手段）的关键。tcp_max_syn_backlog 决定了有多少个“第一次握手”请求可以排队等待；somaxconn 决定了完成三次握手后，有多少连接可以排队等待应用层（如Nginx）来接受。
- 该怎么做：适当调大这两个值，比如都设为
65535。但更重要的是，确保你的Web服务器（如Nginx）的backlog参数也同步调大，否则内核排了队，应用层不取，也白搭。这就像把大门和客厅都拓宽，让访客排队等得舒服点。
4. TIME_WAIT状态优化（net.ipv4.tcp_tw_reuse/recycle）：快速回收“战场遗迹”
TCP连接关闭后，会进入TIME_WAIT状态，默认等2分钟（MSL*2）才彻底释放资源。高并发下，大量TIME_WAIT连接会占满端口和内存。
- 该怎么做：在NAT环境（如云服务器）下要非常谨慎，但在明确是内部服务器或对外提供服务的场景下，可以尝试启用
net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle（注意，后者在较新内核中可能已移除或不建议使用）。核心思想是让系统能更快地打扫战场，把资源腾出来给新的战斗。 我自己看过不少站点，问题往往不是没上防护，而是配错了这里，导致连接数上去后自己把自己拖垮了。
5. 内存与缓冲区调整（net.ipv4.tcp_mem, net.core.rmem/wmem）：给“处理流水线”扩容
TCP需要内存来缓冲收发数据。默认值对于高并发、长连接CC攻击来说，可能太小了。
- 该怎么做：根据你服务器的物理内存，调大
tcp_mem（TCP全局内存）和rmem_default/wmem_default（默认读写缓冲区）。这相当于给每条“数据处理流水线”加宽了传送带，避免因为一个小环节堵塞导致整个车间停工。
重要提醒：调优是门实践艺术，不是抄作业
- 别在生产环境直接搞：先在测试环境用
sysctl -w临时修改测试，用压测工具（如ab、wrk）模拟CC场景，观察效果。 - 监控是眼睛：调优前后，务必用
netstat,ss,conntrack等命令，以及监控系统，紧盯连接数、内存、CPU的变化。 - 组合拳才有效：协议栈调优是缓解，是提升单机抗压能力，但它不能替代外部的清洗、限速和WAF规则。它让你的服务器从“文弱书生”变成“硬汉”，但面对持枪的暴徒（大规模攻击），还是需要高防的“防弹衣”和“保安”（清洗中心）。
- 内核版本是爹：不同Linux内核版本，参数名、默认值、甚至行为都可能不同。网上搜到的“最优值”可能过时了。最靠谱的方法是，查你当前内核版本的官方文档。
最后说句大实话
这类低配防护真扛不住，别硬撑。但如果你正在经历的是那种“加了高防还觉得有点卡”、或者预算有限想挖掘现有服务器潜力的阶段，那么花一个下午，深入研究一下TCP/IP协议栈调优，绝对是性价比最高的安全投入之一。
它不会让你的网站刀枪不入，但能让你在同样的攻击流量下，业务更稳一点，用户体验更好一点。很多时候，安全就是这一点一点的细节堆出来的。
行了，不废话了，登录你的服务器，sysctl -a | grep tcp 先看看现状吧。如果你的源站还裸奔，你心里其实已经有答案了。