Scrapy爬虫在VPS上所有请求均返回403错误求助
解决Scrapy-proxies在VPS上返回403 Forbidden的问题
这种本地运行正常、部署到VPS就全量403的情况确实很棘手,结合你提供的日志和配置信息,我整理了几个优先级较高的排查方向:
1. 优先检查文件路径兼容性
你配置中的USER_AGENT_LIST和PROXY_LIST使用的是Windows系统的路径格式(C:\Users\Administrator\Desktop\...),而VPS通常采用Linux系统,路径规则完全不同。这很可能是核心问题:
- 先将
useragents.txt和proxies.txt上传到VPS的爬虫项目目录下(比如/home/your_username/your_scrapy_project/) - 修改配置文件中的路径为Linux风格,例如:
USER_AGENT_LIST = "/home/your_username/your_scrapy_project/useragents.txt" PROXY_LIST = "/home/your_username/your_scrapy_project/proxies.txt" - 同时确保这两个文件的权限正确(比如设置为
644),保证Scrapy进程能正常读取。如果路径错误或文件不可读,scrapy-proxies可能无法加载代理列表,实际请求会使用VPS自身IP,直接触发目标站的反爬封禁。
2. 验证User-Agent是否正常随机加载
如果useragent文件路径错误,Scrapy会默认使用Scrapy/version (+https://scrapy.org)这类特征明显的UA,很容易被反爬识别。你可以添加一个简单的中间件来验证UA是否正常:
class VerifyUAMiddleware: def process_request(self, request, spider): current_ua = request.headers.get('User-Agent', b'').decode('utf-8') spider.logger.debug(f"Current User-Agent: {current_ua}")
然后将该中间件加入DOWNLOADER_MIDDLEWARES:
DOWNLOADER_MIDDLEWARES = { # 其他中间件... 'your_project_name.middlewares.VerifyUAMiddleware': 350, }
运行爬虫后查看日志,确认UA是否在随机切换。
3. 模拟真实浏览器的请求头
手动用Firefox能访问目标站,说明代理本身有效,但Scrapy的默认请求头和浏览器差异较大,可能被反爬检测到。你可以复制Firefox的请求头(通过F12开发者工具的Network面板查看),添加到Scrapy配置中:
DEFAULT_REQUEST_HEADERS = { 'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8', 'Accept-Language': 'en-US,en;q=0.5', 'Accept-Encoding': 'gzip, deflate, br', 'Connection': 'keep-alive', 'Upgrade-Insecure-Requests': '1' }
让请求更贴近真实浏览器的行为。
4. 确认代理是否真正生效
虽然日志显示“Using proxy”,但可以进一步验证请求是否真的通过代理发送:
- 在爬虫的
parse方法中打印代理信息:def parse(self, response): self.logger.info(f"Request used proxy: {response.meta.get('proxy')}") - 或者在VPS上使用
tcpdump抓包,检查请求的源IP是否为代理IP。如果代理未生效,请求会使用VPS自身IP,导致403。
5. 调整爬取频率避免触发反爬
目标站可能对请求频率敏感,Scrapy默认的并发数和请求间隔可能过高。你可以添加以下配置降低爬取速度:
DOWNLOAD_DELAY = 2 # 每个请求间隔2秒 CONCURRENT_REQUESTS = 4 # 全局并发请求数 CONCURRENT_REQUESTS_PER_DOMAIN = 2 # 单域名并发请求数
先从路径问题开始排查,这是部署时最容易忽略的坑,然后逐步验证其他方向,应该能解决你的403问题。
内容的提问来源于stack exchange,提问作者Biswajit Chopdar
相关产品推荐
相关产品推荐

