Cloudflare Wildcard Proxying: What Changed, What Still Matters

For a long time, proxying wildcard subdomains through Cloudflare was an Enterprise-only feature. Free and Pro plan users could create a *.example.com DNS record, but the orange-cloud proxy toggle was locked, all wildcard traffic went straight to your origin server, unprotected.

That changed in May 2022. Cloudflare quietly made wildcard proxying available on all plans, including free. If you were using a clever CNAME workaround to get around this restriction, you can now replace it with a single native record. But there are still a few real limitations worth understanding.

What the Old Workaround Did (And Why It Worked)

Before the May 2022 change, users discovered a way to effectively proxy wildcard traffic by exploiting how Cloudflare handles proxied CNAME chains.

The trick worked like this:

Create a proxied A record for a specific subdomain say, proxy.example.com pointing to your origin IP, with the orange cloud enabled.
Create a wildcard CNAME pointing to that record:
```
*.example.com  CNAME  proxy.example.com
```
Because proxy.example.com was proxied, any request following the CNAME chain through it also passed through Cloudflare’s edge, even though the * record itself wasn’t flagged as proxied in the dashboard.

This worked because Cloudflare’s proxy operates at the network layer, not just on a per-record basis. Traffic that terminates at a proxied endpoint gets proxied regardless of how it got there. The wildcard record just needed to chain to something already behind the orange cloud.

It was a genuine workaround, not a bug, and it worked well enough that many tutorials documented it as standard practice.

How to Do It Now

Since May 2022, you don’t need the workaround. Just add a wildcard record and toggle it to Proxied directly:

Go to your domain’s DNS settings in Cloudflare.
Click Add record.
Set the name to * and the type to A, AAAA, or CNAME.
Enter your origin IP or hostname as the target.
Toggle to Proxied (orange cloud).
Save.

That’s it. Any subdomain not matched by a more specific record will now route through Cloudflare’s network.

What Still Applies: The Real Limitations

The native wildcard proxy feature is solid, but there are a few things that catch people off guard.

SSL Coverage Stops at One Level Deep

Cloudflare’s Universal SSL the free TLS certificate included with every plan, covers:

Your root domain: example.com
First-level subdomains: *.example.com

It does not cover deeper subdomains like tenant.app.example.com. If your wildcard is meant to support a multi-tenant app where hostnames look like clientname.app.example.com, visitors will get SSL certificate errors.

For deeper coverage, you need Advanced Certificate Manager (~$10/month), which enables “Total TLS”, automatic certificate provisioning for any proxied hostname at any subdomain depth.

Specific Records Override the Wildcard

If you have *.example.com proxied and also have a more specific record like staging.example.com as a grey-cloud DNS-only record, the specific record wins. The wildcard only applies where no more specific match exists. This is standard DNS behavior, but it means your wildcard won’t silently take over existing records.

Cloudflare Pages Doesn’t Support Wildcard Custom Domains

If you host on Cloudflare Pages and want to use a wildcard for custom domains (common for SaaS apps), this isn’t supported. You have to add each subdomain individually.

Redirect Loops With “Flexible” SSL Mode

Once you proxy wildcard traffic, Cloudflare sits between visitors and your origin. If your Cloudflare SSL/TLS mode is set to Flexible but your origin server also redirects HTTP to HTTPS, you’ll get ERR_TOO_MANY_REDIRECTS. The fix is to switch to Full or Full (Strict) mode, which requires your origin to have a valid certificate.

If You’re Self-Hosting (No Public IP)

If your server is behind NAT or a firewall with no open inbound ports, the native wildcard A record won’t work, there’s no IP to point to. The modern solution here is Cloudflare Tunnel (cloudflared):

Run the cloudflared daemon on your server.
Set your wildcard CNAME to <tunnel-id>.cfargotunnel.com (proxied).
Configure the tunnel to route incoming hostnames to your local service.

This works on all plans and gives you full wildcard proxying with no open ports, no static IP, and no workarounds required.

The Short Version

What you need	How to do it
Proxy `*.example.com`	Add a proxied `*` record, no workaround needed
SSL for `*.example.com`	Covered by Universal SSL (free)
SSL for `*.sub.example.com`	Requires Advanced Certificate Manager
Wildcard on Cloudflare Pages	Not supported, add subdomains individually
Wildcard with no public IP	Use Cloudflare Tunnel

The old CNAME trick is worth knowing as a piece of DNS history, and it’s a good example of how proxied CNAME chaining actually works under the hood. But if you’re setting up wildcard proxying today, use the native feature, it’s simpler and fully supported.