应禁用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
不能通过运行时参数临时关闭，必须持久化配置并重启守护进程：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 编辑
/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"和容器实际响应延迟综合评估
