一、获取用户真实IP地址
上代码
1 | public static function getClientIp() |
PS:
$_SERVER
和getenv
的区别,getenv不支持IIS的isapi方式运行的php;getenv(“REMOTE_ADDR”)
函数在 apache下能正常获取ip地址,而在iis中没有作用;$_SERVER['REMOTE_ADDR']
函数,既可在apache中成功获取访客的ip地址,在iis下也同样有效
二、HTTP_X_FORWARDED_FOR
关于 REMOTE_ADDR
这个变量获取到的是直接来源的 IP 地址,所谓直接来源指的是直接请求该地址的客户端 IP 。这个 IP 在单服务器的情况下,很准确的是客户端 IP ,无法伪造。当然并不是所有的程序都一定是单服务器,比如在采用负载均衡的情况(比如采用 haproxy 或者 nginx 进行负载均衡),这个 IP 就是转发机器的 IP ,因为过程是客户端->负载均衡->服务端。是由负载均衡直接访问的服务端而不是客户端。关于 HTTP_X_FORWARDED_FOR 和 HTTP_CLIENT_IP
基于《一》,在负载均衡的情况下直接使用 REMOTE_ADDR 是无法获取客户端 IP 的,这就是一个问题,必须解决。于是就衍生出了负载均衡端将客户端 IP 加入到 HEAD 中发送给服务端,让服务端可以获取到客户端的真实 IP 。当然也就产生了各位所说的伪造,毕竟 HEAD 除了协议里固定的那几个数据,其他数据都是可自定义的。X-Forwarded-For 和 X-Real-IP区别
X-Forwarded-For是用于记录代理信息的,每经过一级代理(匿名代理除外),代理服务器都会把这次请求的来源IP追加在X-Forwarded-For中, 而X-Real-IP,没有相关标准, 其值在不同的代理环境不固定总结
HTTP_CLIENT_IP: 头是有的,只是未成标准,不一定服务器都实现了。
X-Forwarded-For(XFF): 是用来识别通过HTTP代理或负载均衡方式连接到Web服务器的客户端最原始的IP地址的HTTP请求头字段, 格式:clientip,proxy1,proxy2
REMOTE_ADDR: 是可靠的, 它是最后一个跟你的服务器握手的IP,可能是用户的代理服务器,也可能是自己的反向代理。
三、负载均衡和CDN情况
负载均衡
graph TD A[用户访问] -->B(nginx负载均衡服务器) B --> D[nginx服务器1] B --> E[nginx服务器2] B --> F[nginx服务器3]
生产环境中很多服务器隐藏在负载均衡节点后面,你通过REMOTE_ADDR只能获取到负载均衡节点的ip地址,一般的负载均衡节点会把前端实际的ip地址通过HTTP_CLIENT_IP或者HTTP_X_FORWARDED_FOR这两种http头传递过来。
后端再去读取这个值就是真实可信的,因为它是负载均衡节点告诉你的而不是客户端。但当你的服务器直接暴露在客户端前面的时候,请不要信任这两种读取方法,只需要读取REMOTE_ADDR就行了
CDN
graph TD A[客户端 IP:210.32.132.83] --> B(CDN ip:14.215.167.197) B -->|CDN回源,添加用户IP http_x_forwarded_for:201.32.132.83| C[代理服务器nginx] C -->|反向代理,添加上一个节点IP,http_x_forwarded_for:201.32.132.83,14.215.167.197| D[服务器Apache]
所以对于我们获取用户的IP,应该截取http_x_forwarded_for的第一个有效IP(非unknown)。
多层代理时,和cdn方式类似。
注意:无论是REMOTE_ADDR还是HTTP_FORWARDED_FOR,这些头消息未必能够取得到,因为不同的浏览器不同的网络设备可能发送不同的IP头消息
四、swoole+nginx下获取真实IP
最近在使用swoole框架的时候,发现原来php-fpm模式的获取客户端真实的IP发现不能工作了,因为在imi的框架中规定:禁止使用$_GET、$_POST、$GLOBALS、$_SERVER、$_FILES、$_COOKIE、$_SESSION、$_REQUEST、$_ENV
等超全局变量 ,上面的获取客户端IP不能使用了。
实现代码如下:
1 | use Imi\Server\Http\Message\Request; |
nginx配置如下:
1 | server { |