How to Redirect Unknown Subdomains to Your Main Domain with Cloudflare

How to Redirect Unknown Subdomains to Your Main Domain with Cloudflare

Redirect Unknown Subdomains to Your Main Domain Using Cloudflare

Topic: Cloudflare DNS & Subdomain Redirects
Use Case: Redirect unknown subdomains to the main domain
Platform: Cloudflare
Method: Wildcard DNS + Redirect Rules
Redirect Type: 301 Redirect


1. The Problem: What Happens When an Unknown Subdomain Is Visited?

When you manage a website with multiple subdomains, you may eventually encounter visitors trying to access a subdomain that you have not created.

For example, imagine your main website is: example.com

You may already have valid subdomains such as:

  • www.example.com
  • api.example.com
  • app.example.com
  • blog.example.com

But someone could enter a random hostname such as:

abc.example.com

If abc.example.com does not represent an actual application, instead of showing a DNS error or an unnecessary error page, you may want to send the visitor back to your main website:

https://example.com

This article explains how to build this setup using Cloudflare DNS and Cloudflare Redirect Rules.

2. The Solution: Wildcard DNS and Cloudflare Redirect Rules

The solution uses two Cloudflare features working together:

  1. A wildcard DNS record catches requests for subdomains that do not have their own DNS record.
  2. A Cloudflare Redirect Rule checks the hostname and redirects unknown subdomains to the main domain.

The important concept is that DNS resolution and HTTP redirection are different things.

A wildcard DNS record makes the hostname reachable through Cloudflare. The Redirect Rule performs the actual HTTP redirect.

In simple terms:

Unknown Subdomain
        ↓
Wildcard DNS
        ↓
Cloudflare Proxy
        ↓
Redirect Rule
        ↓
301 Redirect
        ↓
Main Domain

3. Understanding the Wildcard DNS Record

A wildcard DNS record uses an asterisk (*) as the hostname. It can match subdomains that do not have a more specific DNS record.

For example:

*.example.com

A wildcard record can allow hostnames such as:

  • abc.example.com
  • random.example.com
  • hello.example.com
  • test.example.com

to reach the Cloudflare network.

For this setup, the wildcard DNS record should be configured as a Proxied record.

Make sure the Cloudflare proxy is enabled and the DNS record shows the orange cloud.

4. Create the Wildcard DNS Record in Cloudflare

Log in to your Cloudflare account and select your domain. Then open:

Cloudflare
→ Your Domain
→ DNS
→ Records

Create a DNS record similar to this:

Type Name Target Proxy Status
CNAME * example.com 🟠 Proxied

In other words, your wildcard DNS configuration represents:

*.example.com → example.com

The exact origin configuration can vary depending on whether your website is hosted on a VPS, Cloudflare Pages, Vercel, another hosting provider, or your own infrastructure.

5. Why the Wildcard Record Must Be Proxied

The redirect is performed by Cloudflare's edge network. Therefore, the request needs to pass through the Cloudflare proxy before the Redirect Rule can process it.

If the wildcard DNS record is DNS only, Cloudflare is not acting as the HTTP proxy for that request.

For this reason, the recommended configuration is:

*.example.com
CNAME
example.com
🟠 Proxied
DNS points the hostname toward Cloudflare, while the proxy allows Cloudflare Rules to process the HTTP request.

6. Keep Your Existing Subdomains

Your real applications can continue using their own DNS records.

For example:

www.example.com
api.example.com
app.example.com
blog.example.com

The wildcard record does not mean that all these domains will suddenly redirect to the main website.

Specific DNS records take precedence over the wildcard record.

This allows you to maintain individual subdomains for different services, applications, APIs, dashboards, and websites.

7. Create a Cloudflare Redirect Rule

After configuring the DNS record, open:

Cloudflare
→ Your Domain
→ Rules
→ Redirect Rules
→ Create Rule

Choose:

Create new Single Redirect

This rule will determine which incoming requests should be redirected.

8. Select Custom Filter Expression

Under If incoming requests match..., select:

Custom filter expression

We want to tell Cloudflare:

Redirect the request when the hostname is not one of my valid domains.

This approach gives you explicit control over which subdomains are considered valid.

9. Add the Cloudflare Filter Expression

For the generic example.com configuration, use:

(http.host ne "example.com" and
 http.host ne "www.example.com" and
 http.host ne "api.example.com" and
 http.host ne "app.example.com" and
 http.host ne "blog.example.com")

Here, ne means not equal.

The expression therefore says that the hostname must not be any of the valid hostnames listed above.

As a result:

  • example.com is excluded.
  • www.example.com is excluded.
  • api.example.com is excluded.
  • app.example.com is excluded.
  • blog.example.com is excluded.
  • Unknown subdomains are matched.

10. Real-World Example Using axay.dev

In my actual setup, the main domain is: axay.dev

The existing subdomains include:

axay.dev
coinvoice.axay.dev
todo.axay.dev
www.axay.dev

Therefore, the Cloudflare filter expression can be:

(http.host ne "axay.dev" and
 http.host ne "coinvoice.axay.dev" and
 http.host ne "todo.axay.dev" and
 http.host ne "www.axay.dev")

With this rule, an unknown hostname such as:

https://abc.axay.dev

can be redirected to:

https://axay.dev

11. Configure the Redirect Destination

Under the Then... section, select:

URL redirect
Type: Static

Set the target URL to:

https://example.com

Then select:

301 - Permanent Redirect

A 301 redirect tells browsers and search engines that the requested resource should permanently redirect to another URL.

For this particular setup, a static redirect is appropriate because every unknown subdomain should go to the same destination.

12. Static vs Dynamic Redirect

Cloudflare provides different redirect options. For this use case, you should use a Static redirect.

The configuration should look like:

Type:
Static

Target URL:
https://example.com

Status Code:
301 - Permanent Redirect

You do not need a dynamic wildcard replacement expression because the destination is always your main domain.

In other words, we want:

abc.example.com
random.example.com
hello.example.com
        ↓
https://example.com

13. Should You Preserve the Query String?

Cloudflare also provides a Preserve query string option.

For this use case, you can leave it disabled if you want the unknown hostname to simply redirect to the main domain.

For example:

https://abc.example.com/test?foo=bar
        ↓
https://example.com

If you have a specific reason to preserve query parameters, you can enable the option according to your application's requirements.

14. Deploy the Cloudflare Redirect Rule

Once the configuration is complete, click:

Deploy

Cloudflare may show a warning similar to:

This rule may not apply to your traffic because your DNS configuration may not be proxying traffic for the domain.

If you have already configured the wildcard DNS record and it is 🟠 Proxied, you do not need to create another wildcard record just because this warning appears.

Check your DNS records first. If the wildcard record is already proxied, you can deploy the rule.

15. Complete Cloudflare DNS Configuration

A simplified DNS configuration can look like this:

Type Name Target Proxy
A/CNAME @ Your website/origin 🟠 Proxied
CNAME www Your website/origin 🟠 Proxied
CNAME api Your API/origin 🟠 Proxied
CNAME app Your application/origin 🟠 Proxied
CNAME * example.com 🟠 Proxied

16. How the Complete Request Flow Works

Let's say a visitor enters:

https://abc.example.com

The request follows this flow:

  1. The browser requests abc.example.com.
  2. The wildcard DNS record matches the hostname.
  3. The request reaches Cloudflare through the proxy.
  4. Cloudflare evaluates the Redirect Rule.
  5. The hostname is not in the allowed subdomain list.
  6. Cloudflare returns a 301 response.
  7. The browser follows the redirect to example.com.
abc.example.com
       ↓
Wildcard DNS
       ↓
Cloudflare Proxy
       ↓
Redirect Rule
       ↓
301 Permanent Redirect
       ↓
https://example.com

17. What Happens to Valid Subdomains?

Existing subdomains are excluded from the redirect condition.

For example:

api.example.com
app.example.com
blog.example.com

These hostnames continue to their configured applications instead of being redirected to the main website.

This is especially useful when your domain hosts several services, such as a frontend application, API server, dashboard, documentation website, authentication service, or SaaS application.

18. Adding a New Subdomain in the Future

One important part of this configuration is maintaining your list of valid subdomains.

Imagine that your website currently has:

www.example.com
app.example.com
blog.example.com

Later, you decide to create a new API:

api.example.com

First, create the appropriate DNS record for the new service.

Type: CNAME
Name: api
Target: your-api-server.example
Proxy: 🟠 Proxied

Then update the Cloudflare Redirect Rule and add api.example.com to the allowed hostname list.

Otherwise, the new API hostname could be caught by the unknown subdomain redirect.

19. Example: Creating api.yourdomain.com

Suppose your real domain is:

yourdomain.com

You want to create:

api.yourdomain.com

Your DNS configuration could contain:

api.yourdomain.com
        ↓
CNAME
        ↓
your-api-server.example
        ↓
🟠 Proxied

After creating the new subdomain, update your Redirect Rule:

(http.host ne "yourdomain.com" and
 http.host ne "www.yourdomain.com" and
 http.host ne "app.yourdomain.com" and
 http.host ne "blog.yourdomain.com" and
 http.host ne "api.yourdomain.com")

Now api.yourdomain.com will be treated as a valid application hostname instead of an unknown subdomain.

20. Testing the Unknown Subdomain Redirect

After deploying the Cloudflare rule, test a hostname that does not exist in your list.

https://abc.example.com

The browser should redirect to:

https://example.com

You can also test several random hostnames:

https://random.example.com
https://hello.example.com
https://test.example.com
https://anything.example.com

These should all be redirected to the main domain if they are not included as valid hostnames in your rule.

21. Test Your Existing Subdomains

Do not only test the unknown hostname. It is equally important to verify that your existing services continue to work.

https://www.example.com
https://api.example.com
https://app.example.com
https://blog.example.com

These should continue to their normal destinations and should not redirect to example.com.

22. Does This Cloudflare Rule Make the Website Slow?

For normal visitors using your valid subdomains, this type of Cloudflare redirect rule should add very little overhead.

The rule is evaluated at Cloudflare's edge before the request reaches your origin server.

An unknown subdomain naturally requires an additional request because the browser first requests the unknown hostname and then follows the 301 response.

Unknown Subdomain
        ↓
Cloudflare
        ↓
301 Redirect
        ↓
Main Domain

Your normal websites and applications should continue using their normal Cloudflare and origin infrastructure.

23. Common Mistakes to Avoid

Using DNS as an HTTP Redirect

A DNS record does not itself perform an HTTP redirect. DNS determines where a hostname resolves, while an HTTP redirect tells the browser to navigate to another URL.

Using DNS Only Instead of Proxied

If the wildcard record is not proxied through Cloudflare, the Cloudflare Redirect Rule may not process the request.

Using a Dynamic Redirect Unnecessarily

If every unknown subdomain should redirect to exactly the same destination, a static redirect is simpler.

Forgetting New Subdomains

If you create a new service such as api.example.com later, remember to add it to your valid hostname list.

24. Recommended Configuration Checklist

  • Wildcard DNS: *.example.com
  • DNS Target: example.com
  • Proxy: 🟠 Proxied
  • Cloudflare Rule: Custom filter expression
  • Redirect Type: Static
  • Status Code: 301
  • Destination: https://example.com
  • Existing Subdomains: Excluded from the redirect condition

25. Final Configuration Example

The complete setup can be summarized as follows:

DNS
────────────────────────────────────

*.example.com
CNAME → example.com
🟠 Proxied


Redirect Rule
────────────────────────────────────

IF hostname is NOT:

example.com
www.example.com
api.example.com
app.example.com
blog.example.com

THEN:

301 Permanent Redirect
→ https://example.com

The result is a clean Cloudflare subdomain management setup where unknown hostnames are handled automatically while your existing applications continue working normally.

26. The Complete Example

With this configuration, the following behavior is possible:

Request Result
example.com Website opens normally
www.example.com Website opens normally
api.example.com API opens normally
app.example.com Application opens normally
blog.example.com Blog opens normally
abc.example.com 301 → example.com
random.example.com 301 → example.com
unknown.example.com 301 → example.com

27. Conclusion

A combination of Cloudflare wildcard DNS and Cloudflare Redirect Rules provides a practical way to handle unknown subdomains.

The wildcard DNS record allows Cloudflare to receive requests for otherwise undefined subdomains, while the redirect rule determines whether the hostname should continue to its application or redirect somewhere else.

The most important thing to remember is:

Wildcard DNS handles the hostname. Cloudflare Redirect Rules handle the redirect.

If you later create a new service such as api.yourdomain.com, configure its DNS record and update the valid hostname list in your redirect rule.

For a real-world configuration such as axay.dev, the same approach can be used to keep existing services like coinvoice.axay.dev, todo.axay.dev, and repo.axay.dev working while sending unknown subdomains back to the main website.

Cloudflare DNS & Redirect Rules guide — created as a practical reference for managing wildcard subdomains and HTTP redirects.