OAuth Redirect Points to localhost: Fixing Google/Microsoft Credentials

When n8n shows the error redirect_uri_mismatch while connecting a Google or Microsoft account, or when you suddenly land on http://localhost:5678/... after clicking "Sign in", this is almost always because n8n is still building the callback address for the OAuth login from the default values localhost and port 5678 instead of from your actual public domain. Google or Microsoft compare this redirect URI sent by the n8n server with the list you have stored in the Google Cloud Console or in the Microsoft app registration, and reject the login as soon as the two do not match exactly. The solution is to correctly set the environment variables N8N_HOST, N8N_PROTOCOL and above all WEBHOOK_URL or N8N_EDITOR_BASE_URL to the public domain, and then enter the redirect URI shown in the n8n credential form unchanged with the OAuth provider. As of: July 2026.

Why does n8n build the redirect URI from localhost in the first place?

By default, n8n automatically calculates editor and webhook addresses from three variables, and without your own configuration, according to the n8n documentation on the deployment environment variables the default values apply: http as N8N_PROTOCOL, localhost as N8N_HOST and 5678 as N8N_PORT. As long as you only test n8n locally on your own computer, this is not a problem, because the browser actually accesses it via localhost. However, as soon as n8n runs on a server, in Docker or behind a reverse proxy, Google or Microsoft still access the same automatically calculated localhost value, because n8n does not know from the outside under which domain it is actually reachable.

How do you correctly set N8N_HOST, WEBHOOK_URL and N8N_EDITOR_BASE_URL?

The most reliable solution is to manually set WEBHOOK_URL to the full public domain, because according to the n8n documentation on webhook configuration behind a reverse proxy this variable overrides the entire automatically calculated URL and is shown both in the editor and registered with external services.

• WEBHOOK_URL: set the full public address with a trailing slash, for example https://n8n.yourdomain.com/, so that n8n uses this domain instead of localhost.
• N8N_HOST: set to the plain domain without protocol, for example n8n.yourdomain.com, since n8n uses this value together with N8N_PROTOCOL and N8N_PORT for the automatic URL calculation.
• N8N_PROTOCOL: set to https as soon as your server is reachable via SSL, since the default value according to the documentation is http.
• N8N_EDITOR_BASE_URL: the public URL under which users reach the editor; according to the documentation it is additionally used for emails from n8n and as the redirect URL for SAML login.
• N8N_PROXY_HOPS: set to 1 if a reverse proxy is in front of it, so that n8n correctly evaluates the forwarding headers.

After setting these variables, the n8n process or container must be restarted, since n8n only reads environment variables at startup.

How do you specifically fix the redirect_uri_mismatch error?

The error occurs because n8n sends a redirect_uri parameter to Google or Microsoft when starting the OAuth flow that does not match the redirect URI stored with the provider, which is why you must manually align both sides. After restarting n8n, open the affected credential again and have the current OAuth redirect URL displayed, which n8n builds under the path /rest/oauth2-credential/callback. Copy this address unchanged into the list of authorized redirect URIs of your Google OAuth client or your Microsoft app registration and save it there. For Google connections, the n8n documentation on Google Drive issues explicitly points out that N8N_EDITOR_BASE_URL and WEBHOOK_URL should use fully qualified domains in order to avoid exactly this redirect URI mismatch. Then reconnect the credential in n8n so that the updated token is retrieved.

What else applies when n8n runs behind a reverse proxy or in Docker?

If n8n runs containerized behind nginx, Traefik or a Cloudflare Tunnel, simply setting the variables is sometimes not enough, because the proxy must forward the original headers such as X-Forwarded-Proto and X-Forwarded-Host to n8n, so that the service internally knows that the request actually came via https and the public domain. In addition to the proxy configuration, therefore also check whether N8N_PROXY_HOPS is set, because without this value n8n does not trust the proxy's forwarding headers and internally falls back to the default values again. Anyone who wants to run an n8n instance in production with several OAuth connections, and does not want to reconfigure redirect URIs again with every server move, benefits from a cleanly documented setup; this is one of the points where NordFlux with n8n setup provides support, so that automations with German data sovereignty continue to run stably even after an update.

Frequently asked questions about OAuth redirect problems in n8n

Do I have to restart n8n after setting the variables?

Yes, a restart is mandatory, because n8n only reads environment variables when the process or container starts. Without a restart, the old, localhost based redirect URI remains active, even if WEBHOOK_URL or N8N_HOST are already set correctly.

Is it enough to only set WEBHOOK_URL?

In most cases yes, since according to the n8n documentation WEBHOOK_URL overrides the entire automatically calculated URL and thus also corrects the OAuth callback address. Additionally, you only need N8N_EDITOR_BASE_URL if links in automatically sent emails or SAML redirects are still shown incorrectly.

Why does redirect_uri_mismatch sometimes also occur with n8n Cloud?

The error can also occur with n8n Cloud if the redirect URL shown in the credential dialog no longer matches exactly the address stored with the provider, for example after a change of the workspace domain. In this case, it helps to copy the currently displayed redirect URI again and update it in the Google Cloud Console or Microsoft app registration.

Does the same solution also apply to Microsoft credentials?

Yes, the principle is identical for Microsoft or Azure connections, since there too an exact match between the redirect URI sent by n8n and the reply URL stored in the app registration is required. So set the same variables N8N_HOST, N8N_PROTOCOL and WEBHOOK_URL and enter the address shown in the n8n credential into the list of reply URLs of your Azure app registration.