processNameFilter is the everyday way to scope Fluxzy rules to a specific local program. Because it works by name rather than PID it survives restarts, which makes it suitable for both ad hoc debugging and persistent capture profiles.
Use processNameFilter when you want a rule that follows a program even when its PID changes between runs. The filter accepts a list of names, so a single rule can cover a family of related tools or several variants of the same binary.
Typical situations:
curl, wget or httpie during a debugging session.chrome, firefox and msedge together.dotnet, node, python) without touching browser or system traffic.Process tracking must be enabled and the connection must originate from the local host. On Windows the .exe extension can be omitted. Matching is case insensitive on every platform.
Restrict capture to traffic produced by classic shell tools so you can replay or inspect it later without polluting the session with browser noise.
rules:
- filter:
typeKind: ProcessNameFilter
processNames:
- curl
- wget
- httpie
actions:
- typeKind: CaptureSessionAction
Apply a tag to any request initiated by a supported browser so you can pivot the timeline by client family.
rules:
- filter:
typeKind: ProcessNameFilter
processNames:
- chrome
- firefox
- msedge
- safari
actions:
- typeKind: ApplyTagAction
tag:
value: browser-traffic
Slow down node to simulate a constrained mobile network for a local development server, while leaving every other tool at full speed.
rules:
- filter:
typeKind: ProcessNameFilter
processNames:
- node
actions:
- typeKind: AverageThrottleAction
bandwidthBytesPerSeconds: 65536
Select exchanges initiated by processes with the specified names. Process names are matched case-insensitively. On Windows, the .exe extension can be omitted. 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
processNameFilter
The following table describes the customizable properties available for this filter:
| Property | Type | Description | DefaultValue |
|---|---|---|---|
| processNames | list1 | List of process names to match | system.Collections.Generic.List1[System.String] |
||
| inverted | boolean | Negate the filter result | false |
The following examples apply a comment to the filtered exchange
Filter traffic from curl process.
rules:
- filter:
typeKind: ProcessNameFilter
processNames:
- curl
actions:
- typeKind: ApplyCommentAction
comment: filter was applied
Filter traffic from curl or wget processes.
rules:
- filter:
typeKind: ProcessNameFilter
processNames:
- curl
- wget
actions:
- typeKind: ApplyCommentAction
comment: filter was applied
View definition of ProcessNameFilter for .NET integration.
This filter has no related filter
No. Process names are compared case insensitively on every platform, so 'Chrome', 'chrome' and 'CHROME' all match the same entry.
No, the suffix is optional. Both 'curl' and 'curl.exe' resolve to the same process on Windows.
The filter matches the actual executable name reported by the OS. If a shim forwards through another binary, target the binary that actually performs the network call.
Yes. Wrap several filters in a filterCollection to require both conditions, for example only requests from 'node' that target your internal API.