核心三点：检查/var/run/docker.sock是否存在、是否被dockerd监听、当前用户是否有读写权限；文件存在≠守护进程在监听，systemctl显示running可能是假活。
核心就三点：socket 文件是否存在、是否被 dockerd 监听、当前用户有没有权限访问它。不是看 systemctl status docker 显示 running 就万事大吉，很多“假活”状态下 socket 根本不通。
确认 /var/run/docker.sock 是否存在且路径正确
客户端默认只认这个路径，不存在就直接报错“cannot connect”。运行：
-
ls -l /var/run/docker.sock—— 若提示“No such file or directory”，说明守护进程压根没成功启动或 socket 激活失败 - 注意：
/var/run通常是/run的软链接，检查ls -ld /var/run确保指向有效目录（如/run） - 若 socket 出现在别的位置（比如
/run/docker.sock），而 CLI 还是去连/var/run/docker.sock，就得改配置或加软链接，不能硬等它自己迁移
验证 dockerd 是否真正在监听该 socket
文件存在 ≠ 有进程在用它。得确认 dockerd 进程已绑定并开始接受连接：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
-
sudo lsof -U | grep docker.sock—— 应看到类似dockerd 1234 root 7u unix 0xffff888123456789 0t0 /var/run/docker.sock的输出 - 没输出？说明 dockerd 没监听，哪怕
systemctl status显示 active，也可能是卡在初始化或崩溃后残留了进程状态 - 可进一步用
sudo timeout 2 socat - /var/run/docker.sock << EOF\nGET /version HTTP/1.0\n\nEOF直连测试；无响应或超时 = socket 不通
检查当前用户对 socket 文件的读写权限
socket 是 Unix 域套接字，权限控制严格，普通用户默认无权访问：
- 看
ls -l /var/run/docker.sock输出中的属组和权限：理想是srw-rw---- 1 root docker - 如果属组是
root或权限是600，普通用户必然被拒，此时命令会静默失败或报连接拒绝 - 解决方法：执行
sudo usermod -aG docker $USER加入 docker 组，然后完全退出终端并重新登录（newgrp docker只临时生效，部分 CLI 行为仍不认） - 验证：运行
groups看输出是否含docker，再试docker info 2>/dev/null && echo OK
留意 daemon.json 配置导致 socket 被绕过或禁用
错误的配置会让 dockerd 放弃监听默认 socket，转而尝试其他通信方式（比如 TCP），结果本地 CLI 却还在找 /var/run/docker.sock：
- 检查
/etc/docker/daemon.json是否含有"hosts": ["tcp://0.0.0.0:2375"]或"hosts": []（空数组会禁用所有 host） - 若存在非 unix host 配置，CLI 默认找不到匹配的 endpoint，就会报 socket 连接失败
- 临时重命名该文件（如
sudo mv /etc/docker/daemon.json /etc/docker/daemon.json.bak），再sudo systemctl restart docker测试是否恢复
