C盘爆满不用慌：从系统文件到软件缓存的全方位清理指南
2026/10/9 10:35:54
群晖 NAS 上跑 Docker，最让人头疼的往往不是容器本身，而是第一步：拉镜像。要么速度极慢，一个几十 MB 的镜像能拉几分钟；要么直接卡在 Downloading 阶段，等半天后报 i/o timeout、EOF 或者 network connection refused。很多人第一反应是群晖出了问题，其实绝大多数情况下，问题出在镜像源上。群晖默认连的是 Docker Hub 官方源，网络链路不稳定、带宽不够、大镜像分片多，任何一个环节出问题都会让 pull 操作看起来像“卡死”。这篇文章就围绕“群晖 Docker 拉镜像慢还失败”这个场景，讲清楚镜像源是什么、怎么配置、配置完怎么验证、失败后怎么排查，以及大镜像和离线场景的替代方案。不管你是刚接触群晖 Docker 的新手，还是已经被镜像问题磨了一下午的运维老手，只要手上设备能正常安装 Container Manager 或 Docker 套件，这套流程都可以直接照着做。
这里要注意一个前提：群晖上的 Docker 环境，和电脑上装 Docker Desktop 是两套不同体系。虽然底层理念一致，但群晖基本是在 DSM 图形界面里操作，配置镜像源的位置、重启 Docker 的方式都不一样。下面按实际落地顺序拆一遍。
1. 拉镜像慢和失败，先别怪群晖，多数是镜像源的问题
1.1 典型现象和背后原因
我见过最多的情况有这几种：
- 打开 Container Manager 的“注册表”页面，搜索镜像时一直转圈，半天不出结果。
- 点下载后进度条不动，或者到了 90% 突然报错，提示
open /var/lib/docker/tmp/GetImageBlob或者received unexpected EOF。 - 明明换了更快的宽带，拉镜像速度还是上不去。
- 拉一个几 GB 的大镜像，经常在某个层卡住，重试后又要从头开始。
这些现象的共同原因，是默认数据源访问不稳定。Docker Hub 本身是一个全球服务，节点和带宽都在海外，国内网络环境直连的时候，连接质量、速度、稳定性都会波动。群晖预装的 Docker 或 Container Manager 默认没有配置任何加速器，pull 请求直接打到 Docker Hub，所以慢和失败也就成了常态。
这不是群晖硬件的问题，也不是 Docker 版本的问题，纯粹是网络路径问题。解决思路很简单：给 Docker 换一个能稳定访问的镜像源，让 pull 请求先经过这个源，再由它去 Docker Hub 获取镜像。这也是 Docker 官方支持的标准配置方式，属于常规运维操作。
1.2 镜像源能解决什么，不能解决什么
先搞清楚边界，否则容易白忙一场。
| 现象 | 直接原因 | 配置镜像源能解决吗 |
|---|---|---|
| pull 很慢，卡在 waiting | 默认源连接不稳定 | 大概率能解决 |
| 拉取到 50% 或 90% 报错 | 网络抖动、连接被重置 | 能缓解，关键看镜像源的稳定性 |
| 注册表搜不到任何镜像 | Docker Hub 搜索受限或源不支持 search API | 可能解决，也可能仍无法搜索 |
| CPU 架构不匹配 | 镜像不支持该 NAS 架构 | 不能解决，需要换镜像或换平台 |
| 群晖本地磁盘空间不足 | /var/lib/docker所在分区满了 | 不能解决，要清理空间 |
所以，配置镜像源主要解决的是“网络访问”问题。如果镜像本身不存在、架构不匹配、磁盘空间不够，那换一百个源也没用。
2. 配置镜像源前，先确认三件事
不要一上来就去改配置。先把环境确认清楚，后面能省很多时间。
2.1 确认 DSM 版本和容器入口
群晖近几年在 DSM 7.2 之后，把原来的 Docker 套件换成了 Container Manager。名字变了，功能入口也变了：
- DSM 7.2 及以后版本，你看到的是Container Manager。
- DSM 7.2 之前，或者一直没有升级的版本，套件中心里还是Docker。
配置镜像源的操作路径不太一样，所以第一步先打开套件中心看一眼自己装的到底是什么。如果你打开的是 Container Manager，就按第 3 章的新版方式操作；如果还是旧的 Docker 套件，就按旧版方式操作。
2.2 确认 Docker 服务和磁盘状态
配置镜像源不会自动让 Docker 变快。前提是 Docker 本身已经正常运行。
在套件中心里确认：
- Container Manager 或 Docker 已安装。
- 状态不是“已停用”，而是“已启动”。
另外看一眼存储空间。群晖拉镜像，会占用系统盘或 Docker 数据目录所在分区的空间。如果剩余空间很小，拉大镜像时很容易在最后阶段报no space left on device。这个错误看起来也像“拉取失败”，但和镜像源无关。
2.3 准备镜像源地址并提前验证
镜像源地址是这次操作的核心。地址失效或不稳定，配置再多次都没用。
获取镜像源地址有两种思路：
- 使用云厂商提供的镜像加速器地址。以阿里云为例，登录容器镜像服务控制台，在“镜像加速器”页面能看到属于你自己账号的专属加速器地址，格式通常是
https://<你的ID>.mirror.aliyuncs.com。 - 使用还在维护的公共镜像源。这类地址变化很快，网上找到的旧地址很可能已经失效，使用前一定要自己验证。
无论用哪个地址，验证方式都一样：在浏览器里打开“镜像源地址 +/v2/”。例如你拿到了https://xxx.mirror.aliyuncs.com，就访问https://xxx.mirror.aliyuncs.com/v2/。
如果返回一个 JSON，哪怕内容是{}，说明地址本身是可以访问的。如果页面打不开、提示超时、返回 404 或 5xx，这个地址基本不能用。
我一般会多准备两到三个地址，这样后面配置多源时可以直接用。但不要拿到一个源就复制一堆不验证的旧地址，那样只会增加排查成本。
可以用下面这个表快速确认环境：
| 检查项 | 怎么看 | 通过标准 |
|---|---|---|
| 容器管理套件名称 | 套件中心首页 | 看到 Container Manager 或 Docker |
| 服务是否运行 | 套件状态 | 已启动 |
| 磁盘剩余空间 | 存储管理器 | 至少有几 GB 可用 |
| 镜像源地址可用性 | 浏览器访问地址/v2/ | 返回 JSON 或 HTTP 200 |
3. 图形界面配置：Container Manager 和旧版 Docker 套件
群晖上最稳妥的配置方式，是在图形界面里操作。不需要开 SSH，不需要敲命令，跟着界面点几轮就能完成。
3.1 Container Manager 配置镜像源
如果你使用的是 DSM 7.2 之后的 Container Manager，按下面步骤走：
- 打开 Container Manager，进入左侧的“注册表”页面。
- 点击右上角的“设置”按钮。
- 在弹出的设置窗口中，找到“镜像源”区域。
- 点击“新增”，输入准备好的镜像源地址。
- 保存后，选择该地址，点击“连接”测试。
- 如果提示连接成功，说明地址能正常访问。
这里要注意：Container Manager 的“连接”测试只代表该地址能访问，不代表它的搜索功能一定可用。也就是说，配置完之后，你仍然可能在“注册表”里搜索不到某些镜像。这不一定是配置问题，具体原因在排错章节会展开说。
3.2 旧版 Docker 套件配置镜像源
如果你还在用老版本的 Docker 套件，操作路径差不多：
- 打开 Docker 套件，点击左侧“注册表”。
- 点击注册表页面右上角的“设置”。
- 在“注册表镜像源”区域，点击“新增”。
- 输入镜像源地址，点击“确定”。
保存后同样会有连接测试。这个动作本质上和 Container Manager 一致，都是把镜像源写进 Docker 的 registry-mirrors 配置里。
3.3 配置后第一时间拉小镜像验证
配置完源，不要着急去拉一个 10GB 的大型镜像。先在“映像”页面点击“拉取”，输入一个轻量的测试镜像，例如hello-world或者nginx:alpine，先验证整条链路通不通。
成功的话，你会看到下载进度条正常走动，最终在“映像”列表里出现hello-world:latest或nginx:alpine。
选择小镜像验证有几个原因：
- 拉取时间短，几秒到几十秒就能判断通不通。
- 如果镜像源有问题，小镜像同样会失败，但排查成本低。
- 大镜像拉取一次时间很长，如果源配置有问题，浪费的时间和流量都更多。
有个容易忽略的点：某些镜像源的搜索 API 不可用，但在“注册表”里搜索不到镜像，不代表不能拉取。你可以在“拉取”页面直接填docker.io/library/nginx:alpine这样的完整路径，让 Docker 绕开搜索步骤，直接走拉取流程。能够拉下来，说明镜像源是生效的。
建议：第一次配置后，先用
hello-world或nginx:alpine验证，能拉下来再处理真正要使用的镜像。不要一上来就并发拉好几个大镜像，避免多个任务同时卡住后不好定位问题。
4. 命令行方式：SSH 修改 daemon.json，适合多源和运维场景
图形界面配置方便，但也有局限。比如你想一次配置多个镜像源、想统一管理多台群晖、或者容器服务启动异常需要手动改配置，这时候命令行方式更直接。
4.1 为什么需要命令行方式
图形界面虽然好用，但在批量维护场景下效率不高。如果你有私钥和 SSH 习惯，通过修改/etc/docker/daemon.json或类似路径下的 Docker 守护进程配置文件，可以直接控制 registry-mirrors。这种方式的好处是：
- 可以一次性写入多个镜像源地址。
- 可以通过脚本自动备份和恢复配置。
- 当图形界面因为某些原因无法打开时，仍能通过命令行恢复 Docker 服务。
缺点是命令行改错容易导致 Docker 无法启动。所以命令行方式更适合有一定基础、能接受命令行操作的用户。
4.2 开启 SSH 并确认 daemon.json 路径
先开启群晖的 SSH 功能：
- 打开“控制面板”。
- 找到“终端机和 SNMP”。
- 勾选“启用 SSH 功能”。
- 端口保留默认，也可以自定义。
然后用终端工具连接群晖，使用管理员账号登录。登录后，先确认 Docker 配置文件的位置。
不同 DSM 版本下，daemon.json 的实际路径可能不同。常见的有：
/etc/docker/daemon.json/var/packages/Docker/etc/daemon.json/var/packages/ContainerManager/etc/daemon.json
先执行这条命令确认原文件是否存在：
sudo cat /etc/docker/daemon.json如果文件不存在，会提示No such file or directory，这说明之前没有手动改过配置。如果文件存在，可以看到已有的内容。修改前建议先把原文件备份一下：
sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak4.3 写入 registry-mirrors 并重启 Docker
使用sudo编辑文件，把镜像源写入registry-mirrors数组。
sudo vi /etc/docker/daemon.json内容示例：
{ "registry-mirrors": [ "https://<你的专属加速器地址>.mirror.aliyuncs.com", "https://<第二个镜像源地址>" ] }这里有两个建议：
- 地址一定要是
https://开头，避免 HTTP 明文请求被链路或中间环节干扰。 - 不要一次写太多源，两到三个足够。源太多的时候，Docker 在某个源超时后会切换到下一个，但如果每个源都不稳定，反而会拖慢整体拉取。
保存文件后，重启 Docker 服务。不同 DSM 版本命令稍有差异，可以先试这一条：
sudo synosystemctl restart docker如果synosystemctl不存在，说明你的 DSM 版本较老，换成：
sudo systemctl restart docker也可以回到套件中心，直接停用再启用 Container Manager 或 Docker 套件，效果一样。
4.4 用 docker info 验证配置生效
重启 Docker 后，不要直接去拉镜像，先看配置是否真正被 Docker 加载：
sudo docker info | grep -A 3 "Registry Mirrors"输出里如果能看到刚才配置的地址，说明 daemon.json 已经被正确读取。这时候再去拉镜像，压力会小很多。
4.5 daemon.json 写错导致 Docker 起不来怎么办
这是命令行方式最常见的风险。一旦 JSON 格式错误，Docker 服务可能启动失败，图形界面里的 Docker 套件也会显示未运行。
遇到这种情况，不要慌，按顺序处理：
- 用 SSH 登录群晖。
- 找到之前备份的
daemon.json.bak。 - 用备份文件恢复：
sudo cp /etc/docker/daemon.json.bak /etc/docker/daemon.json- 重启 Docker：
sudo synosystemctl restart docker如果没有备份，也可以直接新建一个空的daemon.json或删除这个文件，Docker 一般会使用默认配置启动。至少需要保证 JSON 语法完整，缺逗号、多括号、引号不闭合都会导致服务启动失败。
提醒：修改 daemon.json 前，一定要先备份原文件。这一步哪怕只花一分钟，也能避免后续花一小时重新配置环境。
5. 添加镜像源后仍然失败，按这个顺序排查
有时你会发现，明明已经添加了镜像源，连接测试也显示成功，但拉镜像还是失败。别急着继续换源，按下面的顺序一层层查。
5.1 地址失效：用 /v2/ 路径验证
先回到第 2 章的验证方法，在浏览器里打开“镜像源地址 +/v2/”。
如果提示超时、DNS 解析失败、返回 502 或 503，说明这个源当前不可用。这种情况经常发生在公共镜像源上，维护方停服、限流、域名过期都会导致地址失效。
解决方法：换一个新地址，或者回到云厂商控制台重新获取专属加速器地址。
5.2 搜索不到镜像，不代表不能拉取
很多加速器或者镜像源设计的时候只做了 pull 加速，没有实现 Docker Hub 的搜索 API。表现为：
- 在“注册表”里输入镜像名，一直找不到。
- 但你在“拉取”页面输入镜像的完整名称，却能正常下载。
遇到这种情况不要纠结搜索框。直接在“拉取”页面输入docker.io/library/镜像名:标签，比如：
docker.io/library/nginx:alpine能够拉下来，说明镜像源配置生效了，搜索功能缺失只是这个源自身的设计限制。
5.3 拉取到一半失败：重试、换源、查磁盘
如果小镜像能拉，但大镜像拉取到一半失败，优先怀疑三点：
- 镜像本身太大，公共镜像源对大文件有限流或稳定性问题。
- 网络质量不好，中途断开。
- 磁盘空间不足，导致无法完整保存镜像层。
我的处理习惯是：
- 先删掉没拉完的临时文件。去 Container Manager 或 Docker 的“映像”页面，看是否有残留的半成品镜像。
- 检查一下存储空间的剩余量，确认有充足空间。
- 重新触发拉取，观察是不是每次都在同一层中断。
- 如果在同一层反复失败，换一个镜像源，或者用离线导入方式（第 6 章会讲）。
需要知道，Docker 拉取大镜像时会分多个层下载，任何一个层失败，整个 pull 任务都可能失败。这不是你操作的问题，是链路稳定性问题。
5.4 升级 DSM 或重装套件后配置丢失
群晖在系统升级后，偶尔会重置或改变 Docker 相关配置。你可能发现某天拉镜像突然变慢，打开设置一看，之前配置的镜像源被清掉了。
这种情况没有太好的永久解法，只能养成记录习惯：
- 把镜像源地址、daemon.json 路径和内容保存到一个共享文件夹里的文本文件中。
- 升级 DSM 后，主动检查一遍注册表设置。
- 如果配置被清空，直接用备份恢复。
5.5 换源后速度还是不够快
换源后速度慢要区分两类：
如果是小镜像，比如几十 MB 的 nginx，依然很慢，那可能是这个镜像源本身带宽不行。可以再找一个源对比测试。
如果是几 GB 的大镜像，慢是正常的。镜像源本质上是转发或缓存，它到 Docker Hub 拉取也需要时间。公共源在高峰时段还会出现排队，速度下降并不意外。
判断标准很简单：同时段内，同一个镜像，在源 A 和源 B 下各拉一次，看哪个更稳定。多留一个备选源，谁快用谁。
6. 多镜像源、大镜像和离线场景的备用方案
前面说的都是直接配源。遇到特别大的镜像、多台群晖、或者不想再依赖外部源的情况，还有几条更工程化的备用方案。
6.1 多镜像源不要乱加，先保证至少一个稳定源
我见过有人在registry-mirrors里一次性写十个源，以为多多益善。实际效果并不好。Docker 会按顺序尝试，如果某个源超时，它要等超时结束才会切换到下一个，反而拖慢了流程。
更合理的做法是：
- 配置两到三个源，其中一个必须是你验证过能稳定访问的。
- 剩下的一到两个作为兜底。
- 不要为了“看起来很强”而堆大量失效地址。
6.2 大镜像真的拉不动，试试另一台机器导出导入
如果镜像源无法解决某个超大镜像的拉取问题，或者你需要迁移已经下载好的镜像，最直接的思路是：换一台网络稳定、已经成功拉下镜像的机器，导出成 tar 文件，再传到群晖导入。
在能正常拉取镜像的 Linux 机器上执行：
docker pull nginx:alpine docker save -o nginx_alpine.tar nginx:alpine把nginx_alpine.tar文件通过群晖文件服务上传到 NAS，然后 SSH 到群晖执行：
sudo docker load -i nginx_alpine.tar加载完，在“映像”页面就能看到对应镜像。这种方式适合：
- 一次性迁移镜像。
- 大镜像在群晖上多次拉取失败。
- 内网有一台机器已经准备好镜像，想快速分发到其他设备。
6.3 自建私有镜像仓库或使用云厂商镜像仓库
如果你有多台群晖，或者公司内网有多台机器都要用同一个镜像，每次都靠外部镜像源拉一遍很低效。可以在局域网内自建一个 Docker Registry，把常用镜像推到内网仓库里，其他设备直接走内网拉取，速度会明显更快，而且不受外部网络波动影响。
实现方式不复杂：在一台机器上运行 registry 容器，然后把镜像打标签、push 到内网地址。前提是先配置好仓库的地址和基础认证，避免被内网任意机器随意访问。
如果不方便自建，也可以用云厂商提供的容器镜像仓库服务。先把镜像推上去，群晖配置好那个仓库的登录信息后，pull 时直接走云厂商内网或普通公网链路，稳定性比公共镜像源更好控制。
6.4 确认 CPU 架构，别拉错平台版本
群晖 NAS 的 CPU 有 x86 架构和 ARM 架构之分。Docker 镜像一般会分别提供amd64和arm64版本，但某些第三方维护的镜像只做了单一架构。如果你在 ARM 机器上拉了一个只有 amd64 的镜像，会提示类似：
no matching manifest for linux/arm64 in the manifest list entries这种错误和镜像源无关，换了源也一样失败。遇到的话，先确认自己的 CPU 架构：
uname -m输出x86_64就选择 amd64 镜像；输出aarch64就选择 arm64 镜像。如果镜像没有对应架构版本，就换一个支持你架构的替代镜像。
配置镜像源这件事，核心思路其实很窄：先找一个稳定可访问的地址，通过图形界面或 daemon.json 写入 registry-mirrors，然后用小镜像验证。真正拉大镜像时，多看看是不是架构、磁盘、镜像源稳定性引起的连锁问题。
我个人建议，第一次配置时不要追求“全镜像源覆盖”，先把一个源跑通，再去考虑多源或者离线方案。群晖系统升级后，记得回去看一眼配置还在不在。长期跑服务的话，内网私有仓库是比反复依赖公共镜像源更可控的出路。