{"version":"2.1.318","anchor":"gateway-guidance-on-x-forwarded-for-and-trusted-proxies-rewo","canonical_anchor":"gateway-guidance-on-x-forwarded-for-and-trusted-proxies-rewo","heading":"Gateway warning now explains when to trust a load balancer","tier":"notice","area":"Elsewhere","scope":"org","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.318\/e\/gateway-guidance-on-x-forwarded-for-and-trusted-proxies-rewo","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.318","markdown":"### Gateway warning now explains when to trust a load balancer\n\nGateway warnings now say to list a load balancer in `listen.trusted_proxies` only if it adds the client address to X-Forwarded-For itself\n\n**What**\n\nThe self-hosted gateway's warning text changed. It used to tell you to add your load balancer's address range to `listen.trusted_proxies` with no caveat. It now says to list the load balancer there only if it adds the connecting address to the X-Forwarded-For header itself, and warns that otherwise clients can fake their address. The X-Forwarded-For header is where proxies record the original address of a request. Only the wording changed.\n\n**Why**\n\nFollowing the old advice with a load balancer that passes the header through unchanged would let clients pretend to come from any address, which matters for anything that relies on client addresses, such as rate limits.\n\n- Area: Elsewhere\n- Names: `listen.trusted_proxies`\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: org\n- Heads-up: no"}