容器排错不能只盯着容器内部，必须把宿主机和容器看作一个联动系统。很多问题表面在容器里，根子在宿主机配置、内核机制或资源约束上。
先确认容器真实运行状态
别只信 docker ps 显示的“Up”状态。用以下命令交叉验证：
- docker ps -a 查看完整生命周期，注意 ExitCode（如 137=OOM，125= 命令执行失败）
- docker inspect 看 State.Pid 是否为正整数——为 0 表示进程根本没起来；再检查 NetworkSettings.IPAddress 和 Mounts 是否符合预期
- 若容器秒退，加 –rm 启动后立即查日志：docker logs –tail 50
分层定位网络不通问题
容器 ping 不通宿主机、宿主机 curl 不通容器端口，要按命名空间层级排查：
- 查容器是否真有 IP：docker inspect | grep -A 3 IPAddress；若为空，可能是 docker0 网桥异常，尝试 sudo systemctl restart docker
- 确认监听地址：进容器执行 netstat -tuln | grep : 端口 ，服务必须监听 0.0.0.0，不是 127.0.0.1
- 验证端口映射：docker port ，再在宿主机用 curl http://localhost: 映射端口 测试
- 若需跨命名空间调试，用 nsenter 进入容器网络栈：nsenter -t $(docker inspect -f ‘{{.State.Pid}}’ ) -n ip addr
权限与挂载类问题快速识别
报“Permission denied”或配置不生效，大概率是路径或用户权限错位：
- 宿主机目录被映射前若不存在，Docker 会以 root 创建，导致容器内非 root 用户无法写入——提前建好目录并 chown 到目标 UID
- 检查挂载是否生效：docker inspect | grep -A 10 Mounts，确认 Source 路径存在且可读，Destination 在容器内路径正确
- 时区不同步？进容器执行 date，再对比宿主机；修复方式：-v /etc/localtime:/etc/localtime:ro -e TZ=Asia/Shanghai
资源限制引发的隐性故障
CPU、内存、PID 数量等限制不会直接报错，但会让服务卡顿、崩溃或拒绝连接：
- 查 OOM 记录：dmesg -T | grep -i “killed process”，匹配容器名或 PID
- 看容器实际资源使用：docker stats ，观察 CPU% 和 MEM% 是否长期打满
- 检查 cgroup 限制：cat /sys/fs/cgroup/memory/docker//memory.limit_in_bytes（单位字节），确认是否远低于应用需求
- 若用 Kubernetes，用 kubectl describe pod
查 Events 和 Containers.Resources 部分
