Google Auth Redirect to Inaccessible 127.0.0.1:9099 After Running firebase emulators:start

Authentication
1

Hello everyone,

I’ve started my app using the prototyping and add some of Firebase’s products like Firestore, Authentication, Hosting, Apphosting, and Analytics. That worked fine but I saw that it adds the firebase config object directly to my code and through the preview I got auth/popup-closed-by-user (which later I understand that it’s a common issue). so I’ve removed the config from my code and use .env file for that. Then I’ve understand that there are 2 env variable that automatically configured - FIREBASE_WEBAPP_CONFIG and FIREBASE_CONFIG. so I’ve created another env variable when working locally to conditionally pass the firebaseConfig to the initializeApp. This way I was able to work on my project even completely locally (on my local machine without firebase studio).

Something went wrong with the workspace in the process, and after a lot of try and error I’ve run firebase emulators:start in the terminal on firebase studio and now nothing works. It seems that the port that I’ve tried to use was already in use and I couldn’t stopped them because I’m working on the Firebase Studio (which probably don’t have the right permissions). when I’m trying to login with google even on the preview window I’m being redirected to the http://127.0.0.1:9099/emulator/auth/.. which is not working - refuse to connect.

I’ve tried to restart the workspace, clone to another workspace and even created a new firebase project (but when cloning existing repo I can’t use the prototyping feature).

Is there any example of using Firebase Authentication with React & Next with SSR? should I add the firebase config to my source code? can I reset the firebase studio completely?

btw, I can’t see the auth & firebase sections under the publish drawer (but I see it in my other projects).

2

Hello! This is a super frustrating issue, and your detailed log is incredibly helpful for diagnosing it.

I see your main suspicion is the cloud environment’s routing layer, but I think the real clue is inside your terminal log.

This combination is the key:

Bash

 ✓ Ready in 7.5s
 ...
 GET / 404 in 20402ms
 ○ Compiling /_not-found ...

This is actually great news! It means the cloud environment’s proxy is working perfectly. The request is getting to your Next.js application.

The log line GET / 404 in 20402ms is being generated by the Next.js dev server itself. It’s not a 404 from the environment’s proxy (which would be much faster and wouldn’t show up in the npm run dev log).

The 20402ms (20 seconds!) is also a huge clue. It shows that Next.js received the request and then spent a long time trying to find or compile a page for it, failed, and then finally compiled the /_not-found page to serve the 404.

So, we just need to figure out why Next.js itself can’t find your root (/) page.

Here are the most likely causes:

1. Middleware (The i18next Clue)

This is the most likely culprit, especially since I see i18next: languageChanged es and /src/middleware compiling in your logs.

Internationalization (i18n) middleware is a common source of this exact 404 error. Your middleware.ts file is likely intercepting the / request and trying to redirect or rewrite it to a language-specific path, like /es or /en.

If you don’t have a page at that new path (e.g., src/app/[lng]/page.tsx), Next.js will return a 404.

How to Test This:

  1. Stop your dev server.

  2. Go into your src/middleware.ts file and comment out everything except a basic return NextResponse.next().

  3. Restart the dev server with npm run dev.

If your app now loads, you’ve confirmed the middleware is the problem. You’ll need to check your i18next configuration to ensure it’s correctly handling the default locale or that the [lng] routes exist.

2. Missing Root Page (app/page.tsx)

This is the second most common reason. The GET / request means the browser is asking for your homepage.

  • App Router: Do you have a src/app/page.tsx file? (Or app/page.tsx if you’re not using the src directory).

  • Pages Router: (Less likely on Next 14, but possible) Do you have a src/pages/index.tsx file?

If this file is missing, Next.js has nothing to serve for the / route and will correctly return a 404.

3. Corrupted Dev Server Cache

Sometimes, the Next.js dev server just gets into a bad state. The fix is to “nuke” the cache and restart.

  1. Stop the dev server (Ctrl+C).

  2. Delete the .next folder from your project:

    Bash

    rm -rf .next

  3. Restart the server:

    Bash

    npm run dev

This forces Next.js to rebuild everything from scratch and often clears up strange routing issues.

Summary

This doesn’t appear to be a cloud environment or proxy issue. The log GET / 404 proves your Next.js app is receiving the traffic.

The problem is most likely one of these:

  1. Your middleware.ts (for i18next) is rewriting the URL to a route that doesn’t have a page.

  2. A missing src/app/page.tsx file.

I would start by checking the middleware. Let us know if that works!