日誌只說明蜘蛛来過，不說明它拿到了什么
服務器日誌能记錄訪問時間、狀態碼和 User-Agent，但它看不到蜘蛛實际收到的响應体。有些情况在日誌里是一行漂亮的 200，實际返回的却是風控拦截頁、空壳 HTML，或者一段被替換過的内容。想確認蜘蛛看到了什么，最直接的方式是用命令行完整复現一次抓取。
复現之前先准备三样東西：一個你關心的 URL、日誌里出現過的蜘蛛 UA，以及這個域名目前解析到的地址。
第一步：確認請求發到了哪里
命令行發請求和浏览器一样走本地網絡，但這不代表請求一定落到了你预期的机器上。CDN 邊缘节点、负载均衡後的某一台後端，返回结果可能並不相同。
- 先看域名解析结果，確認是否经過 CDN；
- 需要直连源站时，用 curl --resolve 域名:443:源站IP 把請求钉到指定地址；
- 同时带上 Host 头，避免虚拟主机返回預設站点。
這一步的意义是排除“测的其實是另一台机器”這種最常见的誤判。
第二步：用蜘蛛的身份發請求
把 User-Agent 換成日誌里出現的值，完整拷過来，包括版本号和括号里的信息。很多站点、風控和 CDN 會按 UA 分流，用預設的 curl UA 去测，等于测了一個並不存在的场景。
想看重定向的完整鏈條，加上 -L；只想看响應头，加 -I 或用 -s -o /dev/null -D -；想同时拿到狀態碼、耗时和最终地址，可以用 -w 輸出這几項。
第三步：逐項讀响應头
响應头是排查抓取問题时信息密度最高的地方，重点看這几項：
- 狀態碼：200 之外，301/302 是否指向最终地址，403 是否来自風控，5xx 是否偶發；
- Content-Type：是不是 text/html，有没有把頁面当成下载文件返回；
- Content-Encoding：gzip 或 br 是否声明正确，声明了却没压缩會白白消耗抓取時間；
- Location：跳轉鏈有几跳，是否出現循环；
- Cache-Control 與 Vary：缓存版本是否随 UA 變化，移動版和桌面版會不會互相覆盖；
- X-Robots-Tag：是否在响應头层面禁止索引，這個字段经常被忽略。
第四步：看响應体里真正有什么
响應头看完，再確認内容本身。可以把响應体存成文件，用編輯器打開對照頁面源碼。
- 首屏正文是否出現在 HTML 里，還是完全依赖 JS 渲染；
- 主要導航和内容連結是否是真的 a 标簽，而不是点击事件；
- 字符集是否正确，中文有没有出現乱碼；
- 頁面里有没有被插入風控脚本、跳轉脚本或與主题無關的内容。
第五步：換几個身份再比一次
同一條 URL，在不同條件下可能是三份不同的内容。建议至少對比以下几组：
- 移動 UA 與桌面 UA，看連結和正文是否有差异；
- 带 UA 與不带 UA，看是否直接返回 403；
- 登入態與未登入態，看是否被要求跳轉；
- 有條件的话換一個出口地区，看 CDN 缓存是否造成版本差异。
差异本身不一定是問题，真正的問题是你不清楚蜘蛛拿到的是哪一份。
把结果固定成一張检查表
單次复現只能回答当下的疑問。更實用的做法是把上面几步固化成一張表：URL、复現時間、UA、狀態碼、最终地址、Content-Type、正文是否可讀、連結是否可讀，各自寫上结论。
這張表在几個時間点特別有用：站点改版後、上线新的 CDN 或風控規則後、發現抓取量異常下降後。同一張表前後對比，比對着日誌反复猜要快得多。
命令行复現只能回答“蜘蛛能不能拿到這一份内容”。拿不到，說明鏈路确實有問题；拿到了，也不代表一定會被收錄。它的價值在于把不确定的猜测，換成可以复現的事實。