Skip to content

Proxy

Die Proxy-Seite routet den Traffic einer Zone zum Origin und konfiguriert die grundlegenden Request-/Response-Einstellungen, auf denen andere Features aufbauen.

Proxy- und Origin-Konfiguration einer Zone.Proxy- und Origin-Konfiguration einer Zone.
Proxy- und Origin-Konfiguration einer Zone.

Hostnamen werden auf einer eigenen Seite verwaltet -- siehe Hostnamen. Zum Ein- oder Ausschalten von smoxy für die gesamte Zone dient der Schalter Aktiviert / Deaktiviert im Zonen-Header; bei deaktivierter Zone reicht smoxy den Traffic als einfacher Reverse Proxy ohne Caching, Optimierung oder Sicherheit durch.


Standard-Backend

Jede Zone braucht ein Ziel für ihren Traffic: entweder ein einzelner Origin-Server oder ein Load Balancer, der Anfragen auf mehrere Origins verteilt. Die Karte Standard-Backend zeigt das zugewiesene Backend auf einen Blick -- bei einem Origin dessen Adresse und Host-Header, bei einem Load Balancer die Balancing-Methode und die Mitglieder mit ihren Gewichten -- samt Direktlink zur Backends-Seite.

Zum Ändern:

  1. Auf Backend ändern ... klicken (bzw. Backend auswählen ..., solange keines zugewiesen ist) -- die Auswahl klappt direkt in der Karte aus
  2. Das Backend per Suche nach Name, Adresse oder Host finden oder mit den Tabs Alle / Origins / Load Balancer filtern; das zugewiesene Backend trägt den Badge Aktuell
  3. Das neue Backend wählen und mit Änderungen speichern übernehmen -- erst das Speichern wendet die Auswahl an; Verwerfen setzt sie zurück

Dies bestimmt, wohin smoxy Anfragen standardmäßig sendet. Eine Überschreibung pro Anfrage ist mit Conditional Rules möglich.

Die Standard-Backend-Karte mit ausgeklappter Auswahl: Suche, Typ-Tabs und das aktuell zugewiesene Backend.Die Standard-Backend-Karte mit ausgeklappter Auswahl: Suche, Typ-Tabs und das aktuell zugewiesene Backend.
Die Standard-Backend-Karte mit ausgeklappter Auswahl: Suche, Typ-Tabs und das aktuell zugewiesene Backend.

INFO

Hinweis: Origins und Load Balancer werden separat unter Organisation > Backends erstellt, bevor sie einer Zone zugewiesen werden können. Wird das zugewiesene Backend dort später gelöscht, zeigt die Karte eine Warnung, und die Zone kann keinen Traffic weiterleiten, bis ein neues Backend ausgewählt ist.


Komprimierung

smoxy komprimiert Antworten am Edge, bevor sie an Besucher ausgeliefert werden, sodass sie kleiner und schneller übertragen werden. Vom Origin werden die Antworten unkomprimiert angefordert -- auf dem eigenen Server ist keine Konfiguration nötig. Für jede Antwort wird automatisch das beste Format gewählt, das der Browser des Besuchers unterstützt, in dieser Reihenfolge:

FormatVerfügbarkeitBrowser-Unterstützung
Zstandard (zstd)Schalter -- bei neuen Zonen standardmäßig aktiviertAktuelle Chrome-, Edge- und Firefox-Versionen
Brotli (br)Immer aktivDie meisten modernen Browser
GzipImmer aktivUniverseller Fallback, von jedem Browser unterstützt

Brotli und Gzip sind immer aktiv und lassen sich nicht deaktivieren. Zstandard, das neueste der drei Formate mit kleineren Dateien und schnellerer Dekomprimierung, wird pro Zone in der Karte Komprimierung gesteuert: Neu angelegte Zonen starten mit aktiviertem zstd; bei bestehenden Zonen lässt es sich über den Schalter aktivieren. Die Einstellung gilt zonenweit und greift sofort -- kein Cache-Clear nötig.

Die Komprimierungs-Karte: der zstd-Schalter, Brotli und Gzip immer aktiv.Die Komprimierungs-Karte: der zstd-Schalter, Brotli und Gzip immer aktiv.
Die Komprimierungs-Karte: der zstd-Schalter, Brotli und Gzip immer aktiv.

Debug-Header

Wenn aktiviert, fügt smoxy Debug-Informationen zu den HTTP-Response-Headern hinzu. Dies ist nützlich zur Fehlerbehebung von Caching-Verhalten, Regelauswertung und Request-Routing.

Ohne Debug-Header ist s-cache der einzige smoxy-Header, der für Besucher sichtbar ist; alle anderen internen s-*-Header (etwa der Cache-Datei-Hash) werden am Edge entfernt, bevor die Antwort smoxy verlässt. Mit aktivierten Debug-Headern bleiben sie sichtbar.

Während der Entwicklung oder beim Debugging aktivieren und in der Produktion deaktivieren, um keine internen Details preiszugeben.


Server-Timing-Header

Wenn aktiviert, fügt smoxy einen Server-Timing-Response-Header hinzu, der die Request-Verarbeitung in einzelne Phasen aufschlüsselt, sodass Real-User-Monitoring-Tools den Anteil von smoxy an der Latenz direkt im Browser des Besuchers messen können. Der Header ist standardmäßig deaktiviert und wird pro Zone aktiviert.

Der Header meldet den Cache-Status und die an jeder Stufe aufgewendete Zeit mit herstellerneutralen Namen:

  • cdn-cache -- das Ergebnis des Edge-Caches (HIT, MISS, BYPASS oder STALE)
  • edge -- die für die Verarbeitung der Anfrage am smoxy-Edge aufgewendete Zeit
  • origin -- die Zeit, bis der Origin zu antworten begann (nur, wenn smoxy den Origin kontaktiert)

Ein vom Origin bereits gesendeter Server-Timing-Header wird unverändert durchgereicht, und smoxy ergänzt einen Timing-Allow-Origin-Header nur dann, wenn die Antwort noch keinen enthält, sodass die Werte für Skripte auf der eigenen Website lesbar bleiben. Monitoring-Tools wie fastmon werten diesen Header automatisch aus.


HTTP-Header

smoxy kann die HTTP-Header sowohl der an den Origin gesendeten Anfragen als auch der an Besucher zurückgegebenen Antworten anpassen. Beides wird in der Karte HTTP-Header konfiguriert und lässt sich pro Anfrage über Conditional Rules überschreiben.

Request-Header

Header, die smoxy an den Origin-Server sendet, nützlich, um zusätzlichen Kontext an das Backend zu übergeben. Jeder Eintrag wird gesetzt: smoxy fügt den Header hinzu, ein gleichnamiger Header vom Besucher wird überschrieben. Jeder Header erhält einen Namen und einen Wert, einen pro Zeile.

Response-Header

Header der Antwort, bevor sie den Besucher erreicht. Pro Zeile wird gewählt, wie der Header angewendet wird, sodass eine einzige Liste Sicherheits-Header setzen, zusätzliche Werte ergänzen und vom Origin durchgereichte Header entfernen kann:

OperationWirkung
SetErsetzt den gleichnamigen Header des Origins. Sendet der Origin keinen, wird der Header hinzugefügt.
AddSendet eine zusätzliche Zeile für den Header und behält die des Origins, sodass er mehrfach ausgeliefert wird. Nur für Header verwenden, die sich zulässigerweise wiederholen dürfen -- Set-Cookie, Vary, Link, CORS Access-Control-Allow-* und ähnliche. Sendet der Origin keinen, wird er einmal gesetzt.
RemoveEntfernt den Header aus der Antwort des Origins, sodass Besucher ihn nie erhalten.

WARNING

Add nicht für einwertige Header wie Content-Type, Location, ETag oder Last-Modified verwenden: eine doppelte Zeile wird nachgelagert abgelehnt und eine Kopie verworfen. Für solche Header Set verwenden.

Berühren mehrere Operationen denselben Header, wendet smoxy sie in fester Reihenfolge an -- erst Remove, dann Set, dann Add. Ein Set setzt sich damit stets gegenüber dem Origin durch, ein Add ergänzt darauf.

Jede Liste fasst bis zu 15 Einträge; ein Header-Name darf bis zu 255 Zeichen lang sein, ein Wert bis zu 4096.

Dynamische Werte

Set- und Add-Werte können {{req....}}-Platzhalter enthalten, die smoxy pro Anfrage einsetzt -- aus denselben Anfragedaten, auf die auch Conditional Rules zugreifen. Ein Add auf Set-Cookie mit dem Wert

geo_country={{req.geoip.country}}; Path=/

liefert einem Besucher aus Deutschland geo_country=DE. (Remove erwartet nur einen Header-Namen und wird nie interpoliert.)

Referenzierbar sind:

GruppePlatzhalter
Standort (GeoIP){{req.geoip.country}} (ISO 3166-1 alpha-2), .city, .subdivisions, .iseu, .asn, .asorg, .latitude, .longitude
Anfrage{{req.method}}, {{req.uri}}, {{req.host}}, {{req.ip}}
Header, Query-Parameter, Cookies{{req.headers['user-agent']}}, {{req.args['ref']}}, {{req.cookies['sid']}}

Header-, Parameter- und Cookie-Namen stehen in ['...'], da sie - enthalten können; Header-Namen werden in Kleinbuchstaben geschrieben. Die festen Felder oben nutzen Punktnamen wie {{req.geoip.country}}.

smoxy hält die Interpolation sicher:

  • Erreichbar sind ausschließlich Anfragedaten -- es gibt kein Scripting, und nichts außerhalb von req ist lesbar.
  • Zeilenumbrüche werden aus jedem aufgelösten Wert entfernt, sodass ein manipuliertes Cookie oder ein manipulierter Query-Parameter keine zusätzlichen Header einschleusen kann.
  • Ein unbekanntes oder leeres Feld löst sich zu nichts auf. Ein Set-Header, dessen Wert vollständig leer bleibt, wird verworfen und erreicht den Besucher nie; ein Cookie-Wert behält sein name=-Präfix, sodass die Set-Cookie-Zeile stets gesendet wird.

Log-Weiterleitung

Die CDN-Zugriffslogs dieser Zone lassen sich in Echtzeit vom smoxy-Edge an einen eigenen Log-Empfänger streamen. Konfiguriert werden Hostname und Port des Empfängers, das zu sendende Protokoll und Format sowie ein optionales Token zur Authentifizierung. Nur Hostnamen mit aktiviertem CDN erzeugen Logs.

INFO

Hinweis: Log-Weiterleitung ist nur mit CDN verfügbar.

Zu den verfügbaren Protokollen und Formaten sowie den vollständigen Einrichtungsdetails siehe Log-Weiterleitung.


Für Einstellungen zu Caching, Sicherheit, Bildoptimierung und benutzerdefinierten Seiten siehe die jeweiligen Feature-Dokumentationsseiten.