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.
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.
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.
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.
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.
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
AMI Selection: Choose Ubuntu 24.04 LTS (or the latest LTS).
Instance Type:t3.micro is usually sufficient for testing.
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:
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.
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.
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.