近期我们发现Apache日志中2a06:98c0:3600::103这个IPv6地址出现非常多，User Agent一般都是显示的googlebot，我们刚开始以为是Google爬虫使用了IPv6地址，但有些User Agent又不是googlebot，所以有点迷惑，因为这是来自Cloudflare的访问，所以我们想可能是一个反向代理IP，想获取其背后真实访问者的IP地址。🤔️
查看以前博文《Apache安装mod_remoteip获取CDN背后访问者真实IP》，我们的httpd.conf中设置了：
RemoteIPHeader CF-Connecting-I
去年以来我们的Apache日志中总看到一个奇怪的IP地址：253.102.157.193，查询归属地是一个E类保留地址，查询Whois是预留未来使用，而User Agent一般都是显示的googlebot，我们还以为Google有什么特权可以使用保留地址。
最近发现这个地址访问的页面越来越多，可以导致服务器不堪重负，就花时间仔细去了解，才发现这不是访问者的真实IP，而是Cloudflare对IPv6地址转换的一个伪IPv4地址，Cloudflare的面板中在这里设置：
上一篇博客《有人恶意刷百度关键词陷害我们网站》写的是百度对一些黑帽SEO手段判断的不准确，导致我们网站被陷害。百度的作弊识别算法还不够完善，需要人工去发现、处理。我们觉得Google的作弊识别算法应该更好，但最近我们网站上发生的问题让我们看到Google的算法也是有漏洞可以钻的。😒
去年6月我们有一个站在Google的核心算法更新后就遇到流量下降，直到11月核心算法再次更新后流量才恢复，但核心算法的更新为什么会影响我们网站流量、具体问题出在甚么地方？这些问题一直没有搞懂。
今年5月Google的核心算法更新后，我们这个站的流量再次
去年11月份的时候，我们陆续有几个网站发现流量大幅减少，一开始还以为是正常波动或其它常规原因而没有引起重视，直到几周后来自百度搜索的流量持续大幅下降、好几个网站都情况类似，才去深入检查原因。🕵️
结果在百度资源平台中发现"流量与关键词"的热门关键词里面有些明显异常的数据，例如：
红框中的一些关键
最近几天我们国内的两个网站都遇到访问困难，检查发现是百度爬虫抓取量大增，是以前正常情况的很多倍，导致Web服务器CPU、带宽以及数据库服务器都难以应付。Googlebot也曾经出现类似情况。
按照以前的办法，我们是在百度资源平台或者Google Search Console中设置降低爬虫的抓取速率，不过这样设置后需要等待2-3天时间生效，而不能解决当时的问题。
Google的Core Web Vitals（网站核心指标）指标推出后我们也一直在关注，但最主要是关注LCP（Largest Contentful Paint 显示最大内容元素所需时间），对于FID（First Input Delay 首次输入延迟/封锁时间总计）和CLS（Cumulative Layout Shift 累计版面配置转移）没有非常在意。
最近在查看几个主
IPSHU这个网站设立之初就是为用户提供查询IP地址对应地理位置服务的，不过实际上这方面的流量不多，竞争很激烈，有很多网站提供非常类似的功能。
无心插柳柳成荫，我们这个网站的内网IP地址页面的访问量还不错，于是我们前几年把内网IP页面进行了全面改版，增加了很多用户需要的信息，效果也是很明显的。
为了让外网IP页面对用户帮助更大、与其它网站有更大的不同，我
IPSHU网站最开始各种IP地址都用相同的格式显示信息，都是显示的IP地址的地理位置信息，但实际上内网IP和一些特殊IP地址是没有地理位置信息的，几年前将IP地址划分为外网IP地址、内网IP地址和保留IP地址展示不同的信息，重点修改了内网IP地址的显示内容，改为用户更关心的路由器方面常见问答，效果应该是明显的。
最近将保留IP地址的
前段时间对IP地址的AS自治系统分配、Whois的分配服务器、Whois的Json数据获取等做了一些研究，编写程序去把目前的IP地址段的Whois数据都获取到、保存到数据库表中，然后再去读表、显示。
下面是各洲的IP地址Whois页面例子：
去年邮编库与百度开展邮政编码查询合作后，效果还不错，今年百度的人还主动找我们来做更多的智能小程序合作。我们很多年前就做工具类网站，所以也比较适合来做这一类小程序。下面是我们做的一个文字转拼音的百度智能小程序。
这个功能很简单所以也只做了一个页面，直接操作。不过对比其它类似网站或者小程序，我们还是有明显优势：添加了多音字的识别、增加了发音功能等。
下面是这个百度智能
2002-2023 v11.7 a-j-e-0
