1. 为什么容器网络总在能通和不通之间反复横跳刚接触容器化部署的人几乎都会经历同一个阶段单机跑一个服务很顺一旦要跑两个互相调用的服务网络问题就集中爆发。前端连不上后端、后端连不上数据库、容器里ping得通但端口连不上、宿主机能访问容器但容器访问不了宿主机……这些现象有个共同点看起来都是网络不通但根因完全不同。我把这类问题归成三层来看后面所有排查都围绕这三层展开层级关注对象典型症状排查入口容器内进程层服务是否真的在监听容器活着但端口没开ss -lntp、应用日志容器网络层容器与容器、容器与宿主机能 ping 通、连不上端口网段、网关、防火墙端口映射层宿主机与容器之间宿主机访问失败、外部访问失败-p参数、绑定地址绝大多数玄学网络问题其实是第一层和第二层的混淆。举个很常见的例子两个容器互相访问失败很多人第一反应是网络配置错了实际上可能是服务只监听了127.0.0.1而容器之间的流量是从虚拟网卡进来的根本到不了回环地址。这个问题跟网络配置一点关系都没有但现象上完全表现为网络不通。所以这篇内容不打算从什么是容器网络这种教科书定义讲起而是按实际搭建顺序 出错概率来组织先把容器之间怎么互通讲透这是最容易出错的部分再讲宿主机怎么访问容器最后讲跨主机互通时该注意什么。适合已经能跑起单个容器、但一碰到多容器协作就卡住的读者也适合把它当排错手册随时翻。先把结论摆出来同一台宿主机上容器之间最省心的互通方式是自定义网络 容器名解析宿主机访问容器靠端口映射跨主机互通优先考虑覆盖网络或直接用宿主机网络不要靠端口映射硬凑。下面逐条拆。2. 动手之前先把两个概念钉死2.1 容器网络不是虚拟网线而是一张虚拟交换机很多人脑子里对容器网络的想象是给两个容器拉一根网线于是下意识去找连接两个容器的命令。容器网络的实际结构不是这样它更像一台虚拟交换机宿主机上有一个虚拟网桥每个容器从网桥上分到一块网卡拿到一个虚拟网段里的地址网桥负责把这些地址之间的流量转发出去。这个类比很关键因为它直接决定了三件事容器拿到的地址是同网段的同网段内互通由网桥完成不需要额外配置不同网段之间能不能通取决于宿主机有没有做路由和转发网桥是宿主机层面的所以容器跨宿主机通信天然需要额外手段。理解这一点之后为什么默认网络下容器之间要用 IP 访问这个问题就顺了默认网桥只提供二层互通准确说是一层虚拟交换不提供名称解析服务容器之间只能靠地址互认。而自定义网络会附带一个内嵌的名称解析能力容器名直接当域名用。这是后面所有内容的分水岭。提示不同版本的运行时在默认网桥上的名称解析行为并不一致这一点在跨环境迁移时会造成我本地明明是好的这类问题。不要依赖默认网络做服务发现这是最省命的一条经验。2.2 容器里跑的服务监听地址决定一半的连通性第二件必须先钉死的事服务监听的地址比网络配置更能决定连通性。监听127.0.0.1只有容器内部能访问任何从容器外进来的流量都进不来监听0.0.0.0容器所有网卡都能访问容器间、映射后宿主机访问都正常监听指定虚拟网卡地址只在该网卡可达的路径上可用。很多应用默认配置为了安全就绑定回环地址单机开发时完全没问题一旦容器化就变成连不上。所以排查连通性时第一步永远是确认监听地址而不是先怀疑网络。这个顺序错了会在网络配置上浪费掉大量时间。我自己的固定动作是容器起来之后先看进程监听再看网络连通。顺序反过来就会陷入改配置—重启—还是不通的死循环。3. 容器之间互通的四种方式逐一说清适用边界3.1 默认网桥能通但不该拿来协作默认网桥最大的问题是没有名称解析容器之间只能用地址。而地址是动态分配的容器重启就可能变。这样一来任何需要容器互访的场景前端调后端、后端连缓存都会被迫写死地址或者用环境变量在编排层拼地址维护成本很高。更麻烦的是默认网桥上的容器彼此是隐式可达的——同一个默认网桥下的所有容器处于一个大家都能看见大家的状态隔离性很弱。对于只跑单个容器、或者多容器之间完全不需要互访的场景比如几个互不相关的独立服务默认网桥够用一旦涉及服务间调用就不要在这条路上继续投入了。3.2 自定义网桥日常协作的首选自定义网桥解决了默认网桥最痛的三个点容器名即域名同一网络内的容器可以直接用容器名访问不用关心地址隔离性不在同一网络内的容器互相不可见天然分组可指定网段避免和宿主机所在网段冲突。操作上很简单先建网络再起容器# 建一个自定义网桥指定网段避免和现有网段冲突 docker network create --driver bridge --subnet 172.28.0.0/16 app-net # 起两个容器都接入同一个网络并指定容器名 docker run -d --name backend --network app-net my-backend:latest docker run -d --name frontend --network app-net my-frontend:latest # 查看网络内成员和地址分配 docker network inspect app-net起完之后在frontend容器里直接curl http://backend:端口就能通。这里的名称解析是网络内嵌的能力不需要额外配置这也是自定义网桥值得作为默认选择的原因。几个实操细节值得单独提容器名必须唯一。同名容器在同一个网络内会冲突起不来这个报错很直白但容易被忽略成网络问题网络要先建再连。容器已经在跑了可以用docker network connect动态接入但接入后应用未必会立刻感知到新网卡稳妥做法还是起容器时就指定网段别乱选。用172.17、172.18这类默认网段做业务网络容易和宿主机上的其他虚拟网络撞车建议按项目分配独立网段。注意--network指定的网络必须在容器启动时已经存在否则容器起不来。脚本里建网络和起容器要保证顺序或者加失败重试。3.3 端口映射为容器外部的访问服务不是给容器之间用的端口映射-p解决的是宿主机上的进程/浏览器怎么访问容器它不是容器互通的方案。容器之间本来就同网段绕一圈经过宿主机端口再回来多了一层转发还额外占了宿主机端口没有任何好处反而引入了端口冲突的可能。这个误区很常见有人用-p把后端端口映射到宿主机然后让前端容器通过宿主机地址去访问后端。在单机场景下确实能跑但它带来两个隐患一是前端容器依赖宿主机的可达性容器一旦放到别的宿主机上就断二是绕过了网络隔离本该被收敛的访问路径被打通了。我的建议是容器之间的调用永远走容器网络端口映射只留给需要被外部访问的入口服务。3.4 覆盖网络跨宿主机时的正解跨宿主机互通时靠端口映射拼接是行不通的地址不再是同一个网桥上的邻居只能走真实网络。这时候的思路是在真实网络上叠一层虚拟网络让不同宿主机上的容器看起来仍处于同一个网络里容器名解析也照样可用。这类方案的核心要素有三点参与互通的节点要能互相通信、要有一个共享的成员信息来记录哪些容器在哪个节点上、容器流量要能被封装并投递到正确的节点。实际落地时绝大多数情况是一个编排工具把这层封装好了我们只需要在编排配置里声明这些服务属于同一个网络。手写这套配置的意义不大真正需要理解的是它依赖底层节点的连通性底层网络不通、端口被挡覆盖网络再正确也起不来。所以遇到跨主机不通先测节点之间的基础连通再看虚拟网络层。4. 宿主机访问容器端口映射的绑定地址才是关键4.1-p参数的完整语义-p的完整格式是宿主机地址:宿主机端口:容器端口/协议省略宿主机地址时默认绑定所有地址。写全格式能避免很多误解# 只绑定回环地址外部机器无法访问 docker run -d --name api -p 127.0.0.1:8080:8080 my-api:latest # 绑定所有地址外部可访问注意安全边界 docker run -d --name api -p 0.0.0.0:8080:8080 my-api:latest # 只给一个网段可达 docker run -d --name api -p 10.20.30.40:8080:8080 my-api:latest区别在于流量从哪块宿主机网卡进来。绑127.0.0.1时从外部网卡进来的请求根本不会转发到容器表现就是容器在跑、端口在听、外部连不上。这一点在开发环境里被大量使用不希望暴露给外部但如果部署时忘了改就会变成一个很难发现的配置问题。4.2 容器端口不写宿主机端口会怎样-p 8080这种只写一个端口的写法宿主机侧会随机分配一个高位端口。它适合我不关心从哪个端口访问先跑起来看的场景但对于需要被固定访问的服务是隐患——重启后端口可能变化外部依赖方就挂了。生产环境一律写全。4.3 容器访问宿主机的几种路径反向的访问容器要连宿主机上的服务比正向更容易出错因为容器里的本机是容器自己不是宿主机。可行路径有这几类用宿主机的实际地址容器网络能路由到宿主机时可用但地址在多环境下不稳定用宿主机上虚拟网桥的网关地址也就是容器所在网段里那个网关地址通常指向宿主机方向对但不保证所有环境一致用一条固定的别名记录部分运行时会在容器内注入指向宿主机的主机名记录写起来最省事但依赖运行时行为跨环境要验证。我的固定做法是先确认容器内到宿主机网关是否可达再决定用哪条路径。不要凭记忆写地址换台机器就可能不成立。如果服务确实需要双向访问且环境复杂我更倾向把需要共享的服务也放进容器网络两边都在同一个虚拟网络里名称解析直接搞定比研究宿主机地址省心得多。5. 一个真实排错链路从连不上到定位到监听地址这套排查顺序我用了很久几乎覆盖了日常九成的连通性问题。问题现象前端容器调后端失败报连接被拒绝但后端容器在正常运行。5.1 第一步确认两个容器在不在同一个网络docker network inspect app-net看Containers一节里是否有两个容器。曾经遇到过前端容器加入网络失败但启动没报错的情况实际是网络名拼错容器落到了默认网桥上——它在默认网桥上自然找不到后端。这一步的意义是排除网络根本没接入这种低级但高频的原因不要跳。5.2 第二步确认名称是否解析得出来# 在前端容器内执行 getent hosts backend解析不出来说明名称解析没生效回到第一步检查网络。解析出来但地址不对说明连到了错误的容器同名容器残留。这一步把名称解析问题和地址可达问题分开。5.3 第三步确认端口是否可达# 分两步先测连通再测端口 ping -c 2 backend curl -v http://backend:8080/healthping通但curl失败问题基本可以锁定在端口层或应用层。这里有个细节容器里通常没有ping、curl这些工具精简镜像更没有。临时排查可以起一个带工具的调试容器接入同一网络去测比往业务镜像里装工具干净docker run --rm -it --network app-net nicolaka/netshoot这是我很喜欢的一个做法调试容器接入目标网络后从它出发测目标服务既不影响业务容器又拿到了完整的排查工具集。5.4 第四步确认后端到底监听在哪docker exec backend ss -lntp如果看到的是127.0.0.1:8080问题定位完成——服务只监听了回环地址容器网络进来的流量到不了。改配置监听0.0.0.0后重启容器curl立刻通。这个案例里网络配置从头到尾都是对的真正的问题在第一层进程层。我把这个顺序固定成网络成员 → 名称解析 → 端口可达 → 监听地址。顺序的意义在于每一步都在排除一整类原因而不是凭直觉乱试。乱试的代价是时间而且容易改坏本来正确的配置。6. 几个容易踩的坑都是血泪换来的6.1 网段冲突最隐蔽的一类故障宿主机本身在一个网段容器网络又用了相同或重叠的网段结果是宿主机到某些地址的流量被错误地送进虚拟网桥或者容器发往宿主机同网段的服务时被劫持。症状是部分地址通、部分地址不通非常难排查。避免方法很直接建网络时显式指定一个不会和现有环境冲突的网段并且把这条规则写进项目约定里。不要依赖自动分配自动分配的网段在多个项目并行时很容易撞上。还有一种情况是宿主机上装了多层虚拟化环境各自都分配了网段叠加起来更容易冲突。遇到服务本身没问题但就是连不上的情况先看一眼宿主机路由表确认目标网段被谁接管了。6.2 改完配置不重启容器问题永远没修好网络接入、端口映射这类参数绝大多数在容器创建时固化改完必须重建容器才生效。用restart是不够的需要用rm加重新run或者编排层里up -d重建。我见过很多次我明明改了配置还是不通的现场最后发现容器还是旧的。建议养成习惯改网络相关配置后先确认容器是否是新建的看创建时间再判断配置是否生效。这个动作花不了几秒能省掉大量误判。6.3 防火墙与转发开关容器网络的隐形前置条件容器网络依赖宿主机的转发能力。有些环境默认关闭了转发或者安全策略只放行了特定端口结果就是容器之间或容器到外部不通报错信息还极其模糊。排查思路是先看转发开关再看安全策略最后看具体端口放行。这部分内容涉及具体系统配置不同发行版差异较大我不在这里展开具体命令但这个前置条件必须在排错清单里否则会在应用配置上反复绕圈。6.4 别在有状态服务上折腾网络数据库、缓存这类有状态服务网络配置一旦调整容易牵出连接串变更、连接池失效、主从地址失配等一串问题。我的做法是把有状态服务放在一个不轻易改动的固定网络里把易变的业务服务放在另一个网络通过显式连接建立关系。这样改业务侧网络不会波及数据侧排错范围也清晰。7. 把这套东西固化成清单比记命令有用工具和命令会变判断顺序不会。我自己总结了一张固定清单每次搭多容器环境时按顺序过一遍顺序检查项判断依据不通过时的动作1网络是否显式创建并指定网段network inspect重建网络避免网段冲突2容器是否全部接入同一网络网络成员列表启动时指定或动态接入3服务监听地址是否为全地址容器内查看监听改应用配置重启4容器间名称是否可解析容器内解析测试检查网络与容器名5端口是否可达从调试容器测试查端口、查监听6宿主机端口映射是否写全启动参数重建容器7转发与安全策略是否放行系统层检查按需放行清单的价值不在于步骤本身而在于它把改配置这个动作推到了最后。绝大多数连通性问题不需要改任何配置只需要确认现状。先确认、再动手是节省时间最多的习惯。最后分享一个我一直在用的小技巧搭新环境时先起两个最小的调试容器接入目标网络互相测通再往上叠业务服务。这样一旦出问题能立刻判断是环境层面的问题还是应用配置的问题排查范围直接砍掉一半。这个动作花两分钟但通常能省掉半小时的反复试错。