ShieldCache reicht alle Anfragen, die nicht abgewiesen oder aus dem Cache beantwortet werden, an Ihren Server weiter. Diesen Server nennen wir Ursprung. Seine Einstellungen finden Sie im Reiter Ursprung mit den Unterreitern Server, Weitere Ursprünge und Erweitert. Wie immer werden Änderungen erst mit Übernehmen wirksam.
Server: Adresse, Port und TLS
- Adresse: IP-Adresse oder Hostname Ihres Servers. Interne und private Adressen sind aus Sicherheitsgründen nicht erlaubt.
- Port und TLS: Port 443 mit „Verschlüsselt verbinden (HTTPS)“ - empfohlen - oder Port 80 ohne Verschlüsselung. Port 80 geht nur ohne TLS, Port 443 nur mit TLS.
- Zertifikat des Ursprungs prüfen: Standardmäßig an. Schalten Sie es nur ab, wenn Ihr Server ein selbst signiertes Zertifikat nutzt - ohne Prüfung ist die Verbindung zum Ursprung nicht gegen Umleitung geschützt.
- Host-Kopf: Leer gelassen, erhält Ihr Server die aufgerufene Domain. Tragen Sie einen festen Namen ein, wenn Ihr Server die Website nur unter diesem Namen ausliefert.
- Zeitlimit: wie lange ShieldCache auf die Antwort Ihres Servers wartet, 5 bis 300 Sekunden (Standard 60). Antwortet der Server nicht rechtzeitig, sieht der Besucher die Fehlerseite
SC-504-ZEIT.
Mit Ursprung testen ruft ShieldCache die Startseite vom Proxy aus ab, ohne Weiterleitungen zu folgen. Getestet wird der gespeicherte Stand - speichern Sie also vorher.
Zertifikatsfehler nach der DNS-Umstellung
Zeigt Ihre Domain schon auf ShieldCache, kann Ihr Webspace selbst oft kein neues Let's-Encrypt-Zertifikat mehr erhalten. Läuft das alte ab, meldet der Test „Das Zertifikat des Ursprungs passt nicht zur Domain oder ist ungültig“. Schalten Sie dann „Zertifikat des Ursprungs prüfen“ ab oder verbinden Sie über Port 80. Der Weg vom Proxy zum Ursprung läuft dann ohne bzw. mit ungeprüfter Verschlüsselung.
Weiterleitung als Antwort
Antwortet der Ursprung im Test mit einer Weiterleitung, prüfen Sie Host-Kopf und TLS-Einstellung. Leitet Ihr Server zum Beispiel alle HTTP-Anfragen auf HTTPS um, während ShieldCache ihn über Port 80 anspricht, entsteht eine Schleife.
Weitere Ursprünge: Ausfallsicherheit und Lastverteilung
Liegt Ihre Website auf mehreren Servern, tragen Sie im Unterreiter Weitere Ursprünge bis zu vier weitere Server ein. Sie werden genauso angesprochen wie der Haupt-Ursprung: mit demselben Schema, derselben Zertifikatsprüfung und demselben Host-Kopf.
Unter Verteilung wählen Sie:
- Ausfall: Immer der Haupt-Ursprung, die weiteren nur, wenn er nicht erreichbar ist.
- Rundlauf: Anfragen gehen abwechselnd an alle Ursprünge.
- Wenigste Verbindungen: Jede Anfrage geht an den Ursprung mit den wenigsten offenen Verbindungen.
Die Gesundheitsprüfung ist optional: Tragen Sie einen Pfad ein, zum Beispiel /health. ShieldCache ruft ihn alle 15 Sekunden bei jedem Ursprung ab; nur Ursprünge mit einer Antwort 2xx bekommen Anfragen. Ohne Pfad erkennt ShieldCache Ausfälle nur an fehlgeschlagenen Verbindungen. Mit HTTPS braucht die Gesundheitsprüfung einen Host-Kopf beim Haupt-Ursprung. Sind alle Ursprünge ausgefallen, sehen Besucher die Fehlerseite SC-503-URSPRUNG.
Sitzungen und Lastverteilung
Speichert Ihre Anwendung Sitzungen nur im Arbeitsspeicher eines Servers, wählen Sie „Ausfall“. Bei „Rundlauf“ oder „Wenigste Verbindungen“ kann ein Besucher bei jeder Anfrage auf einem anderen Server landen.
Erweitert: Verbindungsaufbau und Besucher-IP
Im Unterreiter Erweitert stellen Sie die Feinheiten der Verbindung ein:
- Zeitlimit Verbindungsaufbau: 1 bis 30 Sekunden (Standard 10). Kürzere Werte erkennen nicht erreichbare Server schneller.
- Besucher-IP an Ihren Server: Da alle Anfragen vom Proxy kommen, sieht Ihr Server zunächst nur die Adresse von ShieldCache. Die echte Besucher-IP steht in Kopfzeilen. Wählbar sind
X-Forwarded-For,X-Real-IP,CF-Connecting-IPundTrue-Client-IP; Standard sindX-Forwarded-ForundX-Real-IP. Die nicht gewählten entfernt ShieldCache, damit Besucher sie nicht fälschen können. Wählen Sie keine, erhält Ihr Server keine Besucher-IP - sparsam, aber Protokolle und Sperren Ihrer Anwendung sehen dann nur ShieldCache.
Eigene Kopfzeilen mit der Besucher-IP
Kommen Sie von einem anderen Schutzdienst und liest Ihre Anwendung die Besucher-IP aus einer festen Kopfzeile, zum Beispiel X-DDOSPROXY, tragen Sie diese unter Eigene Kopfzeilen mit der Besucher-IP ein - bis zu drei. ShieldCache setzt dort die echte Besucher-IP und ersetzt einen gleichnamigen Wert des Besuchers immer. So müssen Sie Ihre Anwendung beim Umzug nicht anpassen.
- Erlaubt sind Buchstaben, Ziffern und Bindestriche, kein Unterstrich und kein Punkt.
- Ihr Server erhält den Namen in üblicher Schreibweise, zum Beispiel
X-Ddosproxy. Die meisten Anwendungen unterscheiden nicht zwischen Groß- und Kleinschreibung. - Sicherheitskritische Kopfzeilen wie
HostoderCookiesind gesperrt. - Datenschutz: Je eingetragener Kopfzeile wird die IP-Adresse zusätzlich übertragen. Tragen Sie nur ein, was Ihre Anwendung wirklich liest.
So liest Ihre Anwendung die Besucher-IP
Viele Anwendungen und Frameworks werten X-Forwarded-For oder X-Real-IP nur aus, wenn sie dem vorgeschalteten Proxy ausdrücklich vertrauen - etwa über eine Einstellung für vertrauenswürdige Proxys oder ein Plugin. Ohne diese Einstellung protokolliert Ihre Anwendung die Adresse von ShieldCache, und eigene Sperren in der Anwendung treffen dann alle Besucher gleichzeitig. Prüfen Sie nach der Umstellung, welche Adresse Ihre Anwendung in ihren Protokollen zeigt.
Größe von Anfragen
Unter Größe von Anfragen legen Sie fest, wie groß hochgeladene Daten (Formulare, Dateien) sein dürfen, 1 bis 1024 MB. Ohne eigene Grenze gelten mit Firewall 50 MB, ohne Firewall gibt es keine Grenze. Größere Anfragen erhalten die Fehlerseite SC-413-GROESSE. Formulare und JSON ohne Dateien prüft die Firewall bis 512 KB - größere ergeben ebenfalls SC-413-GROESSE.