Cloudflare for websites and game servers: what it proxies

Cloudflare's proxy - the orange cloud next to a DNS record - carries HTTP and HTTPS on a specific list of ports, and nothing else. Put it in front of a website and you get caching, a free certificate, a web firewall and a hidden origin address. Point it at a Minecraft server, an Ark server or anything else speaking its own protocol on its own port and the connection simply fails, because there is no HTTP request for Cloudflare to read. That one sentence resolves about eighty per cent of the questions people have about Cloudflare, and the rest of this post is the detail: which ports, which settings, which errors, and what the orange cloud never protects no matter how it is configured.

What the orange cloud actually changes#

Cloudflare is your authoritative DNS host, and each record has a toggle. Grey cloud - "DNS only" - means Cloudflare answers the query with your real address and steps out of the way. Orange cloud means it answers with one of its own anycast addresses, and traffic to that address is handled by the nearest Cloudflare data centre, which then makes its own connection to your server.

Everything else follows from that substitution:

• dig www.example.com returns a Cloudflare address such as 104.21.x.x or 172.67.x.x, never yours.
• The TTL field is locked to Auto, because Cloudflare controls it.
• Your origin only ever sees connections from Cloudflare's ranges, so the visitor's address must come from a header.
• Anything that inspects or rewrites the request - caching, the firewall, redirects, compression - can only happen on records that are proxied.

A zone almost always ends up mixed: www and the apex orange, play and mail grey. That is not a compromise, it is the correct configuration. DNS records explained covers the record types themselves if the A/CNAME/SRV distinction is new.

The ports it will proxy, and everything else#

A proxied record only accepts connections on Cloudflare's supported ports. Anything else is refused or times out, which is why "I enabled the orange cloud and my site on port 3000 stopped working" is a weekly question.

Note what is not there: 25 (SMTP), 3306, 5432, 22, 25565, 27015, and every UDP port in existence. The proxy is an HTTP reverse proxy. It terminates TLS, parses a request, applies rules, and forwards. A protocol it cannot parse is a protocol it cannot proxy.

Cloudflare does sell a product for raw TCP - Spectrum - which is a paid add-on: arbitrary TCP applications on the Business and Enterprise plans, with Minecraft support available lower down the range. Prices and plan boundaries move, so check the current plan page before designing around it, and price it honestly against simply having a decent host.

Game servers and the orange cloud#

This is the section people arrive for, so here is the whole thing plainly.

Game traffic cannot go through the free Cloudflare proxy. Most games use UDP, which the HTTP proxy does not carry at all. The games that use TCP - Minecraft Java on 25565, for instance - use a port that is not on the supported list. Turning the orange cloud on for a game record produces one of two results: the client cannot connect, or it connects to Cloudflare's web edge and gets an HTTP error where it expected a handshake.

The record for a game server stays grey. That is normal and it is what every host expects:

Type   Name    Content          ProxyA      play    203.0.113.10     DNS onlySRV    _minecraft._tcp.play     DNS only

SRV records cannot be proxied at all - Cloudflare will not offer you the toggle - and if the hostname an SRV record points at is itself orange-clouded, the lookup resolves to Cloudflare and the connection fails. Both the SRV record and the A record it targets must be DNS only. SRV records for Minecraft covers the format, and connecting a domain to a game server covers the ordinary A record case.

Two consequences follow, and the second one is the uncomfortable part.

First, Cloudflare does not hide a game server's address. The grey-clouded record publishes it, because it must - the client has to reach your machine directly. Anyone who can read DNS can read that address, including someone planning to attack it.

Second, nothing about the orange cloud on your website protects the game server sharing that address. If your web records are proxied and your game record is not, you have hidden precisely nothing: the A record for play gives away the same IP the website is on. This is the most common way an origin address leaks.

What actually protects a game server is filtering upstream of it, at the network your host runs. On RE:NODE the wording is deliberately narrow: upstream filtering that drops obvious volumetric floods, plus reflection and malformed traffic. Attacks that look like real players are not filtered, because at that point they are indistinguishable from real players without knowing the game. A host that promises no downtime under any attack is selling you a sentence, not a service - what we do about attacks is the longer version, and DDoS attacks on game servers explained covers the attack types themselves.

SSL modes, certificates and redirect loops#

Under SSL/TLS there is a mode setting that decides how Cloudflare talks to your origin, and picking the wrong one causes two very common failures.

Flexible is the trap. Visitors see HTTPS, but the connection from Cloudflare to your server is plain HTTP over the public internet, so the padlock is telling the visitor something untrue. It also produces the classic ERR_TOO_MANY_REDIRECTS: Cloudflare sends an HTTP request, your server redirects HTTP to HTTPS, Cloudflare follows that back to itself, forever. If a site loops immediately after enabling Cloudflare, this is why - switch to Full (strict).

Full (strict) needs a valid certificate on your origin. Either the one your host already issues, or a free Cloudflare Origin CA certificate, which is trusted by Cloudflare only and can be issued for up to fifteen years. Both work; the host-issued one is less to remember.

The interaction that bites on a managed host is certificate renewal. An HTTP-01 validation has to reach your origin on port 80 at /.well-known/acme-challenge/, and a firewall rule, a redirect or Flexible mode can all stop it silently. On RE:NODE, app and web plans include a proxy slot that issues and renews the certificate automatically inside a 21-day window, which means a renewal blocked by something you configured in Cloudflare does not fail today - it fails two months later when the existing certificate expires. If you put Cloudflare in front of a host-managed certificate, grey-cloud the record long enough for a renewal to complete, or switch that host to DNS validation if it offers it. HTTPS and Let's Encrypt explained covers how the validation works.

Two settings worth turning on once Full (strict) is working: Always Use HTTPS, which does the HTTP-to-HTTPS redirect at the edge so your server never sees a plain request, and Automatic HTTPS Rewrites, which fixes mixed-content references in your own HTML.

Caching: what is cached by default and what is not#

By default Cloudflare caches static assets by file extension - images, CSS, JavaScript, fonts - and does not cache HTML. For a WordPress site or any dynamic application, that means the expensive part of every page view still reaches your server. People are consistently surprised by this, having assumed the orange cloud made the site fast.

To cache HTML you create a Cache Rule that sets "Eligible for cache" (the replacement for the old Page Rules "Cache Everything"), and then you must handle the logged-in case. Serve one visitor's dashboard from the edge to everyone else and you have created a data breach with a checkbox. The rules that keep this safe:

• Bypass the cache when a session cookie is present - wordpress_logged_in_*, PHPSESSID, your framework's cookie name.
• Bypass the cache entirely for admin paths and any API that returns per-user data.
• Set a short edge TTL to start with, and raise it once you trust it.

The cleaner approach is to let your own headers drive it. Cache-Control: public, max-age=31536000, immutable on hashed asset filenames, and Cache-Control: private, no-store on anything personal, is a policy that works on every CDN rather than one vendor's dashboard. HTTP caching headers explained goes through the header set properly.

Two operational notes. Development Mode bypasses the cache for three hours and turns itself off, which is what you want while editing a theme. And purge by URL rather than purging everything - a full purge on a busy site sends every request to your origin at once, which is a self-inflicted load spike.

Security settings worth having, and two that break things#

The genuinely useful ones, in order of value on a small site:

• The managed WAF rules. Free plans get a subset, and it stops a large amount of automated nonsense before it reaches PHP.
• Rate limiting. Free plans include one rule. Spend it on the login endpoint - that is where the credential stuffing goes.
• Country or ASN blocking, if your audience is genuinely regional. Blunt, but effective against a specific problem.
• Blocking by path. /wp-login.php, /xmlrpc.php and /.env requests from everywhere except your own address cost nothing to block and are most of an attacker's opening move.

The two that break things, and are enabled by people who do not connect the outage to the setting:

Bot Fight Mode challenges anything it decides is not a browser. That includes your payment provider's webhooks, your GitHub deploy hook, your uptime monitor, your mobile app and your RSS readers. The symptom is a 403 that never appears in your own logs, because your server was never asked. If you run any machine-to-machine traffic, leave it off or exclude those paths.

Under Attack mode shows a five-second interstitial to every visitor before letting them through. It works against a flood, and it breaks every API client and every WebSocket handshake for as long as it is on. It is an emergency switch, not a configuration - turn it off when the emergency ends. WebSockets themselves are proxied fine on all plans; it is the challenge that kills them, and WebSockets behind a reverse proxy covers the other idle-timeout behaviour to expect.

Seeing the real visitor address#

Once traffic is proxied, every connection arrives from Cloudflare. Your access log fills with their ranges, rate limiting by IP throttles everyone at once, and any geolocation you do is measuring a data centre.

The real address arrives in CF-Connecting-IP, and is also appended to X-Forwarded-For. In nginx, restore it so that logs, rate limits and application code all see the truth:

# Repeat set_real_ip_from for every range published at cloudflare.com/ipsset_real_ip_from 173.245.48.0/20;set_real_ip_from 103.21.244.0/22;real_ip_header CF-Connecting-IP;

Never trust that header from a source that is not Cloudflare. It is a plain request header, so anyone connecting to your origin directly can set it to whatever they like - which is exactly why the set_real_ip_from list matters. On a managed host you usually cannot edit nginx, but the same logic applies to the header your platform gives you: on RE:NODE the proxy slot passes the original client address in X-Forwarded-For, and if Cloudflare is also in the chain, that header becomes a list where the leftmost entry is the visitor and each hop appended the one before it.

The other half of this is a firewall that only accepts connections from Cloudflare on 80 and 443, so nobody can skip the proxy by connecting to your address directly. On your own VDS that is a handful of ufw rules plus Authenticated Origin Pulls. On a shared, container-based host it is generally not something you control, which is a real limitation worth knowing rather than assuming.

Reading Cloudflare's error pages#

Cloudflare's five-hundred errors are specific, and each one points at a different half of the system. This table saves a lot of guessing:

The distinction to internalise is between 521 and 522. A refused connection means something answered with "no" - the port is closed or filtered with a reject. A timeout means nothing answered at all, which on a busy server means the request queue is full, and on a firewalled one means packets are being dropped. Checking your own logs answers it immediately: if there is no entry for the request, it never arrived.

A 524 needs mentioning separately because it is not really an error. A request that takes longer than about 100 seconds is cut off at the edge, and on the lower plans that limit is not configurable. Work that takes minutes should not happen inside a request at all - it should be queued and polled. Background jobs on a small server covers how to move it.

What Cloudflare will not do for you#

A short, honest list, because the marketing does not volunteer it.

• It does not host your email. MX records must be DNS only, and if your mail server shares an address with your web server, that MX record publishes your origin. Cloudflare's Email Routing forwards mail; it is not a mailbox. RE:NODE does not host email either.
• It does not hide an address that has already leaked. Old DNS history, a grey-clouded subdomain, a certificate transparency log entry, or an application that makes outbound requests can all give it away. Changing the origin address after enabling the proxy is the only real fix.
• It does not make a slow application fast. Uncached HTML still comes from your server, at your server's speed. If the database query takes 800 ms, it takes 800 ms with an orange cloud in front of it.
• It does not cover non-HTTP services. Databases, SSH, game ports and mail all bypass it completely, and each one is a direct route to your machine that your firewall has to deal with.
• It does not accept unlimited uploads. The free and Pro plans cap a request body at 100 MB. Large file uploads need to go somewhere else, or through a grey-clouded hostname.
• It does not replace backups, updates or a firewall. It filters traffic before it arrives; everything after that is still yours.

Used for what it is - an HTTP edge in front of a website - it is excellent, free, and takes twenty minutes to set up. Used as a shield for a game server, it is a misunderstanding that costs an afternoon.

FAQ#

Can I use Cloudflare's proxy for a Minecraft server?

Not on the free plan. Minecraft Java uses TCP 25565, which is not one of the proxied ports, and the proxy only understands HTTP. Leave the record DNS only, or look at Spectrum, which is a paid add-on with Minecraft support.

Does the orange cloud hide my game server's IP address?

No. The record the game client uses must be DNS only, so it publishes your real address by definition. If your website is proxied but shares that address, the game record leaks it for both.

Why did my site start redirecting in a loop after enabling Cloudflare?

The SSL mode is Flexible, so Cloudflare asks your origin over plain HTTP, your origin redirects to HTTPS, and Cloudflare follows the redirect back to itself. Switch to Full (strict) with a valid certificate on the origin.

Are WebSockets supported?

Yes, on every plan, with no setting to enable. Idle connections are closed after roughly 100 seconds, so send a heartbeat every 30, and keep bot challenges away from the WebSocket path.

Why does my server see Cloudflare's IP instead of the visitor's?

Because Cloudflare makes the connection, not the visitor. Read CF-Connecting-IP, or configure your proxy to restore the real address from it, and only trust that header when the connection comes from a published Cloudflare range.

Does Cloudflare replace what my host does about attacks?

No, and it cannot, because it only sees the traffic that goes through the proxy. Filtering upstream of the server still matters for everything else - the game ports, the database port, and anything on a DNS-only record.