Dev server no longer working with Nginx reverse proxy

[eahmann]

What version of Next.js are you using?

11.1.1-canary.10

What version of Node.js are you using?

12.0.0

What browser are you using?

Chrome

What operating system are you using?

Windows 10 with WSL2

How are you deploying your application?

next dev

Describe the Bug

My dev environment is setup with a Docker container with Nginx running a reverse proxy to port 3000. With versions 11.0.2-canary.17 and above I am getting 502 Bad Gateway. With versions 11.0.2-canary.16 and below, everything is working as expected with the Next.js app (I used create-next-app) rendering through the reverse proxy. This is with running the dev server (next dev)

It seems that the bug was introduced in 11.0.2-canary.17. The dev server through nginx is working fine prior to this version.

Expected Behavior

Nest.js dev server to load through reverse proxy

To Reproduce

You will need a way to use docker-compose. I am using Docker Desktop with WSL2 backend.

Create the following files for minimal reproduction:

docker-compose.yml

version: "3.1"
services:
  web:
    image: nginx:alpine
    ports:
      - "8081:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf

nginx.conf

events {
  worker_connections  1024;
}

http {
    server {
        listen 80 default_server;
        listen [::]:80 default_server;
        proxy_read_timeout 120s;

        server_name localhost;

        root /app/src;
        
        location / {
            proxy_pass http://host.docker.internal:3000;
        }
    }
}

Start nginx with docker-compose up
Start simple Next.Js app on port 3000. I used basic create-next-app

Observe that localhost:3000 works. And that when trying to access localhost:8081 (our reverse proxy) you receive nginx error page 502 Bad Gateway

[timneutkens]

Likely related to this change: #27306

[eahmann]

Yup, I reverted the changes from that commit, and it started working again. @ijjk

[eahmann]

Running next dev --hostname 0.0.0.0 will allow it to run without any modifications. Not ideal in my opinion given that it's not clear why it is failing. In either case the dev server appears to start exactly the same ready - started server on 0.0.0.0:3000, url: http://localhost:3000

[ijjk]

This sounds specific to this set-up, I think we want to keep #27306 as it ensures HMR is working with default Windows set-ups. The change in the above PR ensures we use node's default hostname (related docs). If IPv4 needs be forced over node's default then I think specifying it via hostname like you mentioned above is the correct solution.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.