Proxy chaining is unavoidable in many enterprise environments. Routing some exchanges through a parent proxy while keeping the rest direct lets you debug applications inside the corporate perimeter without splitting your tool chain across two sessions.
Use upStreamProxyAction when Fluxzy itself must route certain exchanges through another HTTP proxy: a corporate gateway, a regional egress proxy, a privacy oriented intermediate, or a third party security solution. The action takes effect on the onAuthorityReceived scope, so you can target it by host or port even before any application data is exchanged.
Three common patterns:
The proxyAuthorizationHeader is sent verbatim, including the scheme. For Basic auth, encode user:password in base64 and prefix with Basic. Other schemes such as Bearer also work as long as the upstream proxy accepts them.
Match a corporate domain and route it through the company gateway. Other hosts continue to use the direct path.
rules:
- filter:
typeKind: HostFilter
pattern: '.*\.corp\.example\.com'
operation: Regex
actions:
- typeKind: UpStreamProxyAction
host: proxy.corp.example.com
port: 3128
Pre encode the credentials in base64 to feed the proxy authorization header. Avoid hard coding secrets, prefer an environment variable injection in CI.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: UpStreamProxyAction
host: 192.168.1.9
port: 8080
proxyAuthorizationHeader: Basic bGVlbG9vOm11bHRpcGFzcw==
Forward TLS traffic through the proxy without decrypting it locally, useful when the corporate proxy enforces its own inspection.
rules:
- filter:
typeKind: HostFilter
pattern: api.partner.example.com
actions:
- typeKind: SkipSslTunnelingAction
- typeKind: UpStreamProxyAction
host: egress.example.com
port: 8080
Use an upstream proxy.
Evaluation scope defines the timing where this filter will be applied.
onAuthorityReceived This scope denotes the moment fluxzy is aware the destination authority. In a regular proxy connection, it will occur the moment where fluxzy parsed the CONNECT request.
upStreamProxyAction
The following table describes the customizable properties available for this action:
| Property | Type | Description | DefaultValue |
|---|---|---|---|
| host | string | ||
| port | int32 | 0 | |
| proxyAuthorizationHeader | string |
The following examples apply this action to any exchanges
Use an upstream proxy to 192.168.1.9 on port 8080.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: UpStreamProxyAction
host: 192.168.1.9
port: 8080
Use an upstream proxy to 192.168.1.9 on port 8080 with basic auth login: leeloo , password: multipass.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: UpStreamProxyAction
host: 192.168.1.9
port: 8080
proxyAuthorizationHeader: Basic bGVlbG9vOm11bHRpcGFzcw==
View definition of UpStreamProxyAction for .NET integration.
This action has no related action
Yes, by default Fluxzy still acts as a man in the middle locally. Combine with skipSslTunnelingAction if you want the TLS to be end to end through the upstream proxy.
Whatever the upstream proxy accepts. Pass the full header value, including the scheme. Basic and Bearer are the most common, but NTLM single token responses are not handled because they need a challenge dance.
The exchange fails with a connection error, which appears in the Fluxzy timeline. Scope the rule tightly so unrelated traffic is not affected if the proxy is down.
Not natively. Fluxzy supports one upstream hop per exchange. If you need a longer chain, configure intermediate proxies independently.