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测试发现，更换统计插件确实无效，这里的无效指的是没有得出出现异常前的数据，访问量突然变得极低之后现在也没恢复到原来水平，但是却变得更为可信了。