Supabase Auth Google OAuth upstream connection error

[gquan9838]

Hi Supabase Support Team,

I’m experiencing an intermittent issue with Google OAuth login in one of my Supabase projects.

When users tried to sign in with Google, the browser showed the following error:

upstream connect error or disconnect/reset before headers. retried and the latest reset reason: remote connection failure, transport failure reason: delayed connect error: 111

After I restarted the Supabase project/server, Google login started working normally again.

This suggests the OAuth configuration itself may be correct, but the Auth service or an upstream/internal service may have been temporarily unavailable or refusing connections.

I checked the Supabase Logs & Analytics section under Auth. Around the working login flow, I can see entries such as:

/authorize | Redirecting to external provider
/authorize | request completed
/callback | request completed
/token | request completed
Login
/user | request completed

I also noticed some Auth log entries like:

/user | 403: invalid claim: missing sub claim

Could you please help investigate whether there was an issue with the Auth service, internal routing, upstream connectivity, or service health for this project around the time the error occurred?

[AlexLimaTKZ]

Hi! I think there are probably two separate issues in the logs here.

The first one:

upstream connect error or disconnect/reset before headers
...
delayed connect error: 111

looks much more like an upstream connectivity/service-health problem than a Google OAuth configuration problem.

111 is effectively a connection-refused condition: the gateway/proxy tried to connect to an upstream service, but the connection could not be established before an HTTP response was produced.

That would also explain why restarting the project restored Google login without changing any OAuth configuration.

A wrong Google client ID, secret or redirect URI would normally result in an OAuth/provider-level error rather than an upstream connection failure before headers.

The other log entry:

/user | 403: invalid claim: missing sub claim

is likely a different issue.

Supabase Auth returns this when /user receives a JWT whose claims do not contain a sub value.

This can happen, for example, if:

an API/anon key is accidentally being used where a user's access token is expected;
getUser() is called before an authenticated session exists;
a server-side request is not forwarding the user's session JWT correctly.

So I wouldn't use that missing sub log as evidence that Google OAuth itself caused the upstream failure.

What I would check if this happens again:

Record the exact UTC timestamp, project region and project reference.
Check whether /authorize is reached at all during the failure.
Check whether the request ever reaches /callback.
Compare the timestamp with the Supabase status page.
Verify that calls to getUser() are using the actual authenticated user's access token, not an API key.
If the same upstream 111 error returns, open a Supabase support ticket with the timestamp/region/project ref, because that part likely requires platform-side logs to diagnose.

Since restarting the project fixed it without any OAuth configuration changes, I would treat the restart as a recovery from an unhealthy upstream/Auth service, rather than as the root fix.

There have also been other Supabase reports with the same delayed connect error: 111 pattern during Auth/service availability problems, so this does not appear to be unique to Google OAuth.

If you still have the timestamp and region from the incident, those would probably be the most useful details for Supabase staff to trace it internally.