Proxies and headers

This page covers non-standard cases: restricted networks, credential-specific egress routes, and upstream-required headers. Skip it if none apply.

When needed §

Common situations:

The server cannot reach some upstreams — route those requests through a proxy.
Different credentials use different egress routes — for example, route by region.
Upstream-required request headers — some relay services verify the source identifier.

If none of these cases apply, leave every setting on this page empty.

Outbound proxies §

There are three modes of proxy configuration:

Inherit — use the configuration from the previous level; this is the default.
Direct connection — explicitly bypass the proxy, even if the previous level has one configured.
Custom — specify a proxy address.

Direct connection does not mean inheritance

These two are easily confused. Inheritance is "Follow the superior". If the superior assigns a proxy, it will go through the proxy; Direct connection is "Explicitly do not go", which is used to make exceptions for individual credentials - for example, most upstreams require a proxy, but one of them cannot use the proxy on the intranet.

Four levels of override §

A proxy can be configured at four levels, The more specific, the higher the priority. The full precedence chain is: credential → Group → global → environment variables → direct.

Environment variables — HTTP_PROXY and HTTPS_PROXY, the process-level fallback egress. It applies only when none of the three levels above specify anything, and changes require a process restart
Global — the default egress configured in the management UI
Group — overrides the global setting for every credential in this Group.
Single credential — overrides the Group and applies only to this credential.

Environment variables are the last layer, not the first

Only when you pick Inheritance in the management UI does the lookup continue to the next level down; if every level inherits, it finally lands on environment variables such as HTTP_PROXY. So once a global proxy is configured in the management UI, environment variables stop applying. Conversely, if any level is set to Direct connection, environment variables do not apply either.
These three variables are documented in full on the Environment variables page.

The credential level is something many gateways do not have. Practical use: multiple accounts of the same provider belong to different regions and need to access from the corresponding region's exit, otherwise it will be considered a cross-region login.

Request header rules §

You can modify request headers sent to the upstream before forwarding; supported actions are Add and Delete. Configuration is split between global and Group levels.

Typical uses:

Add an upstream-required identification header — some relay services require a specific source marker.
Remove client-added interference headers — some clients send tracking headers that the upstream may reject.

Do not touch the authentication header

Authentication-related headers are managed by the gateway itself — it needs to dynamically fill them according to the selected credentials. Changing them using rules will cause the request to fail.

Usage options injection §

Some upstreams do not return token usage by default, so they require an explicit declaration in the request. When usage option injection is enabled, the gateway adds it automatically.

This affects the completeness of statistics and cost estimates — requests without usage data are counted as "missing usage" on the monitoring page, and no cost estimates are generated.

If you find that the cost estimate for a certain Group is significantly low, or the "missing usage" number is large, check this switch first, see Monitoring and Troubleshooting.

See Runtime Settings for the configuration location.