Manual Rules and Automated Policies

Proxyble has two protection models. Core only gives operators direct control over rules. Core plus RioDB adds analytics policies that can create temporary rules when live traffic matches a defined pattern.

Start with review

Before enforcing a change, inspect the current state and confirm the listener and backend are healthy:

sudo proxyble --config-status
sudo proxyble --rules-list

The current release is designed around manual rules and automated policy workflows, rather than a separate passive enforcement mode. A safe rollout means reviewing traffic and application behavior first, then using time-bounded rules or carefully selected policies.

Use manual rules for known cases

Manual rules are appropriate when you know the source, action, and desired duration: an emergency block, a known abusive IP, a controlled test, or a small deployment where operators make each decision.

For example, apply a temporary drop rule to the documentation-only address 203.0.113.25:

sudo proxyble --yes --rules-add \
  --rule DROP \
  --target 203.0.113.25 \
  --expiration 10m

Then check whether that address matches an active rule:

sudo proxyble --rules-check --ip 203.0.113.25

Use a short expiration for initial testing. CIDR targets apply to an address range; use them carefully, particularly for broad public ranges.

Use automated policies for behavior

Automated policies are appropriate when the risky signal appears over time instead of in one request: request floods, credential pressure, endpoint discovery, scraping, retry storms, or expensive endpoint pressure.

An automated policy reads HAProxy events in RioDB, creates a rule decision when its conditions are met, and sends the decision through the local queue to the rule agent. The rule agent validates and routes the action to HAProxy or nftables.

RioDB must be enabled before policy deployment. See Deploy Your First Automated Policy for the initial workflow.

Choose deliberately

• Start with manual rules when operator review is required for every action.
• Add automated policies when you need the system to respond to traffic patterns continuously.
• Use HTTP or terminating HTTPS when a policy needs request-path visibility; TCP pass-through cannot inspect HTTP requests.
• Treat global blocks and long-lived rules as high-impact changes. Test with bounded targets and expirations first.

Next step

See Proxyble Architecture for the component-level enforcement flow, or return to the documentation overview for the initial setup path.