WSL 环境下 Docker 拉取镜像速度慢

本文适用于：

⚠️ 重要提示

这是 WSL 环境下的典型性能问题，不是镜像仓库故障，也不是 DNS 问题。在特定条件下（WSL + 大镜像层 + Windows 挂载目录），Docker 拉取镜像速度会明显下降，甚至出现长时间"看似卡住"的情况。

在使用 WSL（尤其是 WSL2）拉取 Docker 镜像时，可能会遇到下载速度极慢、卡在某个镜像层不动的情况。即使您的网络带宽充足，浏览器或迅雷下载速度正常，Docker 拉取镜像仍然很慢。本文将详细分析这一问题的原因，并提供有效的解决方案。

问题现象

在使用 WSL 拉取 Docker 镜像时，可能会遇到以下情况：

该现象看起来像"仓库限速"或"网络异常"，但实际上并非如此。

Docker 拉取镜像时使用单 TCP 长连接，对网络的丢包率、RTT（往返时延）、链路稳定性非常敏感。与迅雷等下载工具的多线程、多源、运营商加速机制不同，Docker 不具备这些优化机制。

因此，「迅雷下载很快」并不能说明 Docker 网络链路没有问题。Docker 对网络质量的要求更高，在网络不稳定或延迟较高的环境下，单连接下载速度会明显下降。

在 WSL 中，Docker 的真实网络路径为：

Docker → WSL 虚拟网络 → Windows 网络栈 → 物理网卡

相比原生 Linux 或云服务器，WSL 多了一层虚拟网络转发，TCP 稳定性问题更容易被放大。网络延迟和丢包率在虚拟网络层会被进一步放大，导致下载速度下降。

若 Docker 运行在 WSL 中，且当前路径位于 /mnt/c/Users/... 等 Windows 挂载目录，则在拉取镜像时会出现以下问题：

这是 WSL 的已知性能特性之一。Docker 进度条长时间停滞，往往是因为磁盘 I/O 瓶颈，而非网络问题。

因为该层通常体积最大（1GB+），解压与写盘耗时最长。在 WSL + Windows 挂载盘组合下，这类镜像层最容易暴露性能问题。小体积的镜像层可能很快完成，但大体积层会明显卡住。

DNS 仅影响"是否能连接到仓库"。当前场景中镜像已成功开始下载，DNS 不会导致"已连接后持续低速下载"。因此，该问题不符合 DNS 故障特征。

✅ 方案一（强烈推荐）

避免在 /mnt/c 等 Windows 挂载目录中使用 Docker。

在 WSL 中请使用：

cd ~
docker pull xxx

并确保 Docker 的数据目录位于 WSL 自身文件系统中（如 /var/lib/docker），而不是 Windows 挂载目录。

若使用 Docker Desktop，建议直接在 Windows 主机环境执行 docker pull，避免通过 WSL 间接拉取大体积镜像。

Docker Desktop 在 Windows 上运行时，性能通常优于 WSL 环境，特别是在处理大文件 I/O 时。

如果条件允许，可以在以下环境中进行对比测试：

如果其他环境下载正常，可确认问题来源于 WSL 本身，而非网络或镜像仓库问题。

镜像仓库服务运行正常。多节点、多地区测试，大镜像可稳定高速下载。未发现平台侧限速或异常情况。当前问题不属于平台服务故障。

💡 一句话总结：

在 WSL 环境下，尤其是结合 /mnt/c 等 Windows 挂载目录时，Docker 拉取大镜像存在已知性能瓶颈。这不是网络带宽、DNS 或镜像仓库问题，建议在 WSL 自身目录或非 WSL 环境中使用 Docker。

如在非 WSL 环境下仍持续出现异常下载问题，请提交工单并附带完整拉取日志，我们将协助进一步排查。

你可能还会遇到：

本文由「xuanyuan.cloud」维护
专注国内 Docker / 镜像 / Registry 网络问题
内容基于真实用户环境与实测