IETF RFC 2616第4.2节允许一个请求包含具有相同字段名的多个头，只要插入的时间顺序被保留，并且它们的值可以用逗号分隔的值列表转换成单头。
http://tools.ietf.org/html/rfc2616#section-4.2
当且仅当该报头字段的整个字段值被定义为以逗号分隔的列表[即＃（值）]时，具有相同字段名的消息报头字段可以存在于消息中。 必须将多个头域组合成一个“field-name：field-value”对，而不用改变消息的语义，把每个后续的域值附加到第一个域中，每个域都用逗号分隔。 因此，接收具有相同字段名的头字段的顺序对于组合字段值的解释是重要的，因此当消息被转发时，代理务必不改变这些字段值的顺序。 F5不会覆盖任何现有的X-Forwarded-For。 也不会将现有的X-Forwarded-For连接成一个逗号分隔的值。 相反，它将在集合的尾部插入额外的X-Forwarded-For。
但是有多个客户端，代理服务器，CDNs，stream量pipe理器，服务器的操作X-Forwarded-For集合的环境呢？
执行统一的做法似乎是有利的。 但是，最佳做法是什么？
F5 BIG-IP默认的httpconfiguration文件插入标头在请求预先存在的XFF标头集合的末尾累积了一个额外的X-Forwarded-For ，以保持顺序。
AWS ELB鼓励将传入请求的多个X-Forwarded-For整合到包含逗号分隔的XFF IP列表的单个标头中，并加上用户主机地址，以保持顺序。
其他设备可以采用其他的变化。
是否存在针对异构环境的商定build议或事实标准？
此外，提供的任何时间戳数据将允许代码按照添加的时间顺序将X-Forwarded-For标题按照先前的XFF标题的操作可疑的情况明确地sorting。
是的，有一个标准：不要使用X-Forwarded-For。
RFC 7239定义了Forwarded头，它与X-Forwarded-For有着相当不同的语义，新的实现应该使用它。 不幸的是，它遇到了与X-Forwarded-For标识相同的问题：它可能在请求中被定义了两次，或者包含逗号分隔的值列表。 代理也可以完全删除它。
是的，有一个最佳做法：在内部使用不同的标题名称。
请记住，X-Forwarded-For及其替代Forwarded包含不可信input 。 一个客户把他们想要的东西放在这个标题上是微不足道的。 如果您确实需要知道连接到您的服务器的公共IP地址，请将其粘贴到另一个标头中。 例如，CloudFlare为此使用CF-Connecting-IP。 我也见过在nginx中使用的Client-IP和X-Real-IP（你可以在其中定义任何你想要的）。 无论使用什么名称，您的负载均衡器都应该在X-Forwarded-For或Forwarded之外的某个标头中发送请求者的IP地址。