Regelausführung & Reihenfolge

Das Verständnis, wie smoxy Regeln auswertet und ausführt, ist entscheidend für den Aufbau effektiver Traffic-Management- und Sicherheitsrichtlinien. Diese Seite erklärt den Ausführungsablauf, das Reihenfolgensystem und die Verhaltensmuster aller Regeltypen.

Ausführungsablauf zwischen Regeltypen

Anfragen werden in einer bestimmten Reihenfolge verarbeitet:

1. Access Rules: Sicherheitsebene, wird zuerst ausgewertet, trifft Sicherheitsentscheidungen (zulassen, blockieren, herausfordern, überspringen).
2. Rewrite Rules: URL-Umschreibung, modifiziert die Anfrage-URL bevor andere Regeln angewendet werden.
3. Conditional Rules: Bedingungsbasierte Einstellungen, werden zuletzt angewendet.

Bedeutung der Reihenfolge:

• Access Rules zuerst: Sicherheitsaktionen priorisieren.
• Rewrite Rules als zweites: URLs für konsistente Verarbeitung transformieren.
• Conditional Rules zuletzt: Komplexe Logikbedingungen implementieren.

Beispiel: Eine Anfrage an /alte-seite kann über eine Rewrite Rule zu /neue-seite umgeschrieben werden. Dann werden Conditional Rules für /neue-seite angewendet.

Position innerhalb jedes Regeltyps

Wie Position funktioniert

Innerhalb jedes Regeltyps werden Regeln basierend auf ihrer Position (auch Reihenfolge genannt) ausgewertet:

• Position beginnt bei 1 (nicht 0)
• Regeln werden in aufsteigender Reihenfolge ausgewertet (1 -> 2 -> 3 -> ...)
• Beim Erstellen einer neuen Regel wird ihr automatisch die nächste verfügbare Position zugewiesen
• Position ist unabhängig für jeden Regeltyp (z. B. Access Rule #1 und Conditional Rule #1 sind getrennt)

Beispiel:

Access Rules: Position 1, 2, 3, 4, 5...
Rewrite Rules: Position 1, 2, 3...
Conditional Rules: Position 1, 2, 3, 4...

Position bestimmt die Auswertungsreihenfolge

Die Positionsnummer bestimmt, welche Regel innerhalb ihres Typs zuerst ausgewertet wird:

Position 1: Wird ZUERST ausgewertet
Position 2: Wird als ZWEITES ausgewertet
Position 3: Wird als DRITTES ausgewertet
...
Position N: Wird ZULETZT ausgewertet

Dies ist besonders wichtig für:

• Access Rules: Whitelist-Regeln (Allow/Skip) sollten niedrigere Positionen haben als Block-Regeln
• Rewrite Rules: Spezifischere URL-Muster sollten vor allgemeinen Mustern kommen
• Conditional Rules: Regeln, die zuerst angewendet werden sollen, sollten niedrigere Positionen haben

Regeln neu anordnen

Die Ausführungsreihenfolge der Regeln lässt sich jederzeit über die Drag-and-Drop-Oberfläche im smoxy Dashboard ändern.

Wie das Neuanordnen funktioniert

Beim Verschieben einer Regel an eine neue Position:

1. Nach OBEN verschieben (zu einer kleineren Positionsnummer):
   • Alle Regeln zwischen der neuen und alten Position verschieben sich nach unten (+1)
2. Nach UNTEN verschieben (zu einer größeren Positionsnummer):
   • Alle Regeln zwischen der alten und neuen Position verschieben sich nach oben (-1)
3. Ans Ende verschieben:
   • Eine sehr hohe Positionsnummer setzen (z. B. 100)
   • Das System platziert sie automatisch am Ende

Beispiel:

Vorher: [Regel-1, Regel-2, Regel-3, Regel-4, Regel-5]
Verschiebe Regel-5 auf Position 2
Nachher: [Regel-1, Regel-5, Regel-2, Regel-3, Regel-4]

Positionsvalidierung

Das System stellt sicher:

• Keine doppelten Positionen
• Keine Lücken in den Positionsnummern
• Sequentielle Reihenfolge wird beibehalten
• Bei erkannten Konflikten werden alle Positionen automatisch neu berechnet

Erster Treffer vs. alle Treffer

Verschiedene Regeltypen haben unterschiedliche Ausführungsmuster:

Regeltyp	Ausführungsmuster	Stoppt nach Treffer?	Hinweise
Access Rules	Alle Treffer anwenden	Optional	Stop-Modus kann die weitere Auswertung stoppen
Rewrite Rules	Erster Treffer gewinnt	Ja	Stoppt nach erstem URL-Treffer
Conditional Rules	Alle Treffer anwenden	Optional	Fährt fort, außer stop=true

Access Rules - Alle Treffer werden angewendet

Access Rules werden in Positionsreihenfolge ausgewertet, und standardmäßig wendet jede passende Regel ihre Aktion an, bevor die Auswertung mit der nächsten Regel fortfährt. Zwei Mechanismen ändern das:

• Flags der Skip-Aktion: Die Skip-Aktion umgeht bestimmte Sicherheitsfunktionen für die Anfrage (sie überspringt keine anderen Access Rules):
  • waf: Umgeht die Web Application Firewall
  • challenge: Umgeht Challenge, einschließlich Under Attack Mode
• Stop-Modus: Ein Schalter pro Regel. Wenn eine passende Regel den Stop-Modus aktiviert hat, werden alle verbleibenden Access Rules übersprungen.

Best Practice: Whitelist-Regeln (Allow/Skip) auf niedrigeren Positionen (1, 2, 3...) platzieren und Block/Challenge-Regeln auf höheren Positionen.

Rewrite Rules - Erster Treffer gewinnt

Rewrite Rules stoppen nach dem ersten passenden URL-Muster:

1. 1
   Treffer /alter-pfad

   umgeschrieben zu /neuer-pfad
   erster Treffer ▸ STOPP
2. 2
   Treffer /legacy/*

   wird nicht ausgewertet
3. 3
   Treffer /*

   wird nicht ausgewertet

Wichtig: Reihenfolge ist entscheidend! Spezifischere Muster sollten vor allgemeinen Mustern kommen.

Conditional Rules - Alle Treffer werden angewendet

Conditional Rules werten alle aktivierten Regeln aus, deren Bedingungen erfüllt sind:

1. 1
   Treffer: IP aus Büro

   Einstellungen angewendet · Auswertung fährt fort
2. 2
   Treffer: Land = DE

   Einstellungen angewendet · Auswertung fährt fort
3. 3
   Treffer: URI = /api/*

   Einstellungen angewendet · Auswertung fährt fort

Alle drei Regeln können auf dieselbe Anfrage angewendet werden!

Ausnahme: Wenn eine Regel stop=true hat, werden keine weiteren Conditional Rules ausgewertet.

Stop-Verhalten (Conditional & Access Rules)

Die Stop-Option ist nur für Conditional & Access Rules verfügbar.

Wie Stop funktioniert

Wenn aktiviert (stop=true):

• Die Einstellungen der Regel werden angewendet
• Alle nachfolgenden Regeln werden übersprungen
• Andere Regeltypen (Rewrite, Conditional) sind nicht betroffen

Wenn deaktiviert (stop=false, Standard):

• Die Einstellungen der Regel werden angewendet
• Die Auswertung fährt mit der nächsten Regel fort

Anwendungsbeispiel:

1. 1
   WENN Wartungsmodus

   DANN Wartungsseite anzeigen
   STOPP
2. 2
   WENN Büro-IP

   DANN Basic Auth deaktivieren · wird während Wartung nie ausgewertet
3. 3
   WENN Mobil

   DANN Bilder optimieren · wird während Wartung nie ausgewertet

Cache-Hit vs. Cache-Miss Ausführung

Regeln werden in verschiedenen Phasen ausgeführt, abhängig davon, ob Inhalte aus dem Cache oder vom Origin-Server geladen werden:

Typischer Ausführungskontext

• Access Rules: Werden bei Cache-Hit und Cache-Miss ausgeführt (Sicherheit gilt immer)
• Rewrite Rules: Werden vor der Cache-Abfrage ausgeführt (URL-Transformation erfolgt zuerst)
• Conditional Rules: Werden basierend auf Anfragebedingungen ausgeführt (unabhängig vom Cache-Status)

Debug-Header

Debug-Header in der Konfiguration der Zone aktivieren um zu sehen:

• Welche Regeln angewendet wurden
• Cache-Treffer/Miss-Status
• Details zur Regelauswertung

Das hilft zu verstehen, wie genau die Regeln für jede Anfrage ausgeführt werden.

Best Practices für die Regelreihenfolge

1. Access Rules - Whitelist zuerst

Position 1-3: Skip-Regeln (vertrauenswürdige IPs, interne Tools)
Position 4+: Block/Challenge-Regeln (verdächtiger Traffic)

2. Rewrite Rules - Spezifisch vor allgemein

Position 1: /exakte-alte-url -> /neue-url (am spezifischsten)
Position 2-3: Regex-Muster
Position 4-5: Catch-all-Muster (am wenigsten spezifisch zuletzt)

Alle Regeltypen teilen sich ein gemeinsames Regelbudget pro Zone (Standard: 30 Regeln), daher gibt es keine separate Obergrenze für die Anzahl der Rewrite Rules.

3. Conditional Rules - Kritische zuerst

Position 1: Wartungsmodus (mit stop=true)
Position 2-5: Geschäftslogik-Regeln
Position 6+: Optimierungsregeln

Regelreihenfolge testen

1. Debug-Header aktivieren in der Zonen-Konfiguration
2. Testanfragen an die Zone durchführen
3. Response-Header prüfen um zu sehen, welche Regeln angewendet wurden
4. Positionen anpassen basierend auf den Ergebnissen
5. Wiederholen, bis das gewünschte Verhalten erreicht ist