processIdFilter is the most precise way to scope a Fluxzy rule to one local program, but a PID is a short lived value. Use it for quick experiments, and reach for processNameFilter whenever you need a rule that keeps working across restarts or across multiple instances of the same binary.
Reach for processIdFilter when several applications are sharing the same machine and you only want to act on traffic from one specific instance. Because the filter matches a single PID, it is best used in short lived debugging sessions rather than long running automation.
Typical situations:
Process tracking must be enabled, and the connection must originate from the local host. If you need to match a tool by name, or to follow restarts where the PID changes, prefer processNameFilter.
Send every exchange initiated by PID 4242 to a separate fxzy capture so you can analyse it in isolation.
rules:
- filter:
typeKind: ProcessIdFilter
processId: 4242
actions:
- typeKind: CaptureSessionAction
Apply a tag to every request issued by a long running daemon so you can pivot on it later in the UI.
rules:
- filter:
typeKind: ProcessIdFilter
processId: 8123
actions:
- typeKind: ApplyTagAction
tag:
value: worker-daemon
Invert the filter to block any local exchange that is not produced by the explicitly allowed process, a quick way to enforce a per process allow list in a test sandbox.
rules:
- filter:
typeKind: ProcessIdFilter
processId: 1234
inverted: true
actions:
- typeKind: RejectAction
Select exchanges initiated by a process with the specified process ID. Process tracking must be enabled and the connection must originate from localhost.
Evaluation scope defines the timing where this filter will be applied.
requestHeaderReceivedFromClient This scope occurs the moment fluxzy parsed the request header receiveid from client
processIdFilter
The following table describes the customizable properties available for this filter:
| Property | Type | Description | DefaultValue |
|---|---|---|---|
| processId | int32 | The process ID to match | 0 |
| inverted | boolean | Negate the filter result | false |
The following examples apply a comment to the filtered exchange
Filter traffic from process with ID 1234.
rules:
- filter:
typeKind: ProcessIdFilter
processId: 1234
actions:
- typeKind: ApplyCommentAction
comment: filter was applied
View definition of ProcessIdFilter for .NET integration.
This filter has no related filter
processIdFilter only works for connections that originate on the same host as Fluxzy. Remote clients have no resolvable local PID, so the filter is skipped for them.
The match is purely numerical, so a recycled PID will be matched too. Use processNameFilter if the identity of the program matters more than the kernel handle.
Yes, on every platform where Fluxzy can enable process tracking. The OS specific lookup is performed once per connection.
Use the platform tools (Task Manager, Activity Monitor, ps, lsof) before the request, or read it back from the Fluxzy UI which reports the resolved PID on each exchange.