Fix: Cloudflare Tunnel 502 Bad Gateway Error with Open WebUI & Ollama

Navigating to your custom domain routed through a Cloudflare Tunnel (cloudflared) returns a 502 Bad Gateway (Host Error) or connection timeout when accessing Open WebUI or Ollama backends.

---

Quick Fix

Ensure the cloudflared container shares the exact same Docker bridge network as open-webui, and configure the Cloudflare Zero Trust public hostname to target the internal container service name and port (http://open-webui:8080), NOT localhost:3000:

# In Cloudflare Zero Trust Dashboard -> Public Hostnames:
Service Type: HTTP
URL: open-webui:8080

(Note: Open WebUI listens internally on port 8080. Port 3000 is only the host port mapping).

---

Symptoms

• Browser Error: Cloudflare branded error screen displaying “Error 502: Bad Gateway” or “Host Error”.
• Tunnel Logs: docker logs cloudflared shows dial tcp: lookup open-webui: no such host or connect: connection refused.
• Local vs Domain Mismatch: The UI loads properly via http://YOUR_SERVER_IP:3000, but fails when requested through your ai.yourdomain.com Cloudflare tunnel domain.

---

Root Causes of Cloudflare Tunnel 502 Errors

1. Docker Network Isolation: The cloudflared container and open-webui container exist on different Docker networks, preventing internal DNS resolution.
2. Port Mismatch (8080 vs 3000): Pointing the tunnel destination to the external host port 3000 instead of the internal container listener 8080.
3. Localhost Resolution Failure: Setting the tunnel URL to http://localhost:8080 inside a containerized tunnel. In Docker, localhost refers to the tunnel container itself, not the host machine or adjacent containers.
4. TLS Handshake Drop (Missing No-TLS Verify): Pointing the tunnel service to https://open-webui:8080 without a trusted SSL certificate inside the container.

---

Step-by-Step Fix

1. Unified Docker Compose Network

Configure both services within a dedicated bridge network in docker-compose.yml:

version: '3.8'

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    networks:
      - ai_mesh

  tunnel:
    image: cloudflare/cloudflared:latest
    container_name: cloudflare-tunnel
    restart: unless-stopped
    command: tunnel --no-autoupdate run --token ${CLOUDFLARE_TUNNEL_TOKEN}
    networks:
      - ai_mesh

networks:
  ai_mesh:
    driver: bridge

---

2. Cloudflare Zero Trust Dashboard Configuration

1. Open the Cloudflare One / Zero Trust Dashboard > Networks > Tunnels.
2. Select your active tunnel and click Configure.
3. Under the Public Hostnames tab, edit your route:
   • Subdomain: ai (e.g., ai.yourdomain.com)
   • Service Type: HTTP
   • URL: open-webui:8080
4. Under Additional application settings > TLS, if using HTTPS internally, toggle No TLS Verify to ON. (For standard Docker bridge setups, keep Service Type as HTTP and No TLS Verify is not needed).

---

3. Verification & Connectivity Diagnostic

Test direct network connectivity between the tunnel and the Open WebUI service:

# 1. Test DNS and HTTP response from inside the tunnel container
docker exec -it cloudflare-tunnel curl -I http://open-webui:8080

# Expected output:
# HTTP/1.1 200 OK
# Content-Type: text/html; charset=utf-8

# 2. Inspect real-time tunnel logs for active requests
docker logs -f cloudflare-tunnel

---

Related Guides & Blueprints

• Blueprint: Private AI Stack: Ollama, Open WebUI & OPNsense
• Backend Troubleshooting: Fix: Open WebUI Connection Refused & Ollama Not Found
• Production Serving: How to Deploy vLLM on a VPS with Docker

Root Cause Analysis & Deep Diagnostics

┌────────────────────────────────────────────────────────────┐
│                DIAGNOSTIC WORKFLOW MATRIX                  │
│                                                            │
│  1. Check Kernel & Driver State (dmesg / nvidia-smi)       │
│  2. Inspect Container Runtime Logs (docker logs -f)        │
│  3. Verify Host Network Bindings (netstat / ss -tulpn)    │
│  4. Validate Environment Variables & Secret Tokens         │
└────────────────────────────────────────────────────────────┘

Diagnostic Command Sequence

Run the following diagnostic script to isolate kernel, container, and memory bottlenecks:

#!/usr/bin/env bash
set -euo pipefail

echo "=== System Kernel & Driver Status ==="
uname -r
nvidia-smi || echo "NVIDIA Driver missing or unloaded"

echo "=== Container Health & Port Allocation ==="
docker ps --format "table {{.Names}}	{{.Status}}	{{.Ports}}"

echo "=== Memory & Swap Diagnostics ==="
free -h
swapon --show

echo "=== Systemd Service Logs ==="
journalctl -u docker -n 50 --no-pager

Comprehensive Failure Modes & Solution Matrix

Error Code / Log Entry	Underlying Root Cause	Verification Command	Resolution Procedure
CUDA_ERROR_OUT_OF_MEMORY	Context window exceeds allocated VRAM	nvidia-smi	Enable 4-bit quantization (AWQ/GPTQ) or reduce --max-model-len.
docker: unknown option --gpus	Missing NVIDIA Container Toolkit hook	docker info | grep Runtime	Run sudo nvidia-ctk runtime configure and restart Docker.
502 Bad Gateway	Reverse proxy routed before backend ready	curl -Iv http://localhost:8000	Add container dependency healthchecks in docker-compose.yml.
Permission denied (publickey)	Incorrect SSH or token permission	ls -la ~/.ssh/	Fix file permissions: chmod 600 ~/.ssh/id_rsa.

---

Step-by-Step Verification Procedure

1. Verify Backend Availability: Ensure the backend container process is listening on the expected loopback interface using ss -tulpn | grep <port>.
2. Validate Payload Responses: Send a synthetic request payload using curl with verbose output -v to confirm HTTP 200 OK status.
3. Monitor System Telemetry: Watch memory and CPU counters in real time with htop or docker stats during peak request load.