CDN and protection

Proxying a DNS record is how you switch on the CDN and protection. While a record is not proxied, traffic goes straight to your origin; flip Proxy on — and it flows through WebShield.

Records That Can Be Proxied

Proxying is available only for:

• A
• AAAA
• CNAME

Proxying is not available for MX, TXT, SRV, CAA, and other service records.

Enable CDN

1. Open DNS.
2. Find an A, AAAA, or CNAME record for the required host.
3. Enable the Proxy switch.
4. Open the Hosts section and configure traffic behavior for this host.

After proxying is enabled, requests to this hostname pass through WebShield CDN, WAF, and filtering mechanisms.

Proxy Parameters

The host page includes:

• Host mode: Proxy - requests are proxied to the origin server with WAF protection.
• Host mode: Redirect to another host - instead of proxying, visitors receive a 301 redirect to the specified host with the path and query string preserved.
• SSL required - require HTTPS for the protected host.
• Redirect HTTP to HTTPS - redirect HTTP requests to HTTPS.
• Bot protection: Off - do not run an additional browser check.
• Bot protection: Browser - enable browser check for suspicious clients.
• Bot protection: Captcha - enable CAPTCHA verification. This mode is mutually exclusive with Browser.
• HTTP/2 - enable HTTP/2 for client connections.
• HTTP/3 - enable HTTP/3 (QUIC, UDP 443) for client connections. The browser learns about support from the Alt-Svc response header and switches to HTTP/3 on the next request; the first connection always uses TCP. If the visitor’s network blocks UDP, the client transparently stays on HTTP/2.
• Protocol to your server - the protocol WebShield uses to connect to your origin server. It does not affect visitors: their protocol is set by the parameters above.
• Cache pages - allow HTML caching when your server says nothing about freshness (see the “Cache” section). Files are cached regardless of this switch.

Protocol to Your Server

This parameter controls only the “WebShield → your server” leg.

• Automatic (default) - we periodically check whether your server supports HTTP/2 and enable it only when support is confirmed. Until the check runs or if the server fails it, HTTP/1.1 is used. This is the safe option and requires no configuration on your side.
• HTTP/2 - forced. Choose it if you know your server supports HTTP/2 without TLS (h2c) or offers h2 on TLS connections.
• HTTP/1.1 - forced. Choose it if the site started returning errors after switching to HTTP/2.

What HTTP/2 provides on this leg: request boundaries within a connection are unambiguous, which makes the mode more resistant to request smuggling attacks. In addition, parallel requests travel over a single connection, without a separate handshake for each one.

Caution

HTTP/2 has no automatic fallback. Forcing HTTP/2 for a server that does not support it makes the site return 502 for every request. When in doubt, keep “Automatic”.

Note: WebSocket connections are always proxied over HTTP/1.1 regardless of this setting - HTTP/2 has no connection upgrade mechanism. The setting does not affect WebSocket support.

Redirecting www to the Apex Domain

If your main site lives on the apex (for example, a static site on example.com) and www.example.com should lead to it, there is nothing to proxy for www - it has no origin server. Configure a redirect instead:

1. Open DNS and enable Proxy for the www record (this routes traffic to WebShield).
2. Open the www host in the Hosts section.
3. Choose the Redirect to another host mode and set the target host, e.g. example.com.
4. Save the parameters.

Visitors of www.example.com will receive a 301 redirect to example.com with the original path and query preserved. The certificate for www is issued automatically.

Cache

A proxied host is served through the cache on the edge node closest to the visitor.

Files are always cached. Images, styles, scripts, fonts, media — everything recognised by its extension. If your server sends Cache-Control, we follow it literally. If it stays silent, we keep the file for an hour and then ask your server conditionally: unchanged means a short “same as before” reply, with no re-download.

Pages are not cached by default. A silent server means “I don’t know”, not “serve this to everyone” — otherwise a signed-in user’s page would eventually land on someone else’s screen. There are two ways to enable page caching:

• from your server — send Cache-Control: public, max-age=600 (or s-maxage) on pages that are identical for everyone. Nothing to configure on our side;
• with the “Cache pages” switch on the host page — then HTML from a silent server is stored for a minute. A minute is enough to turn a traffic spike (or an attack) into one request per page for your server instead of thousands.

What never reaches the cache, whatever the settings: responses with Cache-Control: private, no-store or no-cache, responses that set a cookie, and anything requested with an Authorization header or a session cookie — those requests always go straight to your server.

Caution

Before enabling page caching, make sure pages that differ for signed-in users are served with Cache-Control: private. We bypass the cache for common session cookies, but we cannot know your own authentication scheme.

Check and Purge

Responses carry an X-Proxy-Cache header: HIT — served from cache, MISS — fetched from your server, BYPASS — the request was treated as personal.

The Purge cache button on the host page instantly invalidates everything cached for this host on every node. Use it after a deploy if files changed under the same names; if your filenames carry a version or a hash, no purge is needed.

Cache hit ratio and the volume served from cache are shown in the Statistics section.

Check Exclusions

Exclusions stop the listed paths from being redirected to a browser check — both the bot protection screen and the automatic checks that apply regardless of the protection switch. They are needed where a redirect breaks the client by its very nature: WebSocket connections, API calls, mobile and server-side SDKs.

What still applies on these paths: malicious request filtering, request rate limits, and address blocks. An exclusion disables the visitor check, not the protection of the site.

Exclusions are entered line by line. Add only required paths, and do not exclude areas that handle user data, authentication, or administrative functions.

Rules:

• up to 50 exclusions;
• each exclusion must start with /;
• root / is not allowed;
• .. is not allowed;
• maximum length is 200 characters per exclusion;
• allowed characters: letters, digits, /, _, ., -, *;
• * is used as a mask at the end of a segment.

How the Current CDN Works

The CDN is a reverse proxy in front of your site: the DNS record points to WebShield, the request arrives to us, passes the protection checks, and only then heads to your origin.

Statistics show “user → WebShield” traffic separately from “WebShield → backend” — so you can see at a glance how much load the cache and protection absorb.

Direct Requests to Your Server

While the site sits behind us, your server’s address stays reachable for anyone who knows it — and such a request bypasses the protection entirely. Close it with the secret header we add to every request we send you: Origin access through WebShield only.