应禁用userland-proxy以提升性能并降低安全风险,具体适用于高并发短连接、已配置DNAT规则、docker-proxy占用CPU过高或使用eBPF网络策略等场景,需通过修改daemon.json设"userland-proxy": false并重启dockerd生效。

停用 Docker 的 userland-proxy 不是为了“配置守护进程本身的功能”,而是为了绕过其默认启用的用户态端口转发组件(docker-proxy),从而减少内核到用户空间的上下文切换和额外进程开销,尤其在高并发短连接、低延迟敏感或 CPU 受限场景下能明显释放系统算力。
哪些场景建议关闭 userland-proxy
以下情况关闭该选项收益显著:
- 容器暴露大量端口(如 API 网关、服务网格入口)且连接频次高、生命周期短
- 宿主机已启用
iptables或nftables并配置了高效的 DNAT 规则,无需docker-proxy中转 - 观测到
docker-proxy进程持续占用 CPU(可通过ps aux | grep docker-proxy查看) - 使用 eBPF 工具(如 Cilium、Falco)或自定义网络策略,需确保流量路径不被用户态代理干扰
正确停用方法:修改 daemon.json 并重启 dockerd
不能通过运行时参数临时关闭,必须持久化配置并重启守护进程:
安全更新和维护 CLI Proxy API(CPA)部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 编辑
/etc/docker/daemon.json,添加或修改字段:
"userland-proxy": false - 确保文件语法合法(无逗号遗漏、引号闭合)
- 执行
sudo systemctl reload docker或sudo systemctl restart docker - 验证是否生效:
docker info | grep "Userland Proxy"应返回Userland Proxy: false
关闭后必须配套的关键操作
禁用 userland-proxy 后,Docker 会将端口映射完全交由内核 netfilter 处理。若未同步调整底层规则,容器端口将无法从外部访问:
- 确认
--iptables=true(默认开启),否则 Docker 不会自动插入 DNAT 规则 - 检查
iptables -t nat -L DOCKER是否存在对应端口的DNAT条目;若缺失,可能因iptables-legacy冲突导致规则未写入,建议统一使用iptables-nft - 若使用
nftables,需确保内核模块nf_tables和nf_nat已加载,并允许 Docker 自动管理nft表(Docker 24.0+ 原生支持) - 避免手动清空
nat表——这会导致所有-p映射失效
注意事项与常见误判
关闭 userland-proxy 是一项底层网络调优,不是安全加固手段,也非万能提速方案:
- 它对长连接(如 WebSocket、gRPC 流)性能影响极小,主要优化短连接建连开销
- 若容器使用
host网络模式,该设置无效(不经过 docker0 桥接) - 某些旧版内核(sysctl -w net.netfilter.nf_conntrack_max=65536
- 不要仅凭 “CPU 占用下降” 就认定成功——应结合
netstat -s | grep -i "segments retransmited"和容器实际响应延迟综合评估

















