# 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**: Priorisiere Sicherheitsaktionen. * **Rewrite Rules als zweites**: Transformiere URLs für konsistente Verarbeitung. * **Conditional Rules zuletzt**: Implementiere komplexe Logikbedingungen. **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 → ...) * Wenn du eine neue Regel erstellst, 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 du zuerst anwenden möchtest, sollten niedrigere Positionen haben ### Regeln neu anordnen Du kannst die Ausführungsreihenfolge deiner Regeln jederzeit über die Drag-and-Drop-Oberfläche im smoxy Dashboard ändern. #### **Wie das Neuanordnen funktioniert** Wenn du eine Regel an eine neue Position verschiebst: 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**: * Setze eine sehr hohe Positionsnummer (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:** Platziere Skip-Regeln (Whitelist) auf niedrigeren Positionen (1, 2, 3...) 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, Page) 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** Aktiviere **Debug-Header** in der Konfiguration deiner Website um zu sehen: * Welche Regeln angewendet wurden * Cache-Treffer/Miss-Status * Details zur Regelauswertung Dies hilft dir zu verstehen, wie genau deine 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 ``` ### Deine Regelreihenfolge testen 1. **Aktiviere Debug-Header** in deiner Website-Konfiguration 2. **Führe Testanfragen** an deine Website durch 3. **Prüfe die Response-Header** um zu sehen, welche Regeln angewendet wurden 4. **Passe die Positionen** basierend auf den Ergebnissen an 5. **Wiederhole** bis du das gewünschte Verhalten erreichst