这样对吗？
不完全是。
CloudFront 遵循正确的语义X-Forwarded-For。具体来说，处理请求的每个系统都会将其客户端地址附加到右侧。这意味着最右边的地址X-Forwarded-For来自 CloudFront 的请求中始终是连接到 CloudFront 的计算机的地址。
如果客户端（与 CloudFront 建立连接的计算机）包含X-Forwarded-For其请求中的标头，该标头可能是伪造的，或者如果客户端是代理服务器，则它可能是合法的，但您很少有办法知道......所以无论哪种方式，您都应该将其视为潜在有价值的，但严格来说非权威。
最右边的值（也可能是唯一的值）是您在从 CloudFront 收到的请求中可以信任的唯一值。
一般来说，从右侧解析，任何您已知的并且可信的已正确识别其上游客户端的地址都可以从列表中删除......但是一旦您遇到第一个不受信任的地址，从右到左，这就是您要处理的地址。正在寻找，因为该地址左侧的任何内容都不可信。
这意味着如果堆栈中的组件（例如 Application Load Balancer 或 Web 服务器）也在添加X-Forwarded-For，那么您需要考虑这些组件的内容also添加到值的右侧，修改 CloudFront 提供的内容。
例如。客户端发送：
X-Forwarded-For: a, b, c
CloudFront添加客户端的IPd:
X-Forwarded-For: a, b, c, d
ALB 收到来自 CloudFront 的请求，因此它添加了 CloudFront 出口地址e:
X-Forwarded-For: a, b, c, d, e
然后您的网络服务器添加平衡器的内部地址f:
X-Forwarded-For: a, b, c, d, e, f
您可以信任并删除f只要它位于平衡器子网的 CIDR 范围内即可。
您可以信任并删除e只要它在 CloudFront 中地址范围 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html.
这给你留下了d作为客户端地址。
价值a and b and c are almost毫无价值，在这个例子中，因为你不能相信它们的真实性，因为它们位于第一个（从右边）不受信任的地址的左侧......偶尔，它们可能在取证上有用，但你不能做任何基于它们的实时决策。
就是这样X-Forwarded-For always作品。由于缺乏理解，许多开发人员似乎做出了天真的假设。在将其用于任何重要的事情之前，请确保您理解它。
In Lambda@Edge https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html触发器，CloudFront 为您提供客户端 IP 地址event.Records[0].cf.request.clientIp。这始终只是一个地址，并且与最右边的值相同X-Forwarded-For当请求离开 CloudFront 前往您的源时（如上所述，这可能会在右侧添加其他值）。
