I am unable to access my digital ocean node js app. I've already SSH'ed in, cloned my Node app from Git, npm installed, and successfully started the app on the droplet, yet I get error
This site can't be reached
Digital Ocean docs say you can access your publicly facing website simply by going to <your website's ip>:<port>:
I did this by going to 67.205.185.63:9000/ (my app is running on port 9000 as you can see):
root#nodejs-512mb-nyc1-01:~/demos# npm start
live-demos#1.0.0 start /root/demos
node app.js
Demos is listening on port 9000
How else should I be accessing my node app?
var express = require('express');
var bodyParser = require('body-parser');
var app = express();
var port = process.env.PORT || 9000;
...
app.listen(port, function () {
console.log('Demos is listening on port ' + port);
});
Some Digital Ocean droplets (mainly one-click apps) come with ufw firewall installed and by default all ports except for 22, 80, and 443 are blocked.
To check if ufw is installed and which ports are blocked/open do:
sudo ufw status
Output:
To Action From
-- ------ ----
22 LIMIT Anywhere
80 ALLOW Anywhere
443 ALLOW Anywhere
22 (v6) LIMIT Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
To allow traffic on port 9000 do:
sudo ufw allow 9000/tcp
Add the 9000 port by writing following command
sudo ufw allow 9000
Related
I'm using flutter socket io to communicate to my server that's running node/express.
The server code:
var express = require('express');
var bodyParser = require('body-parser')
var app = express();
var http = require('http').Server(app);
var io = require('socket.io')(http);
var mongoose = require('mongoose');
app.use(express.static(__dirname));
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({extended: false}))
var Message = mongoose.model('Message',{
name : String,
message : String
})
app.get('/', (req, res) =>{
res.send("Hello");
});
io.on('connection', () =>{
console.log('a user is connected')
});
var server = http.listen(8080, "<MyServerIP>", () => {
console.log('server is running on port', server.address().port);
});
My Flutter code :
connect() async {
try {
String connectionPoint = "http://<MyServerIP>:8080";
//Connect to Socket.IO
socket = IO.io(
connectionPoint,
OptionBuilder()
.setTransports(['websocket']) // for Flutter or Dart VM
//.disableAutoConnect() // disable auto-connection
//.setExtraHeaders({'id': tokenId}) // optional
.build());
//socket.connect();
socket.onConnecting((data){
print("Connecting");
});
socket.onConnectError((data) {
print("Error Connecting - > $data");
});
socket.onConnectTimeout((data) => null);
socket.onDisconnect((data) => null);
} catch (e) {}
}
When ever i try to connect I'm getting a timeout error that's caught in onConnectError.
The node server is running debian, and I've checked the firewall status:
To Action From
-- ------ ----
27017 ALLOW Anywhere
80 ALLOW Anywhere
3000 ALLOW Anywhere
22 ALLOW Anywhere
Samba ALLOW Anywhere
8080 ALLOW Anywhere
27017 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
3000 (v6) ALLOW Anywhere (v6)
22 (v6) ALLOW Anywhere (v6)
Samba (v6) ALLOW Anywhere (v6)
8080 (v6) ALLOW Anywhere (v6)
3000 ALLOW OUT Anywhere
3000 (v6) ALLOW OUT Anywhere (v6)
When I open the url via chrome I'm getting the "Hello" message.
When I try netcat "nc -vz MyServerIp 8080 and I'm getting a success in connecting. I've also checked my local firewall and I've allowed all connections for qemu to my MyServerIp.
Just need some help as to try to work out why I'm getting the timeout and whether there are any ways to debug this ?
##Edit:
MyServerIP is the actual server ip of my server.
##Edit 2:
I used my device to test whether it was something that was local issue to the android emulator. And, I received the same error (I also took the device off my wifi to eliminate any local firewall issues). I'm assuming that this would mean that it has something to do with my server.
The issue being faced was due to the mis-match between the server version and the package being installed with Flutter. The version on the server was > 3. The latest version installed for flutter is not compatible with a server version. There is a beta version that needs to be used.
At the moment there are two options :
Option 1: Downgrade the servers version so that its compatible.
Option 2 use the beta version. (this is the option I took).
Update pubspec.yaml to socket_io_client: ^2.0.0-beta.2 and it connects.
nodejs version v6.11.5
When hosting via Express, the website loads, i.e,
app.listen(port, function () {
console.log("The Server Has Started!");
});
But, when hosting via https, I get ERR_CONNECTION_REFUSED error. For hosting with https, I'm using
var options = {
ca: fs.readFileSync(__dirname+'/keys/sitname.ca-bundle'),
key: fs.readFileSync(__dirname + '/keys/sitname.key'),
cert: fs.readFileSync(__dirname + '/keys/sitname.crt'),
};
var app = express();
.... the app .....
https.createServer(options, app).listen(port, function(){
console.log("server started at port "+port);
});
The port is set to 80 and the ufw rules are as following
To Action From
-- ------ ----
22 LIMIT Anywhere
80 ALLOW Anywhere
443 ALLOW Anywhere
22 (v6) LIMIT Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
Any response will be highly appreciable.
For https you have to set the port to 443 because https uses this port by default. Another option would that you define that you want to use port 80 for https when you send your request: my-domain.com:80. But I'm not sure if this works.
From #floriangosse's comment,
HTTPS uses port 443 by default and thus using port 80 for HTTPS gives ERR_CONNECTION_REFUSED.
Switching to port 443 worked.
We have set up a node server which runs on port 5000.
In a newly created droplet, we have installed and started nginx. To access the node app, we have changed the default port from 80 to 5000 in /etc/nginx/sites-enabled/default
server {
listen 5000 default_server;
listen [::]:5000 default_server;
ufw is enabled
sudo ufw enable
Also the port is enabled
sudo ufw allow 5000/tcp
Also, tried this way too:
sudo ufw allow 5000
As confirmed with sudo ufw status
netstat -ntlp
Also the app is configured to listen on the public interface
const server = app.listen(process.env.PORT || 5000, '0.0.0.0', () => {
console.log('Express server listening on port %d in %s mode', server.address().port, app.settings.env);
});
However, not even the default port was responding. Hence, we reverted to 80 as the default port.
What else is required to access node app outside of the droplet?
When it comes to NodeJS and NGINX, we'll want to configure NGINX to listen on port 80, though we'll want to use proxy_pass to pass the request from the web server (NGINX) to the NodeJS application on the port that the application is running on. This will allow us to keep the port out of the URL.
With the current configuration, NGINX would be listening on port 5000 which would prevent the application from being able to listen in on the same port (or vice versa).
There is an excellent guide that covers setting up NodeJS + NGINX -- this specific part is the most important:
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-node-js-application-for-production-on-ubuntu-16-04#set-up-nginx-as-a-reverse-proxy-server
The above covers how we'd go about setting up the Server Block :-)
I'm totally new to Node and I tried to run a test site on a hosting centos 7 (vultr.com). I've got nodejs, express installed.
Hello.js
const express = require('express')
const app = express()
app.get('/', function (req, res) {
res.send('Hello World!')
})
app.listen(3000, function () {
console.log('Example app listening on port 3000!')
})
run node hello.js
On my PC, http://x.x.x.x:3000/ => shows This site can’t be reached
x.x.x.x took too long to respond.
UPDATE:
I think you should consider about your server port. Have you open port 3000 in CentOS?
You can check your open port by typing
iptables -L
I think the firewall blocked your port you can open it by type this command
iptables -A INPUT -p tcp --dport 3000 -j ACCEPT
If you are using remote server, probably your 8080 port is blocked.
If you have root access and port 80 is open you can try and run script with sudo
But the first option is probably your problem
If you use the Google Cloud platform, you can open port 3000 at FIREWALL RULES in VPC network.
It works for me.
Update: Turns out the only problem was that I was behind a firewall that blocked some ports, but not 8000.
Edit: TL;DR: can't connect to port 9000 remotely, but port 8000 is ok and I don't know why :(
I've got this node.js application that's running on port 8000 and another one (http-proxy) running on port 9000.
Running them on my machine is fine, but I have some problems when I put them up on a server (EC2 instance - I did open the ports in the web console security group[1]). The application works fine, but I can't connect to the proxy from outside. I tried to $ telnet localhost 9000 on the server and it connects, so I guess that's a good sign.
Another thing that I have noticed is that if I try to run the applications separately, I get the same results, i.e.: 8000 - OK, 9000 - NOTOK :<.
However, if I change the port the proxy uses from 9000 to 8000, it works. And if I switch the ports, i.e. application:9000 and proxy:8000, I can connect to the proxy, but not to the application. I have also tried other numbers, but that wouldn't fix it either.
I guess there's something really stupid that has nothing to do with the application itself and that I'm missing, but I can't put my finger on it, so does anyone have any idea why this setup doesn't work?
server.js
var express = require('express.io');
var app = module.exports = express();
require('./proxy');
app.http().io();
app.listen(8000);
// ...
proxy.js
var httpProxy = require('http-proxy');
var url = require('url');
httpProxy.createServer(function(req, res, proxy) {
// ...
proxy.proxyRequest(req, res, {
host: destination.host,
port: 80
});
}).listen(9000);
$ netstat -pln | grep node output
tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 1487/node
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 1487/node
Security group rules
It turned out that the problem was not at all related to the application or the EC2 instance setup.
The network I was in while testing this was blocking some ports. This is why when moving the proxy to port 8000 it was working fine, but on 9000 or any other random ones that I tried it wasn't. D'oh!