Lovable Custom Domain Not Working With Cloudflare? DNS, SSL and Proxy Checks

A Lovable custom domain can fail even when the DNS screen looks “almost right.” The fastest way to fix it is to stop treating domain not working as one problem.

There are at least five layers:

1. The Lovable project is published and knows about the domain.
2. DNS resolves to the intended target.
3. Cloudflare proxying is configured the way the Lovable domain setup expects.
4. HTTPS/TLS is valid.
5. The request reaches the correct app and route.

I use Cloudflare across product and website deployments. One useful debugging rule is that DNS success does not prove application success, and application success does not prove DNS is correct. Test each boundary independently.

1. Confirm the Lovable side first

Before touching Cloudflare, open the project and confirm the custom domain is attached to the correct published project.

Lovable’s current custom-domain documentation says a project needs to be published before the custom domain can serve it. It also provides the DNS record you should create.

Do not copy a CNAME target from somebody else’s tutorial. Use the value Lovable gives your project.

2. Decide whether you are using Cloudflare only for DNS or as a proxy

This distinction matters.

Lovable now explicitly supports using a CDN or reverse proxy such as Cloudflare through an Advanced option labelled along the lines of “Domain uses Cloudflare or a similar proxy.” When enabled, Lovable says you are responsible for configuring and maintaining the proxy.

So first write down your intended architecture:

• DNS only: Cloudflare answers DNS but does not proxy HTTP traffic.
• Proxied: Cloudflare sits between visitors and the Lovable origin.

If you do not know which one you intended, changing the orange/grey cloud repeatedly is guesswork.

3. Inspect the DNS answer, not only the dashboard

Check what the domain actually resolves to publicly.

Look for:

• The correct hostname.
• Duplicate/conflicting A, AAAA or CNAME records.
• An old provider record that was never removed.
• A www record pointing somewhere different from the apex.
• A stale subdomain record from a previous deployment.

The browser error can look like an SSL problem even when DNS is still pointing to an old server.

Lovable says DNS changes can take up to 72 hours to propagate, although most are faster. Rather than simply waiting, query the DNS record and verify whether the new answer is visible from multiple resolvers.

4. Test TLS separately

If DNS is correct but HTTPS fails, inspect certificate state.

Ask:

• Does Lovable show the domain as Live or still verifying?
• Is Cloudflare presenting a certificate for the requested hostname?
• Is the browser receiving a certificate for the wrong origin?
• Is there a redirect loop between HTTP and HTTPS?
• Is a proxy expecting HTTPS to an origin that is not ready for it?

Do not weaken SSL settings just to remove an error screen. Fix the mismatch between the visitor-facing certificate, Cloudflare and the origin.

5. If the homepage works but a direct URL fails, this is probably routing

Suppose example.com loads but example.com/dashboard/settings fails on refresh.

That is no longer primarily a DNS problem. The request reached the domain; the host or application does not know how to serve that route directly.

Test:

• /
• one public nested route;
• one authenticated nested route;
• a refresh on each route;
• a clean/incognito browser session.

This is particularly important because current Lovable projects can use different rendering stacks. Lovable’s SEO/AEO documentation says newer apps use TanStack Start SSR while older React/Vite apps receive prerendering on Lovable-hosted public URLs. If you self-host, your deployment needs to match the stack you actually have.

6. If the domain opens the wrong app, trace ownership

This is one of the easiest problems to misdiagnose.

Check whether the hostname is still connected to:

• an old Lovable project;
• a previous Cloudflare Worker or Pages project;
• another hosting provider;
• a redirect rule;
• a stale DNS record.

A domain can resolve perfectly and still serve the wrong application.

The question is not “is DNS working?” It is which origin owns this hostname now?

7. Change one layer at a time

A bad debugging sequence looks like this:

• change CNAME;
• toggle proxy;
• change SSL mode;
• delete domain in Lovable;
• reconnect domain;
• purge cache;
• change redirects.

Now you have no idea which change mattered.

A better sequence is:

1. Capture current DNS.
2. Confirm Lovable domain configuration.
3. Test the public DNS answer.
4. Test TLS.
5. Test the origin/app.
6. Change the smallest thing that explains the first failed boundary.
7. Re-test before touching the next layer.

That troubleshooting style is something I use across the products I build: preserve evidence and isolate the first disagreement between expected and actual state.

A compact diagnostic table

Before you change a production domain

Record the current working origin and DNS values first. If this domain already receives users, plan how to restore the previous configuration if the cutover fails.

That rollback mindset matters much more than “how fast can I click Connect Domain?”

If the app is also moving from Lovable hosting to Cloudflare Workers, read my Lovable to Cloudflare Workers deployment guide rather than mixing hosting migration and DNS troubleshooting into one step.

If your AI-built product is stuck between Lovable, Cloudflare and a custom domain and every fix creates another error, I help founders map and repair those boundaries. Contact me.

Sources

• Lovable custom domains
• Lovable SEO/AEO and rendering stacks
• Cloudflare Workers deployment docs