docker 使用 –network=host 有时更慢，主因是服务绑定 127.0.0.1 导致容器无法访问自身端口、端口冲突、apm 工具环路请求；需检查监听地址、端口占用及禁用相关监控探测。
为什么 docker run --network=host 有时反而更慢？
因为容器直接复用宿主机网络栈，绕过了 docker0 网桥和 iptables NAT 规则，本该更快——但实际中常因端口冲突、服务绑定逻辑错乱或监控工具干扰而变慢。典型表现是：本地 curl http://localhost:8080 在容器内失败，或延迟突增。
- 检查服务是否绑定了
127.0.0.1而非0.0.0.0：netstat -tuln | grep :8080，只监听127.0.0.1时，--network=host容器无法访问自身暴露的端口 - 确认没有其他进程占用了目标端口，
lsof -i :8080比netstat更准 - 某些 APM 工具（如 Datadog Agent）在 host 网络模式下会尝试重连自身，形成环路请求，需关闭其自动发现或显式禁用 loopback 检测
dockerd 启动参数里哪些网络配置真会影响吞吐？
多数人改了 --mtu 或 --default-ulimit 就以为调优完了，其实关键在三个冷门但高权重的选项：
-
--iptables=false：禁用 Docker 自动管理 iptables 规则，避免与已有防火墙（如 firewalld、nftables）冲突导致连接重传；但必须手动确保FORWARD链策略为ACCEPT，否则跨容器通信直接中断 -
--ip-forward=true：默认开启，但如果宿主机 sysctl 关闭了net.ipv4.ip_forward，Docker 会静默忽略此参数并降级为桥接失效，务必运行sysctl net.ipv4.ip_forward核对 -
--max-concurrent-downloads和--max-concurrent-uploads：影响镜像拉取阶段的并发连接数，和运行时网络性能无关，别误调
容器间通信走 bridge 还是 macvlan？
纯内网高频 RPC（比如微服务间 gRPC 调用）下，macvlan 能绕过 docker0 网桥和 ARP 代理，实测降低 15–25% P99 延迟；但代价是失去 NAT、端口映射和动态 IP 分配能力。
- 使用
macvlan前必须确认物理网卡支持混杂模式（ip link set eth0 promisc on），否则容器发包成功但收不到响应 -
bridge模式下，若发现大量tcp retransmission，先查ethtool -S docker0 | grep drop，常见原因是docker0的 tx/rx ring buffer 溢出，可调大net.core.netdev_max_backlog -
macvlan子接口不能和宿主机同 IP 段共存，否则 ARP 冲突，建议划独立子网（如宿主机用192.168.1.0/24，macvlan 用192.168.2.0/24）
怎么验证容器网络到底卡在哪一层？
别一上来就改 MTU 或开 BBR，先分层排除：物理层 → 驱动层 → 协议栈层 → 应用层。最有效的组合命令是这三条：
- 看丢包：
ss -i dst <code> 容器 IP，关注retrans和rcv_rtt字段；如果retrans> 0 且持续增长，问题在传输层以上 - 看驱动队列：
cat /proc/net/dev | grep eth0，对比rx_dropped和tx_dropped；若数值上升快，说明网卡驱动或 ring buffer 不足，需调ethtool -G eth0 rx 4096 tx 4096 - 看协议栈排队：
ss -s中的tw（TIME-WAIT 套接字数）和mem（内存占用）；若mem接近net.ipv4.tcp_mem上限，说明连接太密或回收慢，要调net.ipv4.tcp_fin_timeout和net.ipv4.tcp_tw_reuse
MTU 错配是最隐蔽的瓶颈之一，尤其在 overlay 网络（如 Swarm、Calico）里，宿主机 MTU 是 1500，但 VXLAN 封装后实际有效 MTU 只有 1450，不调应用层 TCP MSS 就会触发分片，而很多容器内核默认没开 net.ipv4.ip_forward 导致分片包被静默丢弃。
