503 on Chrome DevTools connection request

I can't get chrome devtools to proxy to port 9229 of a node instance; it always receives a 503 response. However if there is a standard http server running on the same machine, it can be proxied to just fine. It seems like the websockets used by the chrome inspect protocol my be the issue.

Here is a reproduction - would you be able to provide assistance with debugging?

docker-compose.yml

version: '3.5'

networks:
  backend:
    driver: bridge

services:

  node:
    image: node:alpine
    command: node --inspect=0.0.0.0:9229 -e "setInterval(() => console.log('tick tock'), 1000)"
    environment:
      VIRTUAL_HOST: node:9229
    expose:
      - 9229
    networks:
      - backend

  ingress:
    image: jwilder/nginx-proxy:latest
    restart: always
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    ports:
      - '80:80'
    networks:
      - backend

Navigate to chrome://inspect and add a configuration for node:80:

Add the following entry in your /etc/hosts file:

127.0.0.1 node

My output:

Generated /etc/nginx/conf.d/default.conf:

# If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the
# scheme used to connect to this server
map $http_x_forwarded_proto $proxy_x_forwarded_proto {
  default $http_x_forwarded_proto;
  ''      $scheme;
}
# If we receive X-Forwarded-Port, pass it through; otherwise, pass along the
# server port the client connected to
map $http_x_forwarded_port $proxy_x_forwarded_port {
  default $http_x_forwarded_port;
  ''      $server_port;
}
# If we receive Upgrade, set Connection to "upgrade"; otherwise, delete any
# Connection header that may have been passed to this server
map $http_upgrade $proxy_connection {
  default upgrade;
  '' close;
}
# Apply fix for very long server names
server_names_hash_bucket_size 128;
# Default dhparam
ssl_dhparam /etc/nginx/dhparam/dhparam.pem;
# Set appropriate X-Forwarded-Ssl header
map $scheme $proxy_x_forwarded_ssl {
  default off;
  https on;
}
gzip_types text/plain text/css application/javascript application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
log_format vhost '$host $remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent"';
access_log off;
resolver 127.0.0.11;
# HTTP 1.1 support
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
proxy_set_header X-Forwarded-Ssl $proxy_x_forwarded_ssl;
proxy_set_header X-Forwarded-Port $proxy_x_forwarded_port;
# Mitigate httpoxy attack (see README for details)
proxy_set_header Proxy "";
server {
        server_name _; # This is just an invalid value which will never trigger on a real hostname.
        listen 80;
        access_log /var/log/nginx/access.log vhost;
        return 503;
}
# node:9229
upstream node:9229 {
                                ## Can be connected with "ws-repro_backend" network
                        # ws-repro_node_1
                        server 172.20.0.2:9229;
}
server {
        server_name node:9229;
        listen 80 ;
        access_log /var/log/nginx/access.log vhost;
        location / {
                proxy_pass http://node:9229;
        }
}

Start with the reproduced docker-compose.yml and the generated /etc/nginx/conf.d/default.conf. Use chrome://inspect against node:80 and compare the failing Chrome DevTools/WebSocket request with the working standard HTTP proxy request, focusing on the shown upstream and proxy headers. Done means identifying and documenting the cause of the 503 or providing a verified proxy configuration that allows the connection.