必须先确认容器处于运行状态（docker ps 查看 Up 状态），再用 docker exec -it 容器名 /bin/sh 进入排查；若已退出需先 docker start，进入后依次执行 id、ps aux、ls -l、netstat、curl 和 ping 等命令验证权限、路径、网络及进程。
当你在统信UOS中运行的Docker容器出现服务无响应、进程异常退出或日志信息不足时，必须进入容器内部直接检查环境变量、进程树、网络配置和文件系统状态，才能准确定位问题根源。
确认目标容器处于运行状态
执行 docker ps 查看当前运行中的容器列表，确保目标容器状态为 Up 且不是 Exited；若已退出，docker exec 将直接报错“No such container”，此时需先用 docker start 启动它，或改用调试镜像启动临时容器。
检查容器是否健康：运行 docker inspect -f '{{.State.Status}} | {{.State.Health.Status}}' ，若 Health.Status 显示 unhealthy，说明健康检查已失败，需优先查看 docker logs 中的最后几行输出。
使用 docker exec 进入正在运行的容器
方法一：以交互式 shell 进入（推荐用于排查）
执行 docker exec -it /bin/sh。UOS默认镜像多基于 Debian/Alpine，/bin/sh 兼容性远高于 /bin/bash；若提示 command not found，说明该镜像未安装 bash，强行指定会失败。
方法二：指定用户身份进入（适用于权限受限场景）
若容器内应用以非 root 用户运行（如 www-data、appuser），而你需模拟其执行环境，加 -u 参数：docker exec -it -u www-data /bin/sh。不加此参数可能因权限差异导致某些文件不可读、进程不可见。
注意：容器必须已启用 TTY 分配（即启动时用了 -t 或 --tty），否则 -it 会报错“container does not support tty”。若原始 run 命令未带 -t，此方法不可用，只能改用 docker run --rm -it --volumes-from 挂载调试。
进入后立即执行的关键诊断命令
第一步：确认当前用户与进程权限
运行 id 和 ps aux，核对 UID/GID 是否与容器启动配置一致；若发现 UID 是 65534（nobody），但应用配置要求 UID 1001，则大概率因 user namespace 映射或 Dockerfile USER 指令冲突导致权限拒绝。
第二步：检查关键路径是否存在且可访问
执行 ls -l /app /config /data（按实际路径替换），特别留意挂载卷是否覆盖了原目录——这是导致“no such file or directory”退出码 127 的最常见原因。若 ls 返回空或 Permission denied，说明挂载失败或 SELinux/AppArmor 策略拦截。
第三步：验证网络连通性与端口监听
运行 netstat -tuln | grep :8080（替换为目标端口），确认服务进程确实在监听；再试 curl -I http://localhost:8080，若返回 000 或 Connection refused，说明进程未启动或绑定地址错误（如只绑 127.0.0.1 而非 0.0.0.0）。
第四步：查看容器内 DNS 与外部连通性
执行 cat /etc/resolv.conf 确认 nameserver 是否为 127.0.0.11（Docker 内置 DNS）；再试 ping -c 2 www.baidu.com，若不通，可能是容器网络模式为 host 但宿主机防火墙拦截，或 custom bridge 网络未配置网关路由。
