Tuning profiles
How OpenShield mitigation profiles work — baseline learning, spike thresholds, per-player token buckets, and the in-kernel Bloom whitelist.
Last updated
On this page
Profiles are tuned mitigation presets. You select one with the profile key in
/etc/openshield/openshield.yaml and the agent applies that preset's detection and
rate-limit behavior to your traffic.
Select a profile
List the presets installed on your server:
openshield profile list
Then set the one you want, for example:
profile: game-udp
Run openshield reload to apply the change.
How a profile decides to mitigate
Each profile is a set of parameters around the same core mechanisms:
- Baseline learning vs spike thresholds. The agent continuously learns your normal traffic baseline. When the current packets per second exceed baseline × the profile's spike factor, mitigation triggers; when traffic settles back, it stands down. A lower spike factor reacts sooner to smaller floods, a higher one tolerates burstier normal traffic.
- Per-player token buckets. Each source gets its own bucket, so one abusive player or client is rate-limited without affecting everyone else on the same port.
- In-kernel Bloom whitelist. Trusted IPs live in a Bloom filter inside the kernel XDP path, so known-good sources are passed at line rate without touching the mitigation pipeline.
When to tune and when to leave defaults
Tune when you can name the problem: legitimate traffic being dropped during peaks, or a flood pattern the current preset reacts to too slowly. Change one thing, reload, and watch the metrics tab before changing another.
For game and voice traffic specifics, see the OpenShield-XDP Game docs. For what the XDP drop path itself does, read How XDP filtering works.