是否有链接 x-forwarded-for 标头的标准？

Question

IETF RFC 2616 第 4.2 节允许请求包含具有相同字段名称的多个标头，只要保留插入的时间顺序，并且它们的值可以转换为具有逗号分隔值列表的单个标头。

http://tools.ietf.org/html/rfc2616#section-4.2

当且仅当该头字段的整个字段值被定义为逗号分隔列表[即，#(values)] 时，消息中可能存在具有相同字段名的消息头字段。通过将每个后续字段值附加到第一个字段值，每个字段值用逗号分隔，必须可以将多个标题字段组合成一个“字段名称：字段值”对，而不改变消息的语义。因此，接收具有相同字段名的头字段的顺序对组合字段值的解释很重要，因此当转发消息时，代理不得更改这些字段值的顺序。F5 不会覆盖任何现有的 X-Forwarded-For。它也不会将现有的 X-Forwarded-For 连接成一个逗号分隔的值。反而，

但是，如果环境中有多个客户端、代理、CDN、流量管理器、参与操作X-Forwarded-For集合的服务器呢？

执行统一的做法似乎有好处。但最佳实践是什么？

F5 BIG-IP 默认 http 配置文件插入标头X-Forwarded-For在请求的预先存在的 XFF 标头集合的末尾累积一个附加标头，以保留顺序。

AWS ELB 鼓励将传入请求的多个X-Forwarded-For合并到一个包含以逗号分隔的 XFF IP 列表以及用户主机地址的单个标头中，以保留顺序。

其他设备可以采用其他变体。

是否存在针对异构环境的商定建议或事实上的标准？

此外，是否提供了任何时间戳数据，以允许代码X-Forwarded-For在先前对 XFF 标头的操作可疑的情况下按添加的时间顺序对标头进行明确排序。

Answer 1

是的，有一个标准：根本不要使用 X-Forwarded-For。

RFC 7239定义了 Forwarded 标头，它与 X-Forwarded-For 具有相当不同的语义，新的实现应该使用它。不幸的是，它遇到了您在此处使用 X-Forwarded-For 确定的相同问题：它可能在请求中定义两次或包含逗号分隔的值列表。代理也可以完全删除它。

是的，有一个最佳实践：在内部使用不同的标头名称。

请记住， X-Forwarded-For 及其替代品 Forwarded 包含不受信任的输入。客户在这样的标题中放入他们想要的任何东西是微不足道的。如果您真的需要知道连接到服务器的任何设备的公共 IP 地址，请将其粘贴在不同的标头中。例如，CloudFlare 为此使用 CF-Connecting-IP。我还看到了 nginx 中使用的 Client-IP 和 X-Real-IP（您可以在其中定义任何您想要的）。无论使用什么名称，您的负载均衡器都应该在X-Forwarded-For 或 Forwarded 之外的某个标头中发送请求者的 IP 地址。