注意：请阅读完整的问题
我试图理解为什么浏览器在每次请求页面时都不显示任何x-forwarded-for头
这里是我的请求头
Request URL:http://localhost:3000/users/sign_in
Request Method:GET
Status Code:304 Not Modified
请求头：
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Cookie:undefined=0; poasterapp=s%3A4faaa6b1723e7c6fbd949083532c52598652547b.sNX%2BKOEed2TEQkQN7I7K5lgpoHMRpwerKFvUegMnTVI; _minerva_session=BAh7CUkiD3Nlc3Npb25faWQGOgZFRkkiJWEyM2Q0ZTViMWEyODBiYmFmODEwZTJhZmUwNWU5ODk5BjsAVEkiE3VzZXJfcmV0dXJuX3RvBjsARiIGL0kiCmZsYXNoBjsARm86JUFjdGlvbkRpc3BhdGNoOjpGbGFzaDo6Rmxhc2hIYXNoCToKQHVzZWRvOghTZXQGOgpAaGFzaHsGOgphbGVydFQ6DEBjbG9zZWRGOg1AZmxhc2hlc3sGOwpJIgAGOwBUOglAbm93MEkiEF9jc3JmX3Rva2VuBjsARkkiMUN0Uk56SXU0dUdIdzgwcFZJM3R0L2N4dlovRllTSGRrQ2o1R0VVanhIaVk9BjsARg%3D%3D--6bd89ce9d29e9bdcf56573f9a153dc663a8fe755
Host:localhost:3000
If-None-Match:"785d34e3998360353567fc710af123fb"
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.102 Safari/537.36
响应头（不需要但仍然需要）
Cache-Control:max-age=0, private, must-revalidate
Connection:close
ETag:"785d34e3998360353567fc710af123fb"
Server:thin 1.5.0 codename Knife
Set-Cookie:_minerva_session=BAh7CEkiD3Nlc3Npb25faWQGOgZFRkkiJWEyM2Q0ZTViMWEyODBiYmFmODEwZTJhZmUwNWU5ODk5BjsAVEkiE3VzZXJfcmV0dXJuX3RvBjsARiIGL0kiEF9jc3JmX3Rva2VuBjsARkkiMUN0Uk56SXU0dUdIdzgwcFZJM3R0L2N4dlovRllTSGRrQ2o1R0VVanhIaVk9BjsARg%3D%3D--dfb3ce9f5c97463cfcd0229a133654e6cc606d98; path=/; HttpOnly
X-Request-Id:41a6f3062dc8bc36b7b3eae71dc5075d
X-Runtime:89.238257
X-UA-Compatible:IE=Edge
如前所述，我没有看到任何x-forwarded-for请求头
阅读x-forwarded-for的wiki页让我觉得，这是通过缓存服务器（在我的例子中，我相信是我的isp提供商）完成的
so am I safe to believe that the **X-Forwarded-For** headers is something that is added at the caching server side (ISP provider)如果是的，他们是不是在烦我
为什么？对于在我的机器上本地运行的服务器和我通过类似于
X-Forwarded-For的浏览器访问它们的情况，也是一样的（即http://localhost:3000不出现在请求头中） 最佳答案
x-forwarded-for不是RFC 2616 Section 5.3中指定的标准请求头，它处理协议标准请求头，协议标准请求头是（在rfc中指定的）
接受
接受字符集
接受编码
接受语言
授权
期待
从
主持人
如果匹配
如果修改自
如果不匹配
中频范围
如果未修改自
最大前进速度
代理授权
范围
小精灵
TE公司
用户代理
为了使传入请求具有自定义的[x-forwarded-for]头，调用客户端必须将其显式添加到该请求中。最简单的解释是，发送请求的客户端没有手动添加该头。
棘手的是，您期望看到的头并不是您必须期望接收的头，除非您的服务和调用方之间存在一个契约，该契约与Httprotocol不同，指示您应该期望在请求头中指定x-forwarded-for值。正如其他人已经指出的，xff报头通常由代理服务器或负载平衡器设置，以指示通过其代理的真正请求者是谁。
作为服务提供商，如果您要求在所有请求中设置[x-forwarded-for]头，则必须在服务策略级别强制它。如果您不想为代理帐户提供服务，而这些代理帐户没有通过其代理IP识别他们正在屏蔽的是谁，请使用403禁止回退他们的请求。如果您处于必须为这些请求提供服务但依赖于设置此头的情况下，则必须创建一个自定义进程，以便将它们的错误反馈给您。
下面是httprotocol对匿名性的看法：
因为链接的源可能是私有信息，也可能是
透露一个其他的私人信息源
建议用户能够选择
发送referer字段。例如，浏览器客户端可以有
打开/匿名浏览切换开关，这将
分别启用/禁用referer和from的发送
信息。
客户端不应在（非安全的）中包含referer头字段
如果引用页是用安全的
协议。
使用http协议的服务的作者不应使用get
基于提交敏感数据的表单，因为这将
使此数据编码在请求uri中。许多现有
服务器、代理和用户代理将在某些日志中记录请求URI。
可能对第三方可见的地方。服务器可以使用
改为基于邮件的表单提交
…
在每个请求中发送详细的用户自定义接受头字段，
特别是如果这些值包括质量值，则可以由服务器使用
作为相对可靠和长寿命的用户标识符。这样的用户
标识符允许内容提供者进行点击跟踪，
并允许协作内容提供商匹配跨服务器
单击单个用户的跟踪或表单提交。注意，对于
许多用户不在代理的后面，主机的网络地址
运行用户代理也将作为长寿命用户
标识符。在使用代理增强的环境中
隐私，用户代理应该保守地接受
向最终用户提供标题配置选项。作为一种极端的隐私
度量值，代理可以过滤中继请求中的接受标头。
提供高度标题的通用用户代理
可配置性应该警告用户隐私的丢失
参与其中。
就我个人而言，我会用401.2回传请求，并通过www-authenticate-response报头将请求者路由到质询屏幕，该报头向请求者显示不允许匿名访问您的站点的通知。这是使用www authenticate报头的一种不规范的方式，但是看起来您希望x-forwarded-for报头能够确认和标识真正的请求者，并允许对您的服务进行公共的非匿名访问。对我来说，这是一个认证问题。
关于http - 浏览器未显示X-Forwarded-For header 的原因，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/21595921/