Forwarded vs X-Forwarded-For (tested)

Forwarded (RFC 7239, 2014) is the standard header for passing the original client address, scheme and host through a proxy. X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host are the older, non-standard headers that do the same job. We sent both kinds to Express 5.2.1 and Werkzeug 3.1.9. Neither framework read Forwarded at all, so in practice your proxy still has to send the X-Forwarded-* headers.

1. The two formats side by side

The same request, after one proxy, written both ways (syntax from RFC 7239, not measured):

X-Forwarded-For: 203.0.113.7
X-Forwarded-Proto: https
X-Forwarded-Host: shop.example.com

Forwarded: for=203.0.113.7;proto=https;host=shop.example.com

Rules from RFC 7239 (not measured):

• Parameters inside one element are separated by ;. Each proxy adds an element; elements are separated by ,, so a two-proxy chain looks like Forwarded: for=203.0.113.7;proto=https, for=198.51.100.2.
• An IPv6 address must be in brackets and quotes, because : and [ are not allowed in an unquoted value: for="[2001:db8::1]:4711". An IPv4 address with a port needs quotes too: for="203.0.113.7:4711".
• A proxy that does not want to reveal an address can send for=unknown or an obfuscated identifier starting with _, for example for=_hidden.
• The main advantage is that one header carries all the values per hop, so the IP and the scheme of the same hop stay together. With X-Forwarded-* they are three separate lists that may not line up.

2. Express 5.2.1 ignores Forwarded

A route that returned req.ip, req.ips, req.protocol and req.hostname. The connection always came from 127.0.0.1. With app.set('trust proxy', true):

The Forwarded header changed nothing under any trust proxy setting we tried (false, true, 1, 2, 'loopback'). The source agrees: the forwarded 0.2.0 package that Express uses parses only req.headers['x-forwarded-for'], and req.protocol / req.host read only X-Forwarded-Proto / X-Forwarded-Host. If your proxy sends only Forwarded, Express sees the proxy's IP and plain http.

3. Werkzeug / Flask ProxyFix ignores it too

Werkzeug 3.1.9 with ProxyFix(app, x_for=1, x_proto=1, x_host=1):

The string Forwarded (as a header name) does not appear anywhere in the installed Werkzeug package. Two more things we measured:

• ProxyFix(app) with no arguments defaults to x_for=1, x_proto=1, so it already applied X-Forwarded-Proto: https. X-Forwarded-Host is off until you set x_host=1.
• Without ProxyFix, request.remote_addr stayed 127.0.0.1, but request.access_route returned the raw client-sent list, for example ["1.2.3.4", "203.0.113.7", "198.51.100.2"]. Do not use access_route[0] as the client IP.

4. The spoofing problem: trust proxy true

A proxy that appends (nginx's $proxy_add_x_forwarded_for, for example) keeps whatever the client sent and adds the real address on the right. So a client that sends X-Forwarded-For: 6.6.6.6 through one proxy produces X-Forwarded-For: 6.6.6.6, 198.51.100.2. We sent that header to Express:

true trusts every hop and takes the leftmost entry, which the client controls. Rate limits, IP allowlists and logs keyed on req.ip can then be bypassed with one header. Use the number of proxies you actually run (1 for a single nginx or load balancer) or the proxy's address or subnet.

A 3-entry chain 1.2.3.4, 203.0.113.7, 198.51.100.2 gave req.ip = 1.2.3.4 with true, 198.51.100.2 with 1, and 203.0.113.7 with 2. Werkzeug's x_for=1 and x_for=2 gave the same results as Express 1 and 2. With x_for=2 and only one entry in the header, Werkzeug ignored the header and kept 127.0.0.1; Express 2 used the single entry.

Neither framework validated the value. X-Forwarded-For: not-an-ip became req.ip = "not-an-ip" in Express (true and 1) and remote_addr = "not-an-ip" with ProxyFix x_for=1. If you store the IP in a database column of type inet, validate it first.

5. Proto and Host lists: Express and Werkzeug disagree

We sent X-Forwarded-Proto: https, http and X-Forwarded-Host: a.example.com, b.example.com:

Express applies the hop count only to X-Forwarded-For. For Proto and Host it checks that the direct peer is trusted and then takes the first, client-controlled value. So even with trust proxy 1, your proxy must overwrite X-Forwarded-Proto and X-Forwarded-Host, not append to them. See X-Forwarded-Proto in nginx and Host header injection.

6. What to configure

For a single nginx in front of Express or Flask (nginx config from the nginx docs, not measured here):

proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host  $host;

// Express
app.set('trust proxy', 1);

# Flask / Werkzeug
from werkzeug.middleware.proxy_fix import ProxyFix
app.wsgi_app = ProxyFix(app.wsgi_app, x_for=1, x_proto=1, x_host=1)

$proxy_add_x_forwarded_for appends to the client's value, which is fine when the app trusts exactly one hop. $scheme and $host replace whatever the client sent. More detail, including set_real_ip_from and real_ip_header: X-Forwarded-For and the real client IP in nginx.

If you also want the standard header, nginx has no built-in Forwarded variable; you build it with proxy_set_header Forwarded "for=$remote_addr;proto=$scheme;host=$host"; (from docs, not measured). That simple version breaks the RFC for IPv6 clients, which need for="[...]", and it drops earlier hops. Only send it if something downstream actually reads it, and keep the X-Forwarded-* headers alongside it for Express and Werkzeug.

7. Checklist

1. Find out which header your framework reads. In our tests Express and Werkzeug read only X-Forwarded-*.
2. Set the trust to the number of proxies you run, never true on a server the internet can reach directly.
3. Make the proxy overwrite Proto and Host, and append (or overwrite) For.
4. Test it: send X-Forwarded-For: 6.6.6.6 yourself and check that your logs still show your real IP.

Written with AI assistance. Measured on 2026-10-02 with Node.js 24.21.0 and Express 5.2.1 (proxy-addr 2.0.8, forwarded 0.2.0) on localhost:8983, curl 8.14.1 as the client, and Werkzeug 3.1.9 ProxyFix on Python 3.13.5 (Werkzeug's in-process test client with REMOTE_ADDR 127.0.0.1, no socket). The RFC 7239 syntax and the nginx config are from the RFC and the nginx docs, not measured; nginx is not installed on the test box. PlainHeaders is our extension; Node.js, Express, Werkzeug and curl are free.