Supabase Project Healthy but API URL Returns NXDOMAIN

[gim934740-maker]

Hello Supabase Community,

I’m experiencing a DNS resolution issue with my Supabase project.

Project Information

• Project Name: ONEPAGE
• Project Reference: sqfytwcxfmnqueyfmvyz
• Region: ap-northeast-2 (Seoul)
• Plan: Free
• Project URL: https://sqfytwcxfmnqueyfmvyz.supabase.co

Problem

My project appears healthy in the Supabase Dashboard, but its public API hostname cannot be resolved.

When attempting Google OAuth authentication from my Vercel-hosted application, the browser displays:

DNS_PROBE_FINISHED_NXDOMAIN

Troubleshooting Already Completed

• Confirmed the project ID and URL match the Supabase Dashboard.
• Verified the Vercel environment variable configuration.
• Redeployed the application.
• Tested from Windows and iPhone.
• Tested using both Wi-Fi and LTE.
• Queried Google Public DNS, which returned Status 3 (NXDOMAIN).
• Confirmed that the project dashboard and Data API settings are accessible.

The problem persists.

Support Ticket

I have already submitted a support request: SU-507495.

Request

Could someone help determine why this project’s public hostname is not resolving?

Is there a problem with DNS provisioning or the API hostname for this project?

If this requires an internal DNS repair or reprovisioning, could the Supabase team advise on the appropriate next steps?

Thank you for your help.

[DYNOSuprovo]

Here is why this occurs and the fastest way to resolve it without waiting on support:

Root Cause

In Supabase's infrastructure, the database compute container and the public edge routing (<project-ref>.supabase.co) are managed by separate provisioning tasks:

1. Database Health: Your PostgreSQL database container has successfully booted in ap-northeast-2 and reports healthy to the Supabase management control plane (which is why the dashboard shows green and the Table Editor / SQL Editor work).
2. Edge DNS Record: The public hostname https://sqfytwcxfmnqueyfmvyz.supabase.co requires a DNS CNAME record in AWS Route 53 pointing to the regional Kong API Gateway ingress. During project creation or unshelving, if the Route 53 API hook experienced a transient timeout or desync, the DNS record was never published to authoritative nameservers.
3. This is why public DNS (8.8.8.8 / 1.1.1.1) returns NXDOMAIN (Status 3: Non-Existent Domain) despite the backend container being alive.

---

Recommended Self-Serve Fix: Trigger Control-Plane Reconciliation

You can usually force Supabase to re-publish the missing DNS record through the dashboard:

1. Navigate to Project Settings > General.
2. Scroll to the bottom and click Pause project (or Restart project if available on your plan).
3. Wait 1–2 minutes until the status shows Paused.
4. Click Resume project.

Why this works: The pause/resume lifecycle triggers the full provisioning reconciliation pipeline. When the project transitions from PAUSED back to ACTIVE_HEALTHY, the orchestrator re-runs the ingress attachment and publishes the Route 53 CNAME for sqfytwcxfmnqueyfmvyz.supabase.co.

---

Verification

Once resumed, test the hostname from your terminal:

nslookup sqfytwcxfmnqueyfmvyz.supabase.co 8.8.8.8

Or using curl:

curl -I https://sqfytwcxfmnqueyfmvyz.supabase.co/rest/v1/

You should receive an HTTP 401 Unauthorized (indicating the Kong API gateway is alive and awaiting your apikey).

---

If Pause/Resume Does Not Resolve It

Since you already have support ticket SU-507495 open, if the pause/resume cycle does not bind the DNS record within 10–15 minutes:

• Update your ticket noting that a project restart was attempted and 8.8.8.8 still reports NXDOMAIN.
• A Supabase engineer can trigger an internal DNS resync hook on tenant sqfytwcxfmnqueyfmvyz to re-bind the Route 53 zone manually.

[Mohamedaloubaido]

Since Google Public DNS also returns NXDOMAIN, and you reproduced this across unrelated networks/devices, this is happening before Vercel, OAuth, TLS, or your application code are involved.

Supabase's own NXDOMAIN troubleshooting guide narrows the usual causes down to:

• an incorrect project reference,
• a paused project,
• a deleted project,
• or a DNS/network-specific resolver problem.

From the information you provided, those appear to be largely ruled out: the project reference matches the Dashboard, the project is shown as healthy/active, and public DNS fails from multiple networks.

At this point I would treat this as a project-hostname provisioning/DNS issue on the Supabase side rather than an application configuration issue.

I would not pause the project just to try to repair DNS unless Supabase Support specifically recommends it. A paused project itself intentionally stops serving the hostname, so pause/resume is not documented as the normal repair procedure for this case.

Since you already opened ticket SU-507495, I would update it with:

Project ref: sqfytwcxfmnqueyfmvyz
Hostname: sqfytwcxfmnqueyfmvyz.supabase.co
Dashboard status: Healthy / Active
Google DNS: NXDOMAIN
Networks tested: Wi-Fi + LTE
Devices tested: Windows + iPhone

It would also help to attach the output of:

nslookup sqfytwcxfmnqueyfmvyz.supabase.co 8.8.8.8

and, if available:

dig +trace sqfytwcxfmnqueyfmvyz.supabase.co

That gives Support evidence that the failure is at DNS resolution rather than at the API gateway or application layer.

Given that the project itself remains accessible in the Dashboard while the canonical <project-ref>.supabase.co hostname returns NXDOMAIN publicly, I don't think there is anything meaningful to fix in Vercel or the Google OAuth configuration until the hostname resolves again.

[yos88da]

You've already ruled out the usual app-side causes, which is the hard part. Because the browser fails at name lookup, nothing in Google's OAuth client, your Vercel settings or the Redirect URLs list can fix it until the project hostname resolves. I'd leave those alone so you don't create a second problem.

Supabase's NXDOMAIN guide lists the causes in order: a mistyped project ref, a paused project, a deleted project, a resolver-specific problem, and custom-domain DNS: https://supabase.com/docs/guides/troubleshooting/nxdomain-error-connecting-to-a-supabase-project. You've covered most of them. The guide's last step, if none apply, is a ticket with the exact hostname, the error and the networks you tested.

On the pause-and-resume advice above: the docs say a paused project stops serving its hostname, so I would not pause a live project unless Supabase support tells you to. Put your test matrix in the ticket (which resolvers, which networks, UTC time), and link the other open NXDOMAIN threads so they see it is not only your project.

Meanwhile, if your sign-in button just fails, a visible message beats a dead click. Prompt for your AI builder: "When the Google sign-in request fails with a network error, show 'Sign-in is temporarily unavailable. Please try again in a few minutes.' on the page instead of failing silently. Do not change any auth settings, keys or redirect URLs."

[gim934740-maker]

Hello Supabase Support Team, I am following up on ticket SU-507495 regarding a DNS resolution issue affecting my Supabase project. Project reference: sqfytwcxfmnqueyfmvyz Affected hostname: sqfytwcxfmnqueyfmvyz.supabase.co The project appears Healthy / Active in the Supabase dashboard, but the public hostname returns NXDOMAIN when queried through Google Public DNS (8.8.8.8). The issue has also been reproduced across different networks (Wi-Fi and LTE) and devices (Windows and iPhone). Based on these findings, could you please investigate whether there is an issue with the project’s public hostname provisioning or DNS records? I have not paused or restarted the project because I would like to avoid unnecessary disruption. Please let me know if you need additional diagnostic information or if the DNS records can be checked and restored on your side. Thank you. 2026년 10월 20일 (화) 15:25, yos88da ***@***.***>님이 작성:

…

You've already ruled out the usual app-side causes, which is the hard part. Because the browser fails at name lookup, nothing in Google's OAuth client, your Vercel settings or the Redirect URLs list can fix it until the project hostname resolves. I'd leave those alone so you don't create a second problem. Supabase's NXDOMAIN guide lists the causes in order: a mistyped project ref, a paused project, a deleted project, a resolver-specific problem, and custom-domain DNS: https://supabase.com/docs/guides/troubleshooting/nxdomain-error-connecting-to-a-supabase-project. You've covered most of them. The guide's last step, if none apply, is a ticket with the exact hostname, the error and the networks you tested. On the pause-and-resume advice above: the docs say a paused project stops serving its hostname, so I would not pause a live project unless Supabase support tells you to. Put your test matrix in the ticket (which resolvers, which networks, UTC time), and link the other open NXDOMAIN threads so they see it is not only your project. Meanwhile, if your sign-in button just fails, a visible message beats a dead click. Prompt for your AI builder: "When the Google sign-in request fails with a network error, show 'Sign-in is temporarily unavailable. Please try again in a few minutes.' on the page instead of failing silently. Do not change any auth settings, keys or redirect URLs." — Reply to this email directly, view it on GitHub <#51752?email_source=notifications&email_token=CRFBFZFXVE564RZHDBPPF5D5U4ANRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJQGYZDCNZXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-19062177>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CRFBFZCRBURUV6CGHFWPFI35U4ANRAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMJQGE4TAMJSUF3AE> . You are receiving this because you authored the thread.Message ID: ***@***.***>