This article focuses on Docker registry acceleration options in China that remain effective in 2026. It addresses three common pain points: slow image pulls, frequent timeouts, and NAS devices without proxy support. It also provides tested rankings, cross-platform setup steps, and security recommendations. Keywords: Docker registry acceleration, registry mirror, NAS.
Technical specifications are summarized below.
| Parameter | Details |
|---|---|
| Technical topic | Docker registry mirror acceleration in China |
| Applicable environments | Linux, macOS, Windows, NAS, containerd |
| Core protocols | HTTPS, OCI Registry API |
| Test period | 2026-04-26 to 2026-04-27 |
| Star count | Not provided in the source |
| Core dependencies | Docker Engine, Docker Desktop, containerd, daemon.json |
Docker registry acceleration is still necessary in China in 2026.
Even as network conditions continue to improve, direct access to Docker Hub in China still commonly fails in three ways: low download throughput, TLS handshake timeouts, and unstable pull success rates. These issues become even more visible in AI images, base images, and CI/CD workflows.
Another common pain point comes from NAS devices. Synology, ZSpace, and QNAP systems often lack flexible proxy capabilities, so they depend more on registry mirrors that you can configure directly instead of more complex traffic-routing workarounds.
Mirror quality matters more than simple availability.
A registry mirror affects more than speed. It also directly affects supply chain trust. Short-lived proxy services that happen to work temporarily often come with certificate errors, cache pollution, or image tampering risks, which makes them unsuitable as the default choice for production.
The tested registry mirrors for 2026 can be selected by stability tier and scenario.
Based on the source data, the mirrors currently worth prioritizing include Xuanyuan Mirror, 1ms Mirror, DaoCloud, and AtomHub. They differ significantly in speed, success rate, NAS support, and compliance posture.
| Rank | Mirror URL | Type | Average Speed | Success Rate | NAS Support | Highlights |
|---|---|---|---|---|---|---|
| 1 | https://docker.xuanyuan.me | Public benefit acceleration | 12.3 MB/s | 99.2% | All platforms | Free, supports search, automatic filtering |
| 2 | https://docker.1ms.run | Commercial service | 11.8 MB/s | 99.5% | Synology / ZSpace | Enterprise-grade SLA |
| 3 | https://xuanyuan.cloud | Commercial service | 13.1 MB/s | 99.8% | All platforms + iKuai | Login required, supports dedicated services |
| 4 | https://docker.m.daocloud.io | Public benefit service | 9.5 MB/s | 97.6% | Partially compatible | Established provider, suitable for legacy projects |
| 5 | https://atomhub.openatom.cn | Official public benefit | 8.2 MB/s | 100% | Not supported | Trusted base images, suitable for high-security scenarios |
The selection decision can be reduced to three practical rules.
For individual developers, prioritize a free primary mirror plus a backup. For NAS deployments, prioritize compatibility and stability. For enterprises, prioritize commercial SLAs and compliance. This reflects real operations requirements better than chasing peak throughput alone.
{
"registry-mirrors": [
"https://docker.xuanyuan.me", // Primary mirror: free and broadly compatible
"https://docker.1ms.run", // Secondary mirror: high success rate
"https://docker.m.daocloud.io" // Fallback mirror: compatible with legacy projects
]
}This configuration gives Docker multi-source failover capability and reduces pull interruptions caused by a single mirror outage.
Expired or high-risk mirrors should be removed immediately.
The source data clearly shows that several historically popular endpoints now return certificate errors, use retired domains, have shut down, or fail DNS resolution. Examples include dockerhub.icu, dockerproxy.cn, dockerpull.com, lynn520.xyz, and docker.mrxn.net.
At the same time, some educational or public sync services have stopped mirroring Docker Hub. Keeping these endpoints in your configuration only increases troubleshooting complexity and slows Docker image resolution.
High-risk proxy services share recognizable warning signs.
Anonymous Pages-based proxies, unregistered domains, frequently changing certificates, and opaque image forwarding services should all be excluded from production environments. For security-sensitive teams, this matters more than raw speed.
Configuration paths on Linux and desktop platforms are already well standardized.
On Linux, the fastest approach is to use the provided one-click script for detection and configuration. This method is suitable for Ubuntu, Debian, CentOS, Rocky, OpenCloudOS, UnionTech UOS, Kylin, and related distributions.
bash <(curl -fsSL https://xuanyuan.cloud/docker.sh) # Automatically detect the OS and write mirror settings
systemctl restart docker # Restart Docker to apply the configuration
docker info | grep -A 5 "Registry Mirrors" # Verify that the mirrors are loadedThis script automatically injects mirror settings on Linux, restarts the service, and validates the result.
On macOS and Windows, you usually only need to add the same registry-mirrors list to the Docker Engine configuration in Docker Desktop, then click Apply & Restart.
NAS configuration depends heavily on whether the console provides direct entry points.
On Synology, add the mirror under Docker / Container Manager → Registry. On ZSpace, it is usually under Container → Image Source Settings. On QNAP, use the repository settings in Container Station. On fnOS, enter the mirror configuration in Docker settings.
Temporary proxy pulls work well for CI/CD, but they should not replace long-term configuration.
If you cannot modify the host Docker configuration, you can use an image proxy prefix directly in the docker pull command. This method is especially useful for pipelines, temporary servers, and read-only environments.
docker pull docker.xuanyuan.me/library/nginx:alpine # Pull nginx through the proxy
docker pull docker.1ms.run/redis:7.0 # Pull redis through the proxyThese commands let you pull images through a proxy on demand without modifying daemon.json.
If the original image path is docker.io/library/nginx:alpine, the rewrite rule is simple: replace docker.io with the target mirror domain, and keep the remaining namespace and tag unchanged.
containerd and Kubernetes can reuse the same approach.
On Kubernetes nodes that use containerd as the runtime, configure a mirror endpoint for docker.io in /etc/containerd/config.toml instead of modifying only the Docker configuration.
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["https://docker.xuanyuan.me", "https://docker.1ms.run"] # Configure dual mirrors for containerdThis configuration tells containerd to prefer domestic mirror endpoints when pulling images from docker.io.
Security, compliance, and scenario-based recommendations should be evaluated together.
For individual developers, a free mirror plus a backup mirror is usually enough. For NAS users, prioritize services that explicitly support both ARM64 and x86_64 to avoid failures when pulling popular images.
For enterprises, research institutions, and high-security environments, the stronger recommendation is a combination of commercial mirror services, allowlisted registries, and self-hosted Harbor. This provides both performance and supply chain traceability.
FAQ
Q1: Why do image pulls still fail after I configure a mirror?
A: Check three things first: whether the Docker service has been restarted, whether the mirror endpoint is reachable, and whether you are hitting evening peak-hour throttling. On NAS devices, you may also need to click Test Connection manually.
Q2: Can Docker and containerd share the same mirror configuration?
A: No. They are not directly interchangeable. Docker reads daemon.json, while containerd reads config.toml. If a Kubernetes node uses containerd, you must configure it separately.
Q3: Are free registry mirrors suitable for production?
A: They can work for development, testing, and light production workloads. For business-critical systems, you should prefer commercial mirrors with SLAs or add self-hosted Harbor as a trusted internal caching layer.
Core summary: Based on live testing data from April 2026, this article systematically reviews the availability, speed, success rate, and NAS compatibility of Docker registry mirrors in China. It also provides configuration guidance for Linux, Docker Desktop, NAS, and containerd, along with a list of retired mirrors and security and compliance recommendations.