ShieldCache passes on all requests that are not rejected or answered from the cache to your server. We call this server the origin. You will find its settings in the Origin tab with the sub-tabs Server, Further origins and Advanced. As always, changes only take effect once you click Apply.
Server: address, port and TLS
- Address: IP address or hostname of your server. Internal and private addresses are not allowed for security reasons.
- Port and TLS: Port 443 with “Connect encrypted (HTTPS)” - recommended - or port 80 without encryption. Port 80 only works without TLS, port 443 only with TLS.
- Verify the origin certificate: On by default. Only switch it off if your server uses a self-signed certificate - without verification, the connection to the origin is not protected against redirection.
- Host header: If left empty, your server receives the requested domain. Enter a fixed name if your server only delivers the website under that name.
- Timeout: how long ShieldCache waits for your server's response, 5 to 300 seconds (default 60). If the server does not respond in time, the visitor sees the error page
SC-504-ZEIT.
With Test origin, ShieldCache fetches the home page from the proxy without following redirects. The saved state is tested - so save first.
Certificate errors after switching DNS
Once your domain points to ShieldCache, your web space itself often can no longer obtain a new Let's Encrypt certificate. When the old one expires, the test reports “The origin certificate does not match the domain or is invalid”. In that case, switch off “Verify the origin certificate” or connect via port 80. The connection from the proxy to the origin then runs without encryption or with unverified encryption.
Redirect as a response
If the origin responds to the test with a redirect, check the host header and TLS setting. For example, if your server redirects all HTTP requests to HTTPS while ShieldCache connects to it via port 80, a loop is created.
Further origins: failover and load balancing
If your website runs on several servers, you can enter up to four further servers in the Further origins sub-tab. They are addressed in exactly the same way as the main origin: with the same scheme, the same certificate verification and the same host header.
Under Distribution you choose:
- Failover: Always the main origin, the others only if it cannot be reached.
- Round robin: Requests go to all origins in turn.
- Fewest connections: Each request goes to the origin with the fewest open connections.
The health check is optional: enter a path, for example /health. ShieldCache fetches it from every origin every 15 seconds; only origins that respond with 2xx receive requests. Without a path, ShieldCache only detects outages from failed connections. With HTTPS, the health check needs a host header on the main origin. If all origins are down, visitors see the error page SC-503-URSPRUNG.
Sessions and load balancing
If your application only stores sessions in the memory of one server, choose “Failover”. With “Round robin” or “Fewest connections”, a visitor may end up on a different server with every request.
Advanced: connection setup and visitor IP
In the Advanced sub-tab you configure the finer details of the connection:
- Connection timeout: 1 to 30 seconds (default 10). Shorter values detect unreachable servers more quickly.
- Visitor IP to your server: As all requests come from the proxy, your server initially only sees the ShieldCache address. The real visitor IP is in headers. You can choose
X-Forwarded-For,X-Real-IP,CF-Connecting-IPandTrue-Client-IP; the default isX-Forwarded-ForandX-Real-IP. ShieldCache removes the ones not selected so that visitors cannot forge them. If you choose none, your server receives no visitor IP - economical, but your application's logs and blocks will then only see ShieldCache.
Custom headers with the visitor IP
If you are coming from another protection service and your application reads the visitor IP from a fixed header, for example X-DDOSPROXY, enter it under Custom headers with the visitor IP - up to three. ShieldCache sets the real visitor IP there and always replaces a value of the same name sent by the visitor. This means you do not have to adapt your application when you move.
- Letters, digits and hyphens are allowed, but no underscore and no full stop.
- Your server receives the name in the usual notation, for example
X-Ddosproxy. Most applications do not distinguish between upper and lower case. - Security-critical headers such as
HostorCookieare blocked. - Data protection: the IP address is transmitted additionally for each header you enter. Only enter what your application actually reads.
How your application reads the visitor IP
Many applications and frameworks only evaluate X-Forwarded-For or X-Real-IP if they explicitly trust the upstream proxy - for example via a setting for trusted proxies or a plugin. Without this setting, your application logs the ShieldCache address, and its own blocks in the application then hit all visitors at once. After switching, check which address your application shows in its logs.
Request size
Under Request size you specify how large uploaded data (forms, files) may be, 1 to 1024 MB. Without a custom limit, 50 MB applies with the firewall, and there is no limit without the firewall. Larger requests receive the error page SC-413-GROESSE. The firewall checks forms and JSON without files up to 512 KB - larger ones also result in SC-413-GROESSE.