Docker容器网络最佳实践核心是隔离到位、通信可控、配置可复现：禁用默认bridge网络，改用自定义bridge实现显式隔离；容器内勿用127.0.0.1访问宿主机，应通过host.docker.internal或动态网关获取；host模式仅限极致性能且无隔离需求场景；none和container模式须按离线计算或sidecar架构精准选用。
看 Docker 容器网络最佳实践，核心是“隔离要到位、通信要可控、配置要可复现”。不是堆参数，而是根据服务角色选对模式、用好命名空间、避开默认陷阱。
bridge 模式别直接用默认 docker0
默认 bridge 网络（docker0）下所有容器同属一个子网（如 172.17.0.0/16），彼此能直接 ping 通、端口互通，相当于没设门禁。生产环境必须规避。
- 创建自定义 bridge 网络，显式隔离：docker network create --driver bridge app-net
- 容器启动时指定网络：docker run --network app-net …
- 同一网络内可通过容器名 DNS 解析通信；跨网络默认不通，需显式连接或暴露端口
访问宿主机服务，别硬写 127.0.0.1
容器里 localhost 指的是自己，不是宿主机。常见错误是数据库配置写 DB_HOST=127.0.0.1，结果连不上。
- Linux 宿主机：用 172.17.0.1（docker0 网桥的宿主机侧 IP）
- 跨平台兼容方案：启动容器时加 --add-host=host.docker.internal:host-gateway
- 更健壮做法：在启动脚本中动态获取网关：ip route | awk '/default/ {print $3}'
host 模式慎用，只在明确需要时开
host 模式让容器共享宿主机网络栈，性能高但完全放弃隔离——端口冲突、iptables 规则混杂、安全边界消失。
- 仅适用于单容器、无多实例需求、且对延迟极度敏感的场景（如实时日志采集 agent）
- 禁止用于 Web 服务、API 网关、数据库客户端等常规应用
- 若必须用，确保宿主机防火墙已精细控制入向流量
none 和 container 模式有明确分工
不是“不用就浪费”，而是按职责精准匹配：
- none 模式：适合离线批处理、加密计算、安全沙箱等彻底不需要网络的场景
- container 模式：用于 sidecar 架构，比如 nginx + log-forwarder 共享网络栈，省去内部通信开销
- 避免把 none 当“省事选项”——后续想加网络就得重建容器
