If you have ever put a service on the internet from your home network, you have run into two ideas that sound harder than they are: routing and tunnelling. They solve different problems, and they work well together.

The idea without the jargon

Imagine you run a small shop inside a gated housing complex. The guard at the gate doesn’t let strangers walk in, so customers can’t just knock on your door. That is your home network: people inside can go out, but nobody from outside can come in.

So you make a deal with a head office in the city. Every morning you phone them, and you leave the line open all day. Customers don’t call you. They call the head office, and the receptionist there asks, “Which shop do you want?” Then she passes the message down your open line, you answer, and she passes your reply back.

• The receptionist choosing the right shop is routing. She has a list of names and where each one goes.
• The phone line you opened yourself is the tunnel. Because you made the call, the guard had no reason to stop it.

The gate never opened, and the customers never learned where your shop is. Everything below is this same story with the technical names put back in.

Routing: deciding where traffic goes

Routing is making a decision about where a request should go next. It happens at several levels:

• Network routing: routers look at an IP address and pick the next hop towards it. Your home router does this for every packet leaving your network.
• Hostname routing: a web server or reverse proxy looks at the name in the request, such as blog.example.com, and sends it to the right application.
• Path routing: the same server looks at the URL path, so /api goes to one service and / goes to another.

In every case there is a table of rules, and the first rule that matches wins. When traffic ends up in the wrong place, the cause is almost always a rule that is missing, too broad, or in the wrong order.

Tunnelling: carrying traffic inside other traffic

A tunnel wraps one connection inside another so it can cross a network it would not otherwise cross. The outer connection is the carrier. The inner traffic rides inside it and comes out at the other end.

Common examples:

• A VPN carries your network traffic through an encrypted tunnel to another network.
• An SSH tunnel forwards a port over an SSH connection. ssh -L 8080:localhost:80 server makes port 80 on the server appear as port 8080 on your machine.
• HTTPS inside a proxy uses a tunnel too: the proxy opens a raw connection and just passes bytes along.

The problem tunnels solve at home

Most home networks sit behind NAT. Your router has one public address, and devices inside have private ones. Connections you start from inside work fine. Connections someone else starts towards you are dropped, because the router doesn’t know which device they are for.

The traditional fix is port forwarding: you tell the router to send incoming traffic on a port to one device. It works, but it exposes a port on your home address, and it breaks if your provider puts you behind carrier-grade NAT or changes your IP.

Reverse tunnels

A reverse tunnel turns the problem around. A small agent on your machine makes an outbound connection to a service on the internet and keeps it open. Outbound connections are allowed through NAT. When a visitor connects to the public service, it sends their request back down the connection you already opened, and the agent passes it to your local application.

Nothing inbound is ever opened on your router. Cloudflare Tunnel, ngrok and similar tools work this way.

How the two fit together

A typical setup has both ideas in it:

1. A visitor goes to blog.example.com. DNS points that name at the tunnel provider.
2. The provider receives the request and looks up a route for that hostname.
3. The route says “send it down tunnel A”.
4. The agent at the other end of tunnel A receives it and forwards it to a local address, such as localhost:4321.
5. The response goes back the same way.

One tunnel can carry many routes. Adding a second site is just another rule, mapping a new hostname to another local port. You don’t open a new port or change the router.

Things to watch for

• The agent is a single point of failure. If it stops, the site goes down. Run it as a service so it restarts on its own.
• You are trusting the provider. Traffic is decrypted at their edge. That is usually fine for a blog and worth thinking about for anything private.
• A tunnel does not secure your application. It hides your address, but a vulnerable app behind it is still vulnerable. Keep it patched, and use access controls for anything that isn’t meant to be public.
• Debug in layers. When it breaks, check DNS first, then whether the route exists, then whether the agent is connected, then whether the local service answers. Each layer has its own typical error.

When to use what

• Hosting a public site from home: a reverse tunnel is simpler and safer than port forwarding.
• Reaching your own machines from anywhere: a VPN or mesh network is a better fit than exposing them publicly.
• One-off access to a single port: an SSH tunnel is enough.

Routing decides where traffic should go, and tunnelling gets it there when the direct path is closed. Once you see them as separate pieces, most networking setups stop looking mysterious.