servd

Documentation

Documentation > Domains & SSL >

Subdomain Routing to Another Hosting Provider

If you've pointed a subdomain of one of your Primary Domains at Servd, but visitors are seeing a different website, an error page from another hosting provider, or an SSL warning, it's likely that another platform is still claiming that subdomain.

This page explains why this happens, how to work out what's responding instead of Servd, and how to fix it.

Why This Happens #

Servd's ingress platform uses Cloudflare as the entry point for all traffic heading to your project. Many other hosting providers, website builders and online services use the same Cloudflare functionality to serve their customers' custom domains.

When a request reaches Cloudflare, it decides where to send it based on the hostname being requested, not the IP address your DNS records point to. So even when your DNS records point at Servd, if another Cloudflare-based platform also has your hostname registered, Cloudflare has to choose between us.

Cloudflare always prefers the most specific match. Primary Domains on Servd can be created either as wildcards (the default) or as an exact, non-wildcard match. When you add example.com as a wildcard Primary Domain we register both example.com and *.example.com. If another platform has store.example.com registered specifically, that registration is a closer match than our *.example.com wildcard, and Cloudflare will send the traffic to them instead of us.

This most commonly happens when:

  • The subdomain was previously connected to another platform (an online store, landing page builder, help centre, status page, previous host etc.) and was never removed from that platform's settings.
  • Your domain's DNS is hosted in a Cloudflare account which has its own configuration for the subdomain.

The domain you entered when creating a Primary Domain (e.g. example.com) is always registered with us as an exact match, whether or not wildcard support is enabled. This problem almost always affects subdomains which are only covered by a wildcard Primary Domain.

Before You Start #

It's worth ruling out a few simpler causes first:

1. Check the subdomain is covered by a Primary Domain. Wildcard Primary Domains cover one level of subdomains, so store.example.com is covered by a wildcard example.com Primary Domain, but shop.store.example.com is not. Primary Domains created with wildcard support disabled don't cover any subdomains, so each subdomain needs to be registered separately.

2. Check your Primary Domain is fully activated. Both Ownership and SSL should be showing as green on your project's Domains page.

3. Check your Routing Rules. Click "Show X Routing Rules" beneath your Primary Domain and make sure there isn't a rule redirecting the subdomain somewhere else.

4. Check your DNS records match exactly. Click the "DNS" button next to your Primary Domain in the Servd dashboard and compare the values to the records you've created for the subdomain. You can check what the rest of the world sees using a tool such as whatsmydns.net, or by running:

dig +short store.example.com

If you've recently changed your DNS records, allow time for the change to propagate based on the record's previous TTL.

If all of the above look correct, continue below.

Step 1: Work Out What's Responding #

Start by checking the headers returned by the broken subdomain, and compare them to a subdomain or Primary Domain that is working correctly on Servd:

curl -s -o /dev/null -D - https://store.example.com
curl -s -o /dev/null -D - https://www.example.com

Note that server: cloudflare will appear in responses from both Servd and any other Cloudflare-based platform, so it doesn't tell you much on its own. Instead, look for differences between the two responses such as platform-specific headers or cookie names. The content of the page itself (error page branding, a "domain not found" message etc.) will often tell you which platform is responding.

Next, check which SSL certificate is being presented. You can do this by clicking the padlock icon in your browser's address bar and viewing the certificate details, or by running:

openssl s_client -connect store.example.com:443 -servername store.example.com </dev/null 2>/dev/null \
 | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

The certificate Servd generates for a wildcard Primary Domain covers both example.com and *.example.com. If the certificate being presented lists store.example.com on its own, it has been issued for someone else's registration of that exact subdomain. This is a strong sign that you're dealing with Cause 1. Note: If you've attached a Custom SSL Certificate to your Primary Domain, compare against that certificate instead.

Finally, check where your domain's DNS is hosted:

dig +short NS example.com

If the results end in ns.cloudflare.com, your domain's DNS is managed within a Cloudflare account and you should also check Cause 2.

Cause 1: Another Platform Still Has the Subdomain Registered #

This is the most common cause. It's likely if the subdomain (or the whole domain) has ever been connected to another website platform or hosting provider, even if that was a long time ago or was set up by a different agency.

  1. Use the information from Step 1, and any history you have for the domain, to identify which platform is responding.

  2. Log into that platform and remove the custom domain or subdomain from its settings entirely. Changing your DNS records away from the platform is not enough. The domain needs to be deleted from the platform's own settings.

  3. If you no longer have access to the platform (e.g. the account has been cancelled, or it belongs to a previous agency), contact that platform's support team and ask them to remove the custom hostname for your subdomain from their configuration. It can help to mention that the hostname is registered in their Cloudflare for SaaS setup, as this tells them exactly where to look.

  4. Once the registration has been removed, re-run the checks in Step 1.

  5. Traffic for the subdomain should now reach Servd.

If you're unable to get the other registration removed, see Registering the Subdomain Explicitly below.

Cause 2: Your Domain's Own Cloudflare Account Is Claiming the Subdomain #

If your domain's DNS is hosted on Cloudflare, Cloudflare gives your own account's configuration priority over wildcard registrations like ours. This means settings in your Cloudflare account can prevent traffic from reaching Servd, even when your DNS record for the subdomain looks correct.

In this situation you'll often see a Cloudflare error page (such as Error 1000, 1014 or 1016) or content from an old origin server, rather than a completely unfamiliar website.

  1. Visit the DNS page for your domain within your Cloudflare account and find the record for the subdomain.

  2. If the record is proxied (orange cloud), make sure its value matches one of the values shown in the "DNS" modal in the Servd dashboard exactly. A CNAME which eventually resolves to one of our values, but doesn't match it directly, will not work. See Migrating A Cloudflare Proxied Domain for more details.

  3. Check for any other configuration in your Cloudflare account which could match the subdomain and send its traffic elsewhere. Common examples include:

       - Proxied wildcard DNS records (* or *.example.com)
       - Workers routes
       - Redirect Rules, Page Rules or Origin Rules

  4. If the record is set to DNS Only (grey cloud), points to Servd's values, and traffic still isn't reaching us, Cloudflare may be giving your account's configuration for the domain priority over our wildcard even though there's no matching proxied record. In this case, see Registering the Subdomain Explicitly below.

Registering the Subdomain Explicitly #

If you can't remove the conflicting configuration, registering the subdomain with Servd directly gives us an exact match for it. Cloudflare treats exact matches as higher priority than wildcards, so in most cases this is enough to route traffic to Servd.

You can do this alongside your existing wildcard Primary Domain. There's no need to remove or change it.

  1. Visit your project's Domains page in the Servd dashboard.

  2. If required, use the Additional Primary Domains addon to increase the project's primary domain limit.

  3. Use the "Add a Primary Domain" form to add the subdomain itself (e.g. store.example.com).

  4. Open the Advanced Options and disable wildcard support, so that only the exact subdomain is registered.

  5. Click Add, then activate the new Primary Domain by completing the Ownership and SSL steps as described in Activating Your Primary Domain.

  6. If the subdomain was being sent to a specific environment or redirect using a Routing Rule on the parent Primary Domain, set the same environment or redirect on the new Primary Domain, then run a Sync.

  7. Once the new Primary Domain is active, re-run the checks in Step 1 to confirm traffic is reaching Servd.

Only disable wildcard support on the new Primary Domain. Your existing example.com Primary Domain should stay as a wildcard so it continues to cover your other subdomains, such as www.example.com.

Still Stuck? #

Reach out via our live chat or drop an email to support@servd.host. To help us get to the bottom of it quickly, please include:

- The subdomain that isn't reaching Servd
- The output of the curl, openssl and dig commands from Step 1
- A screenshot or description of what you see when visiting the subdomain in a browser
- Whether the subdomain (or domain) has previously been used with any other platform or hosting provider