Is 463 my application's fault or an AWS outage?

Neither. 463 is generated by the Application Load Balancer itself, before your target ever sees the request — so it's not your app returning it, and it's not the ALB being down (a healthy ALB emits 463 on purpose). The trigger is a single header: the X-Forwarded-For that arrived at the ALB already contained more than 30 IP addresses. Your target is fine, the ALB is fine; the request is being rejected for the shape of its XFF header. That also means the same URL works from one client and fails from another depending on how many proxies each request crossed.

Can I raise the 30-IP limit on the load balancer?

No. 30 is a hard limit on the Application Load Balancer and no attribute changes it. The routing.http.xff_header_processing.mode attribute lets you control how the ALB handles the header toward your target — append (the default, add the client IP), preserve (pass it through unchanged), or remove (strip it) — but none of those lifts the 30-address ceiling on what the ALB will accept inbound. The real fix is upstream: stop more than 30 IPs from reaching the ALB in the first place, by trimming or resetting X-Forwarded-For at your outermost proxy or CDN.

How is 463 different from 460 and 464?

They're three different ALB-generated codes for three different failures. 463 is the X-Forwarded-For header carrying more than 30 IP addresses — a malformed-request rejection. 460 means the client closed the connection before the load balancer's idle timeout elapsed, while the LB was still waiting (the client gave up, not the server). 464 means incompatible protocol versions between the client and the target group — commonly an HTTP/1.1 request routed to an HTTP/2-or-gRPC target, or the reverse. If you're seeing 502/503/504 instead, that's the target or its health, not the ALB rejecting a request outright.

Views: 5

HTTP 463 (AWS ALB): Too Many Forwarded IP Addresses

HTTP 463: an AWS ALB got an X-Forwarded-For header with 30+ IPs and refused the request. Trace the proxy chain in 3 steps. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your request through an AWS Application Load Balancer comes back 463, and nothing in your application logs shows the request arriving. That’s the tell: the ALB rejected it before your target group ever saw it. 463 isn’t your code, and it isn’t an outage — it’s the load balancer refusing a request because its X-Forwarded-For header arrived carrying more than 30 IP addresses. The ALB treats an XFF list that long as a malformed request and stops it at the edge. So the question isn’t “what’s wrong with my server” — the server never got the request. The question is why the forwarded-for chain reaching the ALB is 30-plus addresses deep.

Symptoms

The client gets HTTP 463; your target’s access logs have no matching entry, because the request never reached the target.
It’s inconsistent across clients: the same endpoint works from one network and returns 463 from another, depending on how many proxies each request traversed.
It shows up after you add a hop in front of the ALB — a new CDN, WAF, or reverse proxy — or after a routing change that sends traffic through your own stack twice.
A plain request straight to the ALB works; the failure only appears on requests that already carry a long X-Forwarded-For header when they arrive.

What This Error Actually Means

463 is one of the status codes the Application Load Balancer generates on its own, alongside 460 (the client closed the connection before the idle timeout elapsed) and 464 (incompatible protocol versions between client and target). AWS’s definition of 463 is narrow: the load balancer received an X-Forwarded-For request header with more than 30 IP addresses, which it treats as similar to a malformed request.

Here’s the mechanism. X-Forwarded-For is a client-supplied, append-only header: each proxy that handles a request adds the address it received the connection from, and by default the ALB appends the immediate client’s IP to whatever was already there. The 30-address cap is on what the ALB receives. If the header shows up already listing more than 30 IPs — because the request crossed a long proxy chain, looped through your infrastructure twice, or was hand-crafted by the client — the ALB rejects it with 463 instead of forwarding it. Thirty is a hard limit; it is not tunable. And because anyone can put whatever they want in X-Forwarded-For before it reaches you, 463 is sometimes the first sign that a client is padding the header deliberately.

Top 3 Causes

A genuinely long proxy chain in front of the ALB - CDN → WAF → reverse proxy → ALB, each appending an address, and the original client already sent an X-Forwarded-For. Deep, legitimate chains — especially multi-CDN setups or service meshes that re-proxy — can accumulate past 30 addresses on their own. Nothing is “attacking” you; the topology simply forwards too many hops.
A request looping through your own stack twice - A routing mistake sends traffic through the same ingress path more than once — an ALB in front of a proxy that points back through another ALB, or a redirect that re-enters the same edge. Each pass roughly doubles the appended addresses, and a chain that was comfortably under 30 crosses the line.
A client padding X-Forwarded-For on purpose - X-Forwarded-For is untrusted client input. A scraper, a scanner, or someone probing how your stack handles the header can send a request that already lists 30-plus IPs, tripping 463 immediately. It’s harmless to the ALB, but if you trust XFF for logging, rate-limiting, or access rules, a padded header is worth noticing — it means someone is testing that surface.

Diagnose with DechoNet

HTTP Check sends a clean request to your endpoint from outside your network — with a normal, short X-Forwarded-For — and shows you the status and headers that come back. If DechoNet gets a healthy 200 where your own client gets 463, that isolates the problem cleanly: the ALB and target are fine, and the 463 is entirely about the bloated XFF header your request path is adding. It rules out “the server is down” in one shot.
IP Check shows you the actual public IP your traffic exits from, so you can compare it against the addresses piling up in the forwarded-for chain and work out which hop is appending what — useful when you’re not sure whether the extra addresses are your own proxies or the client’s.

Resolution Checklist

Reproduce it and count the addresses. Send a request with a deliberately long header — curl -H "X-Forwarded-For: 1.1.1.1, 2.2.2.2, ...(31 entries)" https://YOUR_ALB/ — and confirm you get 463. Then inspect a real failing request’s XFF to see how many IPs it actually carries and where they come from.
Sanitize X-Forwarded-For at the outermost hop. At your CDN or front proxy (Cloudflare, Akamai, an edge nginx), strip or reset the incoming header before appending your own, so the chain that reaches the ALB starts clean. This is the fix AWS itself recommends, and it’s the only one that addresses the 30-address ceiling.
Set the ALB’s XFF handling deliberately. Use routing.http.xff_header_processing.mode — append, preserve, or remove — to match how your target consumes the header. It won’t raise the limit, but choosing remove (when your target doesn’t need XFF) or preserve (when a trusted upstream already set it correctly) keeps the header from growing further at the ALB.
Find and break any loop. Trace the request path for a hop that points back into your own ingress. A request that transits the same edge twice is the most common way a normal chain silently doubles past 30.
Stop trusting raw XFF for security decisions. If rate-limiting or allow/deny rules read X-Forwarded-For directly, use only the addresses your own trusted proxies appended (count from the right), not the whole client-supplied list — otherwise a padded header both trips 463 and poisons your logic.

When to Escalate

If DechoNet’s clean request also returns 463, the ALB is adding the excess itself or a trusted upstream is misconfigured to inject a long XFF for every request — that’s an infrastructure config problem to raise with whoever owns the edge, not a per-client anomaly.
If 463 tracks with a specific source flooding padded headers, treat it as an abuse-surface question, not just a config fix: the request shape is deliberate, and the durable fix is normalizing XFF at the edge plus not trusting it downstream.
If you can’t reduce the legitimate hop count below 30 — a real multi-CDN or mesh topology — the header contract itself needs rethinking with your platform team; collapsing or replacing forwarded-for with a trusted single-hop identity header is an architecture decision, not a load-balancer setting.