403和429不一定是反爬，需结合响应体特征、响应头（如X-Blocked-By、Retry-After）、Content-Type及httpbin验证请求头透传情况综合判断；伪装200的反爬更隐蔽，需检查HTML内容与Content-Length差异。
看 403 和 429 是不是真反爬，还是网站自己挂了
很多新手一看到 403 Forbidden 就以为被反爬了，其实可能是目标页面权限关闭、路径写错，甚至服务器临时配置错误。真正有反爬逻辑的 403 通常伴随特定响应体特征：比如返回页面含 “拒绝访问”“非法请求”“请使用浏览器打开” 等提示；或响应头里带 X-Blocked-By: WAF、X-Firewall: Cloudflare 这类字段。
429 Too Many Requests 更值得细看——它不等于“IP被封”，而是限流中间件（如 Nginx limit_req、Cloudflare Rate Limiting）触发的明确信号。重点观察：Retry-After 响应头是否存在、值是否为秒级整数；Content-Type 是 text/html（人眼可读拦截页）还是 application/json（API级限流）。
- 若
429出现在首次请求就返回，大概率是 UA 或 Referer 校验失败，而非频率问题 - 若
429在第 5 次请求后稳定出现，且Retry-After: 60，说明后端做了严格窗口计数，不是简单 sleep 能绕过的 - 连续多个不同 IP 都返回相同
429，可能是 token 或 cookie 校验失败，导致所有请求被统一归入“异常会话”
用 httpbin.org/headers 快速验证 UA 和 Referer 是否被校验
别直接拿目标站试错。先用 http://httpbin.org/headers 测基础请求头是否能透传——它原样返回你发的所有 header，不设防，适合做“探针”。关键比对点：
- 发一个空
User-Agent请求，看返回里user-agent字段是不是空或默认值（如python-requests/2.31.0），这说明你的 UA 没传过去或被服务端丢弃 - 加一个伪造 UA（如
"User-Agent": "abc123"），再对比返回值，如果服务端没过滤，说明目标站可能根本不校验 UA 格式 - 手动加
"Referer": "https://google.com"，看是否出现在返回中；如果没出现，说明中间有代理或 CDN 清洗了该字段，后续爬取时硬塞 Referer 可能无效
注意：httpbin.org 不模拟真实反爬行为，但它能帮你确认“你的请求头到底有没有发出去”，这是排查的第一步。
立即学习“Python免费学习笔记（深入）”；
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
响应体内容比状态码更可靠：识别伪装成 200 的反爬
越来越多站点放弃直接返回 4xx，改用“假成功”策略：HTTP 状态码是 200，但 HTML 里塞满验证码 iframe、跳转 JS、或空 div + 加密 script 标签。这时候光看状态码完全失效。
实操建议：
- 用
response.text[:200]快速截取前 200 字符，搜索关键词：geetest、turnstile、verify、location.href、document.write - 检查
response.headers.get("Content-Type")是否为text/html，但实际内容却是 JSON 格式（说明被中间件重写了响应） - 对比正常浏览器访问和脚本请求的
Content-Length：如果脚本返回长度明显偏小（比如只有 1KB，而浏览器是 80KB），基本可以断定内容被拦截或降级
为什么 503 有时比 403 更危险
503 Service Unavailable 表面看是服务端问题，但在反爬体系里，它常被用作“软封禁”出口：WAF 或边缘节点检测到可疑流量后，不返回明确拒绝码，而是故意让后端服务超时或主动返回 503，避免暴露防御逻辑。
典型线索：
- 同一 URL，用 curl -v 直连源站 IP 返回
503，但走 CDN 域名却返回200→ 说明 CDN 层在做行为分析 -
503响应头带Server: cloudflare或X-Cache: HIT，基本可锁定是边缘防护触发 - 请求中携带
Cookie时返回503，去掉 Cookie 后变200→ 很可能在用 Cookie 做设备指纹或会话可信度打分
这种场景下，状态码只是表象，真正要盯的是响应头里的中间件标识、CDN 缓存行为、以及 Cookie 的生命周期变化——它们比数字更诚实。
