New Fluxzy v2 just shipped. Electron is out, Tauri is in. gRPC ready, 3x smaller install. Learn more

impersonateAction Action

Make Fluxzy negotiate TLS, HTTP/2 settings, and headers exactly like a named browser version so anti bot defences see a real client.

Modern anti bot systems fingerprint the TLS handshake itself, not just the User-Agent string. impersonateAction is the fastest way to make Fluxzy look exactly like a real browser of a specific version, which is essential for testing protected sites, validating your own defences, or reproducing issues that only occur for one Chrome release.

When to use this action

Use impersonateAction when an upstream server inspects the TLS or HTTP/2 fingerprint of the connection and rejects anything that does not match a real browser. The action loads a profile (TLS ClientHello, HTTP/2 settings, default headers) and applies it for the matched exchanges.

Typical situations include:

  • Testing a website that fingerprints clients with JA3 or JA4 and blocks tooling.
  • Validating that your own anti bot rules behave correctly against a specific browser version.
  • Capturing exchanges that only succeed under a particular Chrome or Safari signature.
  • Reproducing a customer support issue tied to a specific browser release.

The nameOrConfigFile property accepts either a built in profile name (for example Chrome_Windows_131) or the path to a custom configuration file. The action runs on the requestHeaderReceivedFromClient scope.

Real world examples

Impersonate Chrome 131 on Windows

The most common profile for general browsing scenarios.

rules:
- filter:
    typeKind: HostFilter
    pattern: api.internal.example.com
  actions:
  - typeKind: ImpersonateAction
    nameOrConfigFile: Chrome_Windows_131

Use a custom impersonation file

When you need a fingerprint that is not in the built in catalog, point the action to a config file you maintain yourself.

rules:
- filter:
    typeKind: HostFilter
    pattern: payments.example.com
  actions:
  - typeKind: ImpersonateAction
    nameOrConfigFile: /etc/fluxzy/profiles/custom-chrome.yaml

Impersonate a browser only for HTML pages

Helpful when API endpoints accept your default fingerprint but the HTML site rejects it.

rules:
- filter:
    typeKind: FilterCollection
    operation: And
    children:
    - typeKind: HostFilter
      pattern: legacy.example.com
    - typeKind: HtmlResponseFilter
  actions:
  - typeKind: ImpersonateAction
    nameOrConfigFile: Firefox_Windows_120

Reference

impersonateAction

Description

Impersonate a browser or client by changing the TLS fingerprint, HTTP/2 settings and headers.

Evaluation scope

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

YAML configuration name

impersonateAction

Settings

The following table describes the customizable properties available for this action:

Property Type Description DefaultValue
nameOrConfigFile string

Example of usage

The following examples apply this action to any exchanges

Impersonate CHROME 131 on Windows.

rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: ImpersonateAction
    nameOrConfigFile: Chrome_Windows_131

.NET reference

View definition of ImpersonateAction for .NET integration.

See also

This action has no related action

Frequently asked questions

Where do I find the list of available profile names?

The Fluxzy CLI ships with a catalog of browser profiles. Run the CLI help or browse the documentation for the current names. New browser versions are added regularly.

Can I write my own impersonation profile?

Yes. Point nameOrConfigFile to a YAML or JSON file with the ClientHello details, HTTP/2 settings, and default headers you want. This is useful for niche or older browser versions.

Does impersonation also rewrite the User-Agent header?

Yes. The profile sets the default headers, including User-Agent, to match the impersonated browser. You can still override them with addRequestHeaderAction if needed.

Will the upstream certificate validation change?

No. The TLS handshake still uses Fluxzy's certificate store and validation rules. Only the ClientHello and ALPN negotiation are tuned to the profile.

Learn more about Fluxzy rules