Crawlee项目中使用Puppeteer在Docker部署时的超时问题分析与解决

问题背景

在使用Crawlee 3.9.1进行内部文档爬取时，开发人员遇到了一个特殊的问题：当应用部署在基于apify/actor-node-puppeteer-chrome:20的Docker容器中并在AWS EKS上运行时，某些特定页面会出现导航超时错误。有趣的是，这个问题在本地开发环境（包括本地Docker环境）中完全不会出现，只有在生产环境部署时才会发生。

错误表现

系统会先显示警告信息：

WARN PuppeteerCrawler: Reclaiming failed request back to the list or queue. Navigation timed out after 60 seconds.

随后在重试达到最大次数后显示错误：

ERROR PuppeteerCrawler: Request failed and reached maximum retries. Navigation timed out after 60 seconds.

问题排查过程

初步尝试

开发人员尝试了多种方法来解决这个问题：

1. 尝试不同的Docker镜像
2. 测试不同版本的Puppeteer
3. 调整浏览器版本
4. 添加--disable-gpu标志 但所有这些尝试都未能解决问题。

深入分析

当开发人员转而使用纯Puppeteer实现爬虫时，发现了类似的超时问题，但错误信息略有不同：

TimeoutError: Navigation timeout of 30000 ms exceeded

通过启用Puppeteer的调试模式(DEBUG="puppeteer:*")，发现了一个关键线索：系统在尝试加载Google字体资源时出现了超时：

Failed to load resource: net::ERR_TIMED_OUT

根本原因

问题源于以下几个因素的组合：

1. 跨域资源加载：页面尝试加载Google字体等外部资源，这些请求可能受到了已设置cookie的影响
2. 环境差异：生产环境的TCP keepalive超时设置可能比本地环境更长（某些Linux发行版默认设置为2小时）
3. 请求拦截缺失：默认情况下没有对非目标域名的请求进行过滤

解决方案

方法一：禁用导航超时（临时方案）

page.setDefaultNavigationTimeout(0);

方法二：请求拦截（推荐方案）

page.setDefaultNavigationTimeout(0);
page.setRequestInterception(true);
page.on('request', req => {
    if(!req.isInterceptResolutionHandled()) {
        const url = new URL(req.url());
        if(url.hostname !== domain) {
            return req.abort();
        } else {
            return req.continue();
        }
    }
});

技术原理

1. 请求拦截：通过拦截非目标域名的请求，避免了外部资源加载导致的超时问题
2. 性能优化：这种方法不仅解决了超时问题，还能显著提高爬取速度，因为不再需要等待无关资源的加载
3. 资源控制：减少了不必要的网络流量和资源消耗

最佳实践建议

1. 对于爬虫项目，建议始终启用请求拦截，只允许目标域名的请求
2. 在生产环境部署前，应该模拟生产环境的网络条件进行测试
3. 对于关键爬取任务，考虑实现自定义的重试逻辑和错误处理机制
4. 监控和记录所有被拦截的请求，以便后续分析和优化

总结

这个案例展示了在复杂环境中部署网络爬虫时可能遇到的隐蔽问题。通过系统性的排查和深入的技术分析，开发人员不仅解决了当前问题，还总结出了可推广的最佳实践。关键在于理解不同环境下的网络行为差异，并实施适当的请求控制策略。

对于使用Crawlee或Puppeteer的开发人员来说，请求拦截是一个强大而必要的技术，它不仅能解决超时问题，还能提高爬虫的效率和可靠性。