Appears when: OAuth redirects to localhost or wrong URL
Supabase uses the requested redirect only when it matches an allowed Redirect URL; otherwise the flow can fall back to the configured Site URL. Align the app’s redirectTo value, Supabase URL configuration, and the provider callback for the exact production origin.
# Document the intended URL chainSeparate the app start URL, provider callback, Supabase callback, and final return path.# Correct Supabase URL configurationSet a production-safe Site URL and add only the approved application redirect patterns.# Generate redirectTo from trusted configurationUse an explicit environment value or validated origin rather than a leftover localhost constant.# Test each environment independentlyVerify preview, production platform URL, and custom domain without broad wildcard allowances.Preserve the current working revision, change one proven boundary, and verify the published path in a clean session.
Inspect the browser request and note the exact protocol, host, port, path, and trailing slash.
What the result tells you: A value generated from a development origin will reliably send production users back to development.
Confirm the requested destination matches an allowed entry and the fallback Site URL is production-safe.
What the result tells you: An unmatched redirect can cause Supabase to use the Site URL instead.
The OAuth provider should allow Supabase’s callback endpoint while Supabase controls the final app redirect.
What the result tells you: Confusing provider callback and application return URL creates loops or wrong destinations.
| Likely cause | What proves it | First safe action |
|---|---|---|
| Site URL still points to localhost | A value generated from a development origin will reliably send production users back to development. | Document the intended URL chain |
| redirectTo is not allowlisted | An unmatched redirect can cause Supabase to use the Site URL instead. | Correct Supabase URL configuration |
| App derives the wrong origin | Confusing provider callback and application return URL creates loops or wrong destinations. | Generate redirectTo from trusted configuration |
| Provider callback is misconfigured | A value generated from a development origin will reliably send production users back to development. | Test each environment independently |
Supabase uses the requested redirect only when it matches an allowed Redirect URL; otherwise the flow can fall back to the configured Site URL. Align the app’s redirectTo value, Supabase URL configuration, and the provider callback for the exact production origin.
The production fallback destination was never updated.
The app requests a production path that does not match the configured redirect entries.
A hard-coded development URL or proxy header creates the redirect value.
Freeze generated changes, restore the last known working version, reproduce one request, collect the browser and platform logs, and change one layer at a time.
The requested value may not match an allowed Redirect URL, so the configured Site URL is used as a safe fallback.
Usually not. The provider calls Supabase, and Supabase then returns the user to an approved app URL.
Prefer narrow patterns for controlled environments. Broad redirect permissions increase the risk of sending sessions to unintended origins.
Free decision aid
Get a senior view of the constraint, the evidence you have, and the next decision that removes the most risk.
No email required for this decision aid. Dismiss once and this popup stays closed for the session.