How a Forward Proxy Treats a Custom API Header

An API can carry its version in a custom request field such as API-Version. An ordinary forwarding proxy should not discard that field merely because its name is unfamiliar. HTTP requires forwarding unrecognized fields unless a defined exception or configured policy applies.

The Connection field is one such exception. Compare these illustrative requests:

API-Version: 2026-10
Connection: keep-alive

Here the API field has not been designated as local to this connection. In the next example, the sender explicitly changes its scope:

API-Version: 2026-10
Connection: API-Version

A forwarding proxy removes fields named by Connection before forwarding and removes or replaces the connection-specific instructions themselves. An application header intended for the origin should therefore not appear in that token list.

Find the point where the field changes

Compare the client’s constructed request, the proxy’s received and forwarded fields, and what the origin received. A client can omit a header before the proxy sees it; a configured filter can deliberately remove it; a server can reject a request for exceeding a header limit.

Do not infer silent stripping solely from a header-size threshold reported in an old deployment. Limits and rejection behavior belong to the actual components and configuration. Keep the HTTP response and relevant logs with the observation.

For end-to-end HTTPS inside an ordinary CONNECT tunnel, the proxy cannot read and selectively remove the inner API field. Header inspection then belongs at the TLS endpoints or at an explicitly trusted inspection intermediary.