威联通的B站官方账号最近保持着每周一个"Docker一键部署"教程的节奏，8月11日是漫画库Suwayomi，8月5日是本地AI智能体Hermes，再往前还有小说库、音乐聚合和Plex影音库，compose文件都是直接给的。Suwayomi 是开源自托管漫画库工具，依托Docker部署于NAS，支持漫画批量导入、多端阅读。哔哩哔哩按理说照着抄进Container Station就能跑，但现实是很多人卡在了第一步：镜像根本拉不下来。
更磨人的是，搜"Docker镜像源"抄教程，要么列表还是"2024最新版"，要么地址早就死了。这不是个别现象：多数公益 Docker 镜像源已关停，单靠抄旧教程往往无效。知乎这篇文章就在写作当天（8月11日）实测了社区里常见的10个镜像源地址，把散落在几位威联通创作者文章里的加速方案归并成三条路线，按从短到折腾排序，顺便讲清一个最隐蔽的坑：不少官方视频里的应用镜像压根不走Docker Hub，你配好镜像源也白搭。
8月11日实测：10个源里只有4个稳
测试方法是用curl直接请求registry协议的/v2/和nginx的manifest，返回401的地址继续走完token认证流程再下结论。结果只代表测试时刻从我这个网络环境的可达性，不代表速度，也不代表长期稳定，不同运营商和地区会有差异，但至少能看出谁已经死了。
镜像源 | 8月11日实测结果 |
|---|---|
✅ token流程通过，manifest拉取200 | |
✅ manifest直取200 | |
docker.1panel.live | ✅ manifest直取200 |
docker.1ms.run | ✅ 响应正常，标准token机制；hub.rat.dev现已302指向它 |
⚠️ 有响应，但认证是Basic挑战，不走标准token流程 | |
⚠️ 首页活着，镜像路径全部404 | |
dockerhub.icu | ❌ 超时不可达 |
docker.unsee.tech | ❌ 超时不可达 |
docker-cf.registry.cyou | ❌ 超时不可达 |
❌ SSL握手失败 |
比表格本身更值得说的有两个观察。第一，镜像源的半衰期已经短到以周计，NAS装应用这个场景里，论坛里搜到的教程，配的镜像地址很多已经404或限流了，看列表先看它写没写测试日期。知乎第二，不少每周更新的"镜像源列表"其实夹着某家付费服务的软广，公益源混在里面，不是不能用，是要自己挑。
路线A：Docker Hub镜像，Container Station添加自定义存储库（最短，不碰命令行）
只想装Jellyfin、qBittorrent、笔记同步这类镜像在Docker Hub上的应用，最短路线是用Container Station自带的存储库机制，全程不用敲命令。用http-only的公益源（不少cloudflare workers自建源没有https），添加存储库这步的细节容易踩坑。知乎添加完之后，到"映像—提取"里选基本模式，存储库下拉里选刚加的源，填镜像名，先点测试，显示连接成功就能正常拉了。
建议一次配两三个备用源。现在的环境里，镜像源是耗材，不是资产，今天这个能用，明天可能就404，一个死了立刻换下一个，不值得为任何一个源折腾情绪。
路线B：家里有代理的，别填威联通系统设置，它对Docker不生效
家里有软路由或者代理客户端的，会发现威联通系统设置里有个填代理地址的地方，但填完之后Docker拉取照样失败。这不是你配错了：那个系统级代理只在shell里跑的命令中有效，对系统服务（当然也包括Docker拉取）是没有用的。知乎正确姿势是SSH登录NAS，把HTTP_PROXY、HTTPS_PROXY环境变量写进Container Station的Docker启动配置里，指向软路由或代理客户端的局域网地址加端口，保存后执行/etc/init.d/container-station.sh restart重启容器服务，拉取流量才会真正走代理。这条路线最适合家里本来就有代理环境的人，一次配置长期省心；没有代理的直接看路线A或C，别硬上。
路线C：自建中转，适合进阶玩家，但先看清项目消失风险
还有一条更"自主可控"的思路：在NAS或云服务器上自己跑一个中转代理，让它替你去Docker Hub取镜像。HubProxy这类轻量开源项目一个compose就能部署，跑起来后访问NAS的IP加15000端口就能拿到加速链接，再按路线A的办法加回Container Station当自定义存储库用。但这条路要先泼一盆冷水：这类公益项目的生态极其脆弱。知乎走这条路就要做好"项目消失当天换下一个"的心理准备，并把下面的tar导入兜底法学到手。
最隐蔽的坑：官方应用镜像多在ghcr.io，镜像源不管它
不少人配好镜像源、顺利拉下两个Docker Hub镜像之后，去装官方视频当天推荐的Suwayomi，又卡住了。仔细看compose文件，镜像地址前缀是ghcr.io，而你配的registry-mirrors机制只管docker.io，ghcr.io、gcr.io这些仓库根本不走这条路。知乎这就是"镜像源明明活着，官方应用却拉不动"的根本原因。
同日我也测了ghcr方向：ghcr.m.daocloud.io能正常签发token，但取Suwayori镜像的manifest直接返回403，也就是说GHCR的公益加速在当下基本是全灭状态。威联通用户想装这些官方推荐应用，现实可行的路有两条：
tar导入法：在能拉取的电脑上（或借朋友的代理环境）docker save导出tar包，Container Station"映像—导入"里设备选本地计算机或本地QNAP设备，选中文件即可完成，不依赖任何镜像源，是最稳的兜底。
改前缀法：个别全仓库加速服务会给ghcr提供专属域名，把compose里镜像前缀直接替换成加速域名，Container Station对compose文件支持原文件修改和验证，改完点创建即可。
报错怎么判断卡在哪，存着救急
最后附一个报错速查表，下次卡住不用满网搜：
报错表现 | 大致方向 |
|---|---|
进度条卡死、context deadline exceeded | 镜像源死了或直连被墙，换源 |
401/402 | 源需要认证、账号或已限流 |
429 | 撞上Docker Hub官方限流，慢点或换带缓存的源 |
manifest unknown | 镜像名/tag写错，或该源没收录这个镜像 |
一句话收尾：2026年在威联通上玩Docker，镜像源只是耗材。配好两三个备用、学会tar导入、认清ghcr和Docker Hub的区别，外面怎么变，你的NAS都有应用可装。你自家用着还活的源，欢迎留在评论区，我定期复测更新上面那张表。
