Failed to start Google sign-in Failed to fetch

[DigiDon34]

Hi

I tried to self host using the cli commands
I created a Debian VM with docker inside proxmox
Cloudflared to my domain so I have an external URL and adapted it in the Google redirect uri

I first encounter an issue where I could not access the login page
I have to manually correct the .env file from
QUEUE_BACKEND="# bullmq | qstash | internal"
to
QUEUE_BACKEND="internal"

I then struggled to force the url to my domain but used
NEXT_PUBLIC_BASE_URL=https://inbox-zero.digitik.co docker compose --profile all up -d

and it seems to accept it
as confirmed via npx @inbox-zero/cli config
see screenshot

HOWEVER for some reason once I click Accept on the google login I have

Failed to start Google sign-in Failed to fetch
and console mention some calls from internal URL which is nowhere referenced in the .env or yml file.

Access to fetch at 'http://192.168.1.27:3000/api/auth/sign-in/social' from origin 'https://inbox-zero.digitik.co' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Logs looked fine

What can I do? Couldn't find info about this
Thanks

[elie222]

Looks like a CORS issue. I would ask Claude Code/Codex/... to help you fix it up

[DigiDon34]

I already try to debug using comet/perplexity which helped me for the first issue.

But is says the problem is that the fetch is made by the local url 192.168.1.27 instead of the domain.
And that there should be some env variables that is not set correctly.
But none mention this specific IP adress
And the next_public_base_url has been set correctly.

So I do not understand why the fetch is coming from local IP.
And pushed perplexity to its limit on this.

[DigiDon34]

So... I spent again quite some time with claude to try and debug but it was a miss. Here is the recap

Issue: Sign-in fails with CORS error — client-side JS sends auth requests to internal IP instead of public domain.
Setup:

Inbox Zero self-hosted via Docker (ghcr.io/elie222/inbox-zero:latest)
Debian VM on Proxmox
Exposed via Cloudflare Tunnel at https://inbox-zero.digitik.co

The error:
When clicking "Sign in with Google" on https://inbox-zero.digitik.co/login, the browser makes a POST to http://192.168.1.27:3000/api/auth/sign-in/social instead of https://inbox-zero.digitik.co/api/auth/sign-in/social. This triggers a CORS + mixed content block (HTTPS origin → HTTP target).
What is correctly configured:

.env has NEXT_PUBLIC_BASE_URL=https://inbox-zero.digitik.co, NEXTAUTH_URL=https://inbox-zero.digitik.co, BETTER_AUTH_URL=https://inbox-zero.digitik.co
Container env vars confirmed correct via docker compose exec web env
Server-side auth works fine: curl -X POST /api/auth/sign-in/social returns a redirect to Google with the correct redirect_uri=https://inbox-zero.digitik.co/api/auth/callback/google
HTML served by the app contains https://inbox-zero.digitik.co (not the internal IP)
No 192.168 or localhost:3000 found in /app/.next/static/ JS bundles
No 192.168 found in NEXT_DATA
Google OAuth redirect URIs are correctly set
Cloudflare Tunnel is running and routing properly
Tested in incognito — same issue, not a cache/service worker problem

What we haven't been able to determine:

Where the client-side JS gets http://192.168.1.27:3000 as the base URL for the /api/auth/sign-in/social fetch call. It's not in env vars, not in compiled JS bundles, not in the HTML, and not in NEXT_DATA.

Best guess:
The Better Auth client library may be auto-detecting the API base URL at runtime using something other than window.location.origin or the NEXT_PUBLIC_BASE_URL env var — possibly from a response header, a WebSocket handshake, or an internal discovery mechanism that resolves to the container's host IP.

[tschreiner]

I had the same issue. I had to create a .env file in the root folder/same folder as the docker-compose.yml and set the following variables there:

WEB_PORT=3010
NEXT_PUBLIC_BASE_URL=https://inboxzero.teddschreiner.de

Otherwise they won't be loaded. I haven't fully understood why thats the case though.

[elie222]

Thanks for the help @tschreiner! Will try get this into the docs!

[DigiDon34]

@tschreiner Thanks for jumping in but unfortunately it doesn't seem to be the same issue.

I already had a complete .env file in the same folder as docker-compose.yml

And it starts with the correct value

...☹

[tschreiner]

Have you checked the internal IP of the docker container? Can you post the docker-compose.yml and .env files with redacted credentials?

When you start the web container observe the logs. There is some script running which replaces some variables. What does it say?

🚀 Starting Inbox Zero...
Replacing all statically built instances of http://NEXT_PUBLIC_BASE_URL_PLACEHOLDER with **https://inboxzero.teddschreiner.de.**
Replacing all statically built instances of NEXT_PUBLIC_BYPASS_PREMIUM_CHECKS_PLACEHOLDER with true.
Replacing all statically built instances of NEXT_PUBLIC_EMAIL_SEND_ENABLED_PLACEHOLDER with true.
Replacing all statically built instances of NEXT_PUBLIC_AUTO_DRAFT_DISABLED_PLACEHOLDER with false.
🔄 Running database migrations...
Loaded Prisma config from docker/scripts/prisma.config.ts.

[DigiDon34]

My internal ip is this one http://192.168.1.27:3000/ that I did not set in any file

I will upload files

[DigiDon34]

Env.txt
docker-compose.yml.txt

[tschreiner]

I believe it is some kind of caching issue because I read the corresponding code and the URL is generated using NEXT_PUBLIC_BASE_URL and should be correct in your case. It is either cached by the browser, by next.js or by cloudflared?

You use cloudflared, correct? Is there any other reverse proxy running?

Have you tried disabling/clearing your browser cache?
You can remove NEXTAUTH_URL, NEXTAUTH_URL_INTERNAL, BETTER_AUTH_URL from your env. Otherwise the files look fine to me.

Can you try the following commands?

# check env value
docker compose -f docker-compose.yml exec web sh -lc 'tr "\0" "\n" </proc/1/environ | grep "^NEXT_PUBLIC_BASE_URL="'

# check if placeholder was replaced at all
docker compose -f docker-compose.yml exec web sh -lc 'grep -R -n --binary-files=without-match -E "NEXT_PUBLIC_BASE_URL_PLACEHOLDER|http://NEXT_PUBLIC_BASE_URL_PLACEHOLDER" /app/apps/web/.next /app/apps/web/public'

# find internal urls in container files
docker compose -f docker-compose.yml exec web sh -lc 'grep -R -n --binary-files=without-match -E "http://(localhost|127\.0\.0\.1|web:3000|192\.168\.[0-9]+\.[0-9]+(:[0-9]+)?|10\.[0-9]+\.[0-9]+\.[0-9]+(:[0-9]+)?|172\.(1[6-9]|2[0-9]|3[0-1])\.[0-9]+\.[0-9]+(:[0-9]+)?)" /app/apps/web/.next /app/apps/web/public'

# additional searches
docker compose -f docker-compose.yml exec web sh -lc 'grep -R -n --binary-files=without-match "http://192.168.1.27:3000" /app/apps/web/.next /app/apps/web/public'
docker compose -f docker-compose.yml exec web sh -lc 'find /app/apps/web/.next -type f | grep -E "\.js$" | xargs grep -n "sign-in/social"'

If nothing is found try to recreate the container:

docker compose -f docker-compose.yml up -d --force-recreate web
docker compose -f docker-compose.yml logs --tail=100 web
docker compose -f docker-compose.yml exec web sh -lc 'tr "\0" " " </proc/1/cmdline; echo; printenv NEXT_PUBLIC_BASE_URL'