Cannot connect to the Docker daemon 怎么解决？守护进程连不上的 5 种原因

现象：任何 docker 命令都被拒

Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
Is the docker daemon running?

一行结论：docker CLI 客户端活着，但它要对话的 dockerd 守护进程不在。客户端通过一个 Unix socket（或 TCP/SSH）找 daemon，找不到就报这个错。注意它和 permission denied 的区别——那是「socket 在但你不许碰」，本篇是「socket 压根不存在或后面没人」。

五种原因，按概率排序

1. 守护进程没启动（Linux 服务器最常见）

systemctl status docker
# ● docker.service - Docker Application Container Engine
#   Active: inactive (dead)   ← 没跑

sudo systemctl start docker
sudo systemctl enable docker   # 顺手设开机自启

重启后忘了 enable、升级后服务挂了、OOM 把 daemon 杀了都会落到这里。先看状态再谈别的。

2. Docker Desktop 没开（macOS / Windows）

Docker Desktop 的 daemon 跑在虚拟机里，CLI 是独立的——App 没启动，CLI 照样存在，报错也一模一样。打开 Docker Desktop 等鲸鱼图标稳定即可。

3. WSL2：发行版集成被关了

Windows 上在 WSL2 里用 docker，需要 Docker Desktop 开启对当前发行版的集成（Settings → Resources → WSL Integration）。升级 Docker Desktop 后集成开关被重置是高频场景：

# 重启 WSL 后再试
wsl --shutdown

4. daemon.json 写错，daemon 起不来

/etc/docker/daemon.json 有语法错误或非法字段时，systemctl start docker 表面成功实际失败。看真实原因：

journalctl -u docker --since "10 minutes ago" | tail -20
# 常见输出：unable to configure the Docker daemon with file ...: invalid character

改回合法 JSON（注意最后一个键后面不能有逗号），再 restart。这也是配置镜像加速器、日志轮转时最容易踩的坑。

5. docker context 指错了 / rootless 环境变量没设

docker context ls
# NAME       DESCRIPTION                          DOCKER ENDPOINT
# default *  Docker Engine at unix:///var/run/...   ← 星号是当前 context

如果星号落在 remote 或某个失效的 context 上，本地 daemon 再健康也连不上：docker context use default 切回来。

rootless 模式下 socket 在用户目录里（/run/user/<uid>/docker.sock），SSH 新开会话忘了 export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock 就会连到不存在的系统 socket。

诊断路线（两分钟走完）

# 1. 服务状态
systemctl status docker

# 2. 状态不对，看日志找死因
journalctl -u docker -n 30

# 3. 服务正常但仍报错，检查 socket 与 context
ls -l /var/run/docker.sock
docker context ls

# 4. 都正常？直接问 daemon
sudo curl -s --unix-socket /var/run/docker.sock http://localhost/version | head -c 200

第 4 步能拿到 JSON 说明 daemon 活着——报错出在你的用户权限上，去看另一篇：Docker permission denied 排查。

和相近错误的分界线

Rootless 与桌面版：新的启动路径

Docker Desktop（Mac/Windows）：守护进程跑在工具虚机里——「连不上」意味着虚机/应用没启动（启动应用；光开 CLI 不行），升级后 CLI context 可能指错端点（docker context ls 看一眼）。Linux 的 Rootless Docker：守护进程以 systemd 用户单元跑（loginctl enable-linger 让它活过登出——共享机上「昨天还好今天 daemon 死了」多是缺 linger）。第一步永远是搞清你机器跑的是哪种 daemon 模型。

socket 本身：三种状态

/var/run/docker.sock 是 CLI 到守护进程的契约：缺失（刚开机服务没起，或 snap 装的是自己的路径）、权限拒绝（用户不在 docker 组——组成员下次登录才生效：newgrp docker 或重登；chmod 666 的「临时方案」等于全员 root，不该活过当天）、崩溃后残留的 socket 文件（删掉再重启）。ls -l 看 socket 加 ss -lx 过滤 docker，十秒判完三态。

systemd 与重启纪律

现代 Linux：dockerd 是 systemd 服务（containerd 是它的依赖——containerd 死带着 docker 死：先查 systemctl status containerd）。重启纪律：systemctl restart docker 对 daemon 安全但默认杀死运行中的容器（daemon.json 开 live-restore 让容器活过 daemon 重启——blip 和 outage 的区别）；重启循环通常是 daemon.json 配置错（journalctl -u docker -n 50 的头几行就是解析错误）。防整类问题的习惯：daemon 重启后跑一遍 docker ps 对照预期列表。

排查清单

1. systemctl status docker — 服务 active 吗？
2. macOS/Windows — Docker Desktop 应用开了吗？WSL 集成开了吗？
3. journalctl -u docker -n 30 — daemon.json 是否有语法错误？
4. docker context ls — 星号在 default 上吗？
5. rootless — DOCKER_HOST 环境变量设了吗？

排查注记

五种原因按概率排序：Linux 上「服务没启动」排第一，因为重启后忘 enable、升级挂掉、OOM 杀进程都会落到这一类；Docker Desktop 排第二，是因为它的 CLI 独立存在、daemon 跑在虚拟机里，App 没开报错却一模一样。诊断路线第 4 步用 curl 直问 daemon 是刻意设的分叉点——能拿到 JSON 说明 daemon 活着、问题在用户权限，那是 permission denied 篇的领地；本篇和它的分界就一句话：socket 压根不存在，还是 socket 在但你不许碰。

这篇实战笔记来自 ToolVault 工具匣。相关工具：Dockerfile 生成器、docker run 转 compose、Linux 命令速查。相关阅读：Docker 权限问题排查、端口被占用 EADDRINUSE。访问 首页 查看更多开发者工具。