Traffic Selection

After RayLimit knows which runtime you mean, it needs to know which traffic identity you want to shape.

Supported Limiter Families

Family	Subject form	What it means
`ip`	`--ip all` or `--ip <ip>`	direct client-IP shaping inside one runtime, either as a shared all-IP baseline, an evidence-expanded all-IP set, or one specific IP subject
`inbound`	`--inbound <tag>`	one runtime-local inbound listener path
`outbound`	`--outbound <tag>`	one runtime-local outbound egress path

The selected family determines both the logical subject and the backend evidence RayLimit must prove before execution.

Direction And Device Are Always Explicit

RayLimit plans one direction at a time:

--direction upload
--direction download

Every limit command also requires --device <device>. RayLimit never guesses which interface you mean.

If you want to shape both directions, run both commands explicitly:

sudo raylimit limit --pid 1234 --ip all --device eth0 --direction upload --rate 4096
sudo raylimit limit --pid 1234 --ip all --device eth0 --direction download --rate 4096

How The Families Differ

IP

The IP family supports four deliberate shapes:

--ip all --rate ... creates the default runtime-local shared baseline
--ip all --ip-aggregation per_ip --rate ... expands the current live client IP set into concrete specific-IP work
--ip <ip> --rate ... creates a specific override
--ip <ip> --unlimited creates a specific no-limit exception

--ip-aggregation applies only to --ip all. The specific IP path overrides the shared baseline when both match.

Inbound

Inbound uses one runtime-local tag and depends on readable configuration proving one concrete listener path.

Outbound

Outbound uses one runtime-local tag and depends on readable configuration proving one concrete non-zero socket-mark path.

Choosing The Right Family

Choose this family	When it fits best	When to avoid it
`ip`	visible client IP is the real control surface	the listener path or egress route is more meaningful than client identity
`inbound`	one listener path needs its own cap	the inbound config is unreadable, wildcard-only, or not one concrete TCP listener
`outbound`	one egress path needs its own cap	the outbound path depends on shared marks, chaining, or unreadable config

Concrete Versus Blocked

Traffic selection alone is not enough for live mutation. RayLimit must also prove that the current backend path is concrete:

shared --ip all and specific --ip <ip> are concrete through direct attachment
--ip all --ip-aggregation per_ip becomes concrete only after live Xray-backed client IP evidence expands into one or more usable specific-IP targets
inbound is concrete only when one readable concrete TCP listener can be derived
outbound is concrete only when one unique non-zero socket mark can be derived

For per_ip, unavailable or insufficient evidence blocks planning and refuses execution. no_sessions means there is no current concrete per-IP work for that runtime. When proof does not exist, RayLimit blocks instead of fabricating a weaker identity.

Runtime Targeting Overview