Active Supabase project hostname returns NXDOMAIN – API/Auth unreachable

[sharonyoktan-create]

Hello,

I have an active Supabase project whose project hostname is returning NXDOMAIN.

Project ref:
ecmuivcllnebehngccgt

Hostname:
ecmuivcllnebehngccgt.supabase.co

Error:
DNS_PROBE_FINISHED_NXDOMAIN

What I have verified:

• The project is active in the Supabase Dashboard.
• The database and SQL Editor are working.
• google.com resolves normally.
• supabase.co resolves normally.
• Only this project's hostname fails to resolve.
• nslookup for the project hostname returns "Non-existent domain".
• I also tested using external DNS resolvers 8.8.8.8 and 1.1.1.1.
• The hostname is therefore unreachable by the application, blocking Supabase Auth/API access.
• The Dashboard still shows the project as active.

I already opened Supabase support request:
SU-460953

Could someone from Supabase please check whether the DNS record/provisioning for this project hostname is missing or broken and reprovision it if necessary?

IMPORTANT: The project contains existing application data. Please do not delete, reset, or recreate the project/database.

Thank you.

[somuai]

Root Cause & Immediate Recovery Steps for NXDOMAIN on Project Hostname

When a Supabase project is active and the SQL editor / Database works, but [ref].supabase.co returns NXDOMAIN, the issue is located at the Cloudflare Tenant Edge Routing / Kong Gateway DNS sync rather than your actual database cluster.

Here is what is happening under the hood and how to maintain application availability while Support processes ticket SU-460953:

---

1. Architectural Distinction (Why Database Works but API Fails)

• Direct Database / SQL Editor: Routes via the internal Supavisor connection pooler (aws-0-[region].pooler.supabase.com or db.[ref].supabase.co). Your Postgres data, tables, schemas, and WAL logs are completely safe and running.
• API / Auth Subdomain ([ref].supabase.co): Routes via Cloudflare Custom Hostname edge proxies to the Kong API gateway. If the edge SSL/DNS registration mapping between AWS/GCP and Cloudflare drops, public DNS authoritative nameservers return NXDOMAIN for the API subdomain.

---

2. Immediate Workarounds to Keep Application Running

If your backend or server-side services (Next.js server actions, Express, Fastify, Go/Python backends) need immediate database access, you can connect directly via the pooler:

• Direct Connection Pooler (Port 6543 / 5432):

DATABASE_URL="postgres://postgres.[PROJECT_REF]:[YOUR-PASSWORD]@aws-0-[REGION].pooler.supabase.com:6543/postgres?pgbouncer=true"
DIRECT_URL="postgres://postgres.[PROJECT_REF]:[YOUR-PASSWORD]@aws-0-[REGION].pooler.supabase.com:5432/postgres"

This allows ORMs (Prisma, Drizzle, Kysely, TypeORM) and direct PostgreSQL clients to continue functioning with zero dependency on the [ref].supabase.co DNS record.

---

3. Safe Dashboard Action to Force Infrastructure Re-Sync (No Data Loss)

You can prompt the Supabase infrastructure orchestrator to re-issue the Cloudflare edge mapping without touching database data:

1. Go to Project Settings -> General.
2. Click Restart Project (or Fast Reboot).
   • Note: A project restart only cycles the container runtime services (Kong, GoTrue, PostgREST, Realtime, Storage) and triggers the infrastructure API to re-announce the hostname to Cloudflare. It does NOT erase or reset your PostgreSQL database volume.
   • Caution: Do NOT click "Reset Database" or delete the project.

Once the orchestrator cycles, verify the hostname resolution with:

nslookup ecmuivcllnebehngccgt.supabase.co 8.8.8.8

Support on ticket SU-460953 can also manually trigger the Cloudflare edge hostname reprovisioning if the automated sync gets stuck in a stale state.