Cloudflare Spectrum can proxy any TCP traffic, not just HTTP.
Let’s see it in action. Imagine you have a game server running on 192.168.1.100:27015 that you want to expose to the internet securely.
First, you’ll set up a Spectrum application in the Cloudflare dashboard. You’ll define the application name (e.g., my-game-server), select the protocol (TCP), and specify the public IP address and port Cloudflare will use (198.51.100.10:27015). Then, you’ll point this to your origin server’s IP and port (192.168.1.100:27015).
Once configured, Cloudflare assigns a public IP address to your Spectrum application. All TCP traffic destined for 198.51.100.10:27015 will hit Cloudflare’s edge. Cloudflare’s Anycast network routes this traffic to the nearest PoP. From there, Spectrum, leveraging Cloudflare’s global infrastructure, establishes a direct TCP connection to your origin server at 192.168.1.100:27015.
This provides several benefits:
- DDoS Protection: Spectrum acts as a shield, absorbing volumetric attacks before they reach your origin.
- Global Anycast Network: Users connect to the closest Cloudflare PoP, reducing latency.
- Origin IP Obfuscation: Your origin server’s IP address is hidden from direct exposure.
- Load Balancing: For multiple origin servers, Spectrum can distribute traffic.
The core of Spectrum’s magic lies in its ability to act as a transparent TCP proxy. It doesn’t inspect the payload for HTTP-specific headers; it simply maintains TCP connections end-to-end, forwarding packets as they arrive. This allows it to handle any protocol that runs over TCP, like SSH, RDP, game servers (using UDP encapsulated in TCP or directly if Spectrum supports it, though TCP is the focus here), or custom application protocols.
When you configure Spectrum, you’re essentially telling Cloudflare: "For traffic arriving at this public IP and port, tunnel it over TCP to this private IP and port." Cloudflare’s edge routers and internal network handle the heavy lifting of connection management and packet forwarding. They maintain persistent TCP connections to your origin, ensuring low latency and high throughput. The actual packets are encapsulated and sent over Cloudflare’s private backbone, decrypted at the nearest PoP to your origin, and then delivered.
The configuration involves specifying the Protocol as TCP, the Destination Port (the port clients connect to on Cloudflare’s IP), and the Origin Port (the port your service listens on). You also define the Origin IP or Origin Hostname. For example, a basic Spectrum app might look like this in configuration:
{
"name": "my-game-server",
"protocol": "TCP",
"dns": {
"type": "CNAME",
"name": "game.example.com"
},
"ips": [
"198.51.100.10"
],
"ports": [
{
"destination_port": 27015,
"origin_port": 27015
}
],
"origin_pool": {
"name": "game-servers",
"origins": [
{
"name": "primary-game-server",
"address": "192.168.1.100",
"port": 27015
}
]
}
}
This setup means any TCP connection to game.example.com:27015 (which resolves to 198.51.100.10:27015) will be proxied by Cloudflare to 192.168.1.100:27015.
One crucial aspect often overlooked is how Spectrum handles origin health checks and failover. It doesn’t just blindly forward traffic; it actively monitors the health of your origin servers. If an origin becomes unresponsive, Spectrum will automatically direct traffic to healthy origins in the pool. This health check mechanism typically uses TCP probes to the specified origin port, ensuring that the service itself is listening and accepting connections.
The next step in securing non-HTTP TCP traffic would be to explore how to integrate Zero Trust policies with Spectrum.