蜘蛛池跑起来之後，很多人只盯着後台那個抓取數字看，却很少打開服務器上那份原始訪問日誌。實际上，日誌才是判断蜘蛛有没有認真抓、抓得對不對的第一手材料。第三方統計工具大多做了聚合和過滤，而 access log 保留了每一次請求的原始记錄，很多異常只有在這里才看得出来。

日誌里先看哪些字段

一份标准的 Nginx 或 Apache 訪問日誌，通常包含下列内容。建议在配置中把响應時間和完整 User-Agent 都打開，否則後面的分析會缺一半信息：

• 遠端 IP：蜘蛛来源，也是做反向 DNS 校驗的起点
• 時間戳：判断抓取是集中在某個时段還是全天分散
• 請求方法與 URL：看蜘蛛抓的是入口頁、列表頁，還是誤抓的接口和资源
• 狀態碼：200、301、404、5xx 各自的占比
• 响應体大小與响應時間：判断哪些頁面在拖慢整体响應
• User-Agent 與 Referer：辅助判断請求来源和跳轉鏈路

先分辨真蜘蛛和伪装請求

日誌里的 UA 可以随便伪造，所以不能只看字符串。比較稳妥的做法是做反向 DNS 校驗：把 IP 反解成域名，再正向解析回 IP，確認两邊一致，並且域名属于對應搜尋引擎。IP 段也可以對照官方公布的列表定期核對。

如果發現大量 UA 寫着蜘蛛、但反查没有结果、請求频率极高、只盯着少數 URL 的 IP，多半是采集器或掃描器。這類請求不會带来任何價值，反而持續占用带宽和连接數。

從日誌看抓取结构是否合理

把日誌按 URL 路径归類，可以大致看出蜘蛛的行為偏好：

• 入口頁被抓很多次，但列表頁几乎没有记錄，說明連結层級太深，蜘蛛没有顺着往下走
• 大量带參 URL 被反复抓取，属于典型的重复入口，需要考虑归一化或屏蔽
• 图片、CSS、JS 等静態资源占了大头，說明抓取预算被無關内容消耗
• 抓取時間高度集中在某几分钟，可能是触發了限速，或並發被服務端压制

這些現象不直接等于收錄會變差，但至少說明蜘蛛的訪問效率不高，值得回头調整入口頁的連結结构。

狀態碼與响應時間的異常信号

狀態碼分布是最容易被忽略的部分。5xx 比例偏高，通常意味着服務端在蜘蛛压力下不稳定；大量 404 說明入口頁里存在失效連結；301 數量異常，往往是跳轉鏈路拉得太長。响應時間方面，如果同一批 URL 的慢請求比例明顯高于日常水平，就要检查是否有慢查询或外部接口在拖後腿。

另外，蜘蛛常用 HEAD 請求探测頁面是否更新，這類請求不應算作完整抓取，統計时最好單獨分開。

日誌本身的配置注意点

• 開啟 $request_time 與 $upstream_response_time，区分網絡耗时和後端耗时
• 完整记錄 User-Agent，不要截断，否則無法核對蜘蛛身份
• 設定按天轮轉和保留周期，避免日誌寫满磁盘導致服務異常
• 如果流量較大，可以只對蜘蛛 UA 單獨寫一份日誌，便于分析

几個常见的誤判

1. 把請求量等同于抓取量：日誌记錄的是請求，蜘蛛可能只取头部就断開
2. 只看總請求數：几千次請求集中在少數 URL 上，實际覆盖的頁面可能只有几十個
3. 忽略 HEAD 請求：用探测請求判断抓取效率，结论會偏乐观
4. 把日誌当成收錄證據：抓取和收錄是两件事，日誌只能說明蜘蛛来過

可落地的使用建议

1. 保留至少 30 天原始日誌，按天切分，方便對比趋势變化
2. 把日誌導入本地分析工具，按 UA、狀態碼、路径做交叉統計
3. 每周固定看一次蜘蛛抓取 TOP URL 與狀態碼分布，形成自己的基线
4. 發現 5xx 或响應時間突增，先排查服務端，再考虑調整入口頁结构
5. 對疑似伪装的 IP 優先限速，而不是直接封禁，避免誤伤真實蜘蛛

日誌只是观测手段，它能告诉你蜘蛛来了、抓了什么、拿到了什么响應，但不能保證某個頁面一定被收錄。把它当作排查工具，而不是效果承诺。