Use anonymix as a PII Redaction Proxy

Proxy mode sits anonymix between two systems: it redacts PII from the request body, then forwards the request on to an upstream you choose, keeping the method, headers and schema intact. The upstream's response is relayed back to the caller unmodified. Nothing in the calling application changes except its base URL and one header, which makes this the fastest way to strip PII from traffic bound for an LLM API, an outbound webhook, a log shipper, or any other third-party endpoint.

Enabling proxy mode

Set mode: "proxy" and whitelist the upstream origins requests may be forwarded to. mode is mutually exclusive with the default "rest" mode — a running instance is one or the other, and /v1/anonymize* is not available while in proxy mode.

mode: "proxy"

proxy:
  # Whitelist of upstream origins (scheme://host[:port]) callers may target via
  # the X-Anonymix-Target request header. "*" allows any origin., but is not recomended.
  allowed_destinations:
    - "https://backend.example.com"
  # Opt out of the default block on loopback/private/link-local destinations
  # (see Security notes below). Defaults to false -- only set this if the
  # deployment intentionally forwards to its own internal infrastructure.
  allow_private_destinations: false
  request_timeout_ms: 10000
  max_idle_conns: 100
  max_idle_conns_per_host: 20
  idle_conn_timeout_ms: 90000

The X-Anonymix-Target header

Every request must carry an X-Anonymix-Target header set to the full, absolute URL you want the (redacted) request forwarded to. Only that URL's origin is checked against proxy.allowed_destinations — its path and query are forwarded through as given.

curl -X POST https://your-instance.example.com/anything \
  -H "X-Anonymix-Target: https://backend.example.com/api/customers" \
  -H "Content-Type: application/json" \
  -d '{"email":"john@example.com","name":"Jane"}'

# backend.example.com/api/customers receives:
# {"email":"[REDACTED]","name":"[REDACTED]"}

The path you call on the anonymix instance itself doesn't matter — any method and path is accepted and forwarded, since only the target header decides where the request goes.

Security notes

Proxy mode is a whitelist-only forwarder: only http/https targets are accepted, and a request to a destination not listed in allowed_destinations is rejected with 403 before anything is forwarded.

On top of that hostname check, the outbound connection itself is blocked at dial time if it resolves to a loopback, private (RFC1918), link-local, or other non-public address — this is what stops a request from reaching 169.254.169.254 (cloud instance metadata) or internal-network services, even if the hostname was allowlisted or matched a wildcard. Set proxy.allow_private_destinations: true only if the deployment intentionally forwards to its own internal infrastructure.

Setting allowed_destinations: ["*"] turns the proxy into an open forwarder, gated only by whatever network boundary sits in front of the service — the server logs a warning at startup when it detects this. Non-public destinations are still blocked by default even under a wildcard entry, unless allow_private_destinations is set. Prefer listing exact origins.

Response headers

The relayed response still carries X-Anonymizer-Duration-Ms and X-Anonymizer-Fields-Redacted, so you get the same redaction observability in proxy mode as in the REST API, on top of whatever the upstream itself returned.