We Keep Coding

Error 1016 when executing Argo Tunnel from Node child_process

Cloudflare Argo Tunnel from Node child_process
I have an electron app from which I would like to spawn a child process that executes
cloudflared tunnel --url localhost:3000
inside a certain directory. Executing this from cmd inside that directory instantiates the argo tunnel as expected, and the url works while the process is running. This is how I am executing the command from the electron app:
const { spawn } = require('child_process')
let tunnel = spawn('cloudflared', ['tunnel', '--url', 'localhost:4000'], {
stdio: 'inherit', // Will use process .stdout, .stdin, .stderr
cwd: 'c://cloudflare'
})
I can see the normal console output from cloudflare indicating that the tunnel has been established and my server is responding at some-random-name.trycloudflare.com. However, when the process is started from within the electron app, I get Error 1016 displayed on a cloudflare error page.
Does anyone have experience with Argo Tunnel and child_process?

I was able to get your setup to work on my Mac without issue, so you need to look further into the details of your setup. Here is what I did:
Installed Electron Fiddle v0.9.0 from GitHub
Installed cloudflared version 2019.8.4 via homebrew with
brew install cloudflare/cloudflare/cloudflared
From the command line (Terminal window), ran
cloudflared tunnel --url localhost:3000
cloudflared had some complaints:
Cannot determine default configuration path. No file [config.yml config.yaml] in [~/.cloudflared ~/.cloudflare-warp ~/cloudflare-warp /usr/local/etc/cloudflared /etc/cloudflared]
cloudflared will not automatically update when run from the shell
unable to connect to the origin error="Get http://localhost:3000: dial tcp [::1]:3000: connect: connection refused"
Started a web server on localhost:3000 with
python -m SimpleHTTPServer 3000
Loaded the page http://localhost:3000 in my browser
Again ran
cloudflared tunnel --url localhost:3000
Same complaints, except this time it was able to connect:
Proxying tunnel requests to http://localhost:3000
Further output from cloudflared indicated it was bringing up 4 tunnels. For each tunnel, it output
+-----------------------------------------------------------+
| Your free tunnel has started! Visit it: |
| https://sides-universe-gym-metadata.trycloudflare.com |
+-----------------------------------------------------------+
Route propagating, it may take up to 1 minute for your new route to become functional
Note that I did not change or obfuscate the URL, that is exactly what was output, and cloudflared output the same URL 4 times, once for each tunnel.
I went to https://sides-universe-gym-metadata.trycloudflare.com and verified it displayed the same website I had brought up on localhost:3000.
I quit cloudflared by typing ctrl-c in the Terminal window where it was running. It took quite some time to shut down, but I waited until it quit.
I went to https://sides-universe-gym-metadata.trycloudflare.com and verified it displayed an error. It displayed "Error 1016" and "Origin DNS error".
In Electron Fiddle, I selected Electron v6.0.6 and used the default, pre-installed main.js, index.html, and renderer.js. In main.js, I added at the bottom
const { spawn } = require('child_process')
let tunnel = spawn('cloudflared', ['tunnel', '--url', 'localhost:3000'], {
stdio: 'inherit', // Will use process .stdout, .stdin, .stderr
cwd: '/Users/user/development'
})
I clicked "Run" on Electron Fiddle. The "Hello World!" page came up. The Electron Console showed output from cloudflared.
Again cloudflared brought up 4 tunnels, each with the URL https://citysearch-celebs-generator-history.trycloudflare.com
cloudflared then logged:
cloudflared has been updated to version 2019.8.4
PID of the new process is 81076
Quitting...
Metrics server stopped
I have no idea why it "updated" from "2019.8.4" to "2019.8.4". Maybe it has something to do with not having a default configuration, maybe it had something to do with Electron Fiddle running it from a non-standard location. I suspect it is because the command line did not include --is-autoupdated=true.
Immediately after "Metrics server stopped" cloudflared started logging its startup messages, just as before.
Again it brought up 4 tunnels, this time with URL https://gifts-jpg-treasury-correct.trycloudflare.com
Total time elapsed from start through restart to last stable tunnel up: 14 seconds.
I went to https://gifts-jpg-treasury-correct.trycloudflare.com in my local browser and again got the site I was hosting at localhost:3000.
I hit "Stop" in Electron. The Electron server stopped, but cloudflared kept running. I could still load https://gifts-jpg-treasury-correct.trycloudflare.com/
I hit "Run" in Electron. Again cloudflared brought up 4 tunnels. This time it did not auto-update or restart. The 4 new tunnels all had the same new URL: https://reject-pride-built-twisted.trycloudflare.com/
I went to https://reject-pride-built-twisted.trycloudflare.com/ in my local browser and again got the site I was hosting at localhost:3000. I tried https://gifts-jpg-treasury-correct.trycloudflare.com and it, too, was still working.
So I cannot reproduce your problem. Possible issues are that you may have been looking at the first tunnel that came up but cloudflared had updated, closed that tunnel, and started a different one. This worked for me on Mac but it seems you are working on Windows so it could be some Windows-specific issue. It could be that you do not have a server running on localhost:4000 or that your Electron app cannot access C://clouflare.
You need to provide more information, such as the log output of your Electron app running cloudflared and details about the server running at localhost:4000 and any cloudflared configuration files you have set up.

Common cause
Cloudflare cannot resolve the origin web server’s IP address.
Common causes for Error 1016 are:
A missing DNS A record that mentions the origin IP address.
A CNAME record in Cloudflare DNS points to an unresolvable external domain.
The origin host names (CNAMEs) in your Cloudflare Load Balancer default, region, and fallback pools are unresolvable. Use a fallback pool configured with an origin IP as a backup in case all other pools are unavailable.
Resolution
To resolve error 1016:
1) Verify your Cloudflare DNS settings include an A record that points to a valid IP address that resolves via a DNS lookup tool.
2) For a CNAME record pointing to a different domain, ensure that the target domain resolves via a DNS lookup tool.

How to do a reverse proxy with node.js for a shiny app

EDIT
I think the problem might be that the WebSocket connection does not go through the proxy node.js. How to authorize the connection of the WebSocket?
I have a web app hosted on a nodeJS server. On the same vm I also have a shiny serveur hosting an app. I use node to redirect traffic to port 3838 (shiny) when a somes URL are requested.
I use this code on node :
app.use('/the-shiny-app', proxy({target: 'http://localhost:3838', changeOrigin: true}));
With this setting everything works fine on the shiny app when I go on mydomain/the-shiny-app/* except when I try to run code in a code box.
When I try to run code I get this error on the chrome console :
Connection closed. Info: {"type":"close","code":4503,"reason":"The application unexpectedly exited","wasClean":true}
An example of what I mean by code box :
if I do not use node.js and I redirect the traffic (on OS level) from port 80 directly to 3838 everything works fine.
sudo iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-ports 3838
I do not know exactly what kind of exchange is made between the browser and the shiny server when we run code, but maybe the protocol used is blocked by node.js.

I found the problem. As Antony Gibbs said you need to setup a WebSocket upgrade. I'm using http-proxy-middleware you cans find the doc here : https://github.com/chimurai/http-proxy-middleware

Meteor deployed on server, but browser says site can't be reached

So I've deployed my meteor app, and have it up and running on an instance.
I've used the following environment variables:
MONGO_URL='mongodb://localhost:27017/meteor'
ROOT_URL='http://<my static ip>'
PORT=3000
And I run the program using the following command:
node bundle/main.js
It prints my "Meteor is starting up" that is printed using the console.log command, and then doesn't error out, but when I navigate to http://< my static ip >:3000 in a browser, I get an ERR_CONNECTION_REFUSED result.
My open mongod terminal says it's connecting fine to the MongoDB database.
Does anyone have any ideas on how to start debugging this issue?
Thanks.

In server you don't need to run meteor application on port 3000. You can run it on port 80 if the port is not being used by any other program.
If you are using port 80 make sure port 80 is opened by the network security rules.
If you are using port 3000 or any other port you will have to make sure that port is opened by the network security rules as above. Additionally you will have to mention the IP in your url, like http://<your_ip>:<port>

Node.js on Amazon AWS goes down when Putty SSH is disconnected

I just set up my first Amazon AWS server, with a Node.js installation on it. I run my app, at which point Node says that it's listening on port 3000. However, if I close my laptop, Node.js is no longer reachable through my app. How can I make it run even when I'm not logged in to the server through Putty? As a follow-up question, how can I re-open the Node instance (so that I see the any console.log messages from it) when I log back in to my server?
Thank you!

This is part StackOverflow, part Serverfault question I believe. It sounds like the problem is you're running the node server in the foreground of your SSH session, but you'd rather run it like a service (in the background).
When you exec something like that simple node server, you're running it (by default) in your SSH connection, which ends when your connection terminates from sleeping your computer. Some scripts/programs will run by default in the background, but if you're seeing results in STDOUT (printing to the shell) it is running in the foreground.
Highjacking these answers: Node.js as a background service
Two solutions
*nix solution: http://en.wikipedia.org/wiki/Nohup
Node solution: https://github.com/nodejitsu/forever

Node.js script loading not loading from browser (outsider) but loading from command (localhost)

I have successfully installed Node.JS and Balloons.IO chatroom on my linux based vps (with SSH). When typing curl http://mydomain.com:9191/ in the ssh command I can see the html is loaded. But, when trying to reach the same page from my browser it takes some time loading then says page could not be reached. Any idea why ?

My common diagnostic steps:
1) Check that your app is actually listening on the port it should be, you can do this with:
sudo netstat -anp | grep :9191
You should see your app listening to 0.0.0.0:9191 or your.ip.address.here:9191 if you see something like 127.0.0.1:9191, then it is only listening locally so you won't be able to reach it.
2) Ensure your firewall isn't blocking these ports, if you are using iptables you can check with:
sudo iptables --list
This will print the rules for your firewall and you can check if you port is blocked (or allowed).
3) Try connecting locally. My third step is generally to try it locally with curl, you did this step already but for other landing here you can do something like:
curl http://localhost:9191/
and see what you get back
4) Try connecting remotely. If everything above looks fine, try running a verbose curl from a remote host and see what you get:
curl -v http://mydomain.com:9191/
This will show header and body output so you can see if the remote host even responds; if it doesn't then check if the raw port is even accessable with telnet:
telnet mydomain.com 9191
which if successful will print something like:
Trying your.ip.address.here...
Connected to mydomain.com.
Escape character is '^]'.
If it fails it will just hang at Trying... if it fails then your firewall is blocking the port, your host is blocking the port, or your app isn't listening to the port. If your above tests passed then contact your host because something else may be up and you should be able to get support from them.