Docker升级后网络吞吐未达预期，主因是eBPF替代IPVS等默认行为变化与旧内核参数不匹配；应针对性调优TCP连接能力（如somaxconn、tcp_tw_reuse）、缓冲区（rmem_max/wmem_max）及连接跟踪（nf_conntrack_max），并同步调整ulimits和MTU。
Docker 升级后，网络吞吐量下降或未达预期，往往不是版本本身的问题，而是新版本默认行为变化（比如更严格的命名空间隔离、eBPF 默认启用、IPVS 行为调整）与旧有内核参数不匹配所致。关键不是“重设所有参数”，而是针对性校准容器协议栈和宿主机数据平面。
确认升级带来的底层变更
Docker 25+ 开始逐步用 eBPF 替代 IPVS 作为 Ingress 负载均衡器；27+ 中 eBPF 已成默认。这意味着 ipvsadm 可能无输出，而 bpftool map dump 才是验证真实转发路径的依据。若你依赖 IPVS 的 lc 或 wlc 算法，需转向服务部署策略引导（如副本分散、健康检查），而非修改调度器。
重点调优三类内核参数
-
TCP 连接处理能力
高并发短连接场景（如 API 网关、CI 流水线）易受somaxconn和tcp_tw_reuse限制：-
net.core.somaxconn：监听队列长度，建议设为65535（默认常为 128） -
net.ipv4.tcp_tw_reuse：设为1，允许 TIME-WAIT 端口快速复用 -
net.ipv4.tcp_max_syn_backlog：SYN 半连接队列，同步提升至65535
-
-
缓冲区与窗口控制
大吞吐长连接（如日志转发、微服务 RPC）依赖足够大的 TCP 缓冲和可扩展窗口：-
net.core.rmem_max/net.core.wmem_max：建议设为26214400（25MB），避免接收/发送窗口成为瓶颈 -
net.ipv4.tcp_window_scaling：必须为1，否则无法启用大于 64KB 的窗口 -
net.ipv4.tcp_slow_start_after_idle：设为0，防止空闲后重置拥塞窗口
-
-
连接跟踪与资源上限
Docker 升级后对nf_conntrack更敏感，尤其在 NAT 或 Ingress 模式下：-
net.netfilter.nf_conntrack_max：宿主机上建议设为1048576（100 万） -
net.netfilter.nf_conntrack_buckets：设为net.netfilter.nf_conntrack_max的 1/8（如131072），避免哈希冲突 -
net.ipv4.ip_local_port_range：扩为"1024 65535"，提升临时端口可用性
-
配置方式要匹配运行模式
-
使用
docker run启动时：docker run --sysctl net.core.somaxconn=65535 \ --sysctl net.ipv4.tcp_tw_reuse=1 \ --sysctl net.core.rmem_max=26214400 \ --sysctl net.core.wmem_max=26214400 \ -d your-app -
使用
docker-compose.yml时（仅对 bridge/network_mode: default 有效）：services: app: image: nginx:alpine sysctls: net.core.somaxconn: "65535" net.ipv4.tcp_tw_reuse: "1" net.core.rmem_max: "26214400" net.core.wmem_max: "26214400" 若启用
network_mode: host，所有sysctls无效——此时需直接调优宿主机参数，并确保应用监听0.0.0.0。
同步调整配套资源限制
单调内核参数不够：
- 容器内
ulimits.nofile至少设为65536，否则文件描述符先耗尽 - 宿主机
fs.file-max建议设为2097152（200 万） - 若使用
bridge网络，确认docker0网桥 MTU 与物理网卡一致（云环境常用1450）
调优后务必验证：进容器执行 sysctl -a | grep 对应参数，再用 ss -s 查看 socket 统计，结合压测工具（如 wrk 或 go-wrk）对比升级前后的吞吐与 P99 延迟。
