Reverse Proxy with Cloudflare Tunnel Phase - 3 (OCI)
The Easiest Way to Expose Uptime Kuma to the Internet (Using Cloudflare Tunnel) If you’ve ever struggled with setting up a reverse proxy for your self-hosted apps like Uptime Kuma, you’re not alone. Traditional tools like Nginx, Caddy, and Traefik ca...
#cloudflared#devops#reverse-proxy#oracle-cloud#oracle#tunnel#tunneling#cloudflare#devops-articles#devops-trends#devopscommunity#devops-journey#devsecops#devsecops-solutions#full-stack
Responses
Markdown supported · ⌘↵ to post
A Cloudflare Tunnel acting as the public reverse proxy stays boring when each hostname maps to a Compose service name and internal port on the same user-defined network as cloudflared — not a host-published localhost that vanishes once the connector itself runs in a container. Prefer hostname-shaped ingress over path splits unless the upstream (Uptime Kuma or similar) truly understands those prefixes, end with a catch-all that fails closed, and put Zero Trust Access in front of admin UIs before the app login ever renders. TLS can terminate at the Cloudflare edge for the public name while the tunnel hop stays private; mixing cleartext client expectations with TLS public dials is a common “works on the LAN, fails remotely” trap.
After a config reload I check active connectors and tunnel availability first, curl the upstream by service name from inside the cloudflared network, then hit the same hostname through the public edge. A 502 with a healthy connector is almost always wrong port, wrong network membership, or leftover ingress aimed at a renamed service. When you add a second connector for HA, every member must reach that backend — otherwise failover just moves the miss to a box that cannot see the service.