🔖爬虫

打码平台在逆向工程里的位置不是所有验证码都值得自己逆。打码平台（人工+AI 混合识别服务）的价值场景：验证码出现频率低（自建识别不划算）题型复杂多变（语序、推理题，自训模型搞不定）快速验证阶段（先跑通流程，再决定是否自建）把它当成一个"识别能力的外包 API"，工程上要做的是标准化对接 + 稳定性兜底。主流平台与协议对接各平台协议大同小异，都是"上传图片 → 返回答案"的两步或一步到位：import requests, base64, time class DamaClient: # 通用打码客户端骨架（以典型协议为例） def __init__(self, platform

参数全对为什么还是被封很多逆向工程师卡在同一个困惑：签名算法完美还原、设备指纹成套伪装、IP 也是住宅代理——请求还是触发风控。问题出在行为序列：风控不只校验单个请求合不合法，更分析请求序列像不像人。这是行为风控的核心：单点校验防的是"假请求"，序列分析防的是"机器人"。风控在看什么：行为序列的特征维度时间维度：请求间隔分布：真人是长尾分布（快 1s 慢几分钟），机器是正态/均匀分布 操作时段：真人有作息（深夜低频），机器 24 小时均匀 会话节奏：真人"浏览-停顿-操作"，机器"请求-请求-请求"路径维度：页面跳转路径：真人 首页→列表→详情→(返回)

IP 是协议模拟的半壁江山签名算法逆得再完美，单 IP 高频请求照样被封。代理池是规模化的基础设施，但代理类型选错，钱花了一倍效果打对折。先把三种主流代理的本质搞清楚。三种代理的本质差异1. 数据中心代理（机房 IP）来源：阿里云/AWS 等机房 IP 段特点：便宜（几毛钱/个）、快、稳定致命伤：IP 段公开可查，风控直接按 ASN/段封——电商、社交类站点基本秒识别适用：防护弱的站点、对 IP 质量不敏感的业务2. 短效代理（动态转发）模式：给你一个固定入口，后端 IP 池自动轮换（每分钟/每请求换 IP）特点：IP 量大（百万级池子），按量计费坑：IP 质量混杂（机房+住宅混合），且每次请

TLS 指纹之后还有 H2 指纹过了 JA3 检测却被更隐蔽的指纹拦下——问题可能出在 HTTP/2 层。现代网站 90%+ 走 HTTP/2，而 H2 连接的建立过程同样暴露客户端实现：SETTINGS 帧：参数集合和值（HEADER_TABLE_SIZE、INITIAL_WINDOW_SIZE 等）WINDOW_UPDATE 帧：窗口增量的数值HEADERS 帧：伪头顺序（:method :path :authority :scheme 还是别的排列）优先级策略：PRIORITY 帧的使用模式这些全部由 HTTP/2 库的实现决定——Chrome 的 netstack、nghttp2（cu

curl_cffi 为什么是当前的最优解Python 爬虫的 TLS 指纹伪装方案演进：requests（无伪装）→ pyhttpx/tls-client（半吊子）→ curl_cffi（完整方案）。curl_cffi 胜出的原因：基于 curl-impersonate，TLS 指纹逐字节级复刻（不只是 JA3，整个 ClientHello 的字节序都对）HTTP/2 指纹同步模拟（SETTINGS 帧、优先级、窗口更新全对齐浏览器）API 兼容 requests，迁移成本几乎为零pip install curl_cffi基础用法：和 requests 几乎一样from curl_cffi i