What is your goal?
We cannot create or reauthorize a Google / Google Sheets connection on an EU2 org.
What is the problem & what have you tried?
What happens:
- From EU2, use Reauthorize on the existing Google connection, or add a new Google Sheets connection.
- Google sign-in succeeds.
- Browser lands on https://www.make.com/oauth/cb/google/?state=… and shows plain text Resource not found (HTTP 404).
- Make stays on Waiting for authorization… and the connection never saves.
This failed the same way for both Reauthorize and a brand-new Google Sheets connection. Scenario host is EU2; OAuth callback host is global www.make.com.
Has anyone hit EU2 → www OAuth callback 404 for Google Sheets, and is there a workaround without moving the org off EU2?
Error messages or input/output bundles
Attach if UI allows: /workspace/make-oauth-404-capture.png
Screenshots (scenario flow, module settings, errors)
The detail that matters is in your own report: the callback host is www.make.com while your org lives on EU2. Make’s OAuth callbacks are zone-scoped, so a connection started on an EU2 org has to return to eu2.make.com. Landing on www.make.com/oauth/cb/google with a plain-text 404 is consistent with the callback arriving at a host that holds no record of your pending authorization - which is also why Make sits on Waiting for authorization indefinitely. It is still waiting for a callback that went somewhere else.
Three things worth eliminating before you call it a platform bug, because each can rewrite that host.
Start the flow from https://eu2.make.com typed into the address bar, not from a bookmark or an old tab. If you began on www.make.com and were redirected into EU2 after login, the session can carry the wrong origin.
Log out of every Make session first, including any second org on a different zone open in another tab. Mixed sessions across zones are a common way to get a callback aimed at the wrong host.
Check whether something is rewriting URLs: a corporate proxy, a DNS filter, an SSO portal, or an extension that strips subdomains. Try it once on a completely different network, a phone hotspot is easiest. If it works there, you have found it and it is not Make.
If it still lands on www after all three, it is out of your hands and it is a routing bug on their side. Two things make that ticket stick: the full callback URL including the state parameter, and the fact that it reproduces on both a reauthorize and a brand-new connection, which rules out a stale stored connection. State plainly that the org is EU2 and the callback host is www - put like that it is hard to bounce back as reconnect and try again.
One stopgap meanwhile: if the scenario only needs to read or write a sheet, a Google service account with the sheet shared to its address skips the OAuth round trip entirely. Not a fix, but it can keep something running.
Kane - Northpeak Automation
The fact that both Reauthorize and a completely new Google Sheets connection fail at the same OAuth callback URL makes this look more like an EU2 OAuth/callback issue than a Google Sheets configuration problem.
Since the scenario is hosted on EU2 but the callback is landing on the global Make domain and returning 404, I’d avoid changing the scenario itself until the connection path is confirmed.
Have you already had Make Support verify whether Google OAuth callbacks are currently working correctly for EU2 organizations?
