Cloudflare Workers assigns a workers.dev domain by default.
It works, but accessing it from mainland China can sometimes be unstable. Some projects use workers.dev directly as their entry point, making latency and availability a matter of luck.
Here is a common workaround: instead of using the default workers.dev, use your own domain, CNAME it to a Cloudflare optimized domain, and finally catch the requests using Workers routing.
Simply put:
用户 -> 你的域名 -> 优选域名对应的 Cloudflare 节点 -> Workers 路由 -> 你的 WorkerThis isn't magic acceleration, nor does it guarantee the fastest speeds forever. It just changes the entry point to a more suitable Cloudflare node.
When to Use This
This guide is best suited for the following situations:
- You already have a functioning Worker.
- The default
workers.deventry point is unstable in your network. - You have your own domain, and it is already hosted on Cloudflare.
- You want to specify an optimized entry point yourself, rather than using Cloudflare's automatically generated binding method.
If you just want to bind a regular domain to your Worker without messing with optimized domains, using Custom Domains directly is much simpler.
Conclusion First
This guide uses Workers Routes, not Custom Domains.
The reason is simple:
- Custom Domains will cause Cloudflare to automatically create DNS records.
- However, here we need to manually CNAME the domain to an optimized domain.
- Therefore, a Workers Route like
domain/*is much more suitable.
If you are just deploying a Worker normally without setting up an optimized domain, using Custom Domains is easier.
If you want to specify your own optimized entry point, using routes is more appropriate.
Prerequisites
You will need the following:
| Item | Description |
|---|---|
| Cloudflare account | To deploy the Worker |
| A domain hosted on Cloudflare | e.g., example.com |
| A deployed Worker | Ensure the Worker itself is accessible first |
| An optimized domain | e.g., a Cloudflare optimized domain maintained by others, or one you tested yourself |
In our examples, we assume:
Worker 名称：my-worker
你的域名：wk.example.com
优选域名：cloudflare.example.netReplace these with your own when following along.
Final Result
Once finished, you will access your own domain:
https://wk.example.comThe request will first go to the Cloudflare node corresponding to your optimized domain, and then be handed over to the target Worker by the Workers Route. Normal visits, API paths, and static resource paths should all be caught by the same Worker.
Step 1: Verify the Worker is Functioning Normally
Don't rush to change your DNS just yet.
Open the default Worker address:
https://my-worker.<你的 workers.dev 子域>.workers.devProceed only if it returns content normally.
If the default address doesn't even load, fix the Worker first. Otherwise, adding DNS and routing later will only make things more confusing.
You can also test it via command line:
curl -I https://my-worker.<你的 workers.dev 子域>.workers.devAs long as you get a normal HTTP status code, you're good.
Step 2: Add DNS Records
Go to the Cloudflare dashboard and select your domain example.com.
Add a DNS record:
| Type | Name | Target | Proxy status |
|---|---|---|---|
| CNAME | wk |
cloudflare.example.net |
DNS only |
The key here is to select DNS only (the gray cloud) for the proxy status.
Do not enable the proxy.
If you enable the proxy, Cloudflare will process it using its standard proxy logic, and the entry point may not be the optimized domain you want. Many people make a mistake here.
After adding it, your domain should be:
wk.example.comStep 3: Add Workers Route
Go to the Cloudflare dashboard:
Workers 和 Pages -> 你的 Worker -> 设置 -> 域和路由Add a route:
wk.example.com/*Then select your project for the Worker, such as my-worker.
The /* here cannot be omitted.
If you don't add it, the route will only match the root path, and many APIs, static resources, and sub-paths will just break.
Step 4: Test Access
Open in your browser:
https://wk.example.comTest via command line:
curl -I https://wk.example.comIf your Worker has API paths, test those too:
curl -I https://wk.example.com/apiDon't just test the homepage. Many projects load fine on the homepage, but API paths aren't caught by the route, which you only discover later.
How to Verify It's Working
First, check the DNS:
nslookup wk.example.comOr:
dig wk.example.comNormally, you should see it eventually pointing to the optimized domain you set.
Then test HTTPS:
curl -I https://wk.example.comIf it returns the response from your Worker, it means the route is also working.
Frequently Asked Questions
1. Returning a 404 Error
This is most likely because the route is not configured correctly.
Check:
wk.example.com/*Verify the domain name, the asterisk, and the slash.
2. DNS Resolves, but Worker Doesn't Respond
DNS only brings the request to the Cloudflare node.
Whether the Worker executes depends on the Workers Route. Go to "Domains & Routes" to check if the route is bound to the correct Worker.
3. HTTPS Certificate Error
Wait a little while first.
If it still doesn't work, check if the domain is properly hosted in Cloudflare and if the DNS records are typed correctly.
Also, don't randomly use domains that don't belong to you. That's not how certificates and routing work.
4. Optimized Domain Suddenly Slows Down
This is normal.
"Optimization" is not an absolute truth; it just tested well at the moment. Networks change, and nodes change too.
There are only two solutions:
- Switch to a different optimized domain.
- Run speed tests yourself regularly.
5. Is the Free Quota Enough?
It is generally enough for regular personal projects.
The Cloudflare Workers free plan has daily request limits and CPU time limits. Lightweight APIs, redirect pages, and small tools usually have no issues.
But if you are using it for high-traffic downloads or reverse proxying a bunch of things, don't expect to free-ride indefinitely. You'll hit the limits sooner or later.
Choosing Between Routes and Custom Domains
Keep it simple:
| Scenario | Which to choose |
|---|---|
| Normally binding your own domain | Custom Domain |
| Needing to manually CNAME to an optimized domain | Route |
| Worker is the entry point for a full app | Custom Domain |
| Want to preserve your own DNS pointing logic | Route |
I'm using routing here not because it's more advanced, but simply because it fits the "optimized domain" approach.
A Complete Example
Assuming:
Worker：my-worker
域名：example.com
入口：wk.example.com
优选域名：cloudflare.example.netDNS:
CNAME wk cloudflare.example.net 仅 DNS 解析Workers Route:
wk.example.com/*Access:
https://wk.example.comIf it returns the Worker content, you're done.
Final Thoughts
This solution is suitable when you already have a Worker project but the default entry point access is unstable.
Don't overhype it. An optimized domain just changes the entry point; it won't make a poorly built project fast, nor will it fix code issues within the Worker itself.
Make sure the Worker works normally first, then change the DNS, and then bind the route. Following this order prevents things from getting messy.