从超时到狂飙：极空间 NAS 完美配置 KSpeeder 与 Docker 代理分流指南

最近在国内玩 NAS 和 Docker 的朋友们肯定深有体会：Docker Hub 的直连网络越来越薛定谔，基础镜像拉取极其困难；而各种前沿的 AI 项目（比如 Open WebUI）又常常托管在 ghcr.io，直连几乎 100% 被阻断。

为了解决这个问题，我今天进行了一场深度的网络折腾。最初的设想是利用旁路由提供全局代理，同时在本地部署 KSpeeder 来实现官方镜像的 P2P 满速下载。没想到在这个过程中，遇到了意想不到的“代理冲突”大坑。

这篇文章将详细记录我从遇到 Timeout 报错，到揪出底层配置元凶，再到最终构建出**“本地 KSpeeder 满速加速 + 远端魔法代理兜底”**完美混合网络架构的全过程。

踩坑实录：为什么我的本地加速器卡死了？

为了给 Docker 提速，我在极空间 NAS 上通过 Docker Compose 部署了 KSpeeder：

yaml
services:
  kspeeder:
    image: registry.kspeeder.com/linkease/kspeeder:latest
    container_name: kspeeder
    ports:
      - 5443:5443
      - 5003:5003
    volumes:
      - ./kspeeder-data:/kspeeder-data
      - ./kspeeder-config:/kspeeder-config
    restart: unless-stopped

部署完成后，我在极空间的 Docker 界面配置了加速器地址：https://registry.linkease.net:5443。 本以为大功告成，结果一跑 docker pull alpine，直接喜提报错： Client.Timeout exceeded while awaiting headers

进 KSpeeder 后台看日志，又发现了协议冲突警告： client sent an HTTP request to an HTTPS server

经过 ping 和 curl -v 命令的一番交叉排查，我终于发现了盲点：Docker 的全局代理劫持了本地流量！

因为我之前为了拉取海外镜像，给 Docker 配置了一个局域网内的代理节点（例如 192.168.31.221:20172）。当 Docker 试图连接 registry.linkease.net 时，它并没有在 NAS 本地找，而是直接把请求打包扔给了外网代理服务器。远端代理自然找不到我部署在本地的 KSpeeder，最终导致了超时卡死。

破局：潜入 Linux 底层修改 No Proxy 白名单

既然症结在于全局代理，解决思路就很清晰了：我们需要告诉 Docker，“访问 KSpeeder 时，不要走全局代理！”

无奈的是，极空间（ZOS）的图形化界面在这方面做了过度精简，只提供了填代理 IP 和端口的地方，把设置 No Proxy（免代理白名单）的入口给阉割了。我们只能通过 SSH 登录到底层进行硬改。

操作步骤：

1. SSH 登录极空间并获取 root 权限。
2. 寻找真实的配置文件：在 Systemd 架构下，Docker 的代理环境变量并不在 daemon.json 里。我们利用现有的代理 IP 全局搜寻：

   bash
   sudo grep -rl "192.168.31.221" /etc/systemd/system/
   

   果不其然，系统返回了路径：/etc/systemd/system/docker.service.d/http-proxy.conf
3. 编辑配置文件：极空间内置了友好的 nano 编辑器（如果没有也可以用 vi）：

   bash
   sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf
   

4. 添加白名单：找到 Environment="NO_PROXY=..." 这一行，在末尾加上 KSpeeder 的域名。 修改后类似这样： Environment="NO_PROXY=registry.zenithspace.net,localhost,127.0.0.1,registry.linkease.net"
5. 保存并重启服务：

   bash
   sudo systemctl daemon-reload
   sudo systemctl restart docker
   

终极形态：教科书级的双轨分流架构

配置生效后，奇迹发生了。当我尝试拉取体积庞大的 gitlab/gitlab-ce 镜像进行压力测试时，速度瞬间飙升到了 25.6 MB/s！单层几百兆的文件毫无波澜地跑满了我家的物理带宽，KSpeeder 的仪表盘流量也精准对账。

至此，我的 NAS 拥有了一套堪称完美的网络分流架构：

1. ✈️ 常规流量（Docker Hub）：走本地 KSpeeder 专线 因为配置了 NO_PROXY 白名单，常见的官方基础镜像（如 Nginx、Alpine、LinuxServer 系列）会精准命中本地的 KSpeeder 容器。不仅多线程拉满，数据还会沉淀在 NAS 硬盘缓存中。日后局域网其他设备再需要这些镜像，直接内网秒传！
2. 🛡️ 特殊流量（GHCR、Quay 等）：走旁路由代理兜底 遇到像 open-webui 这样前缀自带 ghcr.io 的第三方或海外独家镜像时，Docker 会自动判定跳过本地加速器，无缝走全局代理节点（192.168.31.221）去拉取。这就相当于加了一把万能钥匙，彻底告别了“网络连接重置”的痛点。

结语

折腾 NAS 的乐趣往往就在于此：看似枯燥的日志报错背后，其实隐藏着严密的网络逻辑。通过这次排错，不仅理清了 HTTP/HTTPS 的冲突原理，也深刻理解了 Linux 底层环境变量对 Docker 行为的影响。

如果你也正被 Docker 拉取缓慢折磨，不妨试试这套 “KSpeeder 缓存加速 + 全局代理兜底” 的组合拳，绝对能让你体验到久违的丝滑！