CDN and protection

WebShield CDN and protection layer are enabled by proxying DNS records. When a record is proxied, user traffic goes through WebShield instead of going directly to your origin server.

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.

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.

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 current WebShield CDN works as a reverse proxy in front of your website. The DNS record points to WebShield infrastructure; WebShield accepts the request, applies protection checks, and forwards allowed traffic to the origin defined by the record or configuration.

Statistics show traffic from users to WebShield separately from traffic between WebShield and the backend. This helps estimate CDN impact and origin load.