接触Docker时间长了几乎每个人都会撞上网络相关的坑。而Docker网络冲突恰恰是最让人头疼的一类问题——它不像容器崩溃那样有明确报错往往表现为各种“怪现状”容器能启动但业务访问不了、两个容器之间时通时断、创建网络时提示IP地址已被占用、甚至宿主机自己的业务系统也莫名其妙跟着断网。我自己维护过几十台Docker主机的环境这类问题几乎每个月都能碰上一次。这篇文章就把我踩过的坑和沉淀下来的排查思路完整整理出来从底层原理讲到具体命令最后附上速查表和避坑清单希望能帮你在下一次“网络诡异故障”出现时少走弯路。1. 先从Docker的网络模型说起搞懂冲突的根源1.1 为什么Docker会“抢”网段要理解网络冲突首先得明白Docker默认是怎么分配IP的。Docker安装完成后会自动创建一个名为docker0的虚拟网桥这个网桥默认使用172.17.0.0/16这个私有网段宿主机自己占172.17.0.1后续创建的容器依次拿到172.17.0.2、172.17.0.3……如果你继续用docker network create创建新的bridge网络且不手动指定网段Docker会从系统预留的地址池里继续挑选下一个可用网段常见的有172.18.0.0/16、172.19.0.0/16一直递增到172.31.0.0/16。问题就出在这里这些网段恰好也是局域网、办公网、路由器后台、虚拟机NAT网络最喜欢用的私网段。比如很多单位的内网规划就是172.16.0.0/12整段或者某个办公系统恰好使用了172.17.x.x段一些家用路由器默认是192.168.1.0/24但也有人手动改成172.16.x.xVMware、VirtualBox的NAT模式也经常落在192.168.x.x或172.16.x.x上。Docker启动时并不知道你内网用了哪些网段它只会按自己的顺序往下分配。一旦撞上结果就是容器、宿主机、局域网设备之间路由表互相打架。1.2 冲突的常见类型不只是IP重复这么简单很多人一提“网络冲突”就以为是两个容器IP重复其实没那么单纯。我总结下来常见的有四类。第一类是网段重叠冲突也就是上面说的Docker桥接网段和现有网络网段重叠。第二类是端口映射冲突宿主机上某个端口已经被别的进程占用你再拿-p 8080:80启动容器就会启动失败这类问题其实比网段冲突更常见。第三类是路由表冲突Docker会在宿主机路由表里写入自己网段的路由如果这个路由恰好覆盖了你的业务路由后果就是数据包明明要去某个内网地址却绕进了docker0网桥直接走丢。第四类是网络命名空间污染比如容器残留的虚拟网卡、iptables规则没清理干净导致新建的网络行为异常。理解了冲突的根源后面的排查和解决才有方向。说实话大部分网络冲突都不是什么高深的网络问题而是IP地址规划没做好。2. 网络冲突的典型症状你遇到的到底是什么问题网络冲突的症状五花八门但如果仔细归纳其实都能归到几个典型模式里。你可以对照下面的表现来判断自己到底属于哪一类。2.1 症状一容器起来了但外部怎么也访问不到这是最常见的现象。你明明执行了docker run -d -p 8080:80 nginx容器状态是Upcurl http://localhost:8080也通了但局域网里其他同事的电脑就是访问不到你的服务。如果你确认宿主机防火墙没拦那问题大概率就出在网段上——比如宿主机自身IP是192.168.1.100/24但Docker bridge网络被分配成了192.168.1.128/25一段两者重叠之后Linux路由表里会同时出现两个指向不同接口的192.168.1.0/24路由回包路径就紊乱了数据包不知道应该走物理网卡还是走docker0网桥表现就是“宿主机自己通、别人不通”或者“时通时断”。2.2 症状二创建网络时报地址占用错误当你执行docker network create时如果系统直接报错Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network这就是非常明确的网段冲突信号。Docker想说默认那些网段我一个个试过去发现都被现有网络或系统路由占用了我实在找不到一个干净的网段了。出现这种报错通常说明宿主机上已经创建了大量bridge网络或者物理网卡/虚拟网卡占用了大段私网地址把Docker默认的地址池挤满了。2.3 症状三容器之间互相ping不通或者A能连B但B连不上C如果是同一个bridge网络内的两个容器互相不通可能是网桥本身的问题但如果你创建了多个自定义网络然后把容器分别放进了不同网络里那它们之间本来就不通这是Docker的隔离机制不算故障。真正的故障场景是两个容器都在同一个my-net网络里网络模式下应该互通但实际ping不通或TCP连不上。这时候要检查网段是否和宿主机路由冲突因为如果Docker网络的网关IP和某个真实物理接口的IP相同数据包在宿主机的路由决策阶段就已经被劫走了。2.4 症状四宿主机自己的业务系统跟着遭殃这个更隐蔽。有一次我在一台跑着ERP中间件的服务器上装了Docker结果没过多久公司核心系统的调用开始异常排查下来发现是Docker把172.16.0.0/12网段里的一个子段抢走了而ERP系统恰好就是通过172.16.x.x访问数据库的。这类问题最难定位因为故障现象完全不在Docker容器本身而是宿主机的其他业务先挂了。网络冲突的影响范围从来不只是容器它会把宿主机整个路由搅乱。3. 排查流程像侦探一样定位冲突点排查网络冲突最重要的不是急着改配置而是先把现场情况摸清楚。我有一套固定的排查流程按顺序执行基本不会漏。3.1 先看现状三个必敲的命令第一个命令是docker network ls列出当前所有网络。这一步能确认你手头有多少个bridge网络网络名是什么。docker network ls第二个命令是docker network inspect 网络名。比如我们经常看到一堆xxx_default这样的网络这是docker compose自动创建的。你需要重点看这个网络的Subnet和Gateway字段docker network inspect myapp_default | grep -A 5 Subnet输出类似这样IPAM: { Config: [ { Subnet: 172.18.0.0/16, Gateway: 172.18.0.1 } ] }第三步是看宿主机路由表这在网段重叠时是决定性的证据ip route show table main如果看到类似这样的输出就要警惕了172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 172.18.0.0/16 dev br-abc123 proto kernel scope link src 172.18.0.1 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100注意最后一行和上面两行的关系——如果Docker网段恰好是192.168.1.0/24那路由表里就会出现两条指向同一个网段但不同网卡的路由这就是冲突的直接证据。3.2 看防火墙和NAT规则iptables也是重灾区Docker会往iptables里写大量规则包括NAT规则、FORWARD规则等。如果网络冲突有时候是因为规则顺序错乱或者新旧规则残留互相覆盖。查看NAT表iptables -L -t nat -n -v重点看POSTROUTING链里有没有MASQUERADE规则以及DOCKER相关链的地址范围是否正确。如果你的宿主机开了很多Docker网络这里会有一串DOCKER链每个链对应一个网络。如果你发现某个链里的IP范围和你物理网卡网段重叠基本就能定位问题网络了。3.3 用tcpdump抓包验证让数据说话前面几个命令都是静态查看配置但真正要确定数据包“卡”在哪里还是得抓包。比如容器A能ping通网关但访问容器B的8080端口不通你可以在宿主机上执行tcpdump -i docker0 host 172.18.0.2 and port 8080然后在容器A里发起请求观察有没有包到达docker0。如果容器A的请求从来没出现在docker0上说明请求根本没从容器A出来或者被路由到了别的地方如果请求到了docker0但没有回包说明容器B的响应没走对路。抓包能帮你把问题从“现象”转化为“证据”尤其适合排查那种“时通时断”的怪问题。3.4 分清楚你是在宿主机上还是在容器里排查如果你用的是Linux原生Docker直接在宿主机上执行这些命令没问题。但如果用的是Docker DesktopWindows/macOS情况就完全不同了——Docker实际上是跑在WSL2虚拟机里的你在PowerShell里执行ipconfig看到的网卡列表和容器里看到的网络是完全不同的两层。排查Docker Desktop的网络问题你需要进入WSL2发行版或Docker Desktop的虚拟环境里再执行ip route和iptables这也是很多人拿着网上的Linux排查教程去套Docker Desktop却怎么都找不到对应网卡的原因。4. 解决方案从临时到根治的完整路径定位到冲突原因之后接下来的思路就清晰了要么给Docker换一个不冲突的网段要么让现有业务给Docker腾位置。下面从轻到重给出几套方案你可以按实际情况选择。4.1 临时解法删除重建网络并指定新网段如果冲突的是用docker network create创建的自定义网络最简单的做法是删除后重建这次务必指定一个不会冲突的subnet# 先暂停使用该网络的容器 docker stop $(docker ps -q --filter networkmy-net) # 删除网络 docker network rm my-net # 重建为10.x段避免与内网重叠 docker network create \ --driver bridge \ --subnet10.88.0.0/24 \ --gateway10.88.0.254 \ my-net这里我习惯用10.88.0.0/24因为10.x段通常在企业内网留白比较多比172段和192.168段安全不少。当然前提是你已经确认整个内网都没用到这段地址。重建网络后重新启动容器让它们加入即可。注意docker network rm要求网络里没有容器连接所以必须先停掉容器或者用docker network disconnect先断开。4.2 根治手段修改daemon.json默认地址池如果你的Docker环境下网段冲突是长期问题或者你希望以后创建网络时Docker能自动避开冲突区段那就得改Docker daemon配置。在Linux服务器上编辑/etc/docker/daemon.json加上default-address-pools字段{ default-address-pools: [ {base: 10.90.0.0/16, size: 24} ] }保存后重启Docker服务systemctl restart docker这段配置的意思是说以后Docker在创建新bridge网络时不再去172.18、172.19这些默认网段里挑而是从10.90.0.0/16网段里按“每24位掩码一个子网”的方式分配也就是自动分配10.90.0.0/24、10.90.1.0/24……这样就从根源上避开了最常见的内网冲突区段。如果你用的是Docker Desktop界面里也能改打开Settings - Docker Engine在JSON配置里写入同样的字段然后点击Apply Restart。注意这个配置只对新建的网络生效已经存在的旧网络不会自动迁移需要删除重建。4.3 关键细节改了地址池docker0也要一起改很多人改了default-address-pools但发现docker0这个默认网桥还是顽固地使用172.17.0.1这是因为docker0的地址由另一个参数bip控制。如果docker0本身也和你内网冲突就得在同一个配置文件里再加一行{ bip: 10.90.255.1/24, default-address-pools: [ {base: 10.90.0.0/16, size: 24} ] }这里我把docker0固定成10.90.255.1/24跟自动分配的容器网段隔开来避免以后扩容时打架。改完重启Docker执行ip addr show docker0确认生效。需要注意的是改bip会重建Docker网络栈所有旧容器即使还在它们的网络连接也会被断开重建所以最好在维护窗口执行。4.4 固定IP方案当你的业务必须要稳定IP时有些场景下容器每次重启IP都在变会让你很头疼尤其是下游系统配置了IP白名单的情况。这时可以给容器手动指定固定IP。先在创建网络时指定好子网和IP范围docker network create \ --driver bridge \ --subnet10.91.0.0/24 \ --ip-range10.91.0.128/25 \ fixed-net然后启动容器时指定固定的--ipdocker run -d \ --network fixed-net \ --ip 10.91.0.130 \ --name myapp \ nginx:alpine这里--ip-range限定了DHCP动态分配的区间把你手动固定的IP单独留在另外一段避免Docker自动分配时不小心把同一个IP给了别的容器。固定IP方案有个容易踩的坑如果两个容器手动指定了同一个IP第二启动的容器不会报错但它的网络会异常表现为“能ping通网关但访问不了服务”。所以最好拿个表格记录每个容器的固定IP。4.5 处理端口映射冲突宿主端口被占用了如果你遇到的是docker run时提示port is already allocated那就是典型的端口占用冲突。处理思路很简单先查一下谁占用了端口ss -lntp | grep 8080然后把宿主端口换掉或者停掉占用端口的进程。比较取巧的做法是让Docker自动分配宿主端口只指定容器端口docker run -d -p 80 nginx # 宿主机随机分配一个高位端口映射到容器80然后用docker port 容器名查一下映射到了哪个端口。不过自动分配端口对客户端访问不太友好生产环境还是建议把端口规划写到配置清单里。5. 不同场景下的冲突实录与应对理论和命令都讲完了下面分享几个我实际处理过的场景这样你对照起来更直观。5.1 办公网172网段冲突最经典也最坑某次在客户现场部署一套业务系统服务器是CentOS 7分配的内网IP是172.16.10.5/24客户其他系统都在172.16.0.0/12大网段内互联。装完Docker后默认docker0占了172.17.0.1。起初业务一切正常但当他们在服务器上启动好几个compose项目后突然发现几个跟外部系统对接的服务开始超时。我上服务器一看路由表两个bridge网络分别占了172.18.0.0/16和172.19.0.0/16跟172.16.0.0/12属于同一个大段部分交换机路由开始有歧义。这种问题的危害是间歇性的特别难抓。最终处理是把所有compose项目的网络网段全部改为10.x段同时把daemon.json里的default-address-pools改成10段。这里的教训是只要办公网、机房用了172段Docker就必须全部迁走不要心存侥幸。5.2 家用宽带的192.168网段冲突家用场景一般没这么复杂但也挺常见。家里路由器通常用192.168.1.1或192.168.0.1如果你在NAS或老电脑上装了Docker跑几个容器后发现局域网内的其他设备访问NAS不太稳定或者容器里访问家里其他设备访问不到那十有八九是Docker bridge网络被分配到了192.168.x.x里。比如Docker自动创建了一个192.168.1.0/24的bridge网络网关是192.168.1.1——这跟你家路由器网关一模一样路由表直接乱套。家用环境最简单的解法就是复制上文方案在daemon.json里把bip和default-address-pools都改成一个家里肯定不会用的网段比如10.0.88.0/16重启Docker后一切恢复。5.3 云服务器VPC网段冲突云上更要注意云服务器的VPC网段各家不一但很多默认也集中在172.16.0.0/12到192.168.0.0/16之间。如果你在云主机上装Docker而且VPC的子网恰好划到了172.17.0.0/16这种情况我遇到过好几次那Docker一启动docker0就和VPC内网重叠了后果是这台云主机和其他同VPC主机之间的通信断断续续甚至在控制台远程连接都会受影响。云上环境改配置要更小心因为Docker重启可能会影响SSH连接建议使用云控制台的VNC终端操作避免中途失联。改完配置后记得在安全组里确认一下端口策略因为Docker默认的NAT规则可能绕过或干扰已有的安全策略。5.4 跨主机容器通信overlay网络的隐性冲突还有一种场景是跨主机容器通信时出的问题尤其在使用Swarm或K8s时overlay网络会用到VXLAN技术默认使用UDP 4789端口。如果宿主机之间的防火墙、云安全组没放行这个端口容器之间虽然能加入同一个overlay网络但跨主机的流量直接就断了表现就是“同宿主机容器能通、跨主机不通”。这个问题和IP网段重叠无关属于网络层面的“隐性冲突”。排查时可以抓UDP 4789的包确认是不是被拦了。在云上创建Swarm集群时安全组除了放行管理端口还要把VXLAN端口一并放行否则后面折腾半天都不知道是防火墙在捣乱。6. 常见问题与排查技巧速查表为了让你快速对照我把最常见的网络冲突问题整理成一张表。这里的每一项都是我在实操中验证过的有效路径。症状排查方向处理思路容器能起但外部访问不到查看宿主机route表和bridge subnet换不冲突网段重建网络检查防火墙转发创建网络报“non-overlapping IPv4 address pool”检查docker network ls和已有subnet删除无用网络修改default-address-pools两个同网段容器互ping不通inspect网络确认都在同一网络内检查网关IP是否和物理网卡重叠重启容器容器内无法访问宿主机局域网服务检查容器网段是否被路由到别处改bridge网段避开局域网段用--add-host临时指路端口映射提示“already allocated”ss -lntp查看占用端口进程换端口或停进程用-p 自动端口临时规避改daemon.json后Docker启动失败检查JSON语法journalctl -u docker看日志修复JSON格式错误先用dockerd --validate校验Docker Desktop容器访问宿主机服务失败确认服务监听地址是否含容器网关IP把服务监听0.0.0.0或用host.docker.internal再说几个不在表里但值得记下来的避坑技巧。第一网络规划永远是第一位的。任何一台要装Docker的服务器我先确认它所在的内网网段、办公网网段、云VPC网段然后直接给Docker预留一个完全不相交的大段比如10.233.0.0/16。这套做法帮我挡住了90%的后续问题。你可以把规划写进部署文档里团队其他人来维护时也清楚。第二改daemon.json前一定先备份。我已经见过不止一次因为少写一个逗号导致整个Docker服务起不来的事故。稳妥的做法是改完先执行dockerd --validate验证一下配置再systemctl restart docker。Docker Desktop里也一样JSON编辑框下方如果有红色报错先别急着Apply。第三删除重建网络是“隐性高危操作”。很多人以为docker network rm很安全但如果你网络里还连着容器命令会直接报错如果你先强删了网络即使容器还开着它们的网络接口也会变成瘫痪状态。所以删除之前一定用docker ps -a --filter network网络名确认没有关联容器。第四容器DNS也是网络冲突的受害重灾区。当bridge网段和宿主机局域网段重叠时容器内的DNS解析会变得极其缓慢因为DNS请求包在路由层面就被绕晕了。如果修复网段之前必须临时应急可以在启动容器时指定--dns 8.8.8.8或者改成内网DNS地址来跳过系统默认解析链。我在实际排障中最大的体会是Docker网络冲突这个事儿九成以上都源于IP地址规划时没有给Docker留白。网上很多教程教你各种花式排查命令但如果从一开始就把Docker的网段锁死在和业务网段隔离的区域里后面能省下大把时间。哪怕现在你已经踩了坑也没关系照着上面的方案先摸清现状、抓包确认、改daemon.json重建网络基本都能稳住。最后再分享一个小习惯每次新装Docker环境我都会顺手把docker network ls和ip route这两条命令的输出存一份快照到运维文档里等以后出问题时拿来一对比冲突点立刻现形。这个习惯建议你也保留。
Docker网络冲突排查指南：从网段重叠到路由异常的完整方案
接触Docker时间长了几乎每个人都会撞上网络相关的坑。而Docker网络冲突恰恰是最让人头疼的一类问题——它不像容器崩溃那样有明确报错往往表现为各种“怪现状”容器能启动但业务访问不了、两个容器之间时通时断、创建网络时提示IP地址已被占用、甚至宿主机自己的业务系统也莫名其妙跟着断网。我自己维护过几十台Docker主机的环境这类问题几乎每个月都能碰上一次。这篇文章就把我踩过的坑和沉淀下来的排查思路完整整理出来从底层原理讲到具体命令最后附上速查表和避坑清单希望能帮你在下一次“网络诡异故障”出现时少走弯路。1. 先从Docker的网络模型说起搞懂冲突的根源1.1 为什么Docker会“抢”网段要理解网络冲突首先得明白Docker默认是怎么分配IP的。Docker安装完成后会自动创建一个名为docker0的虚拟网桥这个网桥默认使用172.17.0.0/16这个私有网段宿主机自己占172.17.0.1后续创建的容器依次拿到172.17.0.2、172.17.0.3……如果你继续用docker network create创建新的bridge网络且不手动指定网段Docker会从系统预留的地址池里继续挑选下一个可用网段常见的有172.18.0.0/16、172.19.0.0/16一直递增到172.31.0.0/16。问题就出在这里这些网段恰好也是局域网、办公网、路由器后台、虚拟机NAT网络最喜欢用的私网段。比如很多单位的内网规划就是172.16.0.0/12整段或者某个办公系统恰好使用了172.17.x.x段一些家用路由器默认是192.168.1.0/24但也有人手动改成172.16.x.xVMware、VirtualBox的NAT模式也经常落在192.168.x.x或172.16.x.x上。Docker启动时并不知道你内网用了哪些网段它只会按自己的顺序往下分配。一旦撞上结果就是容器、宿主机、局域网设备之间路由表互相打架。1.2 冲突的常见类型不只是IP重复这么简单很多人一提“网络冲突”就以为是两个容器IP重复其实没那么单纯。我总结下来常见的有四类。第一类是网段重叠冲突也就是上面说的Docker桥接网段和现有网络网段重叠。第二类是端口映射冲突宿主机上某个端口已经被别的进程占用你再拿-p 8080:80启动容器就会启动失败这类问题其实比网段冲突更常见。第三类是路由表冲突Docker会在宿主机路由表里写入自己网段的路由如果这个路由恰好覆盖了你的业务路由后果就是数据包明明要去某个内网地址却绕进了docker0网桥直接走丢。第四类是网络命名空间污染比如容器残留的虚拟网卡、iptables规则没清理干净导致新建的网络行为异常。理解了冲突的根源后面的排查和解决才有方向。说实话大部分网络冲突都不是什么高深的网络问题而是IP地址规划没做好。2. 网络冲突的典型症状你遇到的到底是什么问题网络冲突的症状五花八门但如果仔细归纳其实都能归到几个典型模式里。你可以对照下面的表现来判断自己到底属于哪一类。2.1 症状一容器起来了但外部怎么也访问不到这是最常见的现象。你明明执行了docker run -d -p 8080:80 nginx容器状态是Upcurl http://localhost:8080也通了但局域网里其他同事的电脑就是访问不到你的服务。如果你确认宿主机防火墙没拦那问题大概率就出在网段上——比如宿主机自身IP是192.168.1.100/24但Docker bridge网络被分配成了192.168.1.128/25一段两者重叠之后Linux路由表里会同时出现两个指向不同接口的192.168.1.0/24路由回包路径就紊乱了数据包不知道应该走物理网卡还是走docker0网桥表现就是“宿主机自己通、别人不通”或者“时通时断”。2.2 症状二创建网络时报地址占用错误当你执行docker network create时如果系统直接报错Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network这就是非常明确的网段冲突信号。Docker想说默认那些网段我一个个试过去发现都被现有网络或系统路由占用了我实在找不到一个干净的网段了。出现这种报错通常说明宿主机上已经创建了大量bridge网络或者物理网卡/虚拟网卡占用了大段私网地址把Docker默认的地址池挤满了。2.3 症状三容器之间互相ping不通或者A能连B但B连不上C如果是同一个bridge网络内的两个容器互相不通可能是网桥本身的问题但如果你创建了多个自定义网络然后把容器分别放进了不同网络里那它们之间本来就不通这是Docker的隔离机制不算故障。真正的故障场景是两个容器都在同一个my-net网络里网络模式下应该互通但实际ping不通或TCP连不上。这时候要检查网段是否和宿主机路由冲突因为如果Docker网络的网关IP和某个真实物理接口的IP相同数据包在宿主机的路由决策阶段就已经被劫走了。2.4 症状四宿主机自己的业务系统跟着遭殃这个更隐蔽。有一次我在一台跑着ERP中间件的服务器上装了Docker结果没过多久公司核心系统的调用开始异常排查下来发现是Docker把172.16.0.0/12网段里的一个子段抢走了而ERP系统恰好就是通过172.16.x.x访问数据库的。这类问题最难定位因为故障现象完全不在Docker容器本身而是宿主机的其他业务先挂了。网络冲突的影响范围从来不只是容器它会把宿主机整个路由搅乱。3. 排查流程像侦探一样定位冲突点排查网络冲突最重要的不是急着改配置而是先把现场情况摸清楚。我有一套固定的排查流程按顺序执行基本不会漏。3.1 先看现状三个必敲的命令第一个命令是docker network ls列出当前所有网络。这一步能确认你手头有多少个bridge网络网络名是什么。docker network ls第二个命令是docker network inspect 网络名。比如我们经常看到一堆xxx_default这样的网络这是docker compose自动创建的。你需要重点看这个网络的Subnet和Gateway字段docker network inspect myapp_default | grep -A 5 Subnet输出类似这样IPAM: { Config: [ { Subnet: 172.18.0.0/16, Gateway: 172.18.0.1 } ] }第三步是看宿主机路由表这在网段重叠时是决定性的证据ip route show table main如果看到类似这样的输出就要警惕了172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 172.18.0.0/16 dev br-abc123 proto kernel scope link src 172.18.0.1 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100注意最后一行和上面两行的关系——如果Docker网段恰好是192.168.1.0/24那路由表里就会出现两条指向同一个网段但不同网卡的路由这就是冲突的直接证据。3.2 看防火墙和NAT规则iptables也是重灾区Docker会往iptables里写大量规则包括NAT规则、FORWARD规则等。如果网络冲突有时候是因为规则顺序错乱或者新旧规则残留互相覆盖。查看NAT表iptables -L -t nat -n -v重点看POSTROUTING链里有没有MASQUERADE规则以及DOCKER相关链的地址范围是否正确。如果你的宿主机开了很多Docker网络这里会有一串DOCKER链每个链对应一个网络。如果你发现某个链里的IP范围和你物理网卡网段重叠基本就能定位问题网络了。3.3 用tcpdump抓包验证让数据说话前面几个命令都是静态查看配置但真正要确定数据包“卡”在哪里还是得抓包。比如容器A能ping通网关但访问容器B的8080端口不通你可以在宿主机上执行tcpdump -i docker0 host 172.18.0.2 and port 8080然后在容器A里发起请求观察有没有包到达docker0。如果容器A的请求从来没出现在docker0上说明请求根本没从容器A出来或者被路由到了别的地方如果请求到了docker0但没有回包说明容器B的响应没走对路。抓包能帮你把问题从“现象”转化为“证据”尤其适合排查那种“时通时断”的怪问题。3.4 分清楚你是在宿主机上还是在容器里排查如果你用的是Linux原生Docker直接在宿主机上执行这些命令没问题。但如果用的是Docker DesktopWindows/macOS情况就完全不同了——Docker实际上是跑在WSL2虚拟机里的你在PowerShell里执行ipconfig看到的网卡列表和容器里看到的网络是完全不同的两层。排查Docker Desktop的网络问题你需要进入WSL2发行版或Docker Desktop的虚拟环境里再执行ip route和iptables这也是很多人拿着网上的Linux排查教程去套Docker Desktop却怎么都找不到对应网卡的原因。4. 解决方案从临时到根治的完整路径定位到冲突原因之后接下来的思路就清晰了要么给Docker换一个不冲突的网段要么让现有业务给Docker腾位置。下面从轻到重给出几套方案你可以按实际情况选择。4.1 临时解法删除重建网络并指定新网段如果冲突的是用docker network create创建的自定义网络最简单的做法是删除后重建这次务必指定一个不会冲突的subnet# 先暂停使用该网络的容器 docker stop $(docker ps -q --filter networkmy-net) # 删除网络 docker network rm my-net # 重建为10.x段避免与内网重叠 docker network create \ --driver bridge \ --subnet10.88.0.0/24 \ --gateway10.88.0.254 \ my-net这里我习惯用10.88.0.0/24因为10.x段通常在企业内网留白比较多比172段和192.168段安全不少。当然前提是你已经确认整个内网都没用到这段地址。重建网络后重新启动容器让它们加入即可。注意docker network rm要求网络里没有容器连接所以必须先停掉容器或者用docker network disconnect先断开。4.2 根治手段修改daemon.json默认地址池如果你的Docker环境下网段冲突是长期问题或者你希望以后创建网络时Docker能自动避开冲突区段那就得改Docker daemon配置。在Linux服务器上编辑/etc/docker/daemon.json加上default-address-pools字段{ default-address-pools: [ {base: 10.90.0.0/16, size: 24} ] }保存后重启Docker服务systemctl restart docker这段配置的意思是说以后Docker在创建新bridge网络时不再去172.18、172.19这些默认网段里挑而是从10.90.0.0/16网段里按“每24位掩码一个子网”的方式分配也就是自动分配10.90.0.0/24、10.90.1.0/24……这样就从根源上避开了最常见的内网冲突区段。如果你用的是Docker Desktop界面里也能改打开Settings - Docker Engine在JSON配置里写入同样的字段然后点击Apply Restart。注意这个配置只对新建的网络生效已经存在的旧网络不会自动迁移需要删除重建。4.3 关键细节改了地址池docker0也要一起改很多人改了default-address-pools但发现docker0这个默认网桥还是顽固地使用172.17.0.1这是因为docker0的地址由另一个参数bip控制。如果docker0本身也和你内网冲突就得在同一个配置文件里再加一行{ bip: 10.90.255.1/24, default-address-pools: [ {base: 10.90.0.0/16, size: 24} ] }这里我把docker0固定成10.90.255.1/24跟自动分配的容器网段隔开来避免以后扩容时打架。改完重启Docker执行ip addr show docker0确认生效。需要注意的是改bip会重建Docker网络栈所有旧容器即使还在它们的网络连接也会被断开重建所以最好在维护窗口执行。4.4 固定IP方案当你的业务必须要稳定IP时有些场景下容器每次重启IP都在变会让你很头疼尤其是下游系统配置了IP白名单的情况。这时可以给容器手动指定固定IP。先在创建网络时指定好子网和IP范围docker network create \ --driver bridge \ --subnet10.91.0.0/24 \ --ip-range10.91.0.128/25 \ fixed-net然后启动容器时指定固定的--ipdocker run -d \ --network fixed-net \ --ip 10.91.0.130 \ --name myapp \ nginx:alpine这里--ip-range限定了DHCP动态分配的区间把你手动固定的IP单独留在另外一段避免Docker自动分配时不小心把同一个IP给了别的容器。固定IP方案有个容易踩的坑如果两个容器手动指定了同一个IP第二启动的容器不会报错但它的网络会异常表现为“能ping通网关但访问不了服务”。所以最好拿个表格记录每个容器的固定IP。4.5 处理端口映射冲突宿主端口被占用了如果你遇到的是docker run时提示port is already allocated那就是典型的端口占用冲突。处理思路很简单先查一下谁占用了端口ss -lntp | grep 8080然后把宿主端口换掉或者停掉占用端口的进程。比较取巧的做法是让Docker自动分配宿主端口只指定容器端口docker run -d -p 80 nginx # 宿主机随机分配一个高位端口映射到容器80然后用docker port 容器名查一下映射到了哪个端口。不过自动分配端口对客户端访问不太友好生产环境还是建议把端口规划写到配置清单里。5. 不同场景下的冲突实录与应对理论和命令都讲完了下面分享几个我实际处理过的场景这样你对照起来更直观。5.1 办公网172网段冲突最经典也最坑某次在客户现场部署一套业务系统服务器是CentOS 7分配的内网IP是172.16.10.5/24客户其他系统都在172.16.0.0/12大网段内互联。装完Docker后默认docker0占了172.17.0.1。起初业务一切正常但当他们在服务器上启动好几个compose项目后突然发现几个跟外部系统对接的服务开始超时。我上服务器一看路由表两个bridge网络分别占了172.18.0.0/16和172.19.0.0/16跟172.16.0.0/12属于同一个大段部分交换机路由开始有歧义。这种问题的危害是间歇性的特别难抓。最终处理是把所有compose项目的网络网段全部改为10.x段同时把daemon.json里的default-address-pools改成10段。这里的教训是只要办公网、机房用了172段Docker就必须全部迁走不要心存侥幸。5.2 家用宽带的192.168网段冲突家用场景一般没这么复杂但也挺常见。家里路由器通常用192.168.1.1或192.168.0.1如果你在NAS或老电脑上装了Docker跑几个容器后发现局域网内的其他设备访问NAS不太稳定或者容器里访问家里其他设备访问不到那十有八九是Docker bridge网络被分配到了192.168.x.x里。比如Docker自动创建了一个192.168.1.0/24的bridge网络网关是192.168.1.1——这跟你家路由器网关一模一样路由表直接乱套。家用环境最简单的解法就是复制上文方案在daemon.json里把bip和default-address-pools都改成一个家里肯定不会用的网段比如10.0.88.0/16重启Docker后一切恢复。5.3 云服务器VPC网段冲突云上更要注意云服务器的VPC网段各家不一但很多默认也集中在172.16.0.0/12到192.168.0.0/16之间。如果你在云主机上装Docker而且VPC的子网恰好划到了172.17.0.0/16这种情况我遇到过好几次那Docker一启动docker0就和VPC内网重叠了后果是这台云主机和其他同VPC主机之间的通信断断续续甚至在控制台远程连接都会受影响。云上环境改配置要更小心因为Docker重启可能会影响SSH连接建议使用云控制台的VNC终端操作避免中途失联。改完配置后记得在安全组里确认一下端口策略因为Docker默认的NAT规则可能绕过或干扰已有的安全策略。5.4 跨主机容器通信overlay网络的隐性冲突还有一种场景是跨主机容器通信时出的问题尤其在使用Swarm或K8s时overlay网络会用到VXLAN技术默认使用UDP 4789端口。如果宿主机之间的防火墙、云安全组没放行这个端口容器之间虽然能加入同一个overlay网络但跨主机的流量直接就断了表现就是“同宿主机容器能通、跨主机不通”。这个问题和IP网段重叠无关属于网络层面的“隐性冲突”。排查时可以抓UDP 4789的包确认是不是被拦了。在云上创建Swarm集群时安全组除了放行管理端口还要把VXLAN端口一并放行否则后面折腾半天都不知道是防火墙在捣乱。6. 常见问题与排查技巧速查表为了让你快速对照我把最常见的网络冲突问题整理成一张表。这里的每一项都是我在实操中验证过的有效路径。症状排查方向处理思路容器能起但外部访问不到查看宿主机route表和bridge subnet换不冲突网段重建网络检查防火墙转发创建网络报“non-overlapping IPv4 address pool”检查docker network ls和已有subnet删除无用网络修改default-address-pools两个同网段容器互ping不通inspect网络确认都在同一网络内检查网关IP是否和物理网卡重叠重启容器容器内无法访问宿主机局域网服务检查容器网段是否被路由到别处改bridge网段避开局域网段用--add-host临时指路端口映射提示“already allocated”ss -lntp查看占用端口进程换端口或停进程用-p 自动端口临时规避改daemon.json后Docker启动失败检查JSON语法journalctl -u docker看日志修复JSON格式错误先用dockerd --validate校验Docker Desktop容器访问宿主机服务失败确认服务监听地址是否含容器网关IP把服务监听0.0.0.0或用host.docker.internal再说几个不在表里但值得记下来的避坑技巧。第一网络规划永远是第一位的。任何一台要装Docker的服务器我先确认它所在的内网网段、办公网网段、云VPC网段然后直接给Docker预留一个完全不相交的大段比如10.233.0.0/16。这套做法帮我挡住了90%的后续问题。你可以把规划写进部署文档里团队其他人来维护时也清楚。第二改daemon.json前一定先备份。我已经见过不止一次因为少写一个逗号导致整个Docker服务起不来的事故。稳妥的做法是改完先执行dockerd --validate验证一下配置再systemctl restart docker。Docker Desktop里也一样JSON编辑框下方如果有红色报错先别急着Apply。第三删除重建网络是“隐性高危操作”。很多人以为docker network rm很安全但如果你网络里还连着容器命令会直接报错如果你先强删了网络即使容器还开着它们的网络接口也会变成瘫痪状态。所以删除之前一定用docker ps -a --filter network网络名确认没有关联容器。第四容器DNS也是网络冲突的受害重灾区。当bridge网段和宿主机局域网段重叠时容器内的DNS解析会变得极其缓慢因为DNS请求包在路由层面就被绕晕了。如果修复网段之前必须临时应急可以在启动容器时指定--dns 8.8.8.8或者改成内网DNS地址来跳过系统默认解析链。我在实际排障中最大的体会是Docker网络冲突这个事儿九成以上都源于IP地址规划时没有给Docker留白。网上很多教程教你各种花式排查命令但如果从一开始就把Docker的网段锁死在和业务网段隔离的区域里后面能省下大把时间。哪怕现在你已经踩了坑也没关系照着上面的方案先摸清现状、抓包确认、改daemon.json重建网络基本都能稳住。最后再分享一个小习惯每次新装Docker环境我都会顺手把docker network ls和ip route这两条命令的输出存一份快照到运维文档里等以后出问题时拿来一对比冲突点立刻现形。这个习惯建议你也保留。
