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 (blockieren, herausfordern, überspringen, fortfahren).
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 (skip- oder continue-Aktionen) 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	skip-Aktion kann nachfolgende Regeln überspringen
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 - Positionsbasiert mit Skip

Access Rules werden in Positionsreihenfolge ausgewertet, aber die skip-Aktion beeinflusst die nachfolgende Ausführung:

• Block/Challenge-Aktionen: Fahren mit der nächsten Access Rule fort
• Skip-Aktion mit Flags:
  • access_rules=true: Überspringt verbleibende Access Rules
  • waf=true: Umgeht die Web Application Firewall

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

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

Rewrite Rules - Erster Treffer gewinnt

Rewrite Rules stoppen nach dem ersten passenden URL-Muster:

Position 1: Treffer /alter-pfad -> Umschreiben zu /neuer-pfad -> STOPP
Position 2: Treffer /legacy/* -> WIRD NICHT AUSGEWERTET
Position 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:

Position 1: Treffer (IP aus Büro) -> Einstellungen angewendet -> Fortfahren
Position 2: Treffer (Land = DE) -> Einstellungen angewendet -> Fortfahren
Position 3: Treffer (URI = /api/*) -> Einstellungen angewendet -> Fortfahren
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:

Position 1: WENN (Wartungsmodus) DANN (Wartungsseite anzeigen) STOPP
Position 2: WENN (Büro-IP) DANN (Basic Auth deaktivieren) [wird während Wartung nie ausgewertet]
Position 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 Site 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 (max. 5 Regeln insgesamt)

4. 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 Site-Konfiguration
2. Testanfragen an die Site 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