Lost Connection to server, reconnecting on AWS linux

By the way I might have misspoke that it worked on my previous AWS, as this LINK shows that from at least 2021 I was following this issue.

I'll look at this thread to gain any insight.

ps. I just tried from my iPhone browser, and that Lost Connection shows up.

How do I get to a window like you show? I have all linux command, like "netstat". But in general my AWS instance is just a processor with a firewall and ports.

You simply open the dev tools in your (desktop) browser then go to the network tab.

OK, I see this under the "developer" of a web page (the node-red one).
Here is some: /bot is a Redirect to port 2000

Gets error:

[Error] WebSocket connection to 'wss://semanticmarkers.com/bot/comms' failed: There was a bad response from the server. (x5)

Summary
URL: wss://semanticmarkers.com/bot/comms
Status: 404 Not Found
Source: —

Request
Cache-Control: no-cache
Origin: https://semanticmarkers.com
Pragma: no-cache
Sec-Fetch-Dest: websocket
Sec-Fetch-Mode: websocket
Sec-Fetch-Site: same-origin
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.4 Safari/605.1.15

Response
Access-Control-Allow-Origin: *
Content-Length: 144
Content-Security-Policy: default-src 'none'
Content-Type: text/html; charset=utf-8
Date: Fri, 08 May 2026 00:53:56 GMT
Server: Apache/2.4.66 (Amazon Linux) OpenSSL/3.5.5
Vary: Accept-Encoding
X-Content-Type-Options: nosniff

OK, that makes one thing fairly clear I think. This is an AWS configuration issue.

How, for example, is AWS hiding the Node-RED port? That strikes me as it running a proxy which isn't, perhaps, correctly configured to handle websockets.

I'm not sure how many people on the forum use AWS, I don't, for Node-RED but I fear you may have more joy with AWS support than here.

Running node-red on my mac I can see what you desire:

Summary
URL: ws://localhost:1880/comms
Status: 101 Switching Protocols
Source: —

As for AWS configuration issue, node-red only mentions a single port under my control (1880 or my 2000). So I open that port on the firewall.

If you say node-red needs a wss web socket port to be open - isn't that information I could use and configure AWS?

Or are you saying that is some strange proxy that only AWS has issues with?

There must be more your implementation can share?
thanks.

As I already said, websockets uses the same port as HTTP(S) so no additional port is needed. However, if going through a proxy, you have to be using HTTP v1.1 and have to configure the proxy to support websockets.

I don't know AWS so can't comment on that side. But most, if not all proxies require configuration to support websockets. I know how to do this on my local NGINX (or Caddy) proxies but not on AWS - I don't even know if AWS needs any config, sorry.

I've been using node-red on an AWS for 10+ years. And I guess I've had this
issue all along. It's just a virtual linux box with a firewall, as far as we are told.

And as you say the web sockets are somehow just re-configured through https? Maybe there is more to it and AWS is hitting a wall.

So, maybe your team can discuss this issue more. I can give you access to AWS for testing as well.

I hope you guys don't just punt and say you don't fully support one of the most popular Server-on-Demand services on the internet (Amazon).
thanks.

ps. the httpd server reports trying to access that /comms httpd-in of node-red. But gets 404 error.

75.213.29.86 - - [08/May/2026:01:53:08 +0000] "GET /bot/comms HTTP/1.1" 404 144

Did you try googling for how to enable websockets on AWS?

Hi, I fear you may be misinterpreting what Node-RED is. As an open source project, most of us here, including me, are simply open source and Node-RED enthusiasts, not part of a "team" as such.

The problem is that there are hundreds if not thousands of different environments so unless there are other enthusiasts on the forum who use the same environment type, there may be nobody to help. That's why I suggested trying to get some help from an AWS support forum as well.

Most of my spare development time is focused on developing the UIBUILDER nodes and some web components. I don't typically use cloud compute now I've retired and when working, I was more focused on Azure rather than AWS though even then, not really a "pro" user.

In doing some background reading, I can see plenty of posts online regarding an AWS websocket API but I couldn't really make much sense of them with a casual reading. Unfortunately, that's all I have time for.

I can share my NGINX config which might help you understand the proxy requirements for websockets but that's about it.

Almost certainly because AWS is translating the external-facing endpoints differently to what you expect. Again, this is AWS specific.

AWS is translating the external-facing endpoints differently to what you expect.

All I can say is your product node-red doesn't work correctly with AWS. You can say that's an AWS specific issue, but it's node-red that isn't working as expected.

Looking through the threads, this issue was first reported by someone in 2019. My first use of AWS was 2020 and I reported that issue then.

I'm wiling to debug more.

thanks.

Not my product. I am a user of it just like you (though using it for over a decade).

And I would be willing to help more. But without knowledge of AWS, I fear I cannot and, as I've said, I don't have capacity to start learning AWS. Hopefully, someone else with more knowledge will chip in.

Node-RED works fine in many different environments including cloud ones. So something is certainly different with the AWS environment - I'm not blaming AWS, a number of the big cloud platforms can have some odd effects. I've never had much luck either with IBM or Oracle for example. I've set up Node-RED in two different configurations on Azure but even there, you need to know a reasonable amount about Azure configuration to get things to work.


Perhaps AI will help - here is what Gemini has to say:

How to set up a Linux server on AWS with a node.js app that uses websockets?

Setting up a Node.js server with WebSockets on AWS involves configuring the virtual machine, the networking (security groups), and the application environment. Since WebSockets require a persistent connection, your infrastructure must be configured to handle "upgraded" HTTP requests.

Here is a streamlined guide to getting this running on an EC2 (Ubuntu) instance.


1. Launch the EC2 Instance

  1. AMI Selection: Choose Ubuntu 24.04 LTS (or the latest LTS).
  2. Instance Type: t3.micro is usually sufficient for testing.
  3. Security Group (Crucial):
  • SSH (Port 22): From your IP.
  • HTTP (Port 80): From anywhere.
  • App Port (e.g., 3000): If you aren't using a reverse proxy yet, open the port your Node app listens on.

2. Server Environment Setup

Once you SSH into your instance (ssh -i your-key.pem ubuntu@your-public-ip), install the essentials:

sudo apt update && sudo apt upgrade -y
# Install Node.js (via NodeSource for specific versions)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

Process Management

Use PM2 to ensure your app stays alive if it crashes or the server reboots.

sudo npm install -g pm2
# Start your app
pm2 start server.js
# Ensure it starts on boot
pm2 startup systemd
pm2 save


3. The Node.js WebSocket Code

For WebSockets in Node, the ws library or socket.io are standard. Here is a basic implementation using ws that integrates with an HTTP server:

const http = require('http')
const WebSocket = require('ws')

const server = http.createServer((req, res) => {
  res.writeHead(200)
  res.end('HTTP server running')
})

const wss = new WebSocket.Server({ server })

wss.on('connection', (ws) => {
  console.log('Client connected')
  ws.on('message', (message) => {
    console.log('Received: %s', message)
    ws.send(`Echo: ${message}`)
  })
})

server.listen(3000, () => {
  console.log('Server listening on port 3000')
})


4. Configuring a Reverse Proxy (Nginx)

While you can point traffic directly to port 3000, it is best practice to use Nginx. This allows you to use port 80/443 and handle the WebSocket "Upgrade" headers properly.

  1. Install Nginx: sudo apt install nginx
  2. Edit Config: sudo nano /etc/nginx/sites-available/default
  3. Update the location / block:
location / {
    proxy_pass http://localhost:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
}

  1. Restart Nginx: sudo systemctl restart nginx

5. Important AWS Considerations

  • Idle Timeouts: If you use an AWS Application Load Balancer (ALB), the default idle timeout is 60 seconds. WebSockets will disconnect if no data is sent. You must either increase this timeout in the ALB attributes or implement a heartbeat (ping/pong) in your Node.js code.
  • Elastic IP: EC2 public IPs change if you stop/start the instance. Assign an Elastic IP in the AWS Console to keep your address permanent.

Thanks for the info. Like you say, maybe someone is interested. I just assumed you were support for node-red.

I can support web sockets in node-red, but that's at the user level. The comments above say the node-red internals are moving the socket into the https connection somehow. I would think that's a place to look or at least print out some debug.

THanks.

:rofl: It's open source my friend. Support is from the community. There is FlowFuse if you want to pay for support.

This is automatic due to the way that websockets work. They piggyback off HTTP(S). So if you use HTTPS for Node-RED itself, the Editor will use WSS. However, also note that it is possible to move the TLS processing to a proxy relieving Node-RED of the overheads, but assuming you aren't using a VPN into your cloud server, you would be accessing the Editor via HTTPS external to Node-RED itself - the websockets would still be using WSS but the proxy would be responsible for the translation back to ws before forwarding to Node-RED. This is why an understanding of the cloud architecture is necessary - it is quite likely to be doing things for security and efficiency that need to be taken into account.