目录索引
阅读本文大约需要2分钟。
记一次wsl2网关与docker网段冲突导致主机网络异常
开开心心打开电脑，wsl2一跑，再拽两个cd命令，docker一跑，bug未到断网先到。
噢，又是美好而又值得纪念的一天。
排查过程与思路
导火索是docker容器内go包拉不下来，拉了一遍又一遍，逐渐开始怀疑人生。
怀疑人生系列一：go包代理可能是个内鬼
使用的go包代理是https://goproxy.cn/,所以怀疑可能是代理是个出现了问题，goproxy之前是有出现过不稳定的情况，然而实践验证后发现是自己想太多。
go包拉取报错Get "https://goproxy.cn/github.com/xxx/xxx/@v/v0.0.0-xxx.zip": dial tcp: lookup goproxy.cn,所以首先反应的是在容器内ping该网址以及其他常用网址，发现都是GG。容器内ping不通，自然想到跑来宿主机ping，一ping更是GG，报错ping: www.xxx.com: Temporary failure in name resolution。
怀疑人生系列二：wsl2可能罢工了
根据上个系列，怀疑是win宿主机的wsl2网卡或者dns解析出了问题，对着相关配置一番排查，发现并无异常，毕竟平时也很少动网卡配置。由于还使用netsh端口转发，排查过程略过不表，结论是无关。所以这个系列又完结了。
怀疑人生系列三：没有什么复杂的环境出问题，是重启一次解决不了的
根据人生经验，如果环境出了问题解决不了怎么办?那就重启一次。如果重启一次还是解决不了怎么办？那就重启两次。
因为wsl2先出的问题，只好对wsl2先下手。重启之后，果然不出所料，ping一下，立马起飞。
感觉人生都要起飞时，docker命令一跑，再到容器一ping，炸了。
退出容器一ping，wsl2也炸了。
不是说好的没有什么环境出问题是重启一次解决不了的吗？
怀疑人生系列四：谁动了我的奶酪
几经周折，怀疑人生终于快要完结。很明显，docker动了我的奶酪。
但是此时，又一个疑惑产生，真正的原因是因为我写的是docker-compose文件容器使用的network导致，还是docker服务的network导致的呢。
排查这个问题太难了，我选择启动docker服务ping一次，启动docker-compose容器再排查一次。事实是，我选择启动docker服务之后ping了一次，就抓到了这个罪魁祸首，就是docker服务。
使用route -n或者ifconfig就能发现网段是真的冲突了。
噢，空气都变香甜了。
放开那个网段
因为wsl2的ip如果没有设置为静态，默认是自动分配，所以今天wsl2和docker的网段终于遇上了。
在此之前，从未想到，原来这tm也能冲突。
解决思路一：指定dockr0网段ip
1、停止docker服务 service docker stop
2、删除docker0网卡 ip link del docker0 down
3、在docker配置文件vim /etc/docker/daemon.json指定自己想要的网段ip
{
"bip":"172.17.19.0/24"
}
解决思路二：重启大法
理论上来说，这次wsl2网段和docker0网段撞车是因为wsl2自动分配ip导致，那么只需要开机重启，wsl重新分配ip之后可能就不冲突了。重启win宿主机的次数越多，不冲突的概率就越大。
nice，既然已经有了扎实的理论基础，那我选择解决思路二。
手动滑稽:(
没有什么问题是重启一次解决不了的，如果有，那就重启两次。
哇噢，又是美好的一天，从重启电脑开始。
所属分类：
运维
文章标签：
#docker