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
  │
  1. DNS & TLS ─── CNAME zeigt auf smoxy · Zertifikat wird ausgeliefert
  │
  2. Hostname → Zone ─── Zoneneinstellungen & CDN-Flag greifen
  │
  3. IP-Listen ─── zuerst Zonen-Allow/Block, dann global Allow/Block
  │
  4. Access Rules ─── Allow · Block · Challenge · Skip
  │
  5. Szenarien & WAF ─── Reputation · Under-Attack-Modus · WAF
  │
  6. Rewrite Rules ─── URL wird umgeschrieben, bevor sie weiterverarbeitet wird
  │
  7. Conditional Rules ─── Überschreibungen pro Anfrage · danach Basic Auth
  │
  8. Cache ─── HIT direkt vom Edge · MISS/BYPASS gehen weiter
  │
  9. Origin ─── Standard-Backend (Origin oder Load Balancer)
  │
  10. Antwortverarbeitung ─── Optimierung · SSI/ESI · eigene Header · eigene Seiten
  │
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 Customer-first ausgewertet — die Entscheidung der eigenen Zone überschreibt die globale:

  1. 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.
  2. 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.
  3. Globale Allowlist — die von smoxy verwaltete Vertrauensliste; ein Treffer umgeht alles Weitere einschließlich der Access Rules.
  4. Globale Blockliste — die von smoxy verwaltete Blockliste. Konsequenz des Customer-first-Prinzips: Ein Zonen-Allowlist-Eintrag überschreibt für diese Zone sogar einen globalen Block.

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 Allowlist-Traffic — ein Allow umgeht Basic Auth nie.

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 und Cookie-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).

10. Antwortverarbeitung ​

Bevor die Antwort den Besucher (und den Cache) erreicht, wendet smoxy an:

  • Bildoptimierung — AVIF/WebP-Konvertierung und JPEG-Qualitätssteuerung, gemäß Zoneneinstellungen oder Conditional-Rule-Überschreibungen (Optimierung).
  • HTML-Minifizierung — falls aktiviert (Optimierung).
  • SSI-/ESI-Verarbeitung — Edge-seitiges Seiten-Zusammensetzen (Cache).
  • Eigene Response-Header (Proxy).
  • Eigene Fehlerseiten — anstelle von Fehlerantworten (Eigene Seiten).
  • Debug-Header — einschließlich s-cache, falls aktiviert (Proxy).

Zu klären (Edge-Team)

Die genaue Reihenfolge innerhalb der Antwortverarbeitung (z. B. Minifizierung vor/nach dem SSI-/ESI-Zusammensetzen; ob optimierte Bildvarianten separat gecacht werden) ist noch nicht dokumentiert.

Weiterführend ​