生产环境docker容器网络配置的核心是使用自定义桥接网络实现稳定、安全、可运维的通信：必须创建指定子网的独立网络（如192.168.100.0/24），启用内置dns支持容器名解析，严格控制端口映射范围，并通过docker compose统一编排服务拓扑。
生产环境的 Docker 容器网络配置，核心目标是稳定、可预测、可运维、安全隔离。不能依赖默认 docker0 网桥，也不能用 host 模式牺牲隔离性。实际落地的关键在于：用自定义桥接网络 + 显式 IP 规划 + 容器间服务发现 + 外部访问可控映射。
自定义桥接网络是生产首选
默认 docker0 网桥（172.17.0.0/16）不支持容器名自动解析，且网段固定、易冲突。生产必须创建独立命名、指定子网的桥接网络：
docker network create \ --driver bridge \ --subnet 192.168.100.0/24 \ --gateway 192.168.100.1 \ --opt com.docker.network.bridge.enable_icc=false \ --opt com.docker.network.bridge.host_binding_ipv4=0.0.0.0 \ prod-net
-
--subnet和--gateway明确规划 IP 段，避免与宿主机、内网其他网段重叠 -
enable_icc=false关闭容器间默认互通（配合后续--link或 DNS 控制访问） - 网络名
prod-net需统一、语义清晰，便于 compose 编排识别
容器间通信靠嵌入式 DNS，不是 IP 地址
Docker 自定义网络内置 DNS，容器启动时自动注册名称。只要在同一网络，就能直接用 container-name 访问：
# 启动数据库容器 docker run -d --name db --network prod-net -e POSTGRES_PASSWORD=123 postgres:15 # 启动应用容器，直接通过 db 连接 docker run -d --name api --network prod-net -e DB_HOST=db my-api-image
- 不要写死
192.168.100.2这类 IP —— 容器重启后可能变，且破坏可移植性 - 名称解析由 Docker 内置 DNS 自动完成，无需额外配置
/etc/hosts
外部访问严格按需暴露端口
生产环境禁止裸露所有端口，只映射真正需要对外服务的端口，并绑定到特定宿主机 IP（如仅监听内网或负载均衡器）：
# ✅ 正确：只暴露 443，且仅绑定到内网 IP docker run -d \ --name nginx-proxy \ --network prod-net \ -p 10.10.20.100:443:443 \ -p 10.10.20.100:80:80 \ nginx:1.27-alpine # ❌ 错误：0.0.0.0 映射，或未限制来源 -p 443:443 # 所有网卡都开放，存在暴露风险
- 若前端有负载均衡（如 Nginx、ALB、SLB），建议宿主机只监听
127.0.0.1或内网 IP，由 LB 转发 - HTTP/HTTPS 流量走反向代理，后端服务（如 API、DB）完全不映射外部端口，只在
prod-net内通信
多服务协同建议用 Docker Compose 统一编排
单条 docker run 难以维护，生产推荐 docker-compose.yml 声明式定义网络拓扑：
version: '3.8'
services:
web:
image: nginx:1.27-alpine
networks:
- prod-net
ports:
- "10.10.20.100:80:80"
depends_on:
- app
app:
image: myapp:v2.3
networks:
- prod-net
environment:
- DB_HOST=db
- REDIS_HOST=redis
db:
image: postgres:15
networks:
- prod-net
volumes:
- ./pgdata:/var/lib/postgresql/data
redis:
image: redis:7-alpine
networks:
- prod-net
networks:
prod-net:
driver: bridge
ipam:
config:
- subnet: 192.168.100.0/24
gateway: 192.168.100.1
- 所有服务共享同一逻辑网络
prod-net，天然支持服务名互访 -
ipam显式声明子网，避免运行时动态分配导致 IP 波动 -
depends_on仅控制启动顺序，不保证服务就绪 —— 应用层仍需实现重试或健康检查
补充关键细节
-
不要混用
host模式：它绕过 Docker 网络栈，失去隔离、端口管理、DNS 解析能力，仅限极少数监控/网络工具场景 -
避免
--link：已废弃，功能被自定义网络 DNS 完全替代 - 跨主机通信？ 单机部署够用；若需多节点，应升级到 Kubernetes 或 Swarm，而非硬凑 overlay 网络
- 防火墙配合：宿主机 iptables/firewalld 需放行映射端口，但禁止开放 Docker 默认网桥段（如 172.17.0.0/16）
不复杂但容易忽略
