localtunnel: `--subdomain` option does not always work

I’ve noticed that in some cases when a user starts a localtunnel client - then exits it (via ctrl + c) - the named tunnel is not returned. Launching the client again and requesting the same subdomain results in the user being assigned a random name instead.

Run the client as usual and request a custom domain.

lt --subdomain nice-donkey-20 --port 8000

Then run the client again - requesting the domain and sometimes you are not given the same domain. This behavior has come up in the past and requires looking into the localtunnel/server logic for connection count tracking.

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Reactions: 64
  • Comments: 84 (2 by maintainers)

Most upvoted comments

👍 Same problem here and I am depending on it for local development debugging with a third party application.

This issue still exists. I was running a server with a subdomain before my PC unexpectedly went off. After powering it back on, i can no longer use the subdomain i was previously using.

When i try a new subdomain, it works but can’t use the old one. Seems like the subdomain was not explicitly unassigned in the localtunnel server after the unexpected disconnection.

Oh my god!, this little issue in this moment is gonna ruin my life! I trust this lib and it bite me!

Can confirm this issue still exists. What is the “clean way” to kill the tunnel, to avoid being locked out of a subdomain for hours ?

We would appreciate if any of the active contributors will react on this issue, please.

Issue has been fixed - it was a localtunnel server side issue.

Had this issue - found @Rodrigo-Barros suggestion worked for me. Ended creating a small nodejs file to open and close tunnel. Here it is if anyone wants. Using this I am able to consistently get same subdomain

const localTunnel = require('localtunnel');`

const keypress = async () => {`
    process.stdin.setRawMode(true);`
    return new Promise(resolve => process.stdin.once('data', () => {`
        process.stdin.setRawMode(false);
        resolve();
    }))
}

(async () => {
    const tunnel = await localTunnel({ port: PORT, subdomain: SUBDOMAIN });

    console.log('Tunnel URL: ' + tunnel.url);

    tunnel.on('close', () => {
        console.log('Tunnel closed URL: ' + tunnel.url);
    });

    console.log('Press any key to exit');
    await keypress();

    tunnel.close();
})().then(process.exit);;

@hendrul Trusting a free tool that is not actively maintained to work on a project that would ‘ruin your life’ if it experienced issues is a decision that should probably be reevaluated. You may want to try setting up your own localtunnel server and see if that resolves your issue.

The developer himself wrote:

For those that do find the project useful but suffer from the flaky public server; the server is open source https://github.com/localtunnel/server and I recommend that if you have serious needs you set it up yourself. The client has a command line argument to use other servers.

I will continue to run the public server and make small tweaks here or there if I desire - however I would not consider this project actively maintained.

subdomain bug happens here over than 1 week. I know its a old bug, but I hope @defunctzombie can fix this issue. Is very annoying and unproductive. At least, localtunnel is the best tunnel I have found.

[ISSUE]: REQUESTED SUBDOMAIN NOT WORKING AFTER ONCE

check the running daemon in your server. Chances are that when you exit the tunnel or terminal, the tunnel thread becomes a ZOMBIE daemon . Step 1: use [ps aux] to view all daemon Step2: identify the zombie local tunnel thread (example: node /usr/local/bin/lt -p 8000 -s urdomain) Step3: kill with it’s pid [kill -9 [pid]] Step4: check with ps aux once again, it must be disappeared Step5: request your favourite sub-domain once again . it should be good to go now. if not kindly let me know.

I built my own tunnel server to resolve this issue also. Replaced a few lines in ClientManager.js at line 36. I found this guide helpful. https://medium.com/quark-works/running-your-own-reverse-proxy-with-localtunnel-b1658e239c35

I use localtunnel only for personal project, and this solution works for me as there is no risk that someone else steals the domain, thank you!

These are my modifications

        // can't ask for id already is use
        if (clients[id]) {
            -- id = hri.random();
            ++ this.removeClient(id);
            ++ this.debug = Debug('lt:ClientManager: id %s removed so new connection can be created',id);
        }

inside the newClient function, line 35

i had the same issue and it was very frustrating because the service is used by a remote device, so whenever the domain is changed, i loose the communication with the device. I dont know if this truly helps or i am lucky, but whenever it happens, i try to enter the mysubdomain.loca.lt using a browser and just wait for the server timeout…i repeat this for a number of times and i retry the lt --port X --subdomain mysubdomain in between…

I solved it this way.

The problem: Once you make your subdomain request, and then terminate it with Ctrl+c. It will terminate on the terminal but, the task still runs on the background. I solved it by going to task manager, and terminating all task that involve “HOST”. After that, make your request again for subdomain. i.e, lt --port 3002 --subdomain mysubdomain

@dearzubi the project is not actively maintained. If you’re having issues, you can set up a localtunnel server yourself.

When we start a localtunnel client after Reboot by mistake - Launching the client again and requesting the same subdomain sometimes results in the user being assigned a random URL. I am using port — lt --port 9000 --subdomain mysubdomain. Is there any solution for it and how to set user name and password for it…? please reply Thanks in advance…!

Having this issue again even with custom server setup. The command just stays stuck

@manuelricci I’m on Linux running Raspberry PI OS and this solution seems to work fine:

(async () => {
    const tunnel = await localtunnel({ port: 80, subdomain: "subdomain" });
    
    console.log(tunnel.url);
    
    tunnel.on("close", () => {
      console.log("\nTunnel closed");
    });
    
    process.on("SIGINT", () => {
      tunnel.close();
      process.exit(0);
    });
})();

This solution waits until the event SIGINT is triggered, and closes all tunnels. The signal SIGINT is the signal that the process recieves when the server is shutdown. An example is <kbd>Ctrl</kbd> + <kbd>C</kbd> or an error that automatically shuts down the server.

Note that I use forever when not running tests on my server. forever is an NPM package for nodejs that lets you run your server forever even if you close the window (not over reboots). I recommend you use it too https://www.npmjs.com/package/forever

I’ve also tested this on Windows 10 and it seems to work fine.

I built my own tunnel server to resolve this issue also. Replaced a few lines in ClientManager.js at line 36. I found this guide helpful. https://medium.com/quark-works/running-your-own-reverse-proxy-with-localtunnel-b1658e239c35

I built my own tunnel server to resolve this issue, but it’s still persistent.

@defunctzombie I don’t know if this can help, but I’ve experienced this issue today a few times, and I can give you the stuck links if you want.

I’ve also catched an error (I don’t know if its related to this issue) by asking a stucked subdomain :

your url is: https://bitter-fox-100.localtunnel.me
/usr/local/lib/node_modules/localtunnel/bin/client:65
        throw err;
        ^

Error: connection refused: localtunnel.me:43288 (check your firewall settings)
    at Socket.<anonymous> (/usr/local/lib/node_modules/localtunnel/lib/TunnelCluster.js:47:32)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)

Edit : Eventually, my links are working again after a few hours, so i can’t give any link to help without trying to stuck another link.