Many server apps come with a web page for setup or admin: dashboards, database tools, code editors. Putting those pages on the open internet invites password guessing, and on a NAT VPS every open port is one of your few forwarded ports. An SSH tunnel gives you a third option: the page stays private on the server, and only you reach it, through the SSH connection you already use.

1. Make the app listen only on the server itself

Set your app to listen on 127.0.0.1 (also called localhost) instead of 0.0.0.0. The setting is usually called host, bind or listen address. Then nothing outside the server can reach it. Check with ss:

2. Open the tunnel from your computer

On your own computer (Linux, macOS, or Windows 10 and 11 in PowerShell, which include ssh), run:

ssh -N -L 8080:localhost:3001 root@natbox.io -p YOUR_SSH_PORT

• -L 8080:localhost:3001: connections to port 8080 on your computer go to port 3001 on the server.
• -N: just the tunnel, no shell. Leave the window open while you work; press Ctrl+C to close it.
• Use your own SSH port from the client area, the same one you log in with.

3. Open it in your browser

Go to http://localhost:8080. You are looking at the page on your server, carried over the encrypted SSH connection. In our test it is a small private log browser that only listens on 127.0.0.1:

Tips

• Several pages at once: add more -L options, for example -L 8080:localhost:3001 -L 8081:localhost:8443.
• Save typing: put it in ~/.ssh/config on your computer, then run ssh -N mybox:

  Host mybox
      HostName natbox.io
      Port YOUR_SSH_PORT
      User root
      LocalForward 8080 localhost:3001

• "Address already in use": something on your computer already uses 8080. Pick another local number, such as 8090.
• Over IPv6: you can also connect to your server's IPv6 address on port 22, if your network has IPv6.

Good candidates: the admin page of Uptime Kuma, a database tool for PostgreSQL, or any app you only use yourself. For a public website, use a proper reverse proxy with HTTPS instead: see HTTPS with Caddy.

Get new tutorials in Telegram. Follow @natboxio: every new post, plus short server tips.

On a NAT VPS, ports 80 and 443 of the public IPv4 address are shared by everyone on the node. A reviewer recently asked two fair questions: what happens to a connection the proxy can't place, and how much can the proxy actually take? We checked the first in our config and answered the second with a load test. Here is what we did and what we found, including the parts that weren't perfect.

How HTTPS reaches your server

Each node runs HAProxy in TCP mode. It reads one thing from the start of the TLS handshake, the domain name the browser asks for (SNI), looks it up in the list of domains our customers have linked and verified, and passes the still-encrypted connection to that customer's server. We never terminate TLS or hold your certificate.

• It fails closed. The lookup is an exact match. If no name is sent, or the name isn't linked to a natbox server, the connection is refused. There is no default backend, so a connection can never land on someone else's server. We confirmed this live during the test.
• Fair use per visitor. One source address can open up to 200 new connections in any 10 seconds and keep up to 100 open at once.
• Over IPv6 there is no proxy at all: every server has its own routed /80, so visitors reach it directly. That is also where HTTP/3 works, because UDP 443 isn't forwarded on the shared IPv4. Details are in our docs.

How we tested

• One production node: 18 vCPU, HAProxy 2.8 with 18 threads, a configured maximum of 20,000 connections. We picked it because no customer domain was linked there yet, so no customer HTTPS traffic went through the proxy we were stressing.
• A temporary test server on the same node ran nginx with a self-signed certificate and was capped at 4 CPU cores. We added its test domain to the proxy in memory only and removed it afterwards.
• The load generator ran on the node itself and spread its connections over 250 local source addresses, so the per-visitor limits above weren't what we measured.
• A separate probe opened one real connection every second throughout, to see what an ordinary visitor would have experienced.

Results

New connections. Each one was a full TLS handshake, one HTTP request and a close, with no session reuse. With 100, 400 and 1,000 clients at once we got 548, 558 and 650 handshakes a second, over 53,000 in total, with zero errors.

Long-lived connections. We opened 5,000 and then 15,000 TLS connections, kept them for a minute and sent a request on every one of them every 20 seconds. All 15,000 stayed up and all 45,000 requests were answered. The proxy used 85 MB of memory for them, about 5 KB per connection, and under 2 CPU cores.

What the numbers mean, and what they don't

• The handshake figure is not the proxy's limit. In passthrough mode the expensive part of TLS happens on the server behind the proxy. Ours had 4 cores and became the bottleneck, together with the load generator. HAProxy itself used about 3 of its 18 cores at the busiest point.
• The real ceiling is the connection limit: 20,000 open connections per node, which we set ourselves. 15,000 held without trouble.
• It wasn't free. During the heaviest 30-second step the node's load briefly rose well above its core count, almost all of it from our test client and test server rather than the proxy. Our probe's handshake time went from its usual 15 to 20 ms to as much as 1 second at that moment, and to 2.7 seconds once while we opened 15,000 connections within 20 seconds. That's why we kept each step short, and why we'd run a test like this again only at a quiet hour.
• This is one node and one short test, not a lab benchmark. Real traffic is spread over many visitors and many customer servers, which is easier on the proxy than one test server taking everything.

What this means for your server

If you host a website on natbox, the shared proxy is very unlikely to be what slows you down. Your own server, with its share of CPU, will run out of TLS handshakes long before the proxy does. If you want to skip the proxy completely, add an AAAA record: IPv6 visitors then connect straight to your server, with HTTP/3 if you enable it. You link a domain in the client area (guide).

We'll keep publishing numbers like these as natbox grows. If you'd like to see a test we haven't run, tell us at support@natbox.io.

Get new tutorials in Telegram. Follow @natboxio: every new post, plus short server tips.

When a disk fills up, apps start failing in odd ways: databases stop writing, updates break halfway, and logins can get slow. Small servers fill up faster, so it pays to know where the space goes. Here is how to find out in a few minutes, and what is safe to delete.

About 10 minutes. Debian and Ubuntu commands; the checks work the same on AlmaLinux and Alpine.

1. How full is the disk?

df -h / shows the size of your disk, how much is used and how much is left. On your server the first column shows your own server's name. The Graphs tab in the client area shows the same number. Above about 85% it is time to clean up.

2. Which folders are big?

du adds up folder sizes. Start at the top and work down into the biggest folder:

3. Or browse it with ncdu

ncdu does the same thing with a menu you can move around in with the arrow keys and Enter. Press d on a file to delete it (it asks first) and q to quit.

apt install -y ncdu
ncdu -x /

4. List the biggest files

Usually a few large files are to blame. This lists every file over 100 MB:

Here it is an old backup someone forgot about, and an app log that was never rotated.

5. Clean up safely

• Package cache: apt-get clean removes downloaded package files. Always safe.
• Old kernels and packages: apt autoremove removes packages nothing needs any more. Read the list before you say yes.
• The system journal: journalctl --vacuum-size=50M keeps only the newest 50 MB of logs. See journalctl --disk-usage first.
• A huge log file an app still writes to: empty it with truncate -s 0 FILE rather than deleting it. If you delete a file a running program has open, the space is only freed when that program restarts.
• Old backups: copy them off the server first (see the backups guide), then delete them.

From 37% to 7% used.

Snapshots use disk space too

Snapshots you take in the client area's Snapshots tab are stored on your server's disk, so a snapshot keeps the files it saved, even after you delete them. If space is tight, delete snapshots you no longer need. More in the docs.

Stop it happening again

• Make your app logs rotate: add a file in /etc/logrotate.d/, or log to the journal by running the app as a service (how).
• Cap the journal for good: set SystemMaxUse=100M in /etc/systemd/journald.conf, then systemctl restart systemd-journald.
• Keep backups off the server, not next to the data they protect.

Still short of space? You can move to a bigger plan from the client area at any time. See the plans.

Get new tutorials in Telegram. Follow @natboxio: every new post, plus short server tips.

You start a big download or a backup over SSH, your Wi-Fi drops, and the command dies with your connection. tmux fixes that: it keeps a terminal running on the server, so you can disconnect, go home, and pick it up again later exactly where it was.

About 5 minutes. Works on any natbox plan. Commands for Debian and Ubuntu; on AlmaLinux use dnf install -y tmux, on Alpine apk add tmux.

1. Install tmux and start a session

Log in to your server (ssh root@natbox.io -p YOUR_PORT), install tmux and start a session with a name you will remember:

apt install -y tmux
tmux new -s download

2. Run your long command inside it

You are now inside tmux: it looks like a normal terminal, with a green bar at the bottom showing the session name. Start anything that takes a while. Here we download a 756 MB Debian image:

3. Detach, and log out if you like

Press Ctrl+B, let go, then press D. You are back in your normal shell, and tmux tells you the session is still alive. tmux ls lists your sessions. You can now close the window, log out, or lose your connection: the command keeps running on the server.

4. Come back to it

Log in again, from any computer, and reattach:

tmux attach -t download

Everything is where you left it. Our download had kept going and was at 94%:

When the command has finished, type exit to close the session.

5. Bonus: two panes side by side

Inside tmux, Ctrl+B then % splits the window in two. Here the left pane follows an app's log with journalctl -fu myapp while the right pane checks memory and disk. Ctrl+B then an arrow key moves between panes.

The keys you need

• tmux new -s NAME: start a session. tmux ls: list sessions. tmux attach -t NAME: go back in.
• Ctrl+B then D: detach. Ctrl+B then % or ": split side by side or top and bottom.
• Ctrl+B then [: scroll back with the arrow keys or Page Up; Q to stop scrolling.

tmux or a service?

tmux is for jobs you start by hand and want to watch: downloads, backups, updates, a game server console. Anything that should run all the time and start again after a reboot, such as a bot or a website, belongs in a systemd service instead: see Keep an app running. A tmux session does not survive a server restart.

No server yet? Try one free for a month.

Get new tutorials in Telegram. Follow @natboxio: every new post, plus short server tips.

A lot has changed in the client area over the last few days. Here is everything new, and where to find it.

Manage your servers from Telegram

@NatboxBot lets you check and control your servers from Telegram. Link it from the Telegram page in the client area (account menu, then Telegram). After that you can:

• see each server's status, SSH command, ports, IPv6 address, traffic and paid-until date;
• start, stop and restart a server (stop and restart ask you first);
• pay an unpaid invoice from your account credit, or open it on the website to pay another way;
• get notices for new invoices, payments, support replies, and when a server is set up or a trial is about to end.

The bot also has a small app (the Open app button) with the same features. You can even create an account in the bot. For safety the bot never shows passwords and cannot reinstall a server, and there are no payments inside Telegram.

Snapshots you control

The new Snapshots tab on each server saves the server exactly as it is, for example before a big update, and lets you go back to it later. You can keep 1 snapshot on the free trial and the VPN plan, 2 on Nano, 3 on Box and Box CPU, and 5 on Box Plus. Snapshots use your server's disk space and are stored on the same machine, so keep your own off-site backups as well. The backups guide shows how.

Keep your free trial server

If you like your free trial, you no longer need to start again on a new server. Open the trial in the client area and choose a paid plan to keep it, with all your files and settings. We also email you 7 days and 2 days before a trial ends, so it never ends by surprise.

PayPal from $1

You can now pay with PayPal from $1, so a single month of Nano or Box can be paid directly. Crypto payments start at $3, and account credit works for any amount. The VPN plan and burner servers have their own payment options, listed in the docs.

CaptchaBox: a free captcha for your own sites

CaptchaBox keeps bots out of your website's forms without image puzzles, cookies or Google. Visitors' browsers solve a small puzzle in the background, and your server checks the answer. It is free for 10,000 checks a month, and switching from reCAPTCHA is easy because the server check uses the same answer format. We use it on our own sign-in and sign-up pages.

What's next

Follow this blog for tutorials and news, or subscribe with the RSS feed. You can also watch our videos. Questions or ideas: open a ticket.

Get new tutorials in Telegram. Follow @natboxio: every new post, plus short server tips.

natbox runs small Linux servers with root over SSH, your own block of IPv4 ports and a routed /80 of IPv6, from $1.00 a month. This blog is where we will post step-by-step tutorials, longer guides, and news when something changes on our side.

What you will find here

• Tutorials: one task from start to finish, with every command, written for a natbox server but useful on any Linux VPS.
• Guides: the background to the tutorials, such as how NAT ports and IPv6 work, and how to choose a plan.
• Announcements and updates: new features, changes to plans, and anything that affects your server.

Our reference guides stay in Guides, and the basics of your account are in the docs. Blog posts link to them rather than repeat them.

New: videos

We have also put all our videos on one page: natbox.io/video. They play from our own server, with no YouTube embed and no cookies, and the longer ones have English captions.

• Get a free server and log in over SSH (2:10): start a free trial, log in, change your password, and see how your ports and IPv6 work.
• Host a Discord bot 24/7 (1:39): install a bot, keep its token safe, and run it as a systemd service that restarts by itself.
• Three Shorts of under 35 seconds, including what a NAT VPS is.

Follow along

Add natbox.io/blog/feed.xml to your feed reader, or follow us on X and YouTube. If there is a tutorial you would like to see, open a ticket or email support@natbox.io.

New to natbox? Try a server free for a month.

Get new tutorials in Telegram. Follow @natboxio: every new post, plus short server tips.