When you need traffic to stop and you do not care what the client sees beyond a refusal, rejectAction is the right tool. It is the cheapest way to put a wall in front of a hostname or path while keeping the rest of your capture session running.
rejectAction is the simplest blocking primitive in Fluxzy. It returns a plain HTTP 403 and never reaches the upstream server. Use it when you do not care about the response body and just want to make sure the traffic stops.
Typical fits:
If you need a custom status code or a body payload, pick rejectWithStatusCodeAction or rejectWithMessageAction instead.
Stops every request to the tracker hostname with a 403 so you can verify the rest of the application still works without telemetry.
rules:
- filter:
typeKind: HostFilter
pattern: tracker.example.com
actions:
- typeKind: RejectAction
Useful when teams should migrate to a new endpoint. Combine a host filter with a path filter so only the legacy route is denied.
rules:
- filter:
typeKind: FilterCollection
operation: And
children:
- typeKind: HostFilter
pattern: api.internal.example.com
- typeKind: PathFilter
pattern: ^/v1/legacy
actions:
- typeKind: RejectAction
Confirm an application still renders correctly without external CDN dependencies by returning 403 for every request to the CDN host.
rules:
- filter:
typeKind: HostFilter
pattern: cdn.example.com
actions:
- typeKind: RejectAction
Block the request and return HTTP 403 Forbidden response. Use this action to explicitly deny access to specific resources. This is a simple blocking action with no configuration required.
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
rejectAction
This action has no specific characteristic
The following examples apply this action to any exchanges
Block access to a specific domain.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: RejectAction
View definition of RejectAction for .NET integration.
The following actions are related to this action:
A standard HTTP 403 Forbidden response with no body. The client never reaches the upstream server, so no traffic leaves your machine for the blocked host.
abortAction terminates the connection abruptly, while rejectAction returns a clean HTTP 403. Reach for rejectAction when you want the client to see a structured response, abortAction when you want to simulate a network failure.
Not with this action. Use rejectWithMessageAction if you want a custom body, or mockedResponseAction for full control over headers and content.
No. Fluxzy short circuits the exchange right after parsing the client request, so nothing leaves the proxy.