从 403/429、指纹识别、验证码、动态页面和登录会话出发，说明网页采集受限的真实原因，并给出 API 优先、限速退避、增量缓存和合规账号环境的处理思路。
网页采集遇到 403、429、验证码或登录失效时，正确方向不是先轮换 IP、伪装指纹或“模拟真人”。这些信号通常说明请求频率、访问范围、认证方式或自动化行为超出了网站允许的边界。继续规避会让临时限制升级，也可能违反服务条款、合同、版权或数据保护要求。
更稳定的处理思路是：先确认授权与可用接口，再减少请求、做好缓存和退避，最后才使用浏览器自动化处理确实需要渲染或人工登录的页面。验证码应视为暂停信号，而不是需要破解的技术障碍。
先根据现象定位问题
| 现象 | 常见原因 | 合规处理 |
|---|---|---|
| 429 Too Many Requests | 请求过快、并发过高、重复抓取 | 降低速率，读取 Retry-After，指数退避 |
| 403 Forbidden | 未授权路径、策略拦截、会话缺失 | 检查权限、条款、robots.txt 和认证方式 |
| 出现 CAPTCHA | 网站要求人工确认或阻止自动化 | 暂停任务，人工处理或联系站点获取接口 |
| 登录反复失效 | Cookie 过期、多人覆盖会话、身份验证 | 使用官方 OAuth/服务账号，规范会话交接 |
| 页面有内容，脚本拿不到 | JavaScript 渲染、接口异步加载 | 使用官方 API；获准时用浏览器渲染后读取 DOM |
| 选择器突然失效 | DOM 改版、A/B 测试、语言变化 | 用语义定位、结构测试和告警，不硬编码层级 |
| 数据重复或缺失 | 翻页、游标、时区、更新窗口错误 | 建立唯一键、增量水位和重跑机制 |
一次只改一个变量并保留日志。若同时换 IP、User-Agent、账号和解析器，即使偶然成功，也很难判断问题根因。
第一步：确认你有权采集这些数据
开始前回答四个问题：
- 数据是否公开，还是登录后、付费后或仅对特定角色开放？
- 网站是否提供 API、导出、Feed、Webhook 或合作数据接口？
- 服务条款、robots.txt、合同和当地法律是否允许当前用途？
- 数据是否包含个人信息、受版权保护内容或其他敏感字段？
robots.txt 是站点向自动客户端表达允许和禁止路径的标准机制。RFC 9309 规定了 Robots Exclusion Protocol 的语法和匹配方式，同时也明确它不是访问授权。换句话说，robots.txt 允许抓取不等于你获得了复制、处理或商业使用数据的全部权利；被禁止的路径更不应通过其他入口绕过。
企业项目应保留数据来源、访问依据、用途、字段、保留期限和删除机制。能用聚合数据解决问题时，不要收集可识别个人的信息。
第二步：优先选择稳定的数据入口
优先级通常应是：
- 官方 API、Webhook 或数据导出；
- 公开 Feed、Sitemap 或批量文件；
- 获得许可的普通 HTTP 页面；
- 必须渲染 JavaScript 时才使用浏览器自动化；
- 需要人工账号和交互的页面最后处理。
API 往往提供字段定义、分页、速率限制和错误码，维护成本低于解析 UI。网页只是给人看的界面，随时可能改版，不应把它当成稳定数据库。
如果网站没有合适接口，先联系数据所有者说明用途、频率、字段和商业规模。一个明确的数据授权通常比长期对抗限制更便宜。
第三步：解决 429 和 IP 封禁——减少负载，不是隐藏来源
设定速率与并发上限
从单并发和较长间隔开始，观察响应时间与错误率。服务器返回 Retry-After 时按其要求等待；没有时使用指数退避并加入随机抖动，避免多个任务同时重试。
示意策略：
等待时间 = min(上限, 基础时间 × 2^重试次数) + 随机抖动
达到最大重试次数后停止并告警，不要无限循环。
做缓存和增量更新
对同一 URL 设置缓存，使用 ETag、Last-Modified 等条件请求（如果服务支持）。记录最后更新时间或游标，只抓新增和变化内容。全量任务与日常增量任务分开，能显著降低请求量。
识别自己的客户端
合规爬虫应使用稳定、真实的 User-Agent，说明用途并提供联系页面或邮箱。伪装成普通浏览器、频繁更换身份会让站点更难区分善意流量，也增加被阻止的概率。
当某个 IP 被限制，先暂停任务并核对原因。轮换代理继续请求可能被视为规避访问控制，不是修复方案。
第四步：处理指纹识别和行为分析
浏览器指纹会组合 User-Agent、操作系统、语言、时区、分辨率、Canvas、WebGL 等信号。网站还可能分析请求节奏、导航路径和会话行为。OWASP 将 Fingerprinting、Scraping、CAPTCHA Defeat、Credential Stuffing 等列为不同的自动化威胁场景，这解释了网站为什么会综合多种信号判断自动化风险。
对授权任务，目标不是制造大量“像真人”的身份，而是让环境稳定、可解释：
- 同一业务账号使用固定环境和正常认证；
- 浏览器参数与实际地区和设备保持一致；
- 不随机修改指纹来逃避封禁；
- 把采集频率、任务 ID 和负责人写入日志；
- 与站点约定允许的账号数、并发和数据范围。
如果站点仍把已授权任务误判，向对方提供时间、User-Agent、出口地址和请求样例，请求加入白名单或提供专用接口。
第五步：验证码出现时停止自动化
验证码用于确认真人或阻止可疑自动化。不要使用 OCR、打码平台、验证码破解插件或其他服务自动绕过。
正确处理流程是：
- 立即暂停当前账号和任务队列；
- 保存触发前的请求速率、路径和错误日志；
- 由有权限的人员在官方页面完成必要验证；
- 检查是否请求过快、会话过期或访问了不允许的路径；
- 需要长期自动化时联系站点申请 API、服务账号或白名单。
即使人工完成一次验证码，也不表示之后可以无限自动请求。应先修复触发原因。
第六步：登录和账号多登要用正式权限
登录后数据比公开页面更敏感。优先使用 OAuth、服务账号、API Token 或平台官方团队权限，不要让脚本保存个人主密码。
确需浏览器会话时：
- 一个合法业务账号对应一个稳定环境；
- Cookie 加密存储并设置过期与撤销；
- 开启 MFA，自动化不得绕过二次验证；
- 禁止多人同时重置密码或复制 Cookie；
- 记录谁在何时启动了哪个任务；
- 离职、项目结束或权限变化后立即撤销访问。
多账号只适用于你确实拥有或获授权的账号。网站限制一个主体只能有一个账号时，环境隔离不能用来突破该限制。
第七步：让动态页面解析更耐改版
使用语义和稳定属性
优先定位标题、表头、可访问性属性和站点公开的测试标识，避免依赖 div:nth-child(7) 这类脆弱层级。页面刷新后重新读取 DOM，不假设旧节点仍存在。
把抽取和业务逻辑分开
采集层只负责把页面转成结构化字段，校验层检查类型、范围、唯一键和必填项。这样页面改版时只需调整解析器，不会同时破坏后续分析。
建立样本与告警
保存少量合规的 HTML 或结构快照作为测试样本，不保存完整账号页或敏感数据。监测字段缺失率、记录数、重复率和页面标题；异常时停止写入生产数据。
PurpleMark 在授权采集中的合理作用
当团队需要同时维护多个已授权账号、不同客户或不同地区环境时，可以在 PurpleMark 网页版中为每个业务账号建立独立的浏览器环境，把对应的 Cookie、登录后默认打开的页面和正常网络配置一起保存下来。这样下次再打开这个环境，浏览器会直接回到上次的会话和工作页，避免多人共用同一份 Cookie 或反复重新登录。
需要按客户、平台或地区区分账号时，可以使用环境分组把不同业务账号归到不同分组，再通过成员权限、共享与转移指定谁能打开哪个环境。操作日志会记录每个环境在何时、由谁打开或调整，授权采集出现争议时可以快速回溯到具体的账号和负责人。
PurpleMark 帮助团队把“账号、环境、会话和责任”长期管理在一个工作区里，但它不应用来绕过 IP 封禁、验证码、账号数量限制或网站的反自动化控制。先获得权限，再谈自动化。
一套可维护的采集架构
建议把系统拆成五层：
- 调度层：控制频率、并发、任务优先级与暂停；
- 访问层：API、HTTP 或获准浏览器会话；
- 解析层：把响应转成结构化字段；
- 质量层：去重、类型校验、缺失告警和版本记录；
- 治理层：权限、来源、用途、保留期限与删除。
每条记录保留来源 URL、采集时间和解析版本。发现错误时可以定位并重跑，而不是重新抓取整个网站。
常见问题
换代理能解决 IP 封禁吗？
它可能暂时改变出口地址，却没有解决频率、权限或行为问题。为继续访问而轮换代理可能构成规避。应先停止任务、降低请求并联系站点。
可以自动识别验证码吗？
不应。验证码是要求暂停或人工确认的信号。需要持续自动化时，申请 API、服务账号或白名单。
robots.txt 允许就一定能采集吗？
不一定。robots.txt 不是访问授权，还要考虑条款、版权、隐私、合同和数据用途。
指纹浏览器能让采集“不被发现”吗？
不能保证，也不应以逃避检测为目的。它更适合把合法账号会话和团队权限分开管理，减少 Cookie 混用和误操作。
结语
网页采集受限不是单纯的“反爬技术题”。403、429、指纹识别、验证码和多登限制共同指向权限、负载和身份管理。
稳定方案始终是 API 优先、授权明确、请求克制、增量缓存、解析可测试和账号可审计。遇到验证码或封禁就停下来修复流程，而不是继续隐藏自动化来源。
