Cloudflare Tunnel Ports Explained: HTTP, SSH, and UDP

The question landed in my chat inbox late on a Thursday afternoon from an infrastructure client: “Danu, we are deploying Cloudflare Tunnel for our internal staging cluster. Which inbound ports do we need our network security team to punch open in the edge firewall?”

I could not help but smile. Fifteen years ago, when I was managing perimeter hardware firewalls as a junior technician, the concept of exposing a web service or an SSH bastion without opening a listening port sounded like pure snake oil.

“Zero,” I typed back. “You do not open a single inbound port. In fact, if anyone asks you to forward port 80, 443, or 22 on your perimeter gateway for Cloudflare Tunnel, they fundamentally misunderstand how the tunnel works.”

There was a five-minute silence on the other end. Then came the follow-up: “Wait, if no ports are open on our firewall, how does external traffic reach our local services? And what about UDP for DNS or gaming servers?”

This confusion is universal among developers and sysadmins stepping into zero-trust networking. People conflate inbound listening ports on the edge gateway with local service destination ports and outbound transport sockets.

Here is the breakdown of how Cloudflare Tunnel handles ports, protocols, and network packets under the hood.

The fundamental shift in network topology

Traditional remote access relies on NAT port forwarding. When a public visitor requests https://app.yourdomain.com, your border router catches incoming SYN packets on TCP port 443 and pushes them through a NAT rule to your private server IP.

Traditional Port Forwarding:
Public Client ──[Inbound TCP 443]──► Edge Firewall (OPEN PORT) ──► Internal Server (Port 443)

Every forwarded port is an open door into your network. Port scanners like Shodan or Censys map these listening sockets within minutes of the rule being added. If your web daemon has an unpatched zero-day exploit, an attacker talks directly to your private IP.

Cloudflare Tunnel inverts this architecture completely. The lightweight connector daemon, cloudflared, initiates an outbound-only connection from inside your private infrastructure to the nearest Cloudflare edge Point of Presence (PoP).

Cloudflare Tunnel Architecture:
Internal Server ◄──[Local IPC]── cloudflared ──[Outbound QUIC 7844]──► Cloudflare Edge ◄── Public Client
                                (Firewall: NO INBOUND PORTS)

Because modern stateful firewalls permit established outbound traffic, your perimeter router drops all unsolicited inbound connection requests while maintaining the persistent tunnel socket.

The three distinct port layers

To understand Cloudflare Tunnel ports without confusion, you must separate networking into three distinct planes:

1. The Edge Transport Layer (Firewall to Internet): The outbound connection cloudflared uses to talk to Cloudflare servers.
2. The Local Ingress Layer (Connector to Local Services): The private network ports where your actual applications listen (localhost:8080, 192.168.1.50:22).
3. The Public Ingress Layer (Visitor to Cloudflare Edge): The standard public ports where external browsers and clients connect (443 for HTTPS).

Layer	Direction	Typical Ports	Firewall Rule Needed
Outbound Edge Transport	Outbound	UDP 7844 (QUIC) or TCP 7844 (HTTP/2)	Allow outbound traffic to Cloudflare IP ranges
Local Application Target	Internal / Loopback	80, 443, 22, 53, 3000, 8080	Strictly local host or private subnet communication
Public Visitor Interface	Inbound at Edge	80 (HTTP), 443 (HTTPS)	Managed by Cloudflare CDN edge servers

1. Outbound edge transport: Port 7844 (QUIC and UDP)

When you run cloudflared tunnel run <TUNNEL_ID>, the daemon establishes multiple multiplexed connections to Cloudflare edge nodes.

By default, modern versions of cloudflared use QUIC (HTTP/3 over UDP) on port 7844.

Why UDP port 7844? UDP eliminates head-of-line blocking. If a packet drops during an SSH session, HTTP web requests traveling over the same multiplexed tunnel do not freeze waiting for retransmission.

If your enterprise firewall blocks outbound UDP traffic on port 7844, cloudflared falls back automatically to HTTP/2 over TCP port 7844, keeping the same port but swapping the transport.

To verify your outbound transport protocol:

cloudflared tunnel info <TUNNEL_ID>

You will see active edge connections logged with protocols like quic or http2.

2. Local service routing: HTTP, SSH, and arbitrary ports

Inside your network, cloudflared acts as a reverse proxy client. It reads the incoming request encapsulated within the tunnel and issues a standard HTTP, TCP, or UDP call to your local application.

In your local configuration file (config.yml):

tunnel: a1b2c3d4-e5f6-7890-abcd-ef1234567890
credentials-file: /etc/cloudflared/cert.json

ingress:
  - hostname: gitlab.example.com
    service: http://localhost:8080
  - hostname: terminal.example.com
    service: ssh://192.168.1.15:22
  - hostname: dns.example.com
    service: tcp://192.168.1.20:53
  - service: http_status:404

Notice that gitlab.example.com routes to local port 8080, while terminal.example.com routes to private SSH port 22. None of these local services need to listen on public interfaces. They can bind exclusively to 127.0.0.1 or a private VLAN.

3. Handling UDP through Cloudflare Tunnel

One of the most persistent myths is that Cloudflare Tunnel only supports HTTP web traffic.

While the free web dashboard ingress rules primarily handle HTTP and HTTPS hostnames, cloudflared natively routes raw TCP and UDP traffic through its Private Network Routing (WARP to Tunnel) feature.

If you are running private DNS resolvers (UDP port 53) or internal VoIP signaling, you advertise the private subnet through the tunnel:

cloudflared tunnel route ip add 10.0.0.0/24 <TUNNEL_ID>

When remote team members connect via the Cloudflare WARP client, their UDP packets are encapsulated securely and routed directly across the private tunnel to the internal target host.

Common misconceptions in production

Over the years, I have seen experienced infrastructure engineers tie themselves in knots over these four tunnel myths:

What people assume	The technical reality in production
”I must open port 443 on my router for SSL”	Cloudflare Edge handles public TLS certificates. Your router stays closed
”SSH through tunnel is exposed to everyone”	SSH requires Cloudflare Access Zero Trust policy authentication first
”Tunnel introduces massive latency over UDP”	QUIC transport on port 7844 often outperforms TCP due to zero head-of-line blocking
”If cloudflared crashes, my server gets hacked”	A crashed daemon simply drops the connection. It leaves zero ports listening

In our Cloudflare Tunnel vs Port Forwarding comparison, we demonstrated how an open port on a router invites immediate bot scans, whereas a tunnel keeps your public IP completely dark.

Hardening the tunnel connector host

Even though Cloudflare Tunnel eliminates inbound firewall exposure, the host running cloudflared must still be secured properly:

1. Run cloudflared as an unprivileged system user: Never run the daemon as root. Systemd service templates should isolate execution under a dedicated cloudflared system account.
2. Restrict local outbound interfaces: Ensure the connector host cannot arbitrarily route traffic into sensitive management VLANs unless explicitly required.
3. Audit Linux host baseline: The principles of restricting SSH keys, auditing sudo privileges, and managing daemons apply equally to tunnel hosts. Refer to our Linux server hardening best practices for production hardening checklists.

Step-by-step debugging when the tunnel won’t connect

When cloudflared fails to negotiate with Cloudflare edge PoPs, throwing socket timeout errors or connection refusal, run through these exact debugging steps.

Step 1: Validate local DNS and outbound UDP socket reachability

Many corporate egress firewalls silently drop outbound UDP packets on non-standard ports. Test if UDP 7844 is reaching Cloudflare using nc:

nc -z -v -u region1.v2.argotunnel.com 7844

If the connection hangs or reports filtered, your network gateway is dropping outbound QUIC traffic. You can force cloudflared to operate over standard TCP:

cloudflared tunnel --protocol http2 run <TUNNEL_ID>

Under HTTP/2, cloudflared encapsulates all tunnel traffic across multiplexed TLS sessions on TCP port 7844, which gets through most corporate egress filters that only block UDP.

Step 2: Test local service reachability from the connector host

A common rookie mistake is verifying that the web service works from your desktop browser, but forgetting that cloudflared evaluates hostnames and ports from the perspective of the machine where the daemon is installed.

If your config.yml defines:

ingress:
  - hostname: internal.example.com
    service: http://127.0.0.1:3000

Log into the tunnel connector host and test the target socket directly:

curl -I http://127.0.0.1:3000

If curl returns Connection refused, your application is bound to a specific IP rather than 0.0.0.0 or 127.0.0.1, or the application crashed before the tunnel could forward traffic.

Real field story: The UDP VoIP migration that choked

A few years ago, a logistics client asked me to migrate an internal PBX VoIP server behind Cloudflare Tunnel to protect it from SIP scanner botnets. Their engineers configured the tunnel ingress, but phone calls dropped audio after three seconds.

The issue was protocol mismatch. SIP signaling traveled over TCP, but the Real-time Transport Protocol (RTP) audio stream relied on high-volume dynamic UDP ports. Because their cloudflared instance was forced into HTTP/2 fallback due to an egress firewall restriction, UDP encapsulation was completely disabled.

Once we opened egress UDP port 7844 on their border router and enabled QUIC transport, the audio stream flowed with sub-20ms latency and crystal-clear packet ordering.

Summary checklist for network administrators

Before concluding that Cloudflare Tunnel is broken or blocked:

• Confirm outbound UDP port 7844 is allowed in your perimeter egress policy.
• If UDP is restricted by corporate policy, configure --protocol http2 to enforce TCP port 443 fallback.
• Verify local target services are running and listening on the specified loopback or internal IPs.
• Never forward ports on your router or border firewall for tunnel operations.

Zero-trust architecture feels unfamiliar when you grew up on router port forwards. But once you realize that ports are an internal detail rather than a public invitation, your attack surface shrinks to nearly zero.

Are you running Cloudflare Tunnel over QUIC or HTTP/2 in your homelab or production stack? What protocol issues have you run into?