Cloudflared Setup WOU

Cloudflared Setup WOU

Craig Nielsen

Craig Nielsen

February 23, 2026

Cloudflared setup on some client servers

Cloudflare Tunnel (cloudflared)

What cloudflared is and why it is used

Cloudflare Tunnel (

cloudflared
) creates an outbound-only encrypted connection from this server to Cloudflare's global network. The key consequence of this is that no inbound ports need to be open on the server's firewall. There is no public IP exposed, no port 80 or 443 listening to the internet directly. Instead:

  1. cloudflared
    runs as a service on the server and dials out to Cloudflare over HTTPS (port 443)
  2. Cloudflare holds the public DNS records for all the configured hostnames
  3. When a visitor hits 
    psychicjenha.com
    , the request arrives at Cloudflare's edge, travels back through the established tunnel to this server, and is delivered to 
    localhost
    on the configured port
  4. The response travels the same path in reverse

This means Cloudflare sits in front of every request and provides DDoS protection, TLS termination, and caching before traffic ever reaches the server. The server itself only ever sees connections from 

localhost
— cloudflared delivers them internally.

Visitor browser
      │
      ▼
Cloudflare edge (TLS termination, DDoS protection)
      │  (encrypted tunnel, outbound connection initiated by server)
      ▼
cloudflared daemon on server
      │  (http://localhost:<port>)
      ▼
Nginx server block listening on that port
      │
      ├─ Static site: serves files from /var/www/<site>/
      └─ Proxy: forwards to k3s LoadBalancer → Pod

How the cloudflared config maps to nginx

Each 

ingress
rule in 
/etc/cloudflared/config.yml
maps a public hostname to a 
localhost
port. That port corresponds to a 
listen
directive in one of the nginx 
sites-enabled
files. The table below documents the full mapping:

Public hostnamecloudflared targetNginx 
listen
port		Nginx config fileType
weoptimizeyou.co.za
http://localhost:80
80
wou
Static site
www.byteofcode.dev
/ 
byteofcode.dev
http://localhost:8086
8086
bryce
Static

Why multiple ports are used

Nginx uses the combination of 

listen <port>
and 
server_name
to decide which server block handles a request. When all traffic arrives on port 80 (as it does for the 
weoptimizeyou.co.za
family), Nginx uses the 
Host
header to route to the correct block — this is standard virtual hosting.

For sites on non-standard ports (8080, 8081, 8082, 8083, 8086), the port itself is the routing key. cloudflared sends each hostname's traffic to a different port, and there is a dedicated Nginx server block listening on that port. This pattern is used when:

  • Sites need to be kept fully isolated with no shared configuration
  • The sites predate the 
    weoptimizeyou.co.za
    virtual hosting setup and were built as standalone servers
  • Port-based routing is simpler to reason about when there is no single shared parent domain

The 
httpHostHeader
directive

Each ingress rule in the cloudflared config includes:

originRequest:
  httpHostHeader: www.somesite.com

This tells cloudflared to set the HTTP 

Host
header to this value when it forwards the request to 
localhost
. Without it, Nginx would receive a 
Host
of 
localhost
(or nothing useful) and would fail to match the correct 
server_name
block. With it, the 
Host
header arrives intact and Nginx routes correctly — this is especially important for the port-80 virtual hosting setup where 
server_name
matching is the only routing mechanism.

Catch-all rule

The final entry in the cloudflared ingress config is required by cloudflared and acts as a default for any hostname not matched by an earlier rule:

- service: http_status:404

This mirrors the purpose of the Nginx 

server_name _; return 444;
catch-all block — unrecognised hostnames get an immediate error response rather than being proxied somewhere unintended.

← Back to posts