Conditional Rules

Conditional Rules ermöglichen die Anpassung des Verhaltens von smoxy basierend auf umfangreichen Bedingungen wie IP-Adressen, geografischem Standort, Headern, Cookies und mehr. Im Gegensatz zu Page Rules, die beim ersten Treffer stoppen, erlauben Conditional Rules, dass mehrere Regeln auf dieselbe Anfrage angewendet werden – perfekt für komplexe, mehrschichtige Konfigurationen.

Was sind Conditional Rules?

Conditional Rules erlauben es, jede smoxy-Konfigurationseinstellung basierend auf leistungsstarker bedingter Logik zu überschreiben. Sie sind ideal für Szenarien, in denen mehrere Konfigurationsänderungen zusammenwirken sollen oder wenn URL-Muster allein nicht ausreichen.

Wichtige Eigenschaften:

• Werden als viertes (letztes) in der Regelsequenz ausgeführt (nach Access, Rewrite und Page Rules)
• Umfangreicher Bedingungsabgleich – IP, Land, Header, Cookies, User Agents und mehr
• Werden in Positionsreihenfolge ausgewertet (1, 2, 3...)
• Alle passenden Regeln werden angewendet – mehrere Regeln können dieselbe Anfrage modifizieren
• Optionaler Stopp – stop=true setzen, um die weitere Auswertung zu beenden
• Können jede smoxy-Einstellung aus der Site-Konfiguration überschreiben

Wie Conditional Rules funktionieren

Conditional Rules werden in aufsteigender Positionsreihenfolge (1 -> 2 -> 3...) für jede eingehende Anfrage ausgewertet. Wenn die Bedingungen einer Regel zutreffen, werden ihre Einstellungen angewendet und die Auswertung fährt fort zur nächsten Regel (außer stop=true).

Positionsbasierte Auswertung

Anfrage aus Deutschland, mobiles Gerät
    |
Conditional Rule (Position 1) -> Treffer (Land = DE)? -> Einstellungen anwenden -> FORTFAHREN
    |
Conditional Rule (Position 2) -> Treffer (Mobil)? -> Einstellungen anwenden -> FORTFAHREN
    |
Conditional Rule (Position 3) -> Treffer (URI = /api)? -> Kein Treffer -> Überspringen
    |
Antwort (mit Einstellungen aus Regel 1 UND Regel 2)

Wichtig: Im Gegensatz zu Page und Access Rules stoppen Conditional Rules nicht automatisch nach dem ersten Treffer. Alle passenden Regeln wenden ihre Einstellungen an, außer eine Regel hat stop=true.

Bedingungen & Ausdrücke

Conditional Rules verwenden einen umfangreichen Bedingungs-Builder, mit dem sich Anfragen basierend auf verschiedenen Eigenschaften abgleichen lassen, darunter:

• URI: Anfragepfad
• Host: Domain-Name
• IP: Client-IP-Adresse oder IP-Bereiche
• Country: ISO 3166-2 Ländercode
• City: Stadt des Clients
• Subdivisions: Bundesland/Region
• Is European: Boolean – true wenn Anfrage aus der EU kommt
• Method: HTTP-Methode (GET, POST, PUT, DELETE usw.)
• User Agent: Browser- oder Client-Kennung
• Referer: URL der verweisenden Seite
• Accept Language: Bevorzugte Sprache des Clients
• Cookie: Bestimmter Cookie-Wert
• Arg: Query-Parameter-Wert
• HTTP: Beliebiger HTTP-Header-Wert
• Cache-Control: Cache-Control-Header-Direktiven

Operatoren

• Equal: Wert stimmt exakt überein
• Not Equal: Wert stimmt nicht überein
• In: Wert ist in einer Liste
• Not In: Wert ist nicht in einer Liste
• Matches: Entspricht Regex-Muster
• Contains: Enthält Teilstring
• Not Contains: Enthält Teilstring nicht
• Exists: Feld existiert (unabhängig vom Wert)
• Not Exists: Feld existiert nicht

UND/ODER-Logik

Mehrere Bedingungen lassen sich mit UND/ODER-Operatoren kombinieren, um ausgefeilte Regeln zu erstellen:

(Land = "DE" ODER Land = "AT" ODER Land = "CH")
UND
URI beginnt mit /checkout

Stop-Verhalten

Die Stop-Option ist einzigartig für Conditional Rules und steuert, ob die Auswertung nach einem Regeltreffer fortgesetzt wird.

Wie Stop funktioniert

Wenn stop=false (Standard):

• Einstellungen der Regel werden angewendet
• Auswertung fährt mit der nächsten Conditional Rule fort
• Mehrere Regeln können dieselbe Anfrage modifizieren

Wenn stop=true:

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

Wann Stop zu verwenden ist

stop=true einsetzen, wenn:

• Eine Regel endgültig sein soll und keine weiteren Änderungen nötig sind
• widersprüchliche Einstellungen von anderen Regeln verhindert werden sollen
• ein Wartungsmodus oder ähnliche Override-Szenarien implementiert werden

Beispiel:

Position 1: WENN (Wartungsmodus-Cookie) DANN (Wartungsseite anzeigen) STOPP
Position 2: WENN (Büro-IP) DANN (Auth deaktivieren) [wird während Wartung nie ausgewertet]
Position 3: WENN (Mobil) DANN (optimieren) [wird während Wartung nie ausgewertet]

Wann Conditional Rules verwenden

Conditional Rules verwenden wenn:

• komplexe Bedingungen benötigt werden (IPs, Länder, Header, Cookies usw.)
• mehrere Regeln auf dieselbe Anfrage angewendet werden sollen
• erweiterte UND/ODER-Logik mit mehreren Bedingungen benötigt wird
• URL-Muster allein nicht ausreichen
• Verschiedene Bedingungen unterschiedliche Konfigurationen erfordern, die sich stapeln sollen

Stattdessen Page Rules verwenden wenn:

• nur einfacher URL-basierter Abgleich benötigt wird
• Erster-Treffer-gewinnt-Verhalten gewünscht ist
• Die Logik nur mit URL-Mustern ausgedrückt werden kann

Einstellungen: Jede Konfiguration überschreiben

Conditional Rules können jede Einstellung aus der Konfiguration der Site überschreiben, genau wie Page Rules. Dazu gehören:

• Routing: Verschiedene Origins oder Load Balancer auswählen
• Caching: Cache-TTL, Cache-Keys, Cache-Tags steuern, Cache umgehen
• Bildoptimierung: AVIF, WebP, JPEG, PNG Qualitätsstufen
• Sicherheit: WAF, Basic Auth, benutzerdefinierte Fehlerseiten aktivieren/deaktivieren
• Header: Request/Response-Header hinzufügen, ändern oder entfernen
• Optimierung: HTML/JS/CSS-Minifizierung
• Erweitert: Wartungsmodus, Debug-Header, Proxy-Timeouts

Beim Erstellen oder Bearbeiten einer Conditional Rule einfach die zu überschreibenden Einstellungen auswählen. Die verfügbaren Einstellungen sind nach Kategorie im smoxy Dashboard gruppiert.

Anwendungsfälle & Beispiele

Beispiel 1: Geografische Inhaltsoptimierung

Szenario: Höhere Bildqualität für Nutzer in kaufkräftigen Märkten, Standardqualität für andere.

Position: 1
Bedingung: Land in ["US", "GB", "DE", "CH", "AU"]
Einstellungen:
- JPEG-Qualität: 85
- WebP-Qualität: 85

Position: 2
Bedingung: Land in ["IN", "BR", "MX"]
Einstellungen:
- JPEG-Qualität: 70
- WebP-Qualität: 70

Ergebnis: Beide Regeln können angewendet werden (wenn Bedingungen zutreffen), US-Nutzer bekommen höhere Qualität

Warum nicht Page Rules? Page Rules können nicht auf Land abgleichen – für geografisches Targeting werden Conditional Rules benötigt.

Beispiel 2: Basic Auth für Büro-IPs deaktivieren

Szenario: Die Site verwendet Basic Authentication, aber das Team soll sich vom Büro aus nicht einloggen müssen.

Position: 1
Bedingung: IP in [203.0.113.0/24, 198.51.100.50]
Einstellungen:
- Basic Authentication: Deaktiviert

Position: 2
Bedingung: URI beginnt mit "/admin"
Einstellungen:
- Basic Authentication: Aktiviert
- Basic Auth Benutzer: admin_users

Ergebnis: Büro umgeht Auth (Regel 1), aber Auth ist für den Admin-Bereich weiterhin aktiviert (Regel 2)

Warum nicht Access Rules? Access Rules sind zum Blockieren/Herausfordern/Whitelisten, nicht zum Umschalten von Features wie Basic Auth.

Beispiel 3: Mobil-optimierte Bilder

Szenario: Mobile Nutzer sollen aggressivere Bildoptimierung bekommen, um Bandbreite zu sparen.

Position: 1
Bedingung: User Agent matches "(Mobile|Android|iPhone|iPad)"
Einstellungen:
- JPEG-Qualität: 75
- PNG-Qualität: 80
- WebP-Qualität: 75
- Bild Max-Breite: 1200px

Position: 2
Bedingung: Land = "IN" UND User Agent matches "(Mobile|Android)"
Einstellungen:
- JPEG-Qualität: 65
- WebP-Qualität: 65

Ergebnis: Mobile Nutzer bekommen optimierte Bilder, mobile Nutzer in Indien bekommen Extra-Optimierung

Warum mehrere Regeln? Beide Regeln können angewendet werden – Regel 1 setzt die Basis-Mobiloptimierung, Regel 2 fügt Extra-Optimierung für bestimmte Märkte hinzu.

Conditional Rules vs Page Rules

Die wichtigsten Unterschiede:

Feature	Page Rules	Conditional Rules
Abgleich	Nur URL-Muster	Umfangreiche Bedingungen (IP, Land, Header usw.)
Ausführung	Erster Treffer gewinnt, stoppt	Alle passenden Regeln werden angewendet
Stop-Option	Nein	Ja (optional)
Position	3. in der Sequenz	4. (letzte) in der Sequenz
Einstellungen	Jede Einstellung überschreiben	Jede Einstellung überschreiben

Lassen sich beide verwenden? Absolut! Sie ergänzen sich:

Page Rule: /api/* -> API Load Balancer setzen
Conditional Rule: User-Agent = "mobile" -> Mobile Optimierungen aktivieren
-> Beide werden auf mobile Anfragen an /api/users angewendet

Ausführungsreihenfolge: Page Rule wird zuerst ausgeführt (stoppt bei Treffer), dann werden Conditional Rules ausgewertet (alle passenden werden angewendet).

Best Practices für die Regelreihenfolge

1. Kritische Regeln zuerst

Regeln, die immer Vorrang haben sollen, auf niedrigeren Positionen platzieren:

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

2. Stop strategisch einsetzen

Position 1: WENN (Notfallmodus) DANN (minimale Features) STOPP
Position 2+: Normale Betriebsregeln (werden im Notfall übersprungen)

3. Komplementäre Regeln schichten

Da alle passenden Regeln angewendet werden, lassen sich mehrschichtige Konfigurationen aufbauen:

Position 1: WENN (Land = "DE") DANN (DSGVO-konforme Header)
Position 2: WENN (Mobil) DANN (Mobile Optimierungen)
Position 3: WENN (URI = /checkout) DANN (Hohe Sicherheit)
-> Deutscher mobiler Checkout bekommt alle drei!

4. Widersprüchliche Einstellungen vermeiden

Wenn mehrere Regeln denselben Konfigurationsschlüssel setzen, gewinnt die letzte passende Regel:

Position 1: WENN (Land = "US") DANN (Cache TTL = 3600)
Position 2: WENN (URI = /api) DANN (Cache TTL = 60)
-> US-Anfragen an /api bekommen TTL = 60 (letzter Treffer gewinnt)

IP-Listen verwenden

Statt IPs in jeder Regel fest zu codieren, lassen sich wiederverwendbare IP-Listen in den Kontoeinstellungen erstellen:

1. Eine IP-Liste namens "office_ips" mit den Büro-IP-Bereichen erstellen
2. In den Conditional-Rule-Bedingungen referenzieren

Vorteil: Die IP-Liste wird einmal aktualisiert, und alle Regeln, die sie verwenden, werden automatisch auf allen Sites aktualisiert.

Eindeutigkeit

Jede Site kann nur eine Conditional Rule pro eindeutigem Ausdruck haben. Beim Versuch, ein Duplikat zu erstellen, erscheint: "Die Regel für diesen Ausdruck existiert bereits."

Das verhindert doppelte Regeln und hält die Konfiguration übersichtlich.

Häufige Fehler

Vergessen, dass Regeln sich stapeln

Position 1: WENN (URI = /api) DANN (Cache = deaktiviert)
Position 2: WENN (URI = /api/*) DANN (Cache = aktiviert & Cache TTL = 3600)
-> Beide werden angewendet, letzte gewinnt: Cache = aktiviert mit TTL 3600

Interaktionen beachten

stop=true verwenden oder bei Bedarf in eine Regel zusammenfassen

---

Stop zu früh verwenden

Position 1: WENN (Land = "US") DANN (Einstellungen) STOPP
Position 2: WENN (Mobil) DANN (Mobile Einstellungen) [gilt nie für US-Mobilnutzer]

Stop nur wenn nötig

stop=true nur setzen, wenn die Auswertung wirklich beendet werden muss

---

Conditional Rules für einfache URLs verwenden

Bedingung: URI beginnt mit "/admin"
-> Sollte stattdessen Page Rule verwenden

Page Rules für reine URL-Logik verwenden

Page Rule: Match /admin/* -> Einstellungen
(Einfacher und wird früher ausgeführt)

---

Widersprüchliche Einstellungen aus mehreren Regeln

Position 1: WENN (Mobil) DANN (Bildqualität = 80)
Position 2: WENN (Land = "US") DANN (Bildqualität = 90)
-> US-Mobilnutzer bekommen Qualität = 90 (letzter Treffer gewinnt)

Für überlappende Bedingungen planen

Entweder Stop einsetzen, Positionen anpassen oder Letzter-Treffer-gewinnt-Verhalten akzeptieren

Conditional Rules testen

1. Debug-Header aktivieren in der Site-Konfiguration
2. Testanfragen mit verschiedenen Bedingungen durchführen (IPs, User Agents usw.)
3. Response-Header prüfen um zu sehen, welche Conditional Rules zutrafen
4. Verifizieren, dass die Einstellungen in der erwarteten Reihenfolge angewendet werden
5. Überlappende Bedingungen testen um sicherzustellen, dass das Letzter-Treffer-gewinnt-Verhalten akzeptabel ist