Conditional Rules
Conditional Rules ermöglichen es dir, das Verhalten von smoxy basierend auf umfangreichen Bedingungen wie IP-Adressen, geografischem Standort, Headern, Cookies und mehr anzupassen. 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 dir, 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 – setze
stop=true, um die weitere Auswertung zu beendenKönnen jede smoxy-Einstellung aus deiner Website-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
Mit Conditional Rules kannst du Anfragen anhand verschiedener Eigenschaften abgleichen:
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 –
truewenn Anfrage aus der EU kommtMethod: 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
Kombiniere mehrere Bedingungen mit UND/ODER-Operatoren, um ausgefeilte Regeln zu erstellen:
(Land = "DE" ODER Land = "AT" ODER Land = "CH")
UND
URI beginnt mit /checkoutStop-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 verwenden
Verwende stop=true wenn:
Eine Regel endgültig sein soll und keine weiteren Änderungen nötig sind
Du widersprüchliche Einstellungen von anderen Regeln verhindern möchtest
Du Wartungsmodus oder ähnliche Override-Szenarien implementierst
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
Verwende Conditional Rules wenn:
✅ Du komplexe Bedingungen benötigst (IPs, Länder, Header, Cookies usw.)
✅ Du möchtest, dass mehrere Regeln angewendet werden auf dieselbe Anfrage
✅ Du erweiterte UND/ODER-Logik mit mehreren Bedingungen benötigst
✅ URL-Muster allein nicht ausreichen
✅ Verschiedene Bedingungen unterschiedliche Konfigurationen erfordern, die sich stapeln sollen
Verwende stattdessen Page Rules wenn:
❌ Du nur einfachen URL-basierten Abgleich benötigst
❌ Du Erster-Treffer-gewinnt-Verhalten möchtest
❌ Die Logik nur mit URL-Mustern ausgedrückt werden kann
Einstellungen: Jede Konfiguration überschreiben
Conditional Rules können jede Einstellung aus der Konfiguration deiner Website ü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
Wähle einfach die Einstellungen aus, die du überschreiben möchtest, wenn du eine Conditional Rule erstellst oder bearbeitest. 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ätWarum nicht Page Rules? Page Rules können nicht auf Land abgleichen – du brauchst Conditional Rules für geografisches Targeting.
Beispiel 2: Basic Auth für Büro-IPs deaktivieren
Szenario: Deine Website verwendet Basic Authentication, aber dein Team sollte 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-OptimierungWarum 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:
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
Kann man 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 angewendetAusfü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
Platziere Regeln, die immer Vorrang haben sollen, auf niedrigeren Positionen:
Position 1: Wartungsmodus (mit stop=true)
Position 2-5: Geschäftslogik-Regeln
Position 6+: Optimierungsregeln2. 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, kannst du 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
Anstatt IPs in jeder Regel fest zu codieren, erstelle wiederverwendbare IP-Listen in deinen Kontoeinstellungen:
Erstelle eine IP-Liste namens "büro_ips" mit deinen Büro-IP-Bereichen
Referenziere sie in deinen Conditional Rule-Bedingungen
Vorteil: Aktualisiere die IP-Liste einmal, und alle Regeln, die sie verwenden, werden automatisch auf allen deinen Websites aktualisiert.
Eindeutigkeit
Jede Website kann nur eine Conditional Rule pro eindeutigem Ausdruck haben. Wenn du versuchst, ein Duplikat zu erstellen, siehst du: "Die Regel für diesen Ausdruck existiert bereits."
Dies verhindert doppelte Regeln und hält deine 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
Verwende stop=true oder fasse in eine Regel zusammen, wenn nötig❌ 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
Entferne stop=true, außer du musst die Auswertung wirklich beenden❌ Conditional Rules für einfache URLs verwenden
Bedingung: URI beginnt mit "/admin"
→ Sollte stattdessen Page Rule verwenden✅ Verwende Page Rules für reine URL-Logik
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 verwenden, Positionen anpassen oder Letzter-Treffer-gewinnt-Verhalten akzeptierenConditional Rules testen
Aktiviere Debug-Header in deiner Website-Konfiguration
Führe Testanfragen mit verschiedenen Bedingungen durch (IPs, User Agents usw.)
Prüfe die Response-Header um zu sehen, welche Conditional Rules zutrafen
Verifiziere, dass die Einstellungen in der erwarteten Reihenfolge angewendet werden
Teste überlappende Bedingungen um sicherzustellen, dass das Letzter-Treffer-gewinnt-Verhalten akzeptabel ist
Last updated
Was this helpful?