Nginx sending "Connection: close" instead of "Connection: upgrade" to Golang back end - go

Question

I'm trying to proxy_pass a websocket with Nginx but I'm getting "502 Bad Gateway" and my Golang back end responds: "websocket: the client is not using the websocket protocol: 'upgrade' token not found in 'Connection' header".
Nginx config:
server {
listen 80;
server_name eg.example.com;
location / {
include proxy_params;
proxy_pass http://localhost:8000/;
}
location ~* /chatclientws/[\w\-]+ {
include proxy_params;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
# Added a dummy header to see if Nginx is passing the request properly.
proxy_set_header Dummy "Test";
proxy_pass "http://localhost:8000/chatclientws/$1/";
}
}
Proxy_params:
proxy_set_header Host $http_host;
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 $scheme;
proxy_set_header X-NginX-Proxy true;
httputil.DumpRequest() in the Golang function for the route produces:
GET /chatclientws/13c21679-45b0-424a-872f-aa012a9ee7a0 HTTP/1.0
Host: eg.example.com
# Connection says close.
Connection: close
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,en-GB;q=0.8
Cache-Control: no-cache
# Connection says close again.
Connection: close
Cookie: clientroom=13c21679-45b0-424a-872f-aa012a9ee7a0
Origin: eg.example.com
Pragma: no-cache
# But websocket request does come through.
Sec-Websocket-Extensions: permessage-deflate; client_max_window_bits
Sec-Websocket-Key: ykQiDfJ2Tr2Z88WtnBQkAw==
Sec-Websocket-Version: 13
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
X-Forwarded-For: 92.54.215.31
X-Forwarded-Proto: http
X-Nginx-Proxy: true
X-Real-Ip: 92.54.215.31
Somehow, Nginx is passing down all the information necessary except for the right Connection header.
Or so it seems. As seen above, I added a dummy header, proxy_set_header Dummy "Test";, to see if Nginx is really passing the headers down. The dummy header never makes it through.
On another page with the same Nginx config but without dynamically generated pathnames, dummy header and websocket connection work well. And, if I hardcode the pathname instead of using regex, like this:
location /chatclientws/1a904868-608d-42b2-9e02-4d7d4f8cef19 {
...
proxy_pass "http://localhost:8000/chatclientws/1a904868-608d-42b2-9e02-4d7d4f8cef19";
}
It works.
So, I believe I'm using regex wrongly here. But all the examples I've seen online seem to say my use is ok.
I'm puzzled as well as to how the websocket upgrade request comes through. Why is Nginx selectively passing down information?
How should I proceed from here?

Answer 1

After scouring the net and coming up short, I solved this by trial and error. So, this might not be the most professional solution. Anyway, it looks like we can't do regex with the location stanza in Nginx like this:
location ~* /chatclientws/[\w\-]+ {
...
proxy_pass "http://localhost:8000/chatclientws/$1";
}
}
Instead, do this:
# Name your regex variable.
location ~* /chatclientws/(?<Your_Variable_Name>[\w\-]+) {
...
# Then reference it in your proxy_pass.
proxy_pass "http://localhost:8000/chatclientws/$Your_Variable_Name";
}
Essentially, make your regex into named variables. I guess.