Imagine you run a tiny dessert shop in your dorm room, selling only to people you know. Here's the problem: you don't want to publish your dorm address online, nor do you want strangers to knock on your door, but you still want people to be able to buy from you.
The traditional solution is to hang a sign at the door (router port forwarding), rent an address (dynamic DNS), and then hope that only good customers come. Cloudflared takes a different approach: you hire a delivery platform to handle your orders. Customers only see the platform's storefront; after placing an order, the platform sends someone to pick it up. Your address never appears anywhere else, and you actively go to the platform to check in, not the other way around.
What it actually does
A program called Cloudflared runs on your machine and actively establishes a persistent connection with Cloudflare. When a visitor connects to a Cloudflare edge node, Cloudflare then sends the request along this connection. Your machine has no external ports, and its IP address won't appear in the DNS. Cloudflared itself is open source, Apache-2.0, and Cloudflare provides official container images, making it convenient to pin the version using digests.
I could hardly believe it when I successfully set it up the first time. I hadn't even opened the router's settings page once, and I hadn't added a single firewall rule, yet I was able to connect to the website from the outside. It felt like discovering that you could get in without waiting in line.
Routing table
A tunnel can host many hostnames, each hostname corresponding to "which service on the local machine", for example...blog.example.com Delivered tohttp://127.0.0.1:8080 This table is called ingress. In remote management mode, it exists on the Cloudflare side, and the connector only needs one token to start; in local management mode, it is a YAML file next to the connector.
There's one thing you need to be clear about, and it's best to be clear about it before something goes wrong in the middle of the night: the "local machine" in the table refers to the machine where the connector is located. If the connector is moved to another machine, the destination of the entire table will also be moved. Every service in the table must exist on the new machine; otherwise, the corresponding hostname will return a 502 error.
To use a food delivery analogy: the delivery person remembers "pick up from this building," not "pick up from so-and-so." If you move to the next building, the delivery person will still go to the original building and report that the store is closed. A connector belongs to the tunnel, not to any particular station; a station-by-station migration plan requires first asking "which stations share this tunnel." I learned this lesson after paying tuition—a morning's worth of 502 (likely referring to a type of electrical appliance).
Do not put things you don't want to make public in the routing table.
For things like backend management interfaces, the cleanest protection isn't a password, it's having no routing at all. Make it only listen for the local loopback address and don't write it into the ingress, so it won't be found on the internet; when needed, open an SSH tunnel from your own computer. Scanners will only see the publicly accessible entries.
This isn't like "locking the back door"; this is "there's no back door at all." You don't need to worry about whether the lock is strong enough because there's nothing to pry it open. I think that's the most reassuring part of the whole process.
What does "one tunnel, multiple connectors" mean?
Multiple connectors can run simultaneously within the same tunnel, and Cloudflare distributes traffic among them. This is for high availability: if one machine goes down, the other is still running. It's not a mechanism where "two machines each serve a portion of hostnames."
I initially misunderstood this, thinking I could run a connector on each of the two machines, each responsible for its own site. The result was that requests randomly landed on the machine without the service, with half the requests succeeding and half failing. This was harder to troubleshoot than a complete failure, because even after three attempts, two might work, leading you to assume it was a network instability. For high availability, both machines need to be able to serve the same table, just like two delivery drivers need to know the locations of all stores, not one only knowing the east and the other only the west.
Conflict with strict CSP
Cloudflare's website analytics features inject a piece of JavaScript into each page by default at the edge. If your site's Content-Security-Policy is...script-src 'self' ,No'unsafe-inline' The browser will block this injection, resulting in an extra error in the main console of each page, and analysis data will not be received.
The absurdity of this situation is that neither side is at fault: your CSP is doing its job, and Cloudflare's analytics is doing its job; they just don't get along. The solution is to turn off edge injection, manually place official code snippets on the pages that need analytics, and only on those pages should you relax the CSP restrictions to include the source of the analytics scripts. For pages that don't need analytics, maintain the original policy.
Mini-drama: Is this safe?
"So all your website traffic goes through Cloudflare?"
"Yes, they can see all the requests."
"Aren't you scared?"
"Yes, but the other option is to create a hole in my router and let the whole world knock on my door. Both require trusting something, and I choose to trust a company with thousands of engineers rather than a firewall rule I set up in the middle of the night."
"It sounds like handing the keys to the management office."
"Pretty much. Something could happen in the management office too, but it's better than leaving the key in the door."
Its cost
A single tunnel means a single dependency. If Cloudflare experiences a problem and the connector goes down, all services connected to that tunnel will disappear. The connector's metrics endpoint only listens to the local machine; external monitoring needs to be done separately. I haven't done that yet, which is something I owe, and I'm writing this down to remind myself. Sometimes the biggest use of blogging is to publicly incur a debt, which creates pressure to repay it.
Who is it suitable for?
For those who don't have a fixed IP address, don't want to touch the router, and want to leave TLS and DDoS protection to the edge, the free tier is sufficient. It's simpler to set up than open port forwarding, and the fact that "the machine has no externally exposed ports" itself eliminates a large category of problems.
Back to the dessert shop. Delivery platforms take a cut, have rules, and sometimes crash when you're busiest. But rather than posting my dorm address online, I still choose delivery.
A little background
When this product was launched in 2018, it was called Argo Tunnel and was a paid feature. In 2021, it was renamed Cloudflare Tunnel and made free for everyone. This free move has changed the way many individual developers deploy their systems: previously, setting up a home machine for external use was a tedious task that required figuring out routers, dynamic DNS, and credentials; now it's simply a matter of installing a program and attaching a token.
The Cloudflared connector itself has been open source from the beginning, using Apache 2.0. You can read about how it establishes connections, reconnects, and handles multiple edge nodes. Its connection with Cloudflare automatically selects the nearest data centers and maintains multiple connections. If one connection drops, the others remain open. This is why it is more stable than self-open port forwarding: your home network may be unstable, but it is connected to several locations simultaneously.
Three common misunderstandings
The first misconception is that "tunneling slows down the website." Visitors connect to the nearest Cloudflare node, which then uses its own backbone network to reach the nearest node to you, and finally, your home network. For most visitors, this is faster than connecting directly to your home router because Cloudflare's network is better than your home network.
The second misconception is that "using a tunnel eliminates the need for security." A tunnel protects the "incoming path," and your application still needs its own authentication, input checks, and CSP (Content Support Provider) mechanisms. It blocks direct scans of your IP address, not attacks on your website's logic.
The third misconception is that "a connector can only serve one service." A tunnel can host many hostnames, each pointing to a different port on the local machine, and one connector can handle it all. You don't need to open a tunnel for each station; that would be too much of a hassle to manage.
A small exercise you can try over the weekend
Register a Cloudflare account, point to one of your domains, and the free plan should suffice. Use it on your local machine.python -m http.server 8080 Start a very basic static server and upload any HTML file. Create a tunnel in the Cloudflare dashboard, select remote management, and it will give you an installation command and a token. Run it. Add a route pointing to a specific subnet.http://localhost:8080 .
Then turn off Wi-Fi on your phone and open that subnet using cellular data. You'll see the HTML on your computer, but your router settings haven't changed at all, and your IP address isn't showing up anywhere. This moment is worth experiencing once. After experiencing it, remember to delete the tunnel, or at least remove the router, so that no one...http.server It's always online.
Postscript
The dorm dessert shop analogy actually left something unsaid: delivery platforms know what you're selling and who you're selling to. Cloudflare is the same; all traffic goes through it. This is the price for this approach—not a hidden fee, but a clearly stated price. I paid it because the other option was more expensive for me. Everyone's algorithm is different, but at least you should know what you're paying for.
Project page: github.com/cloudflare/cloudflared