解决方案：在 ld-wrapper.sh 里注入代理变量

🔧 “更进一步”的方法大致原理如下：

1. QNAP QPKG 系统通过 qpkg.conf 定义 Container Station 的安装路径；

2. 启动脚本通常位于：

3. 这个脚本中会调用一些子脚本（比如 run.sh、start.sh 或 container-station.py）来实际启动 dockerd；

4. 你可以直接在这些脚本里添加 export HTTP_PROXY=... 环境变量，这样从根源注入，而不是依赖 ld-wrapper.sh。

✅ 是否需要用更高级方式？

• 让 Docker pull 走代理

• 容器正常运行

• 不会频繁升级 Container Station

• ✅ 安全

• ✅ 持久性（在不升级 Container Station 情况下）

• ✅ 无副作用

iStoreOS Docker 代理配置备忘录

核心原理

配置步骤

1. 配置 Mihomo (Clash core) 代理服务

• 检查 Mihomo 监听状态：Bash 确认 Mihomo (进程名通常是 mihomo) 正在监听 :::7890 (这表示它同时监听 IPv4 的 0.0.0.0:7890 和 IPv6 的 [::]:7890)。
netstat -tulnp | grep 7890

• 测试 Mihomo 出站连接： 在 iStoreOS 命令行，通过 Mihomo 代理测试外部网络访问，确保代理本身工作正常。 Bash 确认能看到 Google 的 HTML 内容。
curl -v -x http://192.168.2.2:7890 https://www.google.com --max-time 20

• 建议使用纯 HTTP 代理端口 (如果 Mihomo 支持)： 如果你的 Mihomo 配置中有单独的 port: 8080 (纯 HTTP 代理)，优先在 Docker 配置中使用 8080 端口，而非 mixed-port，以获得更好的兼容性。

2. 配置 Docker 守护进程的代理

• 通过 UCI 设置代理信息：Bash
注意： 将 192.168.2.2:7890 替换为你 Mihomo 服务实际监听的 IP 地址和端口。如果你使用的是 Mihomo 的纯 HTTP 端口，请将端口改为 8080。

• 删除旧的 daemon.json 文件 (避免冲突)：Bash
rm -f /etc/docker/daemon.json
因为 Docker 启动脚本会生成临时的 daemon.json 文件，保留旧文件可能会导致意外行为。

• 重启 Docker 守护进程：Bash
/etc/init.d/dockerd restart

• 验证 Docker 是否加载了正确的配置： 检查 Docker 守护进程实际加载的 daemon.json 文件内容。BashJSON
cat /tmp/dockerd/daemon.json
确认其中包含 http-proxy 和 https-proxy 等字段。例如：
{ "proxies": { "http-proxy": "http://192.168.2.2:7890", "https-proxy": "http://192.168.2.2:7890", "no-proxy": "localhost,127.0.0.1,192.168.0.0/16" } // ... 其他 Docker 配置 }

3. 排除故障 (如果仍然有问题)

• 确认代理节点工作正常： 如果 docker pull 仍然超时，但 curl 测试代理正常，那么问题很可能出在 Mihomo 当前使用的代理节点本身，它可能对 Docker Hub 的流量不兼容或不稳定。尝试在 Mihomo 仪表盘中切换到其他节点或不同协议的节点。

• 正确拉取镜像名称： 确认你要拉取的 Docker 镜像名称是正确的，例如 docker pull hello-world 而不是 docker pull helloworld。

debian 等系统用systemd管理docker的 配置 Docker pull走代理

✅ 1. 创建配置目录

✅ 2. 编辑代理配置文件

✅ 3. 重载 systemd 并重启 Docker