2

Getting a 400 handshake error on POST requests to my Flask app running socket.io, but I've added in the configs for NGINX according to docs and posts I read online. I'm using an Application Load Balancer in AWS and have set a :80 Target Group and a :443 listener which forwards to the Target Group. I have also added a rule for the route /socket.io to forward request to the target group on :80 and have enabled sticky sessions within the target group. I'm also using a Route53 domain name and enforcing SSL everything works fine except the socket communication.

NGINX conf file:

server { listen [::]:80; listen 80; server_name _domain_name_; access_log /var/log/nginx/access.log; location / { proxy_pass http://127.0.0.1:8000; include proxy_params; } location /socket.io { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; include proxy_params; proxy_http_version 1.1; proxy_buffering off; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_pass http://127.0.0.1:8000/socket.io; } } 

And js file connection for socket.io:

var socket = io(); socket.on('connect', () => { console.log(socket.connected); // true }); 

Connection returns true.

Listener Rule

UPDATE

Switched to NLB and am still having the same issues, however now on my NGINX logs I am seeing

connect() failed (111: Connection refused) while connecting to upstream request: "GET /socket.io/?EIO=3&transport=polling&t=MvDPJhb HTTP/1.1", upstream: "http://127.0.0.1:8000/socket.io/? EIO=3&transport=polling&t=MvDPJhb" 
24
  • This probably isn't the answer you're looking for, but websockets have a bad rep with ALB, have you tried NLB? Enabling and looking at ALB logs may help as well. NGINX logs on the instance as well. Commented Nov 6, 2019 at 2:31
  • I don't understand how using an NLB would work though? I mean a CLB would, but I need the extra capabilities an ALB provides... NGINX logs nothing out for this and access logs look fine? I haven't looked at the ALB logs though, I didn't set that up Commented Nov 6, 2019 at 17:36
  • Can you explain why CLB would? What extra capabilities of ALB do you need? Try and get some info from ALB. In general, NLB is more "stable" in terms of scaling events and traffic persistence than ALB. aws.amazon.com/blogs/aws/… Commented Nov 7, 2019 at 0:18
  • Because with CLB I would have support for TCP which I can configure to route my HTTP requests (from socket.io) through. Or at least that's what I've read. Also, I need the backend auth and the path based routing for future features, I don't think its necessary now, but I would like to setup everything through the ALB now if I can so I don't have to do extra work down the road. Commented Nov 7, 2019 at 0:49
  • Ah, I see. Well I think getting ALB logs and then going from there would be good. I've heard of people having massive issues using websockets through ALB because ALB will kill those connections. Setting the timeout may help as ALB will close connections if data isn't sent after a specified period of time. Have you seen this post? stackoverflow.com/questions/41381444/… Commented Nov 7, 2019 at 1:06

0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.