Localtunnel: Crashing after a few minutes

Created on 26 Dec 2016  路  21Comments  路  Source: localtunnel/localtunnel

Reopening @dpkonofa's issue (#81).

I vote for leaving this issue open until it's fixed. Closing it makes it seem like localtunnel is more stable than it is. People end up frustrated as a result.

image

Most helpful comment

same problem

/Users/temrdm/.nvm/versions/node/v6.9.1/lib/node_modules/localtunnel/bin/client:58
        throw err;
        ^

Error: connection refused: localtunnel.me:37189 (check your firewall settings)
    at Socket.<anonymous> (/Users/temrdm/.nvm/versions/node/v6.9.1/lib/node_modules/localtunnel/lib/TunnelCluster.js:47:32)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at emitErrorNT (net.js:1276:8)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

All 21 comments

same for me

image

any solution?

note: my internet connection is super shaky at the moment - I guess LT needs a steady socket connection open? If the program would just try to restart the session it would be good!

(ngrok works without problems)

same problem

/Users/temrdm/.nvm/versions/node/v6.9.1/lib/node_modules/localtunnel/bin/client:58
        throw err;
        ^

Error: connection refused: localtunnel.me:37189 (check your firewall settings)
    at Socket.<anonymous> (/Users/temrdm/.nvm/versions/node/v6.9.1/lib/node_modules/localtunnel/lib/TunnelCluster.js:47:32)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at emitErrorNT (net.js:1276:8)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

same

/usr/local/lib/node_modules/localtunnel/bin/client:58
throw err;
^

Error: connection refused: localtunnel.me:46657 (check your firewall settings)
at Socket. (/usr/local/lib/node_modules/localtunnel/lib/TunnelCluster.js:47:32)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at emitErrorNT (net.js:1250:8)
at nextTickCallbackWith2Args (node.js:442:9)
at process._

tickCallback (node.js:356:17)

@defunctzombie ='(

+1, whether a named subdomain or not.
(crashes within about 30 seconds!)

Same here...

Same problem, is there any fix or this is the known limitation?

Error: connection refused: localtunnel.me:38913 (check your firewall settings)
at Socket. (C:\Users\D0265\AppData\Roaming\npm\node_modules\localtunnel\lib\TunnelCluster.js:47:32)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at emitErrorNT (net.js:1272:8)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickCallback (internal/process/next_tick.js:98:9)

It seems like server doesn't allows new connections.
I proposed as temporary solution to avoid crashes #155
Tunnel instead of crash will wait 10 seconds and will be restarted.

Same here, I fixed it using bash scripting:

$ while true; do lt -p 8008 -s mycustomdomain; sleep 1; done

Then it was easy to put it into a parametric bash script like this:

 #!/bin/bash

 DOMAIN=$1
 PORT=$2

 if [ $# -eq 0 ] ; then
     echo "No arguments supplied"
     echo "Usage: command DOMAIN PORT"
     exit 1
 fi

 while true
     do lt -p $PORT -s $DOMAIN
     sleep 1
 done

Take a look to another solution shown on issue #81 comment

@cstrap the problem with this solution is that the generated url is not persistent and it changes everytime

@jeffer8a I agree with you if the -s option is missing, otherwise the domain is the same at every crash/reload.

I'm also getting the same error after crash

 Rc&Sw 16:25:32 error swWorkerApp.js   Local Tunnel has an Error : Error: connection refused: localtunnel.me:44067 (check your firewall settings)
    at Socket.<anonymous> (E:\dev\code\ratchet\node_modules\localtunnel\lib\TunnelCluster.js:47:32)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at emitErrorNT (net.js:1283:8)
    at _combinedTickCallback (internal/process/next_tick.js:80:11)
    at process._tickCallback (internal/process/next_tick.js:104:9)
const localtunnel = require("localtunnel");
const forever = require("async/forever");
const gulp = require('gulp');

gulp.task('tunnel', function (callback) {
    let options = {
        subdomain: "asdf",
        local_host: "localhost",
        port: 80,
    };
    forever((next) => {
        let tunnel = localtunnel(options.port, options, function (err, tunnel) {
            if (err) {
                callback(error);
            }

            console.log(tunnel.url);
        });

        tunnel.on('error', function (error) {
            console.log("Error!! Reconnecting");
            next()
        });
    }, (error) => {
        callback(error);
    });
});

Should work

I simplified it with less dependencies by adding re-connect code in the 'close' event...

_lt=require('localtunnel')
function LocalTunnel(port, subdomain, local_host) {
   var  tunnel = _lt(port, { subdomain: subdomain, local_host: local_host }, function (err, tunnel) {
        if (err) {
            console.error("localTunnelCode Failed with error: " + inspect(err))
        } else {
            console.info("localTunnelCode connected and exposed on : " + tunnel.url + ":" + tunnel._opt.port)
        }
    })
    tunnel.on('close', function () {
console.error("tunnel -> Tunnel Closed...Going to Restart")
        tunnel = _lt(port, { subdomain: subdomain }, function (err, tunnel) {
            if (err) {
console.error("localTunnelCode Restart Failed with error: " + inspect(err))
            } else {
console.warn("localTunnelCode Re-Connected and exposed on : " + tunnel.url + ":" + tunnel._opt.port)
            }
        })
    })
    _tunnel.on('error', function (err) {
console.error("tunnel Error -> " + inspect(err))
    })
}

I have the same issue. I don't mind too much, I can start it up again. And really, it's a free service that takes away a _ton_ of headaches...

Same problem here.. Any reason why not to merge the restart code from @julianfrank as an additional option (e.g. --persistent for example )

Same here

having the same issue here. hope there'd be a perma solution soon. PS: currently using the while loop bash solution which seems to work fine.

Same issue reported in #169

I have upgraded the localtunnel server in the hope that it will handle the connection load better. I am still thinking of ways to make it clear that these connections are ephemeral and should not be used for long-lived (days) sessions or permanent urls.

@defunctzombie, (same for #169) maybe localtunnel could identify outage and display reasonable message? Would you like me to open a new issue for that?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nitingupta220 picture nitingupta220  路  5Comments

rr20eid10 picture rr20eid10  路  4Comments

kdoggthebus picture kdoggthebus  路  9Comments

adrienrn picture adrienrn  路  15Comments

sksar picture sksar  路  6Comments