核心原因是守护进程未运行、权限不足或通信路径异常；需依次检查systemctl状态、/var/run/docker.sock存在性与权限、用户是否在docker组，并结合journalctl日志和daemon.json配置定位问题。
直接看核心原因：守护进程没运行、权限不对、通信路径断了，三类问题占了九成以上。不用一上来就重装，先按顺序快速验证。
检查守护进程是否真在运行
很多人以为“docker命令能输”就等于 daemon 在跑，其实 CLI 只是前台工具，后台服务可能根本没起来。
- 执行 sudo systemctl status docker，重点看有没有 active (running) 字样；如果显示 inactive (dead) 或压根报错“Unit docker.service not found”，说明服务没启动或没安装成功
- 若未运行，用 sudo systemctl start docker 启动，再立刻用 sudo systemctl is-active docker 确认返回 active
- 注意：某些系统（如部分 CentOS）用的是 service docker start，命令略有差异
确认 Unix Socket 文件存在且可访问
Docker 默认走 /var/run/docker.sock 这个本地套接字通信。它不是普通文件，而是进程监听的通信端点——文件存在 ≠ 守护进程在监听。
- 运行 ls -l /var/run/docker.sock，正常应看到类似 srw-rw---- 1 root docker 的输出；如果提示 “No such file or directory”，说明 daemon 没成功创建 socket，大概率是启动失败
- 用 sudo lsof -U | grep docker.sock 查看是否有进程正在监听该 socket；没输出 = daemon 没监听，即使服务状态显示 running，也可能卡在初始化阶段
- 如果 socket 权限是 root:root 且模式为 600，普通用户必然被拒，这不是 daemon 故障，而是权限配置问题
验证当前用户是否有访问权限
即使 daemon 正常运行、socket 存在，普通用户默认无权读写这个 root 所有的 socket 文件。
- 最常用解法：把当前用户加进 docker 用户组 —— 先确认组存在（getent group docker），再执行 sudo usermod -aG docker $USER
- 加组后必须刷新会话：运行 newgrp docker（临时切换），或直接注销重登录；不重启、不重登，组权限不会生效
- 验证权限是否到位：执行 docker info 2>/dev/null && echo "OK"；成功输出 OK 表示客户端已能通 daemon
留意配置文件和启动日志中的隐藏线索
daemon 启动失败时，往往不报错到终端，但日志里有明确提示。
- 查最近一次启动日志：sudo journalctl -u docker --since "1 hour ago" | tail -20，重点关注 ERROR 或 panic 开头的行
- 检查 /etc/docker/daemon.json 是否有语法错误或非法配置（比如拼错字段名、用了不支持的存储驱动、insecure-registries 写了不可达地址）；临时重命名该文件，再 sudo systemctl restart docker 测试是否恢复
- 如果改过 Docker 的 data-root 或 bip，要确认对应目录存在且权限正确、子网没和其他网络冲突
