linux系统syn洪水攻击防护需启用tcp_syncookies并调大tcp_max_syn_backlog和somaxconn至65535，缩短tcp_synack_retries至3，禁用危险的tcp_tw_recycle，配合iptables限速及conntrack表容量管控。
直接改 /etc/sysctl.conf 不生效，是因为 Linux 启动后只读一次该文件；不执行 sysctl -p 或未正确加载配置目录，所有参数都只是文本，不会进入内核。
为什么 net.ipv4.tcp_syncookies=1 开了还是被 SYN Flood 打挂
SYN Cookies 是保命机制，不是前置拦截器——它只在 net.ipv4.tcp_max_syn_backlog 和 net.core.somaxconn 队列真正溢出时才触发。如果这两个值太小（比如默认 128 或 1024），攻击包根本到不了 Cookies 阶段就被内核静默丢弃了。
- 先确认当前值：
sysctl net.ipv4.tcp_max_syn_backlog net.core.somaxconn - 生产环境建议统一设为
65535，避免中间环节卡脖子 -
tcp_syncookies设为1即可；设为2会强制绕过队列检查，掩盖真实连接压力，反而不利于问题定位 - 别忘了配套缩短半连接超时：
net.ipv4.tcp_synack_retries=3（默认 5），加快释放异常SYN-RECV状态
net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle 到底能不能开
tcp_tw_reuse=1 可以开，但仅对**主动发起连接的客户端**生效（比如服务器作为 HTTP 客户端调用第三方 API）；服务端监听场景下它不起作用。
tcp_tw_recycle=1 在 2019 年后的主流内核中已被移除，且即使旧版本也极度危险：它依赖 tcp_timestamps，在 NAT、负载均衡或任何存在多客户端共用源 IP 的环境里，会导致连接随机失败（典型现象是客户端发了 SYN，服务端不回 SYN-ACK）。
- 不要启用
tcp_tw_recycle，无论文档怎么写 - 如需加速 TIME-WAIT 回收，优先调低
net.ipv4.tcp_fin_timeout（例如设为30），比强开回收更可控 - 监控
/proc/net/sockstat中的tw数量，若持续高于 2w，说明连接模式本身需优化（比如加连接池、关 keepalive）
哪些参数一改就翻车，必须盯住副作用
内核网络参数不是越大越好，很多参数直接关联内存占用或协议行为，盲目调优等于给攻击者递刀。
-
net.ipv4.tcp_rmem和net.ipv4.tcp_wmem的 max 值别超过物理内存的 10%，否则可能触发 OOM killer 杀进程 -
net.ipv4.ip_local_port_range扩大端口范围（如1024 65535）有用，但最小值别设太低（1024是底线），否则和常用服务端口冲突 -
net.ipv4.icmp_echo_ignore_all=1虽能防 ICMP Flood，但也让基础ping失效；更稳妥的是限速：net.ipv4.icmp_ratelimit=100 -
net.ipv4.conf.all.rp_filter=1启用严格反向路径过滤，但要求路由对称；非网关机器建议逐接口设置并验证，否则可能误丢合法包
最常被忽略的一点：所有内核参数调优都必须配合连接跟踪表（nf_conntrack）容量控制。哪怕 TCP 参数全调优到位，net.netfilter.nf_conntrack_max 设太小或没监控 /proc/sys/net/nf_conntrack_count，一样会在连接高峰时因 conntrack 表满而静默丢包——这个坑，比 SYN 队列还难排查。
