应优先使用自定义bridge网络而非默认docker0，因其支持容器名解析、固定ip、更强隔离及灵活配置；默认bridge存在ip易变、无法dns解析、共享广播域等生产隐患。
看 Docker Bridge 网络的最佳实践，关键不是背命令，而是理解“什么时候该用默认 bridge，什么时候必须换自定义 bridge”。默认的 docker0 看似开箱即用，但生产环境里它几乎处处是坑——容器名解析不了、IP 会变、隔离弱、配置死板。真正稳妥的做法，是把自定义 bridge 当成标准动作，而不是例外。
优先创建自定义 bridge 网络
别依赖默认的 bridge 网络（也就是 docker0）。它不支持服务名通信，容器重启后 IP 可能变动，且所有未指定网络的容器都会挤进去，容易混乱。
- 用
docker network create显式建网，比如：docker network create --subnet=172.20.0.0/16 app-net - 启动容器时明确指定：
docker run --network app-net --name db mysql:8.0 - 同网内的容器可直接用
db这个名字访问，DNS 自动解析，不依赖 IP
容器访问宿主机服务要绕过 localhost
在容器里写 localhost:3306 是连不上宿主机数据库的——因为 localhost 指的是容器自己，不是宿主机。
- Linux 宿主机上，推荐用默认网关地址：
ip route | awk '/default/ {print $3}'得到的 IP（通常是172.17.0.1或类似） - Docker Desktop（macOS/Windows）可用
host.docker.internal，但 Linux 原生 Docker 不支持，别硬搬 - 环境变量注入更可靠，比如：
-e DB_HOST=192.168.1.100 -e DB_PORT=3306（填宿主机真实局域网 IP）
端口映射和防火墙要配对检查
-p 8080:80 只是告诉 Docker 把宿主机 8080 的流量转发给容器 80，但宿主机防火墙可能拦住 8080，导致外网根本连不上。
- 确认 iptables / ufw 放行目标端口：
sudo ufw allow 8080（Ubuntu）或sudo firewall-cmd --add-port=8080/tcp --permanent（CentOS） - 宿主机数据库若被容器访问，也要开放对应端口（如 3306），并确保数据库用户授权允许从容器子网登录
- 避免用
-p :80这种全端口绑定，明确指定宿主机监听 IP，比如-p 127.0.0.1:8080:80更安全
网络诊断从网关和 DNS 入手
容器连不上外网或其它服务，先别猜应用配置，直接查网络基础链路：
- 进容器执行：
ip route—— 看默认网关是不是网桥地址（如172.20.0.1） - 执行：
cat /etc/resolv.conf—— 确认 DNS 是 Docker 内置的127.0.0.11（自定义 bridge 下才启用内建 DNS） - 测试连通性分三步：
① ping 网关（验证容器到网桥）
② ping 同网容器名（验证 DNS 和网桥转发）
③ ping 外网域名（验证 NAT 和 DNS）
不复杂但容易忽略：Bridge 网络本身很稳定，问题大多出在“默认行为”和“想当然”的配置上。把自定义网络当起点，把宿主机 IP 当常识，把端口和防火墙当一对动作，基本就稳了。
