type
Post
status
Published
date
Feb 14, 2026
slug
summary
过年前我有个固定仪式：给 NAS 做一次“系统大扫除”。不求折腾出新花样，只想把运行了一年的东西都检查一遍，顺手把容器升级到最新，省得年里某天突然出问题，连排查都没心情。
tags
文字
category
技术分享
icon
password
URL
过年前想给 NAS 做一次“系统大扫除”。不求折腾出新花样，只想把运行了一两年的东西都检查一遍，顺手把容器升级到最新，省得年里某天突然出问题，连排查都没心情。
这次轮到的是 TeslaMate。
按理说它属于那种“最省心”的服务：拉一下最新镜像，重建容器，数据都在挂载卷里，升级通常就是十几分钟的事。于是我打开群晖的 Container Manager，准备把
teslamate/teslamate 拉下来。然后我就遇到了那种最烦的失败：它不是立刻报错，也不是提示镜像不存在，而是一直等。
像你站在一扇门前敲门，门里有人，但就是不应声。
最后屏幕上跳出一句话：
Failed to pull image: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
看到 “awaiting headers timeout” 的那一刻，我才反应过来：问题根本不在 TeslaMate，也不在 compose 文件。容器升级这件事，本质上依赖一个外部前提：Docker Hub 要能稳定访问。而在国内网络环境里，这个前提并不可靠。
我没有继续赌运气，也没有去改容器参数。因为这类问题，越往“容器内部”调越容易走偏，真正该下手的是“拉镜像这条路”本身。
一、群晖配置代理服务器上网
群晖直接使用局域网内的可以科学上网的代理服务器，配置路径如下：控制面板-网络-常规
不过改了这个之后，还是一样的报错。
二、配置镜像加速：
于是我做了一个更像基础设施层面的改动：给 Docker 引擎加上镜像加速的
registry-mirrors，让所有 docker.io/* 的拉取都优先走一条更稳定的路径。配置长这样（地址用你自己可用的镜像加速域名替换）：
镜像提供者 | 镜像地址 (URL) |
DaoCloud | https://docker.m.daocloud.io |
Huecker | https://huecker.io |
Docker 代理站 | https://dockerhub.timeweb.cloud |
GitHub 代理 | https://ghcr.io |
改完之后我重启了 Docker 引擎（或者干脆重启 NAS，最省心）。然后再回到那一步，重新拉取
teslamate/teslamate。这次没有再“站在门口等回应”。
镜像开始稳定下载，进度条有节奏地走完。随后
up -d 也顺利执行，TeslaMate 正常起来，Grafana 页面也能打开，一切恢复到那种“升级就应该是这样”的状态。- Author:AI Innovation
- URL:http://inno4ai.com/article/30797a38-0bdb-80df-8758-c9677ccda20d
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
