近期我們發現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
