[Help Needed] Docker on Windows: Healthy Backend (LISTENING) but Frontend Fails with "Could not connect / 401 Unauthorized"

[zw0320]

Hi everyone,

I’m encountering a very stubborn issue while setting up a local n8n instance on Docker for Windows and would be grateful for any expert insight.

The core problem is a contradiction: The n8n backend container is provably healthy and listening on the correct port, but the frontend setup page fails with a “Could not connect to server” error. I believe I have exhausted all standard troubleshooting steps and that this might be a rare edge case.

---

My Environment

• OS: Windows

• Docker: Docker Desktop using the WSL 2 backend.

• n8n Image: n8nio/n8n:latest

• Launch Method: Using the docker-compose.yml file below, located in a project folder on my D: drive.

• Access URL: Both http://localhost:5678 and http://127.0.0.1:5678 have been tested.

---

The Symptoms

1. The initial setup page at http://localhost:5678 loads successfully. I can see the “Set up owner account” form.

2. Immediately, a red pop-up appears in the bottom right with the error: Error connecting to n8n. Could not connect to server. Refresh to try again.

3. The Browser Dev Tools (F12) Network tab shows that API requests to endpoints like /rest/login are failing.

4. The failure status code is 401 Unauthorized, and the response body is {"status":"error","message":"Unauthorized"}.

5. Crucial Clue: When accessing from a mobile phone on the same LAN (using the host’s IP address), I receive a specific error message: your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using safari. This strongly suggests a protocol/security mismatch.

---

Proof of Healthy Backend

The evidence overwhelmingly shows that the backend server is running perfectly:

• docker compose ps output shows the container is Up and healthy, with ports correctly mapped (0.0.0.0:5678->5678/tcp).

• docker logs n8n shows a clean startup sequence, with no errors, ending with the success message: Editor is now available via: ``http://localhost:5678.

• netstat -ano -p TCP | findstr "5678" on the host Windows machine confirms a process is LISTENING on port 5678.

---

My docker-compose.yml

This is the exact configuration I am using:

YAML

version: "3.7"

services:
  n8n:
    image: n8nio/n8n
    restart: always
    container_name: n8n
    ports:
      - "5678:5678"
    
    environment:
      - N8N_HOST=localhost
      - N8N_EDITOR_BASE_URL=http://localhost:5678
      - WEBHOOK_URL=http://localhost:5678
      - GENERIC_TIMEZONE=Asia/Singapore
      - N8N_SECURE_COOKIE=false # Explicitly set to false to allow HTTP

    volumes:
      - D:\n8n-project\n8n_data:/home/node/.n8n

---

Troubleshooting Steps Already Taken

I have systematically ruled out the following causes:

1. Browser Issues: Tried hard refresh (Ctrl+F5), cleared cache, used Chrome Incognito mode, and also tried a completely different browser. The result is identical.

2. Firewall & Security Software: Temporarily disabled/uninstalled Windows Defender Firewall and 360 Total Security, followed by a full system reboot. The issue persists.

3. Network/DNS: Tried accessing via 127.0.0.1 instead of localhost. Confirmed no VPN is active and the system proxy is disabled.

4. Docker & WSL Environment: Performed a complete, clean reinstallation of WSL 2 and Docker Desktop from scratch to resolve earlier startup and permission issues. The current environment is stable.

5. n8n Configuration: As seen in the docker-compose.yml file, I have explicitly set all relevant environment variables (N8N_HOST, N8N_EDITOR_BASE_URL, WEBHOOK_URL) to match the access URL and, most importantly, set N8N_SECURE_COOKIE=false to address the error message seen on mobile.

---

My Core Question

Given that the server is verifiably healthy and listening, and all standard client-side blockers and configuration issues have been addressed, what could still be causing the n8n backend to reject the frontend’s API requests with a 401 Unauthorized error?

It seems the N8N_SECURE_COOKIE=false variable is being ignored, or there is another, deeper security policy at the OS or network driver level that is interfering with the connection in a way that specifically triggers this authentication failure.

Any ideas on what hidden system policy, network driver, or advanced configuration I might be missing would be greatly appreciated. Thank you for your time and expertise.

[cutecatcode]

Try to set N8N_PROTOCOL to http