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 beenden

  • Kö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 – 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

Kombiniere mehrere Bedingungen mit UND/ODER-Operatoren, 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 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ät

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

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

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

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, 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:

  1. Erstelle eine IP-Liste namens "büro_ips" mit deinen Büro-IP-Bereichen

  2. 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 akzeptieren

Conditional Rules testen

  1. Aktiviere Debug-Header in deiner Website-Konfiguration

  2. Führe Testanfragen mit verschiedenen Bedingungen durch (IPs, User Agents usw.)

  3. Prüfe die Response-Header um zu sehen, welche Conditional Rules zutrafen

  4. Verifiziere, dass die Einstellungen in der erwarteten Reihenfolge angewendet werden

  5. Teste überlappende Bedingungen um sicherzustellen, dass das Letzter-Treffer-gewinnt-Verhalten akzeptabel ist

Last updated

Was this helpful?