排查容器网络问题时，那种明明服务启动了却死活访问不了的滋味，真是让人抓狂。我就遇到过不少次这样的情况：容器内部测试一切正常，端口映射也做了，但外部请求就像掉进了黑洞一样没反应。这时候一定要冷静下来，从最基础的检查开始，一步步缩小问题范围。
从最底层开始排查
首先要确认端口是否真的在监听，我喜欢用ss -tulnp命令查看端口状态，比netstat更直观。遇到过不少案例都是因为容器内部服务根本没监听对应端口，或者监听的是127.0.0.1这种本地地址。值得注意的是，有些应用服务的配置文件（比如Nginx）默认就是监听localhost，这在容器环境下必须改成0.0.0.0。
很多人容易把容器网络想象得太简单，其实它和虚拟机网络有着本质区别。Docker默认的bridge网络会创建自己的虚拟网桥和iptables规则链，如果突然发现容器之间无法通信，很可能就是它们的网络不在同一个子网。这时docker network inspect命令就派上用场了，它能显示出哪些容器连接到哪个网络。
容易被忽视的防火墙问题
云服务商的防火墙规则总是能给我”惊喜”——有一次在Azure上部署服务，折腾了半天才发现它们默认拦截了所有入站流量。现在我都养成了习惯，部署完第一件事就是检查安全组规则。不过有意思的是，有些云平台的运维界面会把Docker自动添加的规则隐藏起来，需要通过API才能看到完整列表。
本地防火墙也经常是个坑，特别是CentOS默认的firewalld。我之前有次debug了两个小时，最后发现只是因为firewalld没有添加docker0接口到trusted区域。现在我会先用systemctl status firewalld确认防火墙状态，再iptables -L -n -v仔细检查规则。
docker logs里的秘密
很多人排查网络问题都不看容器日志，这太可惜了。其实有时根本就不是网络问题，而是服务启动时遇到了配置错误。我就碰到过一个经典的坑：应用日志显示”监听8080端口失败”，表面看是端口冲突，实际原因是容器内没有权限绑定1024以下端口。这种情况给容器加上--cap-add=NET_BIND_SERVICE权限就好了。
当你觉得自己已经把该检查的都检查过了，网络还是不work，不妨试试docker exec -it 容器名 sh进入容器内部，用curl测试连通性。这一步经常能发现惊喜，比如发现容器内DNS解析异常，或者路由表配置错误。记住，眼见为实，亲手测试才能发现真正的症结所在。
说到底，容器网络问题排查就像破案，需要耐心和有条理的思维方式。你是不是也曾被某个诡异的网络问题困扰很久？欢迎在评论区分享你的故事和解决方法，这些实战经验对谁来说都特别宝贵。
评论