历史记录,  网站搭建,  长篇文章

WP后台统计异常-独立IP访问量突然极低的解决方法

本文于2021年2月3日由AlvinCR更新

一:背景

本文写于2021.1.11日,于2021.2.3测试结束并完成本文。最终数据并没有恢复到出现问题之前的数据,但是现在统计数据我觉得比出现问题之前更准确,ALinvCR认为现在独立IP虽然比之前少很多,但是更加符合真实访问人数。

以下内容默认是在统计插件完好的情况下进行的,虽然是统计插件的原因,但是alvincr更想找出是什么导致了这种原因,这种情况下想解决这个问题最快的方法就是不看这个统计数据,而是采用其他方法;亦或是更改nginx/php设置,使其显示真实IP地址。

如果非要采用这个统计插件,既可以重新设置一下,也可以添加函数。

问题可能性

在我9号的一通操作之后,网站的访问人数不增反减,一开始我没在意,因为不同时间段访问人数有波动很正常,但是到了10号发现有些了奇怪的地方,早上起来的时候访问量接近x(x>>10),但是到了下午是x+3,晚上的时候就变成了x+10,以前站点访问基本上没有太大波动,每个时间段都会有一定的访问量。

当我今天早上(2021.1.11)起来看到访问量只有9的时候,心都凉了,想着各种可能的原因:是不是我的网站被BAN了,是不是被劫持了等等等,但是经过简单的验证发现并未非上述原因。

这时我突然想到了我的一个无心之举:在CDN加速商那里设置了IP统计,然后我进入CDN加速的服务商后台查看数据,令我送了一口气,通过CDN加速商统计的数据并没有太大波动,数据与出现异常前情况相当。

当日(2021.1.11)24小时数据

问题查询

仔细回想一下,导致此结果的罪魁祸首最有可能是:开启CDN加速以及Fastest cache。这两者共同作用使得网站的访问量急速下降,直接降到了冰点。

不过奇怪的是在我单独打开CDN加速的时候并没有出现过这种情况,与Fastest cache共同使用一段时间也没有出现这种现象,在我设置Fastest cache使用CDN提供的API接口后才出现该类问题。(2021.1.13补充:禁用该接口并没有解决该问题,实锤是CDN加速的原因了)

查看后台统计访问的IP地址,可以发现全部都是同一地址段的IP(CDN加速服务商的IP)

二:查找问题

1 Fastest cache

为了验证是否是由Fastest cache使用CDN接口导致的此类问题,因此停用接口3小时,禁用此插件并清除缓存,检测状况。(2021.1.11-GTM-2:56 AM)

经过很长时间的等待验证,结果无效

此外谷歌测试桌面端访问速度由原来的78降到了64,

移动端降到了12..,最后重新开启插件。

三:解决方法

于2021.2.3日最终采用的方法是禁用CDN加速,因为通过我这一个月的使用体验,发现不使用CDN的效果比使用CDN要好很多,CDN加速果然不太适合我这样的不起眼的小站使用,而且被攻击的次数也不多,服务器完全能够抵挡住攻击。

不过采用其他软件进行统计发现统计结果差别很大,基本上差别在50%以上,而且本站统计的访问人数数据,也没有再恢复到出现问题之前的人数,现在统计的人数是原来人数的三分之一左右,是使用CDN加速服务商统计人数的六分之一。

不过现在在百度和谷歌都能够搜索到AlvinCR的个人文章了,每天百度谷歌能固定提供十几个IP,以前一直都是0.

1 有效方法:

方法1 禁用CDN加速

最简单的方法就是禁用CDN加速,但是随着网站的访问量增加,我的那个小服务器肯定吃不消,这个方法只能暂时搁置了,毕竟除了WP统计插件,CDN服务商也提供统计数据,直接参考服务商给的数据就好了。

方法2 更改功能函数

更改中出现一些问题,但是不可否认此方法可行。

2 有一定效果

方法1 改用HTTP_X_FORWARDED_FOR追踪选项

在统计-设置-访客ip中调整此类选项

经过两天的测试,2021.1.13发现:

使用remote_addr(初始设定)统计的人数是实际人数的(1/20)

使用http_x_forwarded_for统计的人数是实际人数(1/10)。

在这里实际人数指的是CDN服务商统计的独立IP数据。

此外:点击数/独立IP 变得莫名之高,原本是1/2,现在变成了1/10。

理论上使用http_x_forwarded_for不会出现这种情况,原因参考下面的附录,个人认为出现此状况,是由于部分用户隐藏真实IP导致的。此外我也找到了相关文章(附2),也验证了我的猜想。

附 相关知识

感谢大神分享的知识,以下内容清晰易懂:

为什么CDN加速会使ip异常

当你的网站使用了CDN后,用户会先访问CDN,如果CDN没有缓存,则回源站(即你的反向代理)取数据。CDN在回源站时,会先添加x_forwarded_for头信息,保存用户的真实IP,而你的反向代理也会设定这个值,不过它不会覆盖,而是把CDN服务器的IP(即当前remote_addr)添加到x_forwarded_for的后面,这样x_forwarded_for里就会存在两个值。Nginx会使用这些值里的第一个,即客户的真实IP,而PHP则会使用第二个,即CDN的地址。

什么是remote_addr

remote_addr代表客户端的IP,但它的值不是由客户端提供的,而是服务端根据客户端的ip指定的,当你的浏览器访问某个网站时,假设中间没有任何代理,那么网站的web服务器(Nginx,Apache等)就会把remote_addr设为你的机器IP,如果你用了某个代理,那么你的浏览器会先访问这个代理,然后再由这个代理转发到网站,这样web服务器就会把remote_addr设为这台代理机器的IP。

什么是x_forwarded_for

正如上面所述,当你使用了代理时,web服务器就不知道你的真实IP了,为了避免这个情况,代理服务器通常会增加一个叫做x_forwarded_for的头信息,把连接它的客户端IP(即你的上网机器IP)加到这个头信息里,这样就能保证网站的web服务器能获取到真实IP。

http://blog.pengqi.me/2013/04/20/remote-addr-and-x-forwarded-for/#:~:text=remote_addr%E4%BB%A3%E8%A1%A8%E5%AE%A2%E6%88%B7%E7%AB%AF%E7%9A%84IP,%E7%84%B6%E5%90%8E%E5%86%8D%E7%94%B1%E8%BF%99%E4%B8%AA%E4%BB%A3%E7%90%86

个人总结:

remote_addr相当于准考证,x_forwarded_for相当于身份证。你的准考证号会根据你选择的考场(代理服务器)而变动,但是无论如何你的身份证是不变的,只要你提供你的身份证我就能准确认出你是谁,不会和别人相混淆。

附2: X-Forwarded-For为什么不准确
参考:

X-Forwarded-For 是一个事实标准,虽然没有写入 HTTP RFC 规范里,从普及程度上看其实可以算 HTTP 规范了。这个标准是这样定义的,每次代理服务器转发请求到下一个服务器时,要把代理服务器的 IP 写入 X-Forwarded-For 中,这样在最末端的应用服务收到请求时,就会得到一个 IP 列表:

X-Forwarded-For: client, proxy1, proxy2

因为 IP 是一个一个依次 push 进去的,那么第一个 IP 就是用户的真实 IP,取来用就好了。但是,事实没这么简单!

从安全的角度上考虑,整个系统最不安全的就是人,用户端都是最好攻破最好伪造的。有些用户就开始钻协议的漏洞:X-Forwarded-For 是代理服务器添加的,如果我一开始请求的 Header 头里就加了 X-Forwarded-For ,不就骗过服务器了吗?

首先从客户端发出请求,带有 X-Forwarded-For 请求头,里面写一个伪造的 IP:

X-Forwarded-For: fakeIP,接着服务端第一层代理服务收到请求,发现已经有 X-Forwarded-For,误把这个请求当成代理服务器,于是向这个字段追加了客户端的真实 IP:

X-Forwarded-For: fakeIP, client

https://www.cnblogs.com/skychx/p/X-Forwarded-For-get-real-IP.html(略有修改,请大神见谅)

个人总结:

通过在header头中加上X-forwarder-for请求头,直接伪造fake IP,而服务器收到x-forwarder-for请求头后认为fake ip就是用户真实ip,就这样一步一步记录下来然后传给下层代理,最终服务器收到的header为X-Forwarded-For: fakeIP, client, proxy1, proxy2

也就是X-Forwarded-For: 虚假ip,客户端,代理1,代理2

他人讨论:

A:也就是说我自己写个代理服务器不将客户端 IP写入 X-Forwarded-For, 并且伪造一堆IP写入X-Forwarded-For, 服务器永远找不到真实客户端IP, 顶多找到最外层代理服务器地址.。

B:理想情况下确实不错,不过现实总是残酷的,比如这样搞代码就没有普适性了,迁移一下服务器就出问题了,另外就是客户也能搭建反向代理。

方法2 禁用cache

从网上教程得知cache对统计效果有一定影响,因此我禁用缓存系统并删除缓存内容。

但是经过禁用WP Fastest Cache三天发现,基本没影响

3 待验证

方法1 更换统计插件

个人认为是无效的,于2021.1.11-2021.2.3测试发现,更换统计插件确实无效,这里的无效指的是没有得出出现异常前的数据,访问量突然变得极低之后现在也没恢复到原来水平,但是却变得更为可信了。

 

Leave a Reply

邮箱地址不会被公开。 必填项已用*标注

WP后台统计异常-独立IP访问量突然极低的解决方法