saltwaterbrc
Go back

Cloudflare Spectrum: Protecting Non-HTTP Traffic at the Edge

Cloudflare’s reputation is built on protecting HTTP and HTTPS traffic. The WAF blocks malicious requests. Page Shield protects JavaScript. Rate Limiting stops bots. The DDoS protection system absorbs volumetric attacks.

But here’s what most people don’t realize: not everything on the internet is HTTP.

SSH servers. RDP endpoints. Game servers. Database connections. IoT devices. Email. FTP. VPN traffic. MQTT brokers. Minecraft instances with a thousand concurrent players. All of these run on Layer 4 (TCP/UDP), and for years, they were left exposed to the internet with no protection layer in front of them.

That’s what Cloudflare Spectrum fixes.

Why Spectrum Exists

Cloudflare built its entire product suite around HTTP/HTTPS protection. That’s where the internet’s consumer-facing traffic lives — websites, APIs, CDN. But the deeper you go into infrastructure, the more you hit non-HTTP protocols.

SSH (port 22) — how system administrators remotely access servers. RDP (port 3389) — how Windows users remote desktop into machines. Databases — MySQL (3306), PostgreSQL (5432), Redis (6379), MongoDB (27017). Game servers — Minecraft (25565), Rust, ARK, CS2, Valheim. Email — SMTP (25/587), IMAP (993), POP3 (995). IoT & Industrial — MQTT (1883), SCADA systems, sensor networks.

All of these protocols run over TCP or UDP. None of them speak HTTP. And for a long time, if you wanted to expose these services to the internet, you had two options: accept the risk or hide behind a VPN.

Spectrum changes that. It extends Cloudflare’s Layer 4 DDoS protection to any TCP/UDP protocol. No agents. No special clients. No installation required. Just a DNS change and a Spectrum configuration.

Real-World Use Cases

Gaming Servers: The #1 DDoS Target

Minecraft is the most obvious example. A popular Minecraft server might have 500-1000 concurrent players at any given time. The server runs on TCP port 25565 and needs to be publicly accessible for players to join.

Here’s the problem: the second a player joins, they know the server’s public IP address. From there, any player with access to a DDoS booter (cheap, readily available on underground forums) can launch an attack. A volumetric attack can take down even a well-provisioned server in seconds.

Without protection, a single malicious player can nuke the entire server for hundreds of other players. The owner loses money (server hosting costs), player trust, and revenue.

With Spectrum, the Minecraft server’s real IP is completely hidden. Players connect to play.example.com which resolves to Cloudflare’s anycast network across 330+ cities globally. The server only sees Cloudflare’s edge IP. Volumetric attacks get absorbed across Cloudflare’s global backbone. The server stays online.

This applies to every game server: Rust, ARK, Valheim, Counter-Strike 2, Palworld. Spectrum is invisible to the player — they just join and play — but it’s a massive layer of protection for the server operator.

SSH & Bastion Hosts

Enterprises run jump boxes or bastion hosts to gate access to their internal infrastructure. These are hardened SSH servers that sit between the internet and your private network. An engineer needs to SSH into the bastion first, then from there SSH into internal machines.

The bastion’s IP address is naturally exposed to the internet — that’s the point. But that also makes it a juicy target for brute-force attacks, zero-day exploits, and protocol-level DDoS.

Spectrum proxies SSH traffic. The bastion server only accepts connections from Cloudflare’s IP ranges. The real origin IP stays hidden. Any DDoS attack against the bastion gets absorbed at Cloudflare’s edge before reaching the server.

Production Databases

MySQL, PostgreSQL, Redis, MongoDB — running a database on the public internet is generally a bad idea. But some workloads require it: multi-region setups, managed cloud databases, or edge applications that need direct database access.

These databases are constantly attacked. Port scanners find them. Exploit scanners test for known CVEs. Credential stuffing attempts brute-force passwords. Volumetric attacks try to exhaust connections.

Spectrum adds a protection layer. The database origin IP is hidden. Cloudflare’s L4 DDoS protection filters malicious traffic before it reaches the database server. Connection limits, rate limiting, and geo-blocking can be applied at the edge.

RDP (Windows Remote Desktop)

RDP (port 3389) is one of the most exploited protocols on the internet. Attackers scan the internet looking for open RDP ports. If they find one, they run credential-stuffing attacks or try known RDP exploits.

Spectrum proxies RDP connections. The Windows server is hidden behind Cloudflare’s network. Only clean connections reach the origin.

IoT & Industrial Control Systems

MQTT brokers, SCADA systems, and industrial IoT devices often need to communicate over the public internet. They’re not web servers. They don’t speak HTTP. But they’re critical infrastructure.

Spectrum protects these without requiring the devices to install agents or change their protocol. The MQTT broker runs on port 1883, Spectrum proxies it, and the origin IP stays hidden.

What I Built: A Real Spectrum Setup

I decided to walk through the entire setup end-to-end. Here’s what I built:

  1. A DigitalOcean VPS — a basic cloud server running Ubuntu 24.04
  2. A Cloudflare Spectrum app — proxying SSH (TCP/22) through Cloudflare’s network
  3. Firewall rules — locking down the origin so it only accepts connections from Cloudflare

The goal: demonstrate origin IP masking, show how traffic flows through Spectrum, and prove that the only way to access the SSH server is through Cloudflare.

Step 1: Create a VPS

First, I created a DigitalOcean Droplet. This is a virtual Linux machine that I’ll use as the “origin” server.

Head to DigitalOcean → Droplets → Create Droplet.

Configuration:

I named the droplet spectrum-ssh to keep things organized.

Within a minute, the droplet is live. DigitalOcean assigns it a public IP address — something like 123.45.67.89. This is the origin server that I’ll put behind Spectrum.

Step 2: Test Direct SSH

Before setting up Spectrum, I confirmed that SSH works when connecting directly to the origin IP.

ssh -l root 123.45.67.89

I’m prompted for the password, I enter it, and I’m logged in. The Ubuntu shell greets me with a banner showing the server’s hostname and OS version.

This proves the server is reachable. It also proves that right now, the origin IP is exposed to the entire internet. Anyone can scan for port 22 on that IP and attempt to access it.

Step 3: Create the Spectrum App

Now I configured Cloudflare Spectrum to proxy SSH traffic.

I logged into my Cloudflare dashboard for saltwaterbrc.com, navigated to the zone, and found Spectrum in the sidebar.

Spectrum → Create Application

Configuration:

I left other settings at defaults and saved. Cloudflare immediately provisioned the app across its global network.

Behind the scenes, Cloudflare is now:

  1. Listening for TCP connections on port 22 at ssh.saltwaterbrc.com
  2. Resolving ssh.saltwaterbrc.com to Cloudflare’s anycast IP (not my origin)
  3. Proxying clean connections to 123.45.67.89:22

Step 4: Test SSH Through Spectrum

Now I test SSH through Spectrum instead of directly to the origin.

ssh -l root ssh.saltwaterbrc.com

I enter the same password and… I’m in. The shell looks the same, the server is the same, but the network path is completely different.

To verify origin IP masking, I ran a quick command:

who -a

This shows login sessions and where they connected from. The key detail: the session shows the IP address that the server sees. Instead of seeing my real public IP, it shows an IP in the 104.28.x.x range — a Cloudflare IP.

This is origin IP masking in action. The SSH server has no idea where I actually came from. It only knows that Cloudflare sent the connection.

Step 5: Lock Down the Origin (The Critical Part)

Here’s where the real security happens. Right now, you can still SSH directly to 123.45.67.89. Spectrum is an optional proxy, but the origin is still exposed.

The whole point of Spectrum is that the origin IP should not be directly accessible. We want to force all traffic through Cloudflare.

I configured the VPS’s firewall (UFW) to only accept SSH connections from Cloudflare’s IP ranges.

First, I enabled UFW and allowed SSH from each of Cloudflare’s IPv4 CIDR ranges:

# Allow SSH only from Cloudflare IPv4 ranges
ufw allow from 173.245.48.0/20 to any port 22
ufw allow from 103.21.244.0/22 to any port 22
ufw allow from 103.22.200.0/22 to any port 22
ufw allow from 103.31.4.0/22 to any port 22
ufw allow from 141.101.64.0/18 to any port 22
ufw allow from 108.162.192.0/18 to any port 22
ufw allow from 190.93.240.0/20 to any port 22
ufw allow from 188.114.96.0/20 to any port 22
ufw allow from 197.234.240.0/22 to any port 22
ufw allow from 198.41.128.0/17 to any port 22
ufw allow from 162.158.0.0/15 to any port 22
ufw allow from 104.16.0.0/13 to any port 22
ufw allow from 104.24.0.0/14 to any port 22
ufw allow from 172.64.0.0/13 to any port 22
ufw allow from 131.0.72.0/22 to any port 22

# Set default policies
ufw default deny incoming
ufw default allow outgoing

# Enable the firewall
ufw enable

After this, the firewall is locked down. Port 22 is only open to Cloudflare’s IP ranges.

Now, if I try to SSH directly to the origin IP:

ssh -l root 123.45.67.89

Connection times out. The firewall blocks it. The only way to SSH into the server is through Spectrum:

ssh -l root ssh.saltwaterbrc.com

This works perfectly because Spectrum is routing the connection from one of Cloudflare’s IPs (which are whitelisted), so the firewall allows it.

How Spectrum Works: The Technical Flow

Let me break down what’s happening at each layer when I SSH into ssh.saltwaterbrc.com:

Step 1: DNS Resolution

$ dig ssh.saltwaterbrc.com +short
104.28.13.45

The domain resolves to a Cloudflare IP, not the origin IP. This is Cloudflare’s anycast IP — shared across thousands of servers globally.

Step 2: TCP Connection to Edge My SSH client connects to 104.28.13.45:22. But which Cloudflare data center? The one that’s geographically closest to me — Cloudflare’s anycast magic handles this automatically.

Step 3: L4 DDoS Inspection At the Cloudflare edge, the connection passes through Spectrum’s L4 DDoS filters:

Step 4: Traffic Forwarding Clean connections are forwarded to the origin. Spectrum looks up the origin address (123.45.67.89:22) and opens a new TCP connection to it.

From the origin’s perspective, the connection came from a Cloudflare IP. The origin server has no way to know where the real client is located.

Step 5: SSH Protocol The SSH protocol handshake happens normally. SSH banner exchange, key exchange, authentication — all transparent to Spectrum. Spectrum is just forwarding the TCP packets.

Step 6: Analytics & Monitoring Cloudflare’s Spectrum dashboard logs every connection:

Key Selling Points of Spectrum

1. Origin IP Masking

Your origin server’s IP is completely hidden. Attackers can’t find it through DNS enumeration, port scanning, or leaked data. They have to go through Cloudflare.

2. L4 DDoS Protection

Cloudflare’s network absorbs massive volumetric attacks across 330+ cities globally. Attacks that would take down an origin server are distributed and filtered at the edge.

3. No Agents or Installation

Unlike other solutions that require software on every device, Spectrum requires nothing but a DNS change. The server just sees new connections from Cloudflare.

4. Any TCP/UDP Protocol

HTTP, SSH, RDP, databases, games, email, IoT — Spectrum works with any protocol. You’re not limited to web traffic.

5. Pricing Model

Spectrum charges per concurrent connection, not per gigabyte. This makes it economical for high-traffic origins. A game server with 1000 concurrent players costs the same whether they upload 1 GB or 100 GB.

6. Latency is Minimal

Since Cloudflare’s edge has 330+ locations, most connections route through a nearby POP. Latency overhead is typically 1-5ms.

The Minecraft Example: Why Spectrum Matters for Gaming

Let me expand on why Minecraft servers were the original use case for Spectrum.

A popular Minecraft server might host 500-1000 concurrent players at peak hours. Each server generates significant revenue: monthly hosting costs ($200-1000), cosmetics, battle pass sales, premium features.

Without Spectrum:

With Spectrum:

This pattern applies to every game server: Rust, ARK, Valheim, Counter-Strike 2, Palworld. Spectrum is the de facto standard for any game that needs to expose a port to the internet.

Spectrum Analytics & Monitoring

Once Spectrum is live, the dashboard shows real-time stats:

For my SSH setup, analytics show a few connections per day (my own testing), but for a game server or popular service, this would show hundreds or thousands of concurrent connections.

Origin IP Hiding: The Hidden Benefit

A subtle but powerful benefit of Spectrum: your origin IP becomes irrelevant.

In traditional setups, your origin IP is your most valuable secret. If it leaks:

With Spectrum, your origin IP can be:

It doesn’t matter. Without Cloudflare’s intermediary, the origin is unreachable.

Bringing It Together: The Full Setup

Here’s the complete picture of what’s live:

  1. Origin server: spectrum-ssh droplet at 123.45.67.89 (DigitalOcean)
  2. Firewall: UFW only allows SSH from Cloudflare’s IP ranges
  3. Spectrum app: ssh.saltwaterbrc.com → TCP/22 → origin
  4. DNS: ssh.saltwaterbrc.com resolves to 104.28.13.45 (Cloudflare)

The user experience is seamless:

ssh -l root ssh.saltwaterbrc.com

The origin is protected, IP is masked, and DDoS attacks are absorbed at the edge. No agents, no VPN, no complexity.

What’s Next: The Broader Picture

This Spectrum setup brings saltwaterbrc.com to 23 Cloudflare products in active use. The HTTP security layer (WAF, API Shield, Page Shield, Rate Limiting) now has a complement: L4 network security through Spectrum.

Cloudflare’s network security depth is impressive:

Each layer adds another fence around your infrastructure.

The logical next step is exploring the Magic family: Magic Transit (DDoS protection for your whole network), Magic WAN (private networking between offices), and Magic Firewall (stateful firewall rules at Cloudflare’s edge).

For now, Spectrum is live and protecting SSH access to my infrastructure. It’s a small demo, but it illustrates a powerful concept: Cloudflare doesn’t just protect web traffic anymore. It protects everything.

Share this post on:
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email
Previous Post
Build What You Sell: 23 Cloudflare Products on One Site
Next Post
Securing APIs with Cloudflare: API Shield, Schema Validation, and Layered Defense