贵萌兄不少人把 Docker 用成了“一条龙”命令：docker run -d -p 8080:80 nginx，页面一开确实能访问。可一旦遇到端口不通、容器之间连不上、重启之后 IP 变了服务找不到，就开始到处翻帖子。这三个问题说穿了，全是 Docker 网络管理的基本功没到位。我见过太多人栽在“容器能跑但网络不通”上，尤其是从 Docker Desktop 安装到真实部署的过渡阶段，几乎每个人都踩过几脚坑。
这篇内容不打算做成命令字典，而是把我这些年处理 Docker 网络问题的思路、排查方法、踩坑记录一次性讲清楚。不管你是刚装完 Docker Desktop 的新手，还是已经在 Linux 服务器上跑容器的老手，只要还在被端口映射、容器互联、网络模式这些东西折腾，这篇就能派上用场。先讲模型，再讲安装期的坑，然后是日常操作，最后给一份故障排查速查表。每一段都对应一个真实场景，可以直接照着做。
1. Docker 网络模型：先把容器之间的通信规则捋清楚
1.1 五种网络模式，各自解决什么问题
Docker 默认提供五种网络模式：bridge、host、none、overlay、macvlan。很多人只知道 docker run 的时候加 -p 做端口映射，却不知道 -p 只是 bridge 网络的一种“对外开口”，而容器与容器之间怎么通信、跨主机怎么通信，完全由网络模式决定。
bridge 模式是默认网络。Docker 会在宿主机上创建一个虚拟网桥 docker0，每个容器分配一个虚拟网卡和 IP，容器之间通过这个网桥转发数据包。好处是隔离性不错，缺点是默认的 docker0 不支持容器名 DNS 解析，容器重启后 IP 会变，写死 IP 的脚本第二天就崩。
host 模式让容器直接共享宿主机的网络栈，没有独立 IP。端口直接用宿主机的，性能损耗最小，但隔离性没了，端口一旦冲突整个容器起不来。我一般只在跑性能敏感型任务时用，比如一些压测工具或对延迟要求极高的服务。
none 模式就是不给容器配网络，适合做纯计算任务或者跑一次就退出的批处理容器。
overlay 模式用于 Swarm 集群，跨多台宿主机通信时用。macvlan 模式则给容器分配一个宿主机物理网络的真实 IP，让容器在局域网里像一台独立机器。这两种日常单机场景用不上，但你要知道存在这么个东西，别到时候在面试或者方案评审时被问住。
1.2 为什么默认 bridge 网络容易“踩坑”
默认情况下，你用 docker run 不带 --network 参数启动的容器，全部挂在名为 bridge 的默认网络上。这个网络有俩硬伤。
第一，容器之间只能通过 IP 访问，不能通过容器名。比如你有两个容器 web 和 db，web 想连 db，你得先 docker inspect db 查它的 IP，再把 IP 写进 web 的配置文件。MySQL、Redis 这类服务一重启 IP 就变，配置文件跟着改，烦不胜烦。
第二，默认 bridge 网络下，所有容器都能互相访问，没有任何隔离策略。如果一台宿主机上跑着多个项目，项目 A 的容器不小心就能连到项目 B 的 Redis，安全隐患很大。
自定义 bridge 网络能同时解决这两个问题。同一自定义网络内的容器，Docker 内置 DNS 会自动把容器名解析成对应 IP。也就是说，你在 web 容器里直接写 db:3306 就能连上数据库，不用关心它实际 IP 是多少。而且不同自定义网络之间默认隔离，除非你显式把它们连到同一个网络上，否则互不相通。
1.3 自定义 bridge 网络的实际用法
创建一个自定义网络只需要一行命令：
bash复制docker network create app-net
启动容器时指定网络：
bash复制docker run -d --name mysql --network app-net -e MYSQL_ROOT_PASSWORD=123456 mysql:8.0
docker run -d --name web --network app-net -p 8080:80 nginx
这样 web 容器里直接 ping mysql 或者用 mysql:3306 连接就行，不用查 IP。
一个容器也可以同时挂在多个网络下，用 docker network connect 实现：
bash复制docker network connect app-net web
docker network connect another-net web
这在做网关或跨网络桥接时非常有用。比如一个容器既要访问内网服务，又要对公网提供服务，就可以同时挂两个网络。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从装好 Docker 到启动容器，卡人的“隐形”网络问题
2.1 Docker Desktop 报 Virtualization support 未检测到：八成不是 Docker 的问题
很多人的第一个坑出现在安装阶段。Windows 上装 Docker Desktop，启动时弹出 “Virtualization support wasn't detected” 之类的报错，第一反应是 Docker 没装好，重装三遍还是老样子。实际上问题出在 Windows 的虚拟化功能没打开。
Docker Desktop 在 Windows 上依赖 Hyper-V 或者 WSL2，这两种方案都需要 CPU 虚拟化功能开启。检查步骤很简单：打开任务管理器，切到“性能”标签，看右下角“虚拟化”这一项是“已启用”还是“已禁用”。如果显示“已禁用”，需要进 BIOS/UEFI，找到 Intel Virtualization Technology 或 AMD SVM Mode，把它改为 Enabled，保存重启。
如果你用的是 Windows 11 家庭版，系统可能默认不装 Hyper-V，这种情况下建议用 WSL2 方案。在 PowerShell 里执行：
powershell复制wsl --install
装完再打开 Docker Desktop 的 Settings，把 “Use the WSL 2 based engine” 勾上。这一步做完，绝大多数启动报错都能解决。
2.2 WSL2 模式下，Docker 的 IP 和端口到底走哪条链路
WSL2 本质是一个轻量虚拟机，和宿主机之间通过虚拟网卡通信。Docker Desktop 在 WSL2 里跑的容器，端口映射跟我们直觉上想的“宿主机 8080 映射到容器 80”不太一样。实际上 Docker Desktop 会自动在 Windows 侧做一层端口转发，默认情况下，你在浏览器访问 localhost:8080 就能到容器里的 80 端口，体验上没区别。
但如果你的应用需要监听非 localhost 地址，比如局域网内其他设备要访问这台机器上的容器，情况就不一样了。WSL2 的 IP 不是固定的，Windows 每次重启 WSL 虚拟网卡的地址都可能变化。我的建议是，这种情况下尽量不要直接用 Docker Desktop 跑生产服务，部署到 Linux 服务器上更省心。
如果你只是本地开发，局域网设备访问不到容器端口，先别急着怀疑 WSL 网络。在 PowerShell 里执行 ipconfig，看以太网或 WLAN 的 IPv4 地址，让同一局域网内的其他设备访问 http://你的WindowsIP:映射端口。如果还是不通，大概率是 Windows 防火墙拦了，在“高级安全 Windows Defender 防火墙”里给对应端口加一条入站允许规则即可。
2.3 “Failed to connect to the docker api at npipe” 与 Docker Context 的真相
Docker Desktop 启动后，命令行执行 docker ps 报错：
text复制error during connect: failed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine
这个报错字面意思是连不上 Docker 的 API 管道。常见原因有两个：一是 Docker Desktop 还没完全启动，引擎没就绪，等十几秒再执行往往就好了。二是 Docker CLI 连接的 endpoint 不对，也就是 Docker Context 指错了地方。
Docker Context 这个概念很多人没注意到，却是个经常坑人的设置。它定义了 Docker CLI 去连接哪个引擎，可以是本机的 Docker Desktop，也可以是远程服务器上通过 TLS 暴露的 Docker Engine。查看当前 context 用：
bash复制docker context ls
正常情况下会有一个 desktop-linux 的 context，标记为当前。如果当前指向了别的远程机器，你执行的命令全在远程上生效，本地的容器当然看不到。
修复方法：
bash复制docker context use desktop-linux
如果你压根不需要远程 context，干脆把没用的删掉：
bash复制docker context rm 名字
3. 日常网络管理实操：端口、互联、DNS 与 Compose
3.1 端口映射：为什么 -p 8080:80 有时候不生效
端口映射的大前提是容器里的进程真的在监听 80 端口。很多新手排查半天，结果发现容器里跑的服务改了端口，或者启动失败根本就没起来。所以碰到端口不通，第一件事永远是进容器里看服务状态：
bash复制docker exec -it 容器名 sh
curl localhost:80
观察容器内部是否能访问，能访问再谈映射问题。
-p 参数的完整格式是：
text复制-p [宿主机IP:]宿主机端口:容器端口[/协议]
默认映射到 0.0.0.0，也就是宿主机所有网卡上的那个端口。如果你只想让容器服务只在本地可访问，可以绑定回环地址：
bash复制docker run -d -p 127.0.0.1:8080:80 nginx
这样局域网内其他设备就无法访问这个端口，安全性更好。
有一个容易忽视的细节：-p 指定的是 TCP 还是 UDP。默认是 TCP。如果你的容器跑的是 DNS 或某些音视频服务，用 UDP 传输，必须显式写明：
bash复制docker run -d -p 53:53/udp -p 53:53/tcp dns容器
3.2 容器互联：用服务名代替 IP 的三种方式
最老式的做法是 --link。docker run --link 目标容器名:别名 之后，当前容器可以通过别名访问目标容器。但这个机制已经过时，官方文档也建议弃用，只是老项目里还能看到。
第二种是自定义网络，前面已经讲过。同一网络内直接通过容器名访问，干净利落。
第三种是 Compose 项目里的服务名。用 docker compose 启动的服务，互相之间用 服务名 作为 hostname 访问，比如你有 web 和 db 两个 service，web 里写 db:3306 就能连上数据库。Compose 会自动创建一个项目专属网络，并把所有服务挂上去。
3.3 Compose 项目里的网络编排与依赖顺序
一个标准的 docker-compose.yml 长这样：
yaml复制version: "3.8"
services:
web:
image: nginx
ports:
- "8080:80"
networks:
- frontend
- backend
db:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: 123456
networks:
- backend
networks:
frontend:
backend:
这里 web 同时挂了 frontend 和 backend 两个网络，db 只挂在 backend 上。效果是 web 能访问 db，但 db 不能直接访问 web 的 80 端口，实现单向隔离。
depends_on 很多人理解成“等依赖服务完全就绪再启动”，其实它只控制启动顺序，不保证依赖服务可用。如果 web 依赖 db 的端口就绪，建议在应用层做重试机制，或者用 healthcheck：
yaml复制services:
db:
image: mysql:8.0
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
interval: 5s
retries: 10
web:
depends_on:
db:
condition: service_healthy
这样 web 会等 db 健康检查通过后才启动，比傻等几秒靠谱得多。
3.4 我常用的网络运维命令清单
排查网络问题不需要记住几百条命令，常用的就这几个：
bash复制docker network ls # 查看所有网络
docker network inspect 网络名 # 查看某网络连接的容器、IP、子网配置
docker port 容器名 # 查看容器的端口映射情况
docker exec 容器名 ip addr # 进容器看它的网络配置
docker exec 容器名 ping 目标 # 测试容器到目标的连通性
docker logs 容器名 # 排查端口不通时，看容器日志往往比看网络更快
我排查网络问题的典型顺序是：先看容器日志，确认服务有没有起来；再看 docker port，确认端口映射是否符合预期；然后进容器 ping 目标 IP 和容器名，确认网络层通不通；最后才查防火墙和路由。
4. 常见网络故障速查：端口不通、权限报错、镜像拉取慢
4.1 端口不通的排查顺序，一条条过
端口不通是最常见的问题，没有之一。我总结了一套固定排查路径：
一是确认容器在跑。docker ps 看状态是否为 Up，如果容器反复重启，八成是应用启动失败，不是网络问题。
二是确认容器内服务在监听。docker exec 容器名 netstat -tlnp 或者 ss -tln 看有没有监听对应端口。有些镜像是精简版，没有这些命令，可以用 apk add iproute2 之类的补一下。
三是确认映射是否生效。docker port 容器名 会显示宿主机端口和容器端口的映射关系。如果这里为空，说明容器根本不是用 -p 启动的，需要在网络层面做端口转发，或者重建容器。
四是确认宿主机防火墙。Linux 上执行：
bash复制sudo iptables -L -n | grep 8080
Windows 上检查防火墙入站规则。如果容器服务正常、映射正常、防火墙也放行了，那多半是云服务商的安全组没开端口。这个坑特别多人踩，本地怎么测都通，换到服务器就不行，最后发现是控制台里的安全组规则漏了。
4.2 “permission denied” 不是网络问题，但最容易让人误判
执行 docker ps 报错：
text复制permission denied while trying to connect to the Docker daemon socket
看着像权限问题，但本质是当前用户不在 docker 用户组里。Linux 上装完 Docker 后，需要把当前用户加入 docker 组才不用每次加 sudo：
bash复制sudo usermod -aG docker $USER
改完重新登录或执行 newgrp docker 使配置生效。这个步骤跟网络没有直接关系，但如果拿这个问题去搜“Docker 网络”相关关键词，很容易被误导去检查网络配置，白折腾半天。我把这类问题也列在这里，是想提醒你，很多报错表面上是网络问题，实际跟网络没半点关系，先看清报错内容再动手。
4.3 镜像拉取慢：配置 registry mirror 的正确姿势
镜像拉取慢是 Docker 使用体验里最影响心情的一件事。解决思路不是换一个多快的网络，而是给 Docker 配置 registry mirror，也就是镜像源的镜像源。Docker 拉镜像时，会先去配置的镜像源地址找，找不到再回源到 Docker Hub。
Linux 上修改 /etc/docker/daemon.json：
json复制{
"registry-mirrors": ["https://你的镜像源地址"]
}
改完后执行：
bash复制sudo systemctl restart docker
用云厂商提供的容器镜像服务地址是最稳妥的选择，速度稳定且内网 CDN 加速明显。
Windows 的 Docker Desktop 在 Settings 的 Docker Engine 配置里编辑相同的 JSON，改完 Apply & Restart 即可。
这里提醒一句：配置镜像源时只推荐可信的公共镜像源或自己所在云平台提供的地址，不要随手抄网上来路不明的源，一方面可能有安全风险，另一方面服务稳定性也没保障。
4.4 容器重启后 IP 变化，如何避免
默认 bridge 网络下，容器重启后 IP 可能变，这是 DHCP 分配的机制决定的。对应用来说最致命的是，代码里写死了容器 IP，比如 web 的配置里有 192.168.16.2:3306，但数据库容器重启后变成了 192.168.16.5，连接直接失败。
标准的解决办法就是前面讲的自定义网络加容器名访问。容器重启后，虽然 IP 变了，但 Docker 内置 DNS 会自动更新，用 mysql 这个名字照样能找到新的 IP。
如果你真的需要固定 IP 的场景，比如某些传统应用改不了配置，可以在创建网络时指定子网，然后给容器分配静态 IP：
bash复制docker network create --subnet=172.20.0.0/16 static-net
docker run --network static-net --ip 172.20.0.10 mysql
静态 IP 能解决问题，但会增加维护成本。网络里每加一个容器都要手动规划 IP，容易冲突，我一般只在数据库或网关这类核心组件上才用。
最后再分享一点个人体会
我接触 Docker 这么久，最大的感受是：网络问题之所以让大多数人头大，是因为它不像容器启停那样有明确的“成功”反馈。容器启动了、日志没报错，可页面就是打不开，这种不确定性很磨人。但反过来，Docker 网络又是整个生态里最规整的一块，只要你理解了 bridge 和自定义网络这两个核心概念，遇到问题按“容器内、映射、防火墙、安全组”的顺序排查，九成以上的问题能在五分钟内定位。
我自己踩坑最多的反而是最简单的环节：忘了看容器日志、没检查防火墙、忽略了云端安全组。网络管理和开发其他环节一样，先确认最基础的东西，再去折腾复杂方案。希望这篇内容能帮你少走几圈弯路，遇到容器网络的问题时能更有底气。