大家好，我是站长。最近在社群里看到不少朋友在折腾 Docker 网络时踩坑：两个容器明明都跑起来了，一个 Nginx 死活连不上后端的 Node.js 服务，查日志全是 Connection refused 或者 timeout。很多人第一反应是去改 -p 端口映射，或者干脆把容器网络改成 host 模式草草了事。说实话，这种做法在单机玩具项目里勉强能跑，一旦上了生产环境，绝对是运维灾难的导火索。
今天站长就从架构师的视角，把 Docker 容器间内网互通这件事彻底讲透。不玩虚的，全是生产环境验证过的 SOP 和调优清单。
一、核心原理概述：为什么你的容器 Ping 不通？
💡 推荐阅读：别再把防火墙当摆设了：从80/443到业务端口，聊聊我踩过的UFW配置坑
要搞懂互通，先得明白 Docker 默认的网络模型。当你安装完 Docker，它会自动创建三个网络：bridge（默认）、host 和 none。绝大多数情况下，容器都跑在默认的 bridge 网络里。
默认 bridge 网络的致命缺陷：它只提供容器与宿主机之间的 NAT 通信，容器之间无法通过容器名进行 DNS 解析。也就是说，你只能通过 Docker 动态分配的 IP（通常是 172.17.0.x 段）来互访。一旦容器重启，IP 变了，你的配置就全废了。
这就是为什么你 exec 进容器去 ping 另一个容器名，会报 ping: bad address 的原因。默认 bridge 网络压根就没有内置的 DNS 服务。
二、生产环境架构规范：自定义 Bridge 网络才是正解
💡 延伸阅读：别再用那些老掉牙的教程了：Nginx 反代 + 免费证书自动续签，我踩过的坑都在这了
在生产环境，站长强烈建议彻底抛弃默认 bridge 网络，使用用户自定义的 Bridge 网络（User-defined Bridge Network）。它自带以下核心优势：
- 自动服务发现：Docker 内置 DNS 服务器，容器之间可以直接通过容器名或网络别名通信，无需关心 IP 变化。
- 更好的隔离性：只有加入同一自定义网络的容器才能互通，默认网络中的容器无法访问，安全性更高。
- 动态热插拔：运行中的容器可以随时加入或离开网络，无需重启。
实操步骤：创建自定义网络并部署双容器
假设我们要部署一个 Web 应用（Nginx）和一个后端 API（Node.js），让 Nginx 能直接通过容器名访问 API。
第一步：创建专属网络
docker network create --driver bridge --subnet 172.20.0.0/16 my-app-net这里站长指定了 --subnet，是为了避免和宿主机内网或其他 VPN 网段冲突。生产环境务必规划好网段，别偷懒用默认的 172.17.0.0/16，否则后续接入 K8s 或 VPN 时你会哭。
第二步：启动后端 API 容器并加入网络
docker run -d --name api-server --network my-app-net --network-alias api node:18-alpine node server.js注意 --network-alias api 这个参数，它给容器起了一个网络别名。这样 Nginx 配置里写 proxy_pass http://api:3000 就行，比写容器名更灵活。
第三步：启动 Nginx 容器并加入同一网络
docker run -d --name web-nginx --network my-app-net -p 80:80 nginx:alpine现在，进入 Nginx 容器测试连通性：
docker exec -it web-nginx ping api
# 输出应显示 PING api (172.20.0.x) 的响应看到延迟数据，说明内网互通已经搞定。接下来只需要修改 Nginx 配置文件，把后端地址指向 http://api:3000 即可。
三、性能与安全加固调优清单
💡 深度技术指南：别再手动传包了：从裸机到生产级容器，站长手把手教你Docker部署项目的正确姿势
网络通了只是第一步，生产环境还得考虑性能和安全性。以下是站长压箱底的调优清单，建议逐条核对。
| 调优项 | 配置建议 | 作用 |
|---|---|---|
| 自定义 MTU | --opt com.docker.network.driver.mtu=1450 |
避免 overlay 网络或 VPN 环境下的分片丢包 |
| 启用 ICC | 默认开启，生产可关闭 --opt com.docker.network.bridge.enable_icc=false |
关闭容器间通信，强制走网关策略，提升隔离性 |
| 固定 IP 分配 | --ip 172.20.0.10（需配合 --subnet） |
关键中间件（如数据库）固定 IP，避免 DNS 抖动 |
| 网络加密 | Overlay 网络启用 --opt encrypted |
跨主机通信加密，防嗅探 |
| 日志驱动限制 | --log-opt max-size=10m |
防止网络日志撑爆磁盘 |
特别提醒：如果你的容器需要跨宿主机通信，那就得用 overlay 网络，并且需要搭建 Consul 或 Etcd 作为服务发现后端。这属于 Swarm 或 K8s 的范畴，复杂度直线上升。对于大多数中小项目，单机自定义 bridge 网络完全够用。
另外，站长建议在云服务器上部署时，务必检查安全组规则。很多新手在 Docker 里配好了网络，结果云厂商的安全组没放行端口，外部死活访问不了。买云服务器时，尽量选大厂，网络稳定性和安全组管理都省心。别为了省几十块钱用杂牌云，网络抖动丢包能让你怀疑人生。
四、验证测试与 SOP 总结
配置完成后，不要只 ping 一下就完事。生产环境的标准验证流程如下：
- DNS 解析验证：
docker exec web-nginx nslookup api，确认返回正确的容器 IP。 - 端口连通性验证：
docker exec web-nginx nc -zv api 3000，确认目标端口开放。 - 应用层验证：
docker exec web-nginx curl -I http://api:3000/health，确认 HTTP 状态码 200。 - 反向验证：从 api 容器 ping web-nginx，确保双向互通，排除单向防火墙规则干扰。
- 重启持久化验证：
docker restart api-server，再次执行上述测试，确认容器 IP 变化后 DNS 依然能正确解析。
最后，站长总结一下标准操作流程（SOP）：
规划网段 → 创建自定义网络 → 容器加入网络并设置别名 → 应用配置使用别名通信 → 执行五步验证 → 加固 MTU 与 ICC 策略。
把这套流程跑通，你就能彻底告别端口映射的泥潭。Docker 的网络模型设计其实非常优雅，只是默认配置为了兼容性做了一些妥协。作为开发者，主动拥抱自定义网络，才是走向生产级部署的第一步。
好了，今天的分享就到这里。如果你在配置过程中遇到什么诡异问题，欢迎在评论区留言，站长看到会尽量回复。折腾网络这件事，踩坑越多，功力越深。