< HTTP/1.1 463 Too Many Forwarded IP Addresses

TL;DR: An AWS Application Load Balancer returns 463 when the incoming X-Forwarded-For header lists more than 30 IP addresses. It’s a count limit, not a size limit, so raising header buffers won’t help. Count the entries, find the hop that keeps appending, and fix forwarding there.

What it means

463 isn’t a standard HTTP status; it’s specific to AWS. “Too Many Forwarded IP Addresses” describes the condition, and AWS documents it as HTTP 463. The ALB rejects any request whose incoming X-Forwarded-For carries more than 30 addresses.

Because the limit is on the number of addresses, the header’s length in bytes tells you little. If you’re tuning header sizes, you’re debugging a different problem: 431 Request Header Fields Too Large.

Confirm which hop rejected it

Search the ALB access logs for elb_status_code = 463. Check target_status_code too: a - means the log recorded no response from a connected target, which is what you’d expect when the ALB itself refused the request. Then use the timestamp and URL to find the same request at the proxy sitting just in front of the ALB.

At that trusted hop, capture the incoming X-Forwarded-For value. Count the comma-separated addresses and compare the value before and after each proxy to see where the list grows. Keep these client addresses out of public tickets.

Here’s a header fragment (an example, not a captured ALB request):

X-Forwarded-For: 192.0.2.10, 198.51.100.20, 203.0.113.30

That’s three entries. Count the failing request the same way; the number of proxies you meant to deploy and the number that actually touched the request are often different.

Fix the forwarding chain

Walk each proxy’s forwarding rule. The usual suspects are a value copied twice, a loop that sends traffic through the same proxy more than once, or an entry point that keeps whatever chain the client sent. Treat these as hypotheses and check each against the captured header; a 463 on its own doesn’t tell you which one you have.

At your public ingress, decide which upstream proxies you trust and build the forwarded chain from that policy. Inside the trusted path, pass the legitimate chain along without duplicating it. After you change a hop, retest through the whole path.

The ALB has its own header handling: routing.http.xff_header_processing.mode accepts append, preserve or remove, and defaults to append. That setting controls what the ALB forwards to your targets. AWS doesn’t describe it as a way around the 30-address limit on the incoming header, so fix the upstream chain rather than counting on a mode change.

Related

• X-Forwarded-For
• 431 Request Header Fields Too Large
• 400 Bad Request