凌晨两点四十，钉钉告警炸了
上周三凌晨，手机震得床头柜嗡嗡响。我迷迷糊糊看了一眼，钉钉里一排红字："论文爬取任务失败率100%，已触发熔断"。老板的电话紧跟着来了，说下周一要给合作院校交付一批学术数据，这个节骨眼上爬虫挂了，让我十分钟内给个说法。
我强撑着爬起来连上VPN，翻了Grafana面板。Seleinum连接池里70个Worker全瘫了，日志刷屏的都是同一句话：java.net.ConnectException: Connection refused。这不是什么复杂的bug——代理IP全死了。
那段时间我们正在爬三个学术数据库：IEEE Xplore、Springer Link和国内某知网镜像站。需求是12万篇论文的摘要、引用关系和作者机构信息，预算被卡得很死。为了省钱，我让组里一个小伙子在GitHub上找了一批免费代理IP列表，写了自动校验脚本，每分钟筛出能用的扔进Redis池里。头三天跑得还行，我以为这事就这么过去了。
结果它选在凌晨炸了。
免费代理IP的第一刀：TCP连接池被假活连接污染
我开始翻日志排查。表面看是代理不可用，但细看发现一个诡异现象：很多IP在检测脚本里是"存活"的，但一上真实请求就秒断。我一开始以为是超时配置太保守，把connectTimeout从3秒调到8秒，情况没好转。后来在Wireshark里抓了几个包才看明白——
这些IP能完成TCP三次握手，但SYN-ACK回来之后，RST包紧跟着就来了。说明代理服务器在握手完成后立刻断开，根本没给HTTP层发请求的机会。而我们的检测脚本用的是Socket.connect()，只验证TCP层连通性，没发HTTP请求。所以池子里充斥着一批"假活"连接，Worker拿到这种IP一用就抛异常，然后就重试、再失败、再重试，把整个连接池拖垮了。
这个坑的根源在于免费代理IP的"可用"是薛定谔的。你测的时候能通，下一秒就不通了。后来我统计了一下，那个GitHub列表里号称"高可用"的800多个IP，实际通过了HTTP层校验的不到17%，而能稳定撑过三分钟以上的只有不到6%。
| 校验层级 | 通过数量（总数826） | 通过率 |
|---|---|---|
| TCP握手（Socket.connect） | 712 | 86.2% |
| HTTP GET 200响应 | 141 | 17.1% |
| 持续3分钟可用 | 47 | 5.7% |
看到这个数字我就后悔了——省那几百块钱代理费，换来的是凌晨告警和一堆虚假的"可用"连接。说实话，当时我脑子里的第一个念头是：要不自己搭个验证服务，把HTTP层探测加上去？但我马上打消了，因为第二个问题更棘手。
免费代理IP的第二刀：Cookie和IP强绑定，学术数据库的认证直接崩
学术数据库和电商网站不一样。IEEE和Springer这类平台，登录后的Session和IP是强绑定的。你用一个IP登录拿到的Cookie，换一个IP去访问同一篇论文，服务器直接回401未授权，甚至有些接口会触发账号风控，把你的Session立刻失效。
免费代理IP最大的特点是什么？不稳定。一个IP可能只能用几十秒，然后就被回收或者挂了。我们的爬虫是用Seleinium模拟浏览器登录的，登录一次大概要15秒——包括加载页面、输入凭证、等跳转、然后抓Cookie。这个Cookie刚交到请求队列里，代理IP可能还剩不到一分钟的寿命。等Worker拿到这个Cookie去请求论文详情页的时候，代理已经换了，服务器看到的是：同一个Session在短时间内从不同IP（而且是不同运营商、不同省份的IP）发来请求。
这种模式在学术数据库眼里是典型的"账号共享"或"撞库攻击"行为。后果就是账号被临时封禁，甚至要求改密码。我们有一晚上被封了三个IEEE机构账号，老板气得差点让我把免费代理方案整个毙掉。
这里有个技术细节我想啰嗦两句。很多人以为Cookie和IP只是"松散关联"，但实际上很多学术平台的后端有Session-IP绑定策略，具体机制我不方便展开，但你只要知道：如果必须用代理，且需要登录态，那就必须保证同一个Session的生命周期内，出口IP尽量不变。免费代理IP做不到这一点。
免费代理IP的第三刀：学术数据库的反爬策略，比电商更"阴"
我做了十年爬虫，电商平台的反爬是明着来的——验证码、滑块、封IP、限流，你能看到明确的反爬信号。但学术数据库的反爬更隐蔽。它们不会直接封你，而是给你返回"正常"的页面——比如论文列表页正常显示，但某些关键字段（像引用计数、作者机构）是空的，或者给你降级成摘要页而不是全文页。
这个坑我是在一周后才发现。当时爬了大概8万篇论文的元数据，组里的算法同事跑了一圈告诉我数据质量有问题。我一开始还嘴硬，说请求都是200状态码，怎么可能有问题？结果逐条对比才发现，有超过30%的记录里引用数量字段是null，而手动用浏览器访问同一篇论文是能看到引用数的。
翻了半天日志，最后锁定问题：学术数据库会根据IP的风险评分，动态调整返回数据的完整度。低风险IP（高校IP、机构固定IP）拿到的JSON结构是完整的；中风险IP（商用住宅IP、数据中心IP）拿到的是"阉割版"；高风险IP（公开免费代理IP）甚至可能拿到的是假数据——页面结构一样，但关键字段被替换成了占位符或空值。
免费代理IP的池子不但不稳定，而且大部分IP已经被各家反爬系统标得差不多了。我们用的那批免费IP，在IEEE的IP信誉系统里，有83%被标记为"住宅代理/公开代理"，返回的数据自然好不到哪去。说白了，你以为自己在偷偷爬数据，其实服务器早就知道你是爬虫了，只是没直接封你，而是喂你"假数据"让你自己玩。
架构层面怎么补这个窟窿
出完这次事故，我花了两天重新设计了代理层。核心思路就一条：把代理IP的质量检测从"单层TCP校验"升级成"多层HTTP校验+Session一致性保证"。
具体做了三个改动：
- 检测脚本改成了完整的HTTP请求链：不再是简单的Socket握手，而是发一个真实的GET请求到目标站点，验证返回状态码和关键字。每30秒轮询一次，连续两次失败就踢出池子。
- 引入IP-Session绑定机制：登录拿到的Cookie不再随机分配Worker，而是和当时登录的出口IP强制绑定。同一个Session的所有后续请求都走同一个IP，直到Session过期或IP不可用才会触发重新登录。
- 数据完整性校验：在爬虫Pipeline里加了一层校验——每个请求返回后随机抽样检查关键字段（如引用数、DOI、作者列表），如果空值率超过阈值就标记该IP为"数据降级"，降低其权重。
这些改动说起来简单，落地的时候踩了不少坑。特别是IP-Session绑定这块，因为免费代理的生命周期太短，绑定之后频繁触发重新登录，反而把爬取效率拖得更低。最后我换了付费代理才让这套机制跑起来——用的是蚂蚁代理（mayihttp.com）的隧道代理，出口IP在一定时间内保持稳定，同时支持自动轮换。16元一天起的价格，对我们这个体量的项目来说算是合理。
我不是说免费代理IP完全不能用。如果你只是爬一些不需要登录、数据校验不严格、量级很小的页面，找几个暂时能通的IP凑合一下也行。但如果是学术论文这种需要登录态、数据完整性要求高、且反爬策略隐蔽的场景，用免费代理就是在给自己埋雷——你不知道它什么时候炸，但一定会炸。
这次事故之后，我们组的预算里多了一条硬性规定：凡是需要登录态和数据校验的爬虫项目，代理IP预算不得低于整体爬虫预算的15%。这个数字是我用凌晨两点四十的那个告警换来的。