高并发负载均衡场景优先IPVS，日常防火墙规则管理选nftables它是iptables的官方继任者，语法更清晰、性能更好，但iptables凭借存量生态和习惯，短期内仍有一席之地。
三者定位：谁管流量转发，谁管数据包过滤
很多刚接触服务器网络配置的朋友，容易把IPVS、iptables和nftables混为一谈，其实这三兄弟的分工完全不同，搞清楚定位,选型就成功了一半。
IPVS是内核里的四层负载均衡器，全称IP Virtual Server，工作在Linux内核的NETFILTER框架之上，但它的核心职责是流量分发把进来的请求按算法转发给后端多台真实服务器，它工作在TCP/UDP层，不关心数据包内容,转发效率极高。
iptables和nftables是数据包过滤框架，负责的是允许还是拒绝、修改还是标记，简单说，IPVS决定流量去哪台机器，iptables/nftables决定流量能不能过。
nftables是iptables的替代品，从Linux内核3.13开始引入，主流发行版（CentOS 8+、Debian 10+、Ubuntu 20.04+）默认都已切换到nftables底层，iptables的规则语法在nftables里被重新设计，但为了兼容,很多系统仍提供iptables命令的nft转换层。
nftables和iptables哪个好：语法、性能与生态
这是被问得最多的一个问题，直接说结论：新部署的服务器，没有历史包袱的话，选nftables。
语法差异：nftables更接近人类语言
iptables命令写起来繁琐且反直觉，一条规则要拆成多个链、多个表，新手经常分不清INPUT和FORWARD的区别,比如屏蔽一个IP：
# iptables写法 iptables -A INPUT -s 1.2.3.4 -j DROP # nftables写法 nft add rule inet filter input ip saddr 1.2.3.4 drop
nftables支持地址族合并，用inet一个表同时处理IPv4和IPv6，而iptables需要分别维护-4和-6两套规则，规则管理上，nftables支持原子替换、批量加载，改配置不会出现iptables那种”清空再加载”的中间状态。
性能表现：nftables略占优
业内专家指出，nftables在规则数量较多时，查表性能优于iptables，iptables的规则是线性遍历的，规则一多延迟明显；nftables采用哈希链等数据结构，规则数量对性能的影响小得多，同时nftables支持chains的并发更新,不会像iptables那样在并发修改时出现竞争锁。
不过对大多数中小站点来说，几十条规则的情况下，两者性能差距体感几乎为零。性能差异在规则量达到几百上千条时才拉开。
生态兼容：iptables存量巨大
虽然nftables是未来，但iptables的生态惯性依然很强，大量老教程、运维脚本、安全工具（比如fail2ban、Docker早期版本）都直接调用iptables命令，如果你用的是CentOS 7或Ubuntu 18.04这类老系统，或者依赖的软件还不支持nftables，那继续用iptables完全没问题稳定压倒一切。
IPVS和iptables区别：负载均衡与包过滤是两码事
很多做Kubernetes集群运维的朋友会把这两个概念搞混，因为kube-proxy的iptables模式和IPVS模式是两种负载均衡实现方案，但注意：这里iptables是被动模拟负载均衡，IPVS是原生负载均衡器。
性能差距：IPVS写入内核哈希表，iptables遍历规则链
kube-proxy的iptables模式，每创建一条Service规则，就会在iptables里生成一串规则链，一个几千个Service的集群，iptables规则可能达到几万条，每次数据包都要遍历这些规则,内核CPU消耗巨大。
IPVS模式则不同，它使用内核哈希表存储转发规则，查询时间复杂度是O(1)，规则数量对性能几乎无影响，据行业通用的基准测试数据,IPVS在万级Service场景下的吞吐量和延迟都远优于iptables模式。
功能差异：IPVS专为LB设计，iptables是通用工具
IPVS原生支持多种调度算法：轮询、加权轮询、最少连接、源地址哈希、目标地址哈希等，直接配置即用，iptables的随机或轮询转发需要配合--statistic模块,实现繁琐且灵活性差。
另外IPVS天生支持连接跟踪和会话保持，TCP连接的超时、重试、持久性都有专项优化，iptables做转发只是”能用”，谈不上”好用”。
典型选型：Kubernetes集群节点上万，首选IPVS
如果你在维护Kubernetes集群，且Service数量超过几十个，强烈建议把kube-proxy切到IPVS模式,具体操作：
# 查看当前模式 kubectl get cm -n kube-system kube-proxy -o yaml | grep mode # 修改为IPVS模式 kubectl edit cm -n kube-system kube-proxy # 将 mode: "" 改为 mode: "ipvs"
但要注意，IPVS模式不负责数据包过滤
，如果要做网络策略（NetworkPolicy），还是需要iptables或nftables配合，两者是互补关系,不是替代关系。
高并发场景下IPVS和nftables怎么配合
生产环境很少只用一种方案，一个典型的高并发服务器配置方案是这样的：
流量入口 → nftables做安全过滤（防扫描、限速、封禁恶意IP）→ IPVS做四层负载均衡 → 后端真实服务器
第一步：nftables做前置防护
在流量打到IPVS之前，先用nftables把恶意流量挡掉,比如限制单IP的并发连接数：
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0; }
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input tcp dport 80 meter flood size 1024 { ip saddr timeout 10s limit rate 30/second } drop
第二步：IPVS做核心转发
清理掉垃圾流量后，剩下的是正常业务流量，交给IPVS做高效转发,配置IPVS虚拟服务器：
# 安装管理工具 yum install -y ipvsadm # 创建虚拟服务，使用加权最少连接算法 ipvsadm -A -t 192.168.1.100:80 -s wlc # 添加后端真实服务器，权重分别为2和1 ipvsadm -a -t 192.168.1.100:80 -r 10.0.0.1:80 -g -w 2 ipvsadm -a -t 192.168.1.100:80 -r 10.0.0.2:80 -g -w 1
注意-g表示DR模式（直接路由），这是IPVS性能最高的部署方式，流量回程不经过LB节点，响应速度极快。
第三步：nftables在POSTROUTING做NAT
如果使用NAT模式（不需要-g），IPVS转发后需要做SNAT,这一步可以用nftables完成：
nft add rule inet nat postrouting ip saddr 10.0.0.0/24 masquerade
实际选型：按场景对号入座
为了让你更直观地做决定,这里用一张表总结常见场景的推荐方案：
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 单机Web服务器，只需开放80/443端口 | nftables | 语法简洁，管理方便 |
| 老系统（CentOS 7及以下）维护 | iptables | 系统默认，改动最小 |
| Kubernetes集群（Service>50） | IPVS | 规则规模大，性能碾压iptables |
| 自建四层负载均衡（LVS+Keepalived） | IPVS | 原生LB能力，调度算法丰富 |
| Docker/K8s网络策略（NetworkPolicy） | iptables/nftables | IPVS不负责包过滤 |
| 需要NAT端口转发 | nftables | 支持地址族合并，配置更直观 |
代理服务器怎么选：区分四层和七层
如果你的场景是搭建代理服务器，还要额外区分：IPVS是四层转发，不解析HTTP协议，不支持路径路由、域名转发、TLS终止，需要这些能力，得用Nginx、HAProxy等七层负载均衡器，架构上常见组合是：Nginx（七层）→ IPVS（四层）→ 后端服务器，或者反向：IPVS（四层）→ Nginx（七层）→ 后端。
服务器性能优化：规则数量是核心变量
无论是选择哪种方案，都要关注规则管理规范，建议把规则写成脚本文件（nftables的.nft脚本或iptables的.sh脚本），通过版本管理工具维护，而不是随手敲命令，据统计，相当一部分线上故障源于规则误操作，成体系的配置管理比选型本身更重要。
常见问题速答
IPVS和iptables怎么选？
看用途，做负载均衡选IPVS，做防火墙选iptables，如果两个都要，可以同时启用，IPVS处理转发，iptables处理过滤，互不冲突，Kubernetes环境建议直接切IPVS模式,规则过多时性能差距非常明显。
nftables能完全替代iptables吗？
能，但需要时间，nftables是内核官方推荐的替代方案，主流新系统已默认使用，但许多老工具和脚本仍依赖iptables命令，兼容层也不算完美，如果你在维护老系统，不需要强行迁移；新项目则建议直接上nftables,学习成本并不高。
服务器配置IPVS需要什么前提条件？
内核需要支持ip_vs模块，多数标准内核已内置，可以用modprobe ip_vs加载，lsmod | grep ip_vs验证，还需安装ipvsadm管理工具，另外注意：云服务器（如简米云、酷番云）的VPC网络模式下，IPVS的DR模式可能受限，需要确认安全组放行相关流量，或改用NAT模式（简米云服务器多见此情况，需根据实际网络环境调整），IPVS与云平台安全组不冲突，但安全组规则优先级高于IPVS转发,配置时需同步放行。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/557344.html
