客户端与守护进程挂起本质是本地通信链路中断或守护进程失活，需交叉验证进程真实状态、socket连通性、资源负载及用户权限，而非仅依赖systemctl显示的active状态。
客户端与守护进程挂起，通常表现为命令卡住、无响应、超时或反复提示“cannot connect to the docker daemon”。这不是网络延迟问题，而是本地通信链路中断或守护进程自身失活。排查要从“进程是否真在运行”开始，而不是只看服务状态。
确认守护进程真实运行状态
systemctl status docker 显示 active (running) 不代表 dockerd 正常工作——它可能假死、被 OOM 杀掉，或卡在某个 goroutine 中。必须交叉验证：
- 执行 sudo docker info：若超过 5 秒无输出，基本可判定守护进程无响应
- 检查日志末尾是否有 throttled、timeout waiting for daemon 或 OOM killed process 'dockerd' 等线索
- 用 ps aux | grep dockerd 确认进程 PID 是否存在；再用 kill -0
测试进程是否可接收信号（无报错=存活）
验证 Unix socket 连通性
/var/run/docker.sock 是默认通信通道，挂起常因套接字不可达或权限阻塞：
- 运行 ls -l /var/run/docker.sock：权限应为 srw-rw----，属组为 docker；若属主异常或权限为 600，CLI 将静默失败
- 用 sudo timeout 2 socat - /var/run/docker.sock 直连测试：无响应或超时，说明守护进程未监听该 socket
- 检查 sudo lsof -U | grep docker：确认 dockerd 是否确实在监听 /var/run/docker.sock
检查资源与配置干扰项
守护进程自身负载过高或配置冲突，会导致命令排队、响应停滞：
- 查看 CPU 和内存压力：top -p $(pgrep dockerd) 或 sudo docker stats --no-stream（注意：此命令本身依赖守护进程，若已挂起则跳过）
- 检查 /etc/docker/daemon.json 是否误配 "hosts": ["tcp://0.0.0.0:2375"]：启用 TCP 监听会绕过 Unix socket，且可能触发 TLS 握手或防火墙策略，反而引发连接挂起
- 临时禁用非核心功能，如将 daemon.json 中 "features": {"buildkit": false}，减少后台 goroutine 负载
排除用户权限与会话缓存影响
普通用户未正确加入 docker 组，或终端会话未刷新组信息，会导致每次 CLI 调用陷入权限协商循环，表现类似挂起：
- 运行 groups 确认输出含 docker；若无，执行 sudo usermod -aG docker $USER
- 必须完全退出当前终端并重新登录（newgrp docker 无法生效），否则组权限不加载
- 避免长期使用 sudo docker：它绕过 socket 权限校验，但掩盖真实权限问题，且在某些 SELinux 或 AppArmor 环境下反而更易挂起
