agent-as-reverse-proxy example not updated for agent v3 + request host forwarding broken with agent v3

[DCurci]

Description

The agent-as-reverse-proxy example appears to be outdated and has not been updated for agent v3 (latest version is v3.1.0). Additionally, request host forwarding as reverse proxy does not work correctly with agent v3 at least with HTTP/1.x backend protocol (max_http_version: "h1").

What changed between v2 and v3

In agent v2, host preservation was controlled in agent.yaml configuration file via:

proxies.preserve_host = true | false

In v3, according to the documentation, the equivalent setting is:

reverse_proxy.forward.request_host = (string)

The docs state: "If not specified, it will use the request hostname" — implying host forwarding should work by default. However, in practice the request host is not being forwarded correctly when running the agent-as-reverse-proxy example with agent v3.

Steps to reproduce

1. Clone this forked repository: https://github.com/DCurci/docker-example
2. Run the agent-as-reverse-proxy example
3. Observe that the upstream receives the wrong Host header

The agent-as-reverse-proxy example has been modified for agent v3 providing a sample agent.yaml configuration file and a custom nginx.conf file to print the following received headers in the nginx logs:

• Host
• X-Forwarded-For
• X-Forwarded-Host
• X-Forwarded-Proto

When the agent-as-reverse-proxy example runs, in TRACE log level, a message like the following one is printed:

redirectionio-agent-1 | 2026-05-15T12:14:59.803301Z TRACE creating proxy service for peer: RedirectionIoHttpPeer { address: Host("nginx"), port: 80, tls: false, request_host: Some("nginx"), sni_host: Some("nginx"), identifier: "redirectionio-proxy/docker-reverse-proxy", allow_invalid_certificates: false, force_close: false, forward_header_strategy: Auto, request_timeout: Some(15s), response_timeout: Some(15s), body_size_limit: 16777216 }

where you can see: request_host: Some("nginx")

Observed behavior

1. When invoking the agent reverse proxy (port: 8080) with:

curl 'http://127.0.0.1:8080/' -H 'Host: localhost' -H 'X-Forwarded-Host: www.example.com' -H 'X-Forwarded-For: 127.0.0.1' -H 'X-Forwarded-Proto: http'

the request host is always set as specified in reverse_proxy.forward.address (i.e. nginx) and the nginx log is:

... "GET / HTTP/1.1" 200 1234 "referer: -" "user-agent: curl/8.20.0" "host: nginx" "x-forwarded-for: 127.0.0.1, 172.21.0.1" "x-forwarded-host: www.example.com" "x-forwarded-proto: http"

2. When invoking the nginx server directly (port: 80) with:

curl 'http://127.0.0.1:80/' -H 'Host: localhost' -H 'X-Forwarded-Host: www.example.com' -H 'X-Forwarded-For: 127.0.0.1' -H 'X-Forwarded-Proto: http'

the request host is correct (i.e. localhost) and the nginx log is:

... "GET / HTTP/1.1" 200 1234 "referer: -" "user-agent: curl/8.20.0" "host: localhost" "x-forwarded-for: 127.0.0.1" "x-forwarded-host: www.example.com" "x-forwarded-proto: http"

Expected behavior

The example should work with agent v3, and the request Host header should be forwarded to the upstream as documented. Otherwise agent v3 will not work with CDNs forwarding the request host header and an upstream server with several virtual hosts.

Environment

• Agent version: v3.1.0 (latest)
• Example: agent-as-reverse-proxy

[lyrixx]

Hello Daniele,

It looks like we forgot to update this repository when releasing Agent v3. Thanks for the report!

We'll take a look as soon as possible and keep you updated.

[joelwurtz]

Hey,

To be precise about this, it has currently the following behavior in v3 :

• If there is no request_host key and the adress contains an hostname : it will use this hostname as the host in the forwarded request
• If there is no request_host key and the address does not contains an hostname (i.e. it contains an ip : 127.0.0.1 by example) it will use the host from the request
• It there is a request_host key, it will use it as the hostname

If there is multiple hosts possibles for the same virtual host, and you use an hostname in the fordward address then you have to use multiple virtual host (one for each domain) actually to force the request host.

We are aware this is not an ideal solution and we are looking into readding the preserve_host option in the next version to make it work like before for this use case.

[DCurci]

Hi Grégoire, thanks for the feedback.

I'd also like you to look into the "Request host forwarding broken with agent v3" issue as soon as possible.
This issue is blocking the upgrade of our local proxy agents to version 3 for our paid subscriptions.

I had to open the issue here because it looks like you don't have a specific agent repository.

[DCurci]

Hey,

To be precise about this, it has currently the following behavior in v3 :

• If there is no request_host key and the adress contains an hostname : it will use this hostname as the host in the forwarded request
• If there is no request_host key and the address does not contains an hostname (i.e. it contains an ip : 127.0.0.1 by example) it will use the host from the request
• It there is a request_host key, it will use it as the hostname

If there is multiple hosts possibles for the same virtual host, and you use an hostname in the fordward address then you have to use multiple virtual host (one for each domain) actually to force the request host.

We are aware this is not an ideal solution and we are looking into readding the preserve_host option in the next version to make it work like before for this use case.

Hi Joel, we're currently in case #1: no request_host key and the address contains a hostname (e.g., localhost).

This is because proxy agents are sidecar containers of our main service containers.

A configuration with multiple virtual hosts for the agent would be excessively complex in terms of maintenance, so a preserve_host option in the global configuration, as in version 2, would be more suitable since we could have a single Docker image with a single configuration variable (preserve_host = true | false).

In the meantime, I'll see if we can get it to work with the address 127.0.0.1.