scriptos/adguard-shield
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 18 Wiki Activity

docs: Dokumentation umfassend überarbeitet

Browse Source
This commit is contained in:
Patrick Asmus
2026-05-01 01:17:05 +02:00
parent a7f7dbdb71
commit 7bbdb104c4
10 changed files with 1970 additions and 1167 deletions
Download Patch File Download Diff File Expand all files Collapse all files

369
docs/tipps-und-troubleshooting.md
View File

@@ -4,41 +4,55 @@ Dieses Dokument hilft beim Eingrenzen typischer Probleme im Betrieb. Die Reihenf
## Erste Diagnose
Diese Befehle liefern meistens schon genug Hinweise:
Diese fünf Befehle liefern meistens schon genug Hinweise, um ein Problem einzugrenzen:
```bash
# 1. Läuft der Service?
sudo systemctl status adguard-shield
# 2. Was sagt das Journal?
sudo journalctl -u adguard-shield --no-pager -n 100
# 3. Funktioniert die API?
sudo /opt/adguard-shield/adguard-shield test
# 4. Was ist der aktuelle Zustand?
sudo /opt/adguard-shield/adguard-shield status
# 5. Gibt es Warnungen oder Fehler?
sudo /opt/adguard-shield/adguard-shield logs --level warn --limit 100
```
Wenn du aktuelle Queries sehen willst:
Wenn du aktuelle Queries und den Echtzeit-Zustand sehen willst:
```bash
sudo /opt/adguard-shield/adguard-shield live
```
---
## Service startet nicht
Prüfen:
### Prüfen
```bash
sudo systemctl status adguard-shield
sudo journalctl -u adguard-shield --no-pager -n 100
```
Typische Ursachen:
### Typische Ursachen
- Konfigurationsdatei fehlt oder hat falsche Rechte
- Binary fehlt oder ist nicht ausführbar
- `iptables`, `ip6tables` oder `ipset` fehlen
- AdGuard-Home-API ist nicht erreichbar
- alte Shell-Artefakte verursachen Konflikte
- systemd-Unit wurde manuell geändert, aber `daemon-reload` fehlt
| Ursache | Lösung |
|---|---|
| Konfigurationsdatei fehlt | `/opt/adguard-shield/adguard-shield.conf` prüfen |
| Falsche Dateirechte | `sudo chmod 600 /opt/adguard-shield/adguard-shield.conf` |
| Binary fehlt oder nicht ausführbar | `ls -l /opt/adguard-shield/adguard-shield` prüfen |
| Systempakete fehlen | `which iptables ip6tables ipset systemctl` prüfen |
| API nicht erreichbar | Erst AdGuard Home starten |
| Alte Shell-Artefakte | Go-Installer meldet Konflikte, alte Version deinstallieren |
| Unit manuell geändert | `sudo systemctl daemon-reload` ausführen |
Nützliche Prüfungen:
### Nützliche Prüfbefehle
```bash
ls -l /opt/adguard-shield/adguard-shield
@@ -47,15 +61,17 @@ which iptables ip6tables ipset systemctl
sudo systemctl daemon-reload
```
---
## Verbindung zu AdGuard Home schlägt fehl
Test:
### Test
```bash
sudo /opt/adguard-shield/adguard-shield test
```
Prüfe in `/opt/adguard-shield/adguard-shield.conf`:
### Konfiguration prüfen
```bash
ADGUARD_URL="http://127.0.0.1:3000"
@@ -63,17 +79,17 @@ ADGUARD_USER="admin"
ADGUARD_PASS="..."
```
Häufige Fehler:
### Häufige Fehler und Lösungen
| Symptom | Mögliche Ursache |
|---|---|
| HTTP 401/403 | Benutzername oder Passwort falsch |
| HTTP 404 | falsche URL oder AdGuard Home nicht hinter dieser URL |
| Timeout | Firewall, DNS, falsche IP, Dienst nicht erreichbar |
| connection refused | AdGuard Home läuft nicht oder anderer Port |
| keine Querylog-Einträge | Querylog in AdGuard Home deaktiviert oder leer |
| Symptom | Mögliche Ursache | Lösung |
|---|---|---|
| HTTP 401/403 | Benutzername oder Passwort falsch | Zugangsdaten in der Konfiguration prüfen |
| HTTP 404 | Falsche URL oder falscher Port | URL und Port prüfen, AdGuard-Home-Weboberfläche testen |
| Timeout | Firewall, DNS-Problem oder falsche IP | Netzwerk und Erreichbarkeit prüfen |
| Connection refused | AdGuard Home läuft nicht oder anderer Port | `systemctl status AdGuardHome` prüfen |
| Keine Querylog-Einträge | Querylog deaktiviert oder leer | In AdGuard Home prüfen: Einstellungen > Querylog |
Direkt testen:
### Direkt testen (unabhängig von AdGuard Shield)
```bash
curl -k -u "admin:passwort" "http://127.0.0.1:3000/control/querylog?limit=1&response_status=all"
@@ -81,9 +97,11 @@ curl -k -u "admin:passwort" "http://127.0.0.1:3000/control/querylog?limit=1&resp
Passe URL und Zugangsdaten entsprechend an.
---
## Keine Sperren trotz vieler Anfragen
Prüfen:
### Prüfen
```bash
sudo /opt/adguard-shield/adguard-shield live --once
@@ -91,46 +109,53 @@ sudo /opt/adguard-shield/adguard-shield history 50
sudo /opt/adguard-shield/adguard-shield logs --level debug --limit 100
```
Mögliche Ursachen:
### Mögliche Ursachen und Lösungen
- `RATE_LIMIT_MAX_REQUESTS` ist zu hoch
- `RATE_LIMIT_WINDOW` ist zu kurz
- `API_QUERY_LIMIT` ist zu niedrig und verpasst Spitzen
- Client steht in `WHITELIST`
- externe Whitelist enthält die IP
- AdGuard Home sieht nicht die echte Client-IP, sondern nur einen Proxy/Forwarder
- Querylog enthält die Anfragen nicht
- `DRY_RUN=true` ist gesetzt
| Ursache | Lösung |
|---|---|
| `RATE_LIMIT_MAX_REQUESTS` zu hoch | Grenzwert senken oder `live` beobachten |
| `RATE_LIMIT_WINDOW` zu kurz | Zeitfenster verlängern |
| `API_QUERY_LIMIT` zu niedrig | Erhöhen, damit Spitzen nicht verpasst werden |
| Client steht in `WHITELIST` | Whitelist prüfen |
| Externe Whitelist enthält die IP | `whitelist-status` prüfen |
| Proxy/Forwarder maskiert echte Client-IPs | AdGuard Home sieht nur die Forwarder-IP; Forwarder whitelisten |
| Querylog enthält die Anfragen nicht | In AdGuard Home prüfen, ob Querylog aktiviert ist |
| `DRY_RUN=true` ist gesetzt | In der Konfiguration auf `false` setzen |
Wichtig bei Proxies und Forwardern: Wenn AdGuard Home nur eine einzige interne IP sieht, zählt AdGuard Shield auch nur diese IP. In solchen Setups muss die Architektur geprüft oder der Forwarder gewhitelistet werden.
**Wichtig bei Proxies und Forwardern:** Wenn AdGuard Home nur eine einzige interne IP sieht (z.B. die IP eines Routers oder Reverse Proxy), zählt AdGuard Shield auch nur diese IP. In solchen Setups muss die Architektur geprüft oder der Forwarder gewhitelistet werden.
---
## Zu viele Sperren
Erst Übersicht:
### Übersicht verschaffen
```bash
sudo /opt/adguard-shield/adguard-shield status
sudo /opt/adguard-shield/adguard-shield history 100
```
Dann Ursachen einordnen:
### Ursachen und Gegenmaßnahmen
| Ursache | Gegenmaßnahme |
|---|---|
| legitimer Client fragt häufig dieselbe Domain | Client whitelisten oder Limit erhöhen |
| Router/Resolver bündelt viele Clients | Router/Resolver whitelisten |
| Legitimer Client fragt häufig dieselbe Domain | Client whitelisten oder `RATE_LIMIT_MAX_REQUESTS` erhöhen |
| Router/Resolver bündelt viele Clients | Router/Resolver in `WHITELIST` aufnehmen |
| CDN/App erzeugt viele Subdomains | `SUBDOMAIN_FLOOD_MAX_UNIQUE` erhöhen |
| externe Blocklist ist sehr groß | `blocklist-status` prüfen und Benachrichtigungen deaktiviert lassen |
| GeoIP Allowlist zu eng | Länder prüfen oder `GEOIP_MODE` ändern |
| Externe Blocklist ist sehr groß | `blocklist-status` prüfen und ggf. Liste anpassen |
| GeoIP Allowlist zu eng | Länder prüfen oder `GEOIP_MODE` wechseln |
Falsch gesperrte IP freigeben:
### Falsch gesperrte IP freigeben
```bash
# Sperre aufheben
sudo /opt/adguard-shield/adguard-shield unban 192.168.1.100
# Offense-Zähler zurücksetzen (damit progressive Sperren nicht sofort eskalieren)
sudo /opt/adguard-shield/adguard-shield reset-offenses 192.168.1.100
```
Dauerhaft ausnehmen:
### Dauerhaft ausnehmen
```bash
WHITELIST="127.0.0.1,::1,192.168.1.1,192.168.1.100"
@@ -142,24 +167,35 @@ Danach:
sudo systemctl restart adguard-shield
```
---
## Firewall prüfen
Status:
### Status über AdGuard Shield
```bash
sudo /opt/adguard-shield/adguard-shield firewall-status
```
Direkt prüfen:
### Direkte Prüfung mit Systembefehlen
```bash
# ipsets anzeigen
sudo ipset list adguard_shield_v4
sudo ipset list adguard_shield_v6
# iptables-Regeln anzeigen
sudo iptables -n -L ADGUARD_SHIELD --line-numbers -v
sudo ip6tables -n -L ADGUARD_SHIELD --line-numbers -v
# Prüfen, ob Chain in INPUT eingehängt ist
sudo iptables -n -L INPUT --line-numbers -v | grep ADGUARD
# Bei Docker Bridge: DOCKER-USER prüfen
sudo iptables -n -L DOCKER-USER --line-numbers -v | grep ADGUARD
```
Firewall neu aufbauen:
### Firewall neu aufbauen
```bash
sudo /opt/adguard-shield/adguard-shield firewall-remove
@@ -169,40 +205,47 @@ sudo systemctl restart adguard-shield
Nach dem Neustart werden aktive Sperren aus SQLite wieder in die ipsets geschrieben.
---
## Sperren bleiben nach Ablauf aktiv
Prüfen:
### Prüfen
```bash
sudo /opt/adguard-shield/adguard-shield status
sudo /opt/adguard-shield/adguard-shield history 100
```
Temporäre Sperren werden beim Start und während des Pollings auf Ablauf geprüft. Wenn eine Sperre permanent ist, wird sie nicht automatisch freigegeben.
Temporäre Sperren werden beim Start und während jedes Pollings auf Ablauf geprüft. Wenn eine Sperre als permanent angezeigt wird, wird sie nicht automatisch freigegeben.
Permanent sind typischerweise:
### Permanente Sperren (gewollt)
- DNS-Flood-Watchlist-Treffer
- Progressive-Ban-Maximalstufe
- manuelle `ban`-Sperren
- GeoIP-Sperren
- externe Blocklist mit `EXTERNAL_BLOCKLIST_BAN_DURATION=0`
| Typ | Warum permanent |
|---|---|
| DNS-Flood-Watchlist-Treffer | Sofortiger Permanent-Ban |
| Progressive-Ban auf Maximalstufe | Eskalation durch wiederholte Verstöße |
| Manuelle `ban`-Sperren | Manuell gesetzt, manuell aufheben |
| GeoIP-Sperren | Permanent bis Konfigurationsänderung |
| Externe Blocklist mit `BAN_DURATION=0` | Permanent bis IP aus Liste entfernt |
Manuell freigeben:
### Manuell freigeben
```bash
sudo /opt/adguard-shield/adguard-shield unban 192.168.1.100
```
---
## Dry-Run verwenden
Dry-Run ist ideal für neue Regeln:
Dry-Run ist ideal, um neue Konfigurationen zu prüfen, bevor sie produktiv gehen:
```bash
# Dry-Run starten (Strg+C zum Beenden)
sudo /opt/adguard-shield/adguard-shield dry-run
```
Währenddessen:
Währenddessen die Ergebnisse prüfen:
```bash
sudo /opt/adguard-shield/adguard-shield history 50
@@ -210,215 +253,291 @@ sudo /opt/adguard-shield/adguard-shield history 50
Im Dry-Run werden mögliche Sperren als `DRY` protokolliert. Es entstehen keine aktiven Sperren und keine Firewall-Änderungen.
---
## Externe Whitelist
Status:
### Status prüfen
```bash
sudo /opt/adguard-shield/adguard-shield whitelist-status
```
Manuell synchronisieren:
### Manuell synchronisieren
```bash
sudo /opt/adguard-shield/adguard-shield whitelist-sync
```
Typische Probleme:
### Typische Probleme
- URL nicht erreichbar
- Datei enthält Windows-Zeilenenden oder BOM
- Hostname ist nicht auflösbar
- Einträge enthalten Ports oder URLs statt IP/Hostname
- DNS-Auflösung liefert `0.0.0.0`, weil AdGuard den Host blockiert
| Problem | Lösung |
|---|---|
| URL nicht erreichbar | URL im Browser oder mit `curl` testen |
| Windows-Zeilenenden oder BOM | Datei in UTF-8 ohne BOM und mit `LF`-Zeilenenden speichern |
| Hostname nicht auflösbar | DNS-Auflösung prüfen, ggf. alternativen Hostnamen verwenden |
| Einträge enthalten Ports oder URLs | Nur IPs, CIDR-Netze und Hostnamen werden unterstützt |
| DNS liefert `0.0.0.0` | AdGuard blockiert den Host; Ausnahme in AdGuard Home einrichten |
Format prüfen:
### Erwartetes Listenformat
```text
192.168.1.100
10.0.0.0/24
trusted.example.com
192.168.1.100 # IPv4-Adresse
10.0.0.0/24 # CIDR-Netz
trusted.example.com # Hostname (wird per DNS aufgelöst)
# Kommentare sind erlaubt
```
---
## Externe Blocklist
Status:
### Status prüfen
```bash
sudo /opt/adguard-shield/adguard-shield blocklist-status
```
Manuell synchronisieren:
### Manuell synchronisieren
```bash
sudo /opt/adguard-shield/adguard-shield blocklist-sync
```
Alle externen Blocklist-Sperren freigeben:
### Alle Blocklist-Sperren freigeben
```bash
sudo /opt/adguard-shield/adguard-shield blocklist-flush
```
Wenn zu viele IPs gesperrt werden:
### Zu viele IPs gesperrt?
1. `EXTERNAL_BLOCKLIST_URLS` prüfen.
2. Liste manuell ansehen.
3. Whitelist für eigene IPs ergänzen.
4. `EXTERNAL_BLOCKLIST_NOTIFY=false` lassen.
5. Bei Bedarf `EXTERNAL_BLOCKLIST_AUTO_UNBAN=true` setzen.
1. `EXTERNAL_BLOCKLIST_URLS` prüfen: Welche Listen sind konfiguriert?
2. Liste manuell ansehen: Wie viele Einträge enthält sie?
3. Whitelist ergänzen: Eigene IPs sollten dort stehen.
4. `EXTERNAL_BLOCKLIST_NOTIFY=false` belassen, um den Benachrichtigungskanal nicht zu überfluten.
5. `EXTERNAL_BLOCKLIST_AUTO_UNBAN=true` setzen, damit entfernte Einträge automatisch freigegeben werden.
---
## GeoIP
Status:
### Status prüfen
```bash
sudo /opt/adguard-shield/adguard-shield geoip-status
```
Einzelne IP prüfen:
### Einzelne IP prüfen
```bash
sudo /opt/adguard-shield/adguard-shield geoip-lookup 8.8.8.8
```
Cache leeren:
### Cache leeren
```bash
sudo /opt/adguard-shield/adguard-shield geoip-flush-cache
```
Alle GeoIP-Sperren freigeben:
### Alle GeoIP-Sperren freigeben
```bash
sudo /opt/adguard-shield/adguard-shield geoip-flush
```
Typische Ursachen:
### Typische Probleme und Lösungen
| Problem | Lösung |
|---|---|
| keine Länder erkannt | MaxMind-Key, MMDB-Pfad oder `geoiplookup` prüfen |
| private IPs werden nicht geprüft | `GEOIP_SKIP_PRIVATE=true` ist aktiv, das ist Standard |
| zu viele Länder gesperrt | `GEOIP_MODE` und `GEOIP_COUNTRIES` prüfen |
| Allowlist sperrt fast alles | im Allowlist-Modus sind nur genannte Länder erlaubt |
| Keine Länder erkannt | MaxMind-Key, MMDB-Pfad oder `geoiplookup`-Befehl prüfen |
| Private IPs werden nicht geprüft | `GEOIP_SKIP_PRIVATE=true` ist Standard und korrekt |
| Zu viele Länder gesperrt | `GEOIP_MODE` und `GEOIP_COUNTRIES` prüfen |
| Allowlist sperrt fast alles | Im Allowlist-Modus sind nur genannte Länder erlaubt; alle anderen werden gesperrt |
| Datenbank nicht gefunden | `GEOIP_LICENSE_KEY` oder `GEOIP_MMDB_PATH` setzen |
| Datenbank veraltet | `geoip-flush-cache` und Service neu starten |
### Ländercodes nachschlagen
Die GeoIP-Ländercodes folgen dem Standard ISO 3166-1 Alpha-2. Eine vollständige Liste findest du in der [ISO-3166-1-Kodierliste auf Wikipedia](https://de.wikipedia.org/wiki/ISO-3166-1-Kodierliste).
---
## Reports
Status:
### Status prüfen
```bash
sudo /opt/adguard-shield/adguard-shield report-status
```
Test:
### Funktionstest
```bash
# Testmail senden
sudo /opt/adguard-shield/adguard-shield report-test
# Text-Report in der Konsole ansehen
sudo /opt/adguard-shield/adguard-shield report-generate txt
```
Wenn keine Mail ankommt:
### Keine Mail kommt an?
- `REPORT_EMAIL_TO` gesetzt?
- `REPORT_MAIL_CMD` vorhanden?
- Mailer für root konfiguriert?
- Cron installiert?
- Spam-Ordner geprüft?
| Prüfpunkt | Befehl / Aktion |
|---|---|
| `REPORT_EMAIL_TO` gesetzt? | Konfiguration prüfen |
| `REPORT_MAIL_CMD` vorhanden? | `which msmtp` |
| Mailer für root konfiguriert? | `/root/.msmtprc` oder `/etc/msmtprc` prüfen |
| Cron installiert? | `sudo cat /etc/cron.d/adguard-shield-report` |
| Spam-Ordner geprüft? | E-Mail-Provider prüfen |
| SMTP-Port offen? | Ausgehende Verbindung auf Port 587/465 testen |
Cron prüfen:
### Cron prüfen
```bash
sudo cat /etc/cron.d/adguard-shield-report
sudo /opt/adguard-shield/adguard-shield report-send
```
---
## Benachrichtigungen
Prüfen:
### Prüfen
```bash
sudo /opt/adguard-shield/adguard-shield logs --level warn --limit 100
```
Häufige Ursachen:
### Checkliste
- `NOTIFY_ENABLED=false`
- falscher `NOTIFY_TYPE`
- Webhook-URL leer
- Ntfy-Topic leer
- Token ungültig
- ausgehende HTTPS-Verbindung blockiert
- externe Blocklist meldet nichts, weil `EXTERNAL_BLOCKLIST_NOTIFY=false`
- GeoIP meldet nichts, weil `GEOIP_NOTIFY=false`
| Prüfpunkt | Beschreibung |
|---|---|
| `NOTIFY_ENABLED=true` | Benachrichtigungen global aktiviert? |
| `NOTIFY_TYPE` | Korrekt geschrieben? (`ntfy`, `discord`, `slack`, `gotify`, `generic`) |
| Webhook-URL | Gesetzt und erreichbar? |
| Ntfy-Topic | Nicht leer? |
| Token | Gültig und nicht abgelaufen? |
| Netzwerk | Ausgehende HTTPS-Verbindungen möglich? |
| Modul-Schalter | `EXTERNAL_BLOCKLIST_NOTIFY` und `GEOIP_NOTIFY` separat prüfen |
Bei `generic` Webhook kannst du testweise einen lokalen HTTP-Empfänger oder einen Request-Inspector (z.B. webhook.site) verwenden, um den gesendeten Payload zu sehen.
---
## SQLite direkt auswerten
Für tiefergehende Analysen:
Für tiefergehende Analysen kannst du die SQLite-Datenbank direkt abfragen:
### Sperren nach Quelle und Grund
```bash
sudo sqlite3 /var/lib/adguard-shield/adguard-shield.db \
"select source, reason, count(*) from active_bans group by source, reason order by count(*) desc;"
"SELECT source, reason, count(*) FROM active_bans GROUP BY source, reason ORDER BY count(*) DESC;"
```
Letzte History:
### Letzte History-Einträge
```bash
sudo sqlite3 /var/lib/adguard-shield/adguard-shield.db \
"select timestamp_text, action, client_ip, domain, reason from ban_history order by id desc limit 20;"
"SELECT timestamp_text, action, client_ip, domain, reason FROM ban_history ORDER BY id DESC LIMIT 20;"
```
Offense-Zähler:
### Offense-Zähler
```bash
sudo sqlite3 /var/lib/adguard-shield/adguard-shield.db \
"select client_ip, offense_level, last_offense from offense_tracking order by offense_level desc;"
"SELECT client_ip, offense_level, last_offense FROM offense_tracking ORDER BY offense_level DESC;"
```
### Whitelist-Cache
```bash
sudo sqlite3 /var/lib/adguard-shield/adguard-shield.db \
"SELECT ip, source FROM whitelist_cache ORDER BY ip;"
```
### GeoIP-Cache
```bash
sudo sqlite3 /var/lib/adguard-shield/adguard-shield.db \
"SELECT ip, country_code FROM geoip_cache ORDER BY ip LIMIT 50;"
```
---
## Alte Shell-Artefakte entfernen
Wenn der Installer alte Dateien meldet, zuerst sauber migrieren. Typische alte Dateien:
```text
adguard-shield.sh
iptables-helper.sh
external-blocklist-worker.sh
external-whitelist-worker.sh
geoip-worker.sh
offense-cleanup-worker.sh
report-generator.sh
unban-expired.sh
adguard-shield-watchdog.sh
```
| Datei | Funktion in der alten Version |
|---|---|
| `adguard-shield.sh` | Hauptskript |
| `iptables-helper.sh` | Firewall-Management |
| `external-blocklist-worker.sh` | Blocklist-Synchronisation |
| `external-whitelist-worker.sh` | Whitelist-Synchronisation |
| `geoip-worker.sh` | GeoIP-Prüfung |
| `offense-cleanup-worker.sh` | Offense-Bereinigung |
| `report-generator.sh` | Report-Erstellung |
| `unban-expired.sh` | Ablauf temporärer Sperren |
| `adguard-shield-watchdog.sh` | Watchdog-Skript |
Die Go-Version ersetzt diese Funktionen durch das eine Binary. Alte Worker sollten nicht parallel laufen.
Details zur Migration stehen in der [Update-Anleitung](update.md).
---
## Service hart zurücksetzen
Wenn der Zustand unklar ist:
Wenn der Zustand unklar ist und ein sauberer Neustart nötig ist:
```bash
# Service stoppen
sudo systemctl stop adguard-shield
# Firewall-Struktur entfernen
sudo /opt/adguard-shield/adguard-shield firewall-remove
# Service neu starten (baut Firewall aus SQLite wieder auf)
sudo systemctl start adguard-shield
# Status prüfen
sudo /opt/adguard-shield/adguard-shield status
```
Das entfernt die Firewall-Struktur und lässt den Daemon sie beim Start wieder aus SQLite aufbauen.
Das entfernt die Firewall-Struktur und lässt den Daemon sie beim Start wieder aus dem SQLite-State aufbauen. Aktive Sperren bleiben in der Datenbank erhalten.
---
## Deinstallation
Konfiguration behalten:
### Konfiguration behalten
```bash
sudo /opt/adguard-shield/adguard-shield uninstall --keep-config
```
Alles entfernen:
### Alles entfernen
```bash
sudo /opt/adguard-shield/adguard-shield uninstall
```
Ohne `--keep-config` werden Installationsverzeichnis, State-Verzeichnis und Logdatei entfernt.
---
## Zusammenfassung: Wichtigste Diagnosebefehle
| Befehl | Zweck |
|---|---|
| `systemctl status adguard-shield` | Service-Status prüfen |
| `journalctl -u adguard-shield -n 100` | Systemd-Journal ansehen |
| `test` | API-Verbindung prüfen |
| `status` | Aktuellen Zustand und aktive Sperren anzeigen |
| `live` | Echtzeit-Ansicht mit Queries, Sperren und Logs |
| `history 100` | Ban-History anzeigen |
| `logs --level warn --limit 100` | Warnungen und Fehler anzeigen |
| `firewall-status` | Firewall-Regeln und ipsets anzeigen |
| `dry-run` | Konfiguration testen ohne echte Sperren |