有些页面的内容不在最初返回的那份文档里，要等脚本跑完才拼出来。抓这类页面要多一步渲染，代理IP接的位置也跟着多了一种选法：接在浏览器最外层，还是接在发请求的那一层。选错了，要么渲染不出来，要么抓到的还是空壳。
渲染这一步为什么会干扰代理
页面上的脚本自己也会发请求，去取数据、取图片、取字体。这些请求走不走代理，取决于代理接在哪一层。接在浏览器最外层，脚本发的请求大多跟着走；接在应用发请求的那一层，脚本自己发的那些请求往往不经过这一层，直接连出去。表现出来就是主文档拿到了，拼装内容的那几个请求却没走代理。
要判断是不是这种情况，可以看渲染前后来源有没有变化。渲染前是一个来源，渲染后另一个，说明脚本那一层没跟着走。
- (‘第一步’, ‘确认渲染是否真的完成，等元素出现再取内容’)
- (‘第二步’, ‘看脚本发出的请求有没有走代理，比对渲染前后的来源’)
- (‘第三步’, ‘把代理接到浏览器最外层，让页面内的请求一并跟随’)
- (‘第四步’, ‘换一条线路再跑一次，确认结果是稳定的’)
等待时间定多长
等待时间定得太短，页面还没拼完就去取内容，抓到的是空壳；定得太长，大部分时间花在等上面。合理的做法是等某个具体元素出现，别固定等几秒。元素出现了就取，这样既不会抢跑，也不会白等。
超时也能当信号
元素等待还有个附带好处：超时能作为失败信号。等了上限还没出现，说明这一页这次没拿到，可以直接计入失败，交给重试处理，不必再猜。
等待策略定好，失败判断就有了依据。
渲染和代理怎么分开排查
这类任务出错时，先分清是渲染的问题还是代理的问题。把代理暂时去掉跑一次，能渲染出内容，说明问题在代理这一层；去掉代理仍然渲染不出来，说明问题在页面或者等待策略上。分开看，比混在一起猜快得多。
渲染类任务的排查顺序：先确认页面能拼出来，再确认代理IP走的是哪条线路。
渲染和多出来的那些请求，是两类问题，分开看。
渲染抓取用到的代理IP，建议在任务开始时就固定下来，中途不要换。渲染过程本身要持续一段时间，中途换线路会让页面内的请求分散到不同来源上，前后拼起来的内容可能对不上。
把渲染完成和代理生效这两件事分别确认过，动态页面的抓取就稳了。先确认页面拼出来了，再确认走对了线路。