n8n OAuth redirect points to localhost? Here is how to fix redirect_uri_mismatch with N8N_HOST and WEBHOOK_URL.
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.
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.
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.
After setting these variables, the n8n process or container must be restarted, since n8n only reads environment variables at startup.
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.
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.
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.
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.
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.
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.
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
The most practically relevant n8n environment variables for German self-hosting setups: host, webhook URL, timezone, security, and database at a glance.
n8n webhook fine in testing, silent in production? Here is how to find the cause: activation, WEBHOOK_URL, path conflicts.
n8n reporting 'JavaScript heap out of memory'? Here is how to fix it with NODE_OPTIONS, filesystem mode, and execution pruning.
N8N_HOST, WEBHOOK_URL, and N8N_EDITOR_BASE_URL all have to line up again every time your environment changes, or the OAuth connection falls back to localhost or throws a redirect_uri_mismatch. NordFlux runs managed n8n operation, including environment variables, reverse proxy configuration, and OAuth connections, so Google and Microsoft credentials keep working instead of breaking with every deployment. In an initial conversation, we look at your n8n environment and fix the cause, not just the symptom.
