Cloudflare in Front of the Service

If your domain is on Cloudflare, it's the most predictable front by behavior: dynamics aren't cached, methods and headers pass out of the box. I show the four-step setup and explain why for a Russian audience it comes in second rather than first. Practice.

This material is about engineering your own infrastructure and is educational in nature. You are responsible for complying with the laws of your own jurisdiction.

Where Cloudflare shines and where it doesn't

The general basics of CDN fronting (XHTTP inbound on the origin, GET/POST modes, nginx) were covered in the theory and in the Yandex practice — they're common to all providers. Here it's only the Cloudflare specifics.

Cloudflare is the benchmark for predictability. But it has polar pros and cons, and they determine where to place it.

What's good:

• Doesn't cache POST and long-GET by default — dynamics pass as is.
• XHTTP works even where there's no WS/gRPC.
• Free plan, worldwide coverage.

What's inconvenient from Russia:

• Cloudflare DNS is slow from Russia.
• Payment from Russia is unavailable.

Conclusion: for a Russian audience, it's unreliable as the primary front. Its role is a benchmark for overseas use and backup. For a Russian audience, combine: direct Self-steal Reality as primary + XHTTP behind a CDN as backup, and for the Russian CDN take Yandex.

Setup in four steps

If the domain is already on Cloudflare's NS, the whole front goes up fast.

Step 1. DNS record in Proxied mode.

You create a cdn record (A → node IP) and enable Proxied (the orange cloud). It's the orange cloud that routes traffic through Cloudflare's network — gray (DNS only) just resolves the IP directly and gives no front.

Step 2. SSL/TLS → Full.

In the Cloudflare panel: SSL/TLS → Overview → Full. The cache doesn't touch POST and long-GET here (dynamics aren't cached by default), so unlike with a Russian CDN, there's no need to specially disable the cache.

If you want to play it safe and explicitly forbid caching on the XHTTP path — create a Cache Rule via the API (the path itself is secret, so it's a placeholder):

curl -X POST \
  "https://api.cloudflare.com/client/v4/zones/ZONE_ID/rulesets/phases/http_request_cache_settings/entrypoint" \
  -H "Authorization: Bearer CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "rules": [
      {
        "description": "Bypass cache for XHTTP path",
        "expression": "(http.host eq \"cdn.your-domain.com\" and starts_with(http.request.uri.path, \"/PATH_XHTTP\"))",
        "action": "set_cache_settings",
        "action_parameters": { "cache": false }
      }
    ]
  }'

And keep the main thing in mind: the encryption mode should be exactly Full (strict) — then Cloudflare validates the origin's certificate. Plain Full (without strict) silently accepts a self-signed cert and opens the door to a MITM between the CDN and the node.

Step 3. XHTTP in packet-up mode.

On the origin you stand up the same XHTTP inbound as for any CDN (see the common practice), in packet-up mode — it's the most compatible. XHTTP passes through Cloudflare even where WS/gRPC are blocked.

Step 4. Host in Remnawave.

Create a Host: cdn.your-domain.com:443, path=/xh, packet-up mode, TLS. The client connects to the CDN domain, Cloudflare pulls from the origin.

What to watch for

• Close the origin to everyone except Cloudflare. Since the client only goes through the CDN, direct access to the node's IP isn't needed — close it off with a firewall to Cloudflare's ranges so the node can't be found by scanning.
• The /xh path is secret. On the origin, nginx proxies only this path to Xray without buffering, and serves the decoy site for everything else (as in the common practice).
• Keep ECH disabled. A separate trap: with ECH on, a site behind Cloudflare may open from Russia only via VPN — if the origin suddenly becomes unavailable from Russia, check SSL/TLS → Edge Certificates → ECH → Off.

Wrap-up

Cloudflare is the most trouble-free front if the audience is overseas or you keep it as backup. For Russia it's second place because of slow DNS and unavailable payment. Keep it in the subscription as an additional host alongside direct Reality and a Russian CDN — then some channel is always live.

For the CDN-front mechanics, see the theory; for a working Russian front with a POST-block workaround, see the Yandex CDN practice.