最近在部署 3qruok.com 的时候被墙又戏耍了，在国内环境下使用 Docker，网络问题始终是绕不开的痛点。即便你本地开启了系统的 TUN 模式或全局代理，在使用 Kamal 进行部署时，依然可能遇到下面这种让人冒火的“玄学”报错：

DEBUG [1ecc2695] ERROR: failed to build: failed to solve: failed to fetch anonymous token: 
Get "[https://auth.docker.io/token?scope=repository%3Alibrary%2Fruby%3Apull&service=registry.docker.io](https://auth.docker.io/token?scope=repository%3Alibrary%2Fruby%3Apull&service=registry.docker.io)": EOF
...
docker stdout: #0 building with "kamal-local-docker-container" instance using docker-container driver

明明机器已经开启了 TUN 模式，为什么 Docker 构建时还是拿不到 Token 导致 EOF？

核心矛盾：消失的网络继承

问题的根源在于 Kamal 默认的构建机制。Kamal 在打包时会创建一个名为 kamal-local-docker-container 的构建器，它使用的是 docker-container 驱动。

什么是 docker-container 驱动？

它的本质是在你的 Docker 中启动一个独立的 BuildKit 容器：

• 它的使命：实现跨平台构建（Multi-platform builds）。它内部集成了一个独立的 QEMU 模拟器，这使得它能完全脱离宿主机硬件架构的影响。无论你的 Mac 是 Intel 还是 M 系列芯片，它都能为你“直出”目标环境（如 x86）的镜像。
• 它的副作用：由于它运行在一个高度隔离的容器内，它拥有完全独立的网络命名空间。它不会自动继承宿主机的 TUN 代理或环境变量，甚至会忽略你在 Docker Desktop 界面设置的镜像源（Registry Mirrors）。这导致它在尝试拉取基础镜像（如 ruby:slim）时，依然在直接撞墙。

解决方案：回归宿主机驱动

要解决这个问题，最简单的办法是让构建任务交还给宿主机的 Docker Daemon 来处理，从而直接利用宿主机已经配置好的网络环境。

操作步骤

1. 修改 deploy.yml 在配置文件中明确指定 builder 的驱动为 docker：

   builder:
     driver: docker
   

2. 提交配置（关键点） Kamal 部署时会检查 Git 状态。如果 deploy.yml 的修改没有被 git add，Kamal 可能会读取旧的配置导致修改不生效：

   git add config/deploy.yml
   

3. 清理旧的构建器 删掉那个由于网络原因卡死的旧构建实例，强制 Kamal 重新初始化：

   docker buildx rm kamal-local-docker-container
   

4. 重新运行部署 执行 kamal deploy，此时构建进程将直接调用本地 Docker 环境。

深度解析：为什么 driver: docker 依然能打出 x86 镜像？

你可能会担心：如果不用 docker-container 驱动，我在 ARM 架构的 Mac 上还能打出生产环境需要的 x86 镜像吗？

答案是肯定的。 这是因为 Docker Desktop for Mac 已经在其底层的 Linux 虚拟机里注册了 QEMU。当你切换到 driver: docker 时：

• 架构模拟：依然由 Docker 虚拟层底层的 QEMU 负责，跨平台打包能力依然存在。
• 网络控制：构建进程此时运行在宿主机 Docker 的“亲生”环境下，它能完美识别并使用你本地调教好的代理或镜像站。

总结

在 Kamal 部署流程中，如果你遭遇了 Docker 认证阶段的 EOF 错误，通常是因为默认的构建容器陷入了“网络孤岛”。

将 builder 的驱动修改为 docker 是目前国内开发者最务实的解决方案。它通过牺牲一点点构建隔离性，换取了对宿主机网络环境的完美继承，让部署过程不再卡在第一步。