我想知道你从什么地方得到后端"都"不喜欢这个结论

@crazystory 两边监听的对象要保持一致 否则取出 job 的时候无法反序列化

a 只 push 到队列 不进行队列监听 b 用对应配置监听就行了

敢不敢换个头像

我同事的日志清一色 up
我说了好多次让他写详细点我看日志大概知道你做了啥，无用，所以现在他的 commit 基本没法追查，要你对着 commit 的详细记录去看变更才知道做了什么

怎样才算中级。。。

100 倍？？？

小伙子。。你有 3 个{{{ 却只有 2 个 }} 自己再仔细看看

用 vbox 虚拟了一个 windows ce

我咋看着像广告

相似度 90%。。。说是自己的不太合适吧

没有

@msg7086 但是依然脱离不了自定义 head 。。。结果并没有啥改变

@msg7086 服务器对码农透明的时候，才能针对性的根据实际情况防止伪造。反之不透明的时候，理论上是没办法防止伪造的

@msg7086 一样的， realip 也属于把 IP 放到一个自定义的 head 里，客户端依然可以伪造。当然如果设置了 realip 的头以后，经过负载均衡的时候负载均衡会覆盖这个伪造数据，从而使这个数据是合法的。所有的负载均衡都可以这样做，不光是 nginx 。

一、关于 REMOTE_ADDR
这个变量获取到的是《直接来源》的 IP 地址，所谓《直接来源》指的是直接请求该地址的客户端 IP 。这个 IP 在单服务器的情况下，很准确的是客户端 IP ，无法伪造。当然并不是所有的程序都一定是单服务器，比如在采用负载均衡的情况（比如采用 haproxy 或者 nginx 进行负载均衡），这个 IP 就是转发机器的 IP ，因为过程是客户端->负载均衡->服务端。是由负载均衡直接访问的服务端而不是客户端。

二、关于 HTTP_X_FORWARDED_FOR 和 HTTP_CLIENT_IP
基于《一》，在负载均衡的情况下直接使用 REMOTE_ADDR 是无法获取客户端 IP 的，这就是一个问题，必须解决。于是就衍生出了负载均衡端将客户端 IP 加入到 HEAD 中发送给服务端，让服务端可以获取到客户端的真实 IP 。当然也就产生了各位所说的伪造，毕竟 HEAD 除了协议里固定的那几个数据，其他数据都是可自定义的。

三、为何网上找到获取客户端 IP 的代码都要依次获取 HTTP_CLIENT_IP 、 HTTP_X_FORWARDED_FOR 和 REMOTE_ADDR
基于《一》和《二》以及对程序通用性的考虑，所以才这样做。 假设你在程序里直接写死了 REMOTE_ADDR ，有一天你们的程序需要做负载均衡了，那么你有得改了。当然如果你想这么做也行，看个人爱好和应用场景。也可以封装一个只有 REMOTE_ADDR 的方法，等到需要的时候改这一个方法就行了。

@dorentus 合法的语法为何要警告。这不是多此一举。 就是需要这样写呢。