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.
A browser needs cross-origin access, or a client needs custom response headers

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.
Select proxy — choose an enabled proxy from the shared catalog

First add or bulk-import proxies on the Proxies sidebar page, with one HTTP or SOCKS5 address per line; duplicate configurations are skipped. Then select them in global, group, or credential settings. A proxy can be referenced in multiple places, and changing its address affects all resources using it.

When a referenced proxy is disabled or deleted, that level inherits from its parent and may ultimately use a direct connection. Re-enabling the proxy automatically restores retained references. Tests only check the server’s access to the test URL through that proxy and do not automatically change its enabled state.

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.

Three cloud-channel exceptions

Azure OpenAI, AWS Bedrock, and Google Vertex AI currently do not support GPT-Load managed proxies. Use the support matrix for the exact status of other channels.

View the managed proxy support matrix →

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.

Upstream 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.

Response headers and CORS §

Configure downstream response-header rules under Settings → Browser access to set or remove custom headers returned to clients. Authentication, required protocol fields, and reserved gateway headers cannot be overridden; use the dedicated CORS settings for CORS headers.

CORS is disabled by default. For browser cross-origin requests, enable it and configure allowed origins, methods, and request headers. When allowing credentials, the allowed origin cannot be *.

Both settings apply only to the /v1 and /v1beta data plane, not the /api management API. Allowed preflight requests are handled automatically; actual requests still require AccessKey authentication.

See Runtime Settings for the configuration location.