smoxy

Deutsch

English

Deutsch

English

Erscheinungsbild

Lebenszyklus einer Anfrage ​

Diese Seite erklärt, was mit einer Anfrage geschieht — vom Moment, in dem der Browser eines Besuchers den Hostnamen auflöst, bis zur Auslieferung der Antwort — und in welcher Reihenfolge die Features von smoxy darauf wirken. Sie ist das mentale Modell hinter allen anderen Seiten: Sicherheitsentscheidungen, Regeln, Caching und Origin-Abrufe passieren jeweils an einem festen Punkt dieser Sequenz.

Besucher
Edge
  1. 1
    DNS & TLS
    CNAME zeigt auf smoxy · Zertifikat wird ausgeliefert
  2. 2
    Hostname → Zone
    Zoneneinstellungen & CDN-Flag greifen
Sicherheit
  1. 3
    IP-Listen
    globales Allow gewinnt · dann Zonen-Allow/Block · dann globales Block
  2. 4
    Access Rules
    Allow · Block · Challenge · Skip
  3. 5
    Szenarien & WAF
    Reputation · Under-Attack-Modus · WAF
Regeln
  1. 6
    Rewrite Rules
    URL wird umgeschrieben, bevor sie weiterverarbeitet wird
  2. 7
    Conditional Rules
    Überschreibungen pro Anfrage · danach Basic Auth
Cache & Origin
  1. 8
    Cache
    MISS/BYPASS gehen weiter zum Origin
    HIT ▸ direkt vom Edge
  2. 9
    Origin
    Standard-Backend (Origin oder Load Balancer)
Antwort
  1. 10
    Antwortverarbeitung
    eigene Header · Fehlerseiten · SSI/ESI · Bildoptimierung
Besucher

1. DNS & TLS ​

Eine Anfrage erreicht smoxy, weil der CNAME-Eintrag des Hostnamens auf smoxy zeigt. Solange dieser Eintrag nicht auf smoxy auflöst, greift nichts auf dieser Seite — die Zone kann vollständig konfiguriert und Zertifikate ausgestellt werden, ohne dass Traffic umgeleitet wird.

Am Edge terminiert smoxy TLS mit dem Zertifikat, das den Hostnamen abdeckt (siehe Wie SSL funktioniert).

2. Hostname → Zonen-Zuordnung ​

Der Host-Header ordnet die Anfrage einem Hostnamen zu, der Hostname seiner Zone. Ab hier gilt die gesamte Konfiguration der Zone: Proxy-Einstellungen, Sicherheit, Regeln, Caching und Optimierung. Zwei Schalter steuern alles Weitere:

  • Der Aktiviert/Deaktiviert-Schalter der Zone (Zonen-Header) — eine deaktivierte Zone verarbeitet Traffic nicht mit smoxy-Features.
  • Das CDN-Flag des Hostnamens — bei deaktiviertem CDN werden Caching und Optimierung für diesen Hostnamen übersprungen; Proxy- und Sicherheitsverarbeitung können weiterhin greifen.

Weiterleitungen werden direkt nach der Zonen-Zuordnung aufgelöst — ein Weiterleitungs-Hostname antwortet hier, vor jeglicher Sicherheits- oder Inhaltsverarbeitung.

Siehe Hostnamen und Was ist eine Zone?.

3. IP-Listen ​

Die Sicherheitsprüfung passiert vor der Inhaltsverarbeitung — blockierter Traffic berührt also weder den Cache noch den Origin. Die IP-Listen werden in dieser Reihenfolge ausgewertet — ein Allow überspringt alles Weitere:

  1. Globale Allowlist — die von smoxy verwaltete Vertrauensliste. Ein Treffer ist absolut: Er umgeht alles Weitere, einschließlich Zonen-Blockliste, Access Rules und Basic Auth. Das ist die einzige Ausnahme vom Customer-first-Prinzip und bleibt der eigenen vertrauenswürdigen Infrastruktur von smoxy vorbehalten.
  2. Zonen-Allowlist — ein Treffer markiert die Anfrage als s-allowlist und überspringt Zonen-Blockliste, Reputation, Under-Attack-Modus und WAF. Access Rules und Basic Auth werden nicht übersprungen. Da Allowlist-Traffic von den verwalteten Szenarien weder erfasst noch bewertet wird, kann eine gelistete IP von einem Szenario weder blockiert noch per Challenge geprüft werden. Ein Zonen-Allowlist-Eintrag überschreibt zudem die globale Blockliste von smoxy für diese Zone.
  3. Zonen-Blockliste — ein Block-Eintrag beendet die Anfrage hier (eine Challenge muss bestanden werden). Da dies vor den Regelstufen läuft, lässt sich ein Zonen-Blocklisteneintrag nicht durch eine Allow-Access-Rule überschreiben — zum Ausnehmen einer IP dient die Zonen-Allowlist.
  4. Globale Blockliste — die von smoxy verwaltete Blockliste. Ein Zonen-Allowlist-Eintrag (Schritt 2) überschreibt sie für diese Zone.

Das entspricht der in Threat Lookup angezeigten Entscheidungsquelle: Zone → globale Blockliste → globale Reputation.

4. Access Rules ​

Access Rules laufen nach den IP-Listen und vor der Szenario-/WAF-Stufe: Sie werten Anfrageeigenschaften aus (IP, Land, Pfad, User Agent, …) und erlauben, blockieren, prüfen per Challenge oder überspringen. Die Skip-Aktion nimmt die Anfrage von der WAF-Stufe oder von Challenges aus; der Stop-Modus beendet die Auswertung weiterer Access Rules nach einem Treffer. Access Rules gelten auch für Zonen-Allowlist-Traffic — sie sind die eigene Richtlinienebene oberhalb der Vertrauenslisten.

5. Szenarien & WAF ​

Sofern kein Allow (oder eine Skip-Aktion) die Anfrage ausgenommen hat, folgen drei Prüfungen in dieser Reihenfolge:

  1. Reputation — von den verwalteten Szenarien für diese IP getroffene Entscheidungen (Block, Challenge oder Throttle). Die Szenario-Engine selbst läuft asynchron auf den Traffic-Logs; der Anfragepfad setzt nur ihre gespeicherten Urteile durch — weshalb Threat Lookup die vollständige Entscheidungshistorie zeigen kann.
  2. Under-Attack-Modus — ist er für die Zone aktiv, müssen Besucher eine Challenge bestehen, bevor es weitergeht.
  3. WAF — das verwaltete Regelwerk prüft die Anfrage und blockiert Treffer (in der Regel mit einer 403).

6. Rewrite Rules ​

Rewrite Rules transformieren die URL, bevor sie weiterverarbeitet wird. Alles nach dieser Stufe — Conditional Rules, der Cache-Key und die Origin-Anfrage — arbeitet mit der umgeschriebenen URL. Regeln matchen mit =, ~ oder ~* und können Capture-Groups im Ziel wiederverwenden.

7. Conditional Rules ​

Conditional Rules sind die letzte Regelstufe. Alle passenden Regeln werden angewendet (in aufsteigender Positionsreihenfolge, sofern keine passende Regel Stop setzt), und jede kann Zoneneinstellungen für diese eine Anfrage überschreiben — Caching-Verhalten, Cache-Key-Zusammensetzung, Bildoptimierung, Basic Auth und mehr. Details unter Ausführung & Reihenfolge.

Nach den Regelstufen wird Basic Auth durchgesetzt (wie auf der Zone konfiguriert oder pro Regel überschrieben). Es gilt auch für Zonen-Allowlist-Traffic — ein Zonen-Allow umgeht Basic Auth nie. Einzige Ausnahme ist ein Treffer auf der globalen Allowlist, der Basic Auth zusammen mit allem Übrigen umgeht (Schritt 1 oben).

8. Cache ​

Nach bestandener Sicherheitsprüfung und mit finaler URL entscheidet smoxy, ob die Antwort aus dem Edge-Cache kommen kann:

  1. Eignung — der Hostname hat CDN aktiviert und der Content-Type der Antwort ist cachebar (siehe Unterstützte MIME-Typen). HTML erfordert den aktivierten Dynamischen Cache der Zone.
  2. Cache-Key — gebildet aus Request-URI und Query-String, optional erweitert um Hostname, Land, Cookie- und Header-Werte (Cache).
  3. HIT — der Key existiert im Cache: Die Antwort kommt vom Edge, der Origin wird nicht kontaktiert, die Antwort trägt s-cache: HIT.
  4. MISS — noch nicht gecacht: Die Anfrage geht weiter zum Origin, die Antwort wird gemäß TTL und Cache-Control des Origins gespeichert.
  5. BYPASS — smoxy überspringt den Cache absichtlich: Der Origin sendete no-cache, private oder max-age=0 ohne positives s-maxage (bei aktiviertem Origin-Cache-Control berücksichtigen), die Anfrage trug einen gültigen http-bypass-Header, oder der Content-Type ist ungeeignet. Wichtig: s-maxage hat Vorrang — max-age=0, s-maxage=3600 wird gecacht (Details).

Stale-Cache-Optionen können abgelaufene Inhalte ausliefern, während der Origin nicht erreichbar ist oder eine frische Kopie geholt wird (Stale-Cache).

9. Origin ​

Bei MISS oder BYPASS leitet smoxy die Anfrage an das Standard-Backend der Zone weiter — einen einzelnen Origin oder einen Load Balancer, der per Random oder IP Hash über Origins verteilt (Backends). Die Anfrage erreicht den Origin mit:

  • dem konfigurierten Host-Header (oder dem Standard des Origins),
  • den eigenen Request-Headern (Proxy),
  • den GeoIP-Headern von smoxy zum Standort des Besuchers (GeoIP-Header).

Ist das Backend ein Load Balancer, wird bei einem Verbindungsfehler auf den nächsten funktionsfähigen Origin ausgewichen — erneut versucht wird nur, solange noch nichts an einen Origin gesendet wurde (Ausfallsicherheit und Failover).

10. Antwortverarbeitung ​

Bevor die Antwort den Besucher erreicht, wendet smoxy an:

  • Eigene Response-Header — nach der Origin-Antwort angewendet, sodass sie gleichnamige Origin-Header überschreiben (Proxy).
  • Debug-Header — einschließlich s-cache, falls aktiviert (Proxy).
  • Eigene Fehlerseiten — ein 502/504 vom Origin sowie das 503, das smoxy erzeugt, wenn kein Origin verfügbar ist, werden durch die Fehlerseite der Zone ersetzt (Eigene Seiten).
  • SSI-/ESI-Verarbeitung — Edge-seitiges Seiten-Zusammensetzen (Cache). ESI-Tags werden in SSI-Includes umgeschrieben, und die Includes werden bei der Auslieferung expandiert, bei jeder Anfrage: bei Cache-HITs ebenso wie bei MISSes. Der Cache speichert die nicht zusammengesetzte Seite; jedes eingebundene Fragment wird unabhängig geholt und gecacht.
  • Bildoptimierung — AVIF/WebP-Konvertierung und Qualitätssteuerung, gemäß Zoneneinstellungen oder Conditional-Rule-Überschreibungen (Optimierung). Die Konvertierung läuft asynchron nach dem ersten Miss: Die erste Antwort liefert das Original, ein Optimierungsjob erzeugt anschließend die Varianten. Varianten werden als separate Cache-Dateien neben dem Original gespeichert und pro Anfrage anhand des Accept-Headers ausgewählt.
  • HTML-Minifizierung — falls aktiviert (Optimierung).

Weiterführend ​