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 Rewrite Rules, die beim ersten Treffer stoppen, erlauben Conditional Rules, dass mehrere Regeln auf dieselbe Anfrage angewendet werden – perfekt für komplexe, mehrschichtige Konfigurationen.

Conditional Rules: Verhalten anhand von Bedingungen anpassen.

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 drittes (letztes) in der Regelsequenz ausgeführt (nach Access und Rewrite 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 Zonen-Konfiguration überschreiben

Der Traffic-Reihenfolge-Drawer: wo Conditional Rules in der Anfrage-Pipeline stehen.

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 Rewrite 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-1 alpha-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
• Header: Beliebiger HTTP-Header-Wert
• Cache-Control: Cache-Control-Header-Direktiven

Operatoren

• Gleich: Wert stimmt exakt überein
• Ungleich: Wert stimmt nicht überein
• Ist in: Wert ist in einer Werteliste enthalten
• Ist nicht in: Wert ist nicht in einer Werteliste enthalten
• Ist in CIDR: Client-IP liegt innerhalb eines CIDR-Bereichs oder entspricht einer einzelnen IP-Adresse (nur IP-Feld)
• Ist nicht in CIDR: Client-IP liegt außerhalb eines CIDR-Bereichs bzw. entspricht nicht der einzelnen IP-Adresse (nur IP-Feld)
• Ist in Liste: Client-IP ist in einer referenzierten IP-Liste (nur IP-Feld)
• Ist nicht in Liste: Client-IP ist nicht in einer referenzierten IP-Liste (nur IP-Feld)
• Entspricht: Entspricht einem Regex-Muster
• Enthält: Enthält einen Teilstring
• Enthält nicht: Enthält keinen Teilstring
• Vorhanden: Feld existiert (unabhängig vom Wert)
• Nicht vorhanden: Feld existiert nicht

Das IP-Feld bietet die CIDR- und Listen-Operatoren (Ist in CIDR / Ist nicht in CIDR, Ist in Liste / Ist nicht in Liste) anstelle der generischen Ist in / Ist nicht in. Die CIDR-Operatoren akzeptieren sowohl CIDR-Bereiche (203.0.113.0/24) als auch einzelne IPv4-/IPv6-Adressen (203.0.113.45); eine einzelne Adresse trifft genau auf diese Adresse zu.

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

Der Conditional-Rule-Editor: der Wenn-Bedingungs-Builder und der Dann-Einstellungs-Picker, mit der Regelliste in der linken Leiste.

Stop-Verhalten

Die Stop-Option steuert, ob die Auswertung nach einem Regeltreffer fortgesetzt wird (Access Rules besitzen mit dem Stop-Modus ein Äquivalent).

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) 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 Rewrite Rules verwenden wenn:

• nur eine URL umgeschrieben oder normalisiert werden soll, ohne die Konfiguration zu ändern
• die Änderung sich nur mit URL-Mustern ausdrücken lässt
• die Transformation früher erfolgen soll, bevor Conditional Rules ausgewertet werden

Einstellungen: Jede Konfiguration überschreiben

Conditional Rules können jede Einstellung aus der Konfiguration der Zone überschreiben. 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-Minifizierung
• Erweitert: Wartungsmodus, Debug-Header

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.

Der Dann-Einstellungs-Picker: Zoneneinstellungen durchsuchen, den Zonen-Standardwert sehen und eine Überschreibung hinzufügen.

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 Conditional Rules? Land lässt sich nicht allein mit URL-Mustern abgleichen – für geografisches Targeting werden die umfangreichen Bedingungen der Conditional Rules benötigt.

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

Szenario: Die Zone 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 Rewrite Rules

Die wichtigsten Unterschiede:

Feature	Rewrite 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 (stoppt immer bei Treffer)	Ja (optional)
Position	2. in der Sequenz	3. (letzte) in der Sequenz
Zweck	Die Anfrage-URL umschreiben	Jede Zoneneinstellung überschreiben

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

Rewrite Rule: ^/legacy/(.*)$ -> /$1 (URL normalisieren)
Conditional Rule: User-Agent = "mobile" -> Mobile Optimierungen aktivieren
-> Die URL wird zuerst umgeschrieben, dann werden Conditional Rules auf die umgeschriebene Anfrage angewendet

Für das vollständige Bild, wie die Regeltypen in Reihenfolge ausgewertet werden, siehe Ausführung & Reihenfolge.

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 Zonen aktualisiert.

Eindeutigkeit

Jede Zone 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

---

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 Zonen-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