dongyubin/DockerHub: a maintained list of China-accessible Docker Hub mirrors

What dongyubin/DockerHub actually is: a README and nothing else

The repository has one top-level entry, README.md. There is no source code, no Dockerfile, no release, no package manifest and no licence file. The README is a curated table of Docker Hub mirror accelerator addresses that the author states were tested and still usable in mainland China as of 2026-06-13, followed by a longer table of addresses that no longer work, most struck through.

The problem it addresses is narrow and real. Docker Hub is the registry Docker clients pull from by default, and the README notes that many mirrors previously used from China, including cloud vendor and university mirrors, have stopped working. A user who cannot reach Docker Hub needs an alternative endpoint to place in their Docker daemon configuration. This list is a starting point for finding one.

Who it is for: engineers and operators in mainland China configuring a Docker daemon, and anyone maintaining a build environment that must pull public images there. Who it is not for: anyone wanting a tool, a proxy they can run themselves, or a service with an SLA. The README points to a blog version at wangdu.site for more timely updates, which is an admission that the GitHub copy lags.

How the mirror list is organised, and why the dead table matters more

The live table pairs a mirror name with an accelerator address. Examples the README lists include https://docker.1ms.run, https://docker.m.daocloud.io, https://docker.xuanyuan.me, https://registry.cyou and https://mirror.houlang.cloud. Some entries carry conditions in the same cell: docker.1panel.live is noted as restricted to China, Tencent's mirror.ccs.tencentyun.com is described as internal-network only and not usable as an external domain accelerator, and mirror.houlang.cloud is noted as requiring registration and a token.

The dead table is the more informative half. It records addresses such as dhub.kubesre.xyz, dockerpull.org, docker.1panel.dev, docker.foreverlink.love, hub.uuuadc.top and docker.ckyl.me, with reasons where the author knows them: dockerpull.org is marked as blocked by the GFW on 12/27, and hub.uuuadc.top is marked as shut down by its author because of traffic volume. Aliyun appears in the dead table with a note that it requires login, is system-assigned, and can only pull old images.

That pattern is the actual lesson of the repository. Mirror endpoints are volunteer-run or vendor-run, they disappear for regulatory, cost or abuse reasons, and a list like this is a snapshot. The README itself warns that some mirrors serve only base images or a whitelist, and asks users to switch addresses when an image is unavailable and to use self-funded proxies reasonably.

Using a listed mirror: daemon configuration, not installation

There is nothing to install from this repository. The README does not give install steps because there is no software; the thing you install is Docker, and the thing you configure is the daemon. The README's contribution is the endpoint list you put into that configuration.

The README does not include a daemon.json example, so any configuration file you write is your own. What the README gives you is the set of accelerator addresses to choose from, such as https://docker.1ms.run, https://docker.m.daocloud.io or https://docker.xuanyuan.me. Which key you use and how you write the file depends on your Docker installation, and the README does not document that part.

The first real use is a pull that previously failed. Take an address from the live table, configure your daemon with it, and try the pull again. If it fails, that is the signal the README describes: switch to another address from the live table. Do not assume a mirror that answers for one image answers for all of them. The README states that some mirrors cover only base images or a whitelist, so a failure on an application image does not necessarily mean the endpoint is down.

The limits: no code, no licence, no freshness guarantee, and mirrors you do not control

The first limitation is structural. This is a list, and a list cannot enforce anything. If an endpoint in the live table stops working, nothing in the repository notices. The only freshness signal is the date in the README heading, 2026年6月13日, and the separate table of dead addresses that keeps growing.

The second is that the repository carries no licence. The README is a compilation of third-party service addresses and links. Reusing the text or the table in another project has no stated terms, which is a practical problem for anyone wanting to republish it. That is a description of what the repository contains, not legal advice; if reuse matters to you, the absence of a licence file is the fact to weigh.

The third is that the mirrors are not yours. Several are described as run by volunteers at their own expense, one was shut down by its author over traffic, and one was blocked at the network level. A mirror can also change what it serves without notice, which is why the README's own instruction is to switch addresses when an image will not pull. Any pipeline that hard-codes a single endpoint from this list has a single point of failure that the list cannot remove.

The fourth is scope. The README covers Docker Hub mirrors for users in mainland China. If you are outside that region, or you pull from registries other than Docker Hub, this list does not address your problem.

Alternatives: run your own registry proxy instead of borrowing someone's

The real alternative is not another list. It is running your own pull-through cache or registry proxy, so the endpoint you configure is one you operate and can monitor. The difference in approach is ownership: a list entry is a third-party service whose availability, image coverage and acceptable-use policy you do not control, while a self-hosted proxy is your infrastructure with your own logs and your own failure modes.

The cost side is where the comparison bites. A self-hosted proxy needs a host reachable from your build machines, storage for cached layers, and someone to keep it running. The list needs a text editor. For a single developer who occasionally pulls an image, the list is the proportionate choice; for a CI system pulling images on every build, a borrowed endpoint that can be shut down over traffic is a dependency worth replacing.

A second alternative is the vendor mirror route, which the README partially covers. Tencent's mirror.ccs.tencentyun.com is listed with the explicit constraint that it works only from inside Tencent's network and not as a public accelerator domain. That is a different trade: a vendor-operated endpoint with a documented scope, usable only where the vendor's network reaches it. The README also lists Aliyun in the dead table with the note that it requires login, is system-assigned and can only pull old images, which is a reminder that vendor mirrors come with their own coverage limits.

Maintenance and upgrade cost

The repository's last push was on 2026-06-13. It is not archived, but that is more than three months before today, and the README's own live table is dated the same day, so the list should be read as a snapshot from that date rather than a continuously updated feed. The README directs readers to a blog version for more timely updates, which suggests the author treats the GitHub copy as secondary.

Upgrade cost is close to zero in the software sense: there is no dependency to bump, no API to track, no migration. The cost is operational and recurring. Every mirror endpoint you configure is a dependency that can fail without a commit in this repository, and the only maintenance action available to you is re-checking the table and re-testing endpoints. Budget for that check as part of your build environment, not as a one-time setup.

On licensing, the repository states no licence. The README aggregates links to third-party services, and each of those services has its own terms, which the README does not reproduce. If you intend to redistribute the table or build on it, the absence of a stated licence and the absence of the mirrors' terms are both gaps you would need to resolve with the respective parties.

Editorial conclusion

Adopt this list if you are in mainland China and need to find a working Docker Hub mirror endpoint to put in your Docker daemon configuration, and treat it as a starting point to test rather than a guarantee. Do not adopt it if you need a program, a CLI, a hosted service or anything with a support commitment; the repository contains only README.md. Before relying on any entry, verify three things yourself: that the endpoint still resolves, that it serves the specific image you need (several listed mirrors are described as offering only base images or a whitelist), and that the mirror's own terms permit your use. The 2026-06-13 table is the only dated evidence of availability in the repository, and the dead table below it exists precisely because entries stop working.

Frequently asked questions

Official sources

1. dongyubin/DockerHub on GitHub
2. Issues
3. Project website
4. README