某天线上爬虫突然大面积返回 403，第一反应是目标站挂了？结果浏览器访问完全正常，心里咯噔一下——被反爬了。
403 Forbidden 这个状态码，平时见得不比 404 少，但爬虫场景里它通常不是因为真的没权限。多数时候是对方已经认出了你不是人，直接拒掉，甚至懒得给个像样的错误页面。
403 是怎么触发的
触发点其实就那几类，只是每次组合得不一样。
最常见的就是请求头没带对。服务端先扫一眼 User-Agent，如果你用 requests 默认的那个 python-requests/x.x.x 过去，等于举着牌子说“我是脚本”。
有些站还会查 Referer，直接从空白页跳过去的请求大概率被拦。另外 Cookie 或登录态缺失，也会被当成未授权直接返回 403。
紧接着就是 IP 的事。
同一个 IP 短时间内反复请求，哪怕 UA 完美，行为上也不像真人。这时候要么被暂时 ban 掉，要么直接弹验证码。行为分析更隐蔽一点，比如两次请求间隔太固定、页面停留时间几乎为零，或者总是在抓取那些普通用户根本不会点的深层链接。后台风控模型一旦判定异常，403 就来了。
还有一些情况不是反爬，而是真·权限或协议问题。
比如网站强制 HTTPS，你用了 HTTP 去连；或者需要客户端证书，你没配；又或者服务器目录权限本身就配错了。这类虽然少，但排查时如果一直盯着爬虫伪装使劲，就容易绕进去。
从最简单的开始改
我现在的习惯是，不管什么站，先无脑补一套请求头。
User-Agent 直接用 Chrome 最新版的标识，Referer 顺手设成目标站首页，有时候加个 Accept-Language。这么一改，至少有三分之一原本 403 的站能直接通。
用 requests 的话，别忘了 catch 一下状态码。response.raise_for_status() 如果爆了，可以在 except 里针对 403 做下一步处理，而不是直接抛异常退出。这个点很小，但线上跑起来很方便做自动重试和降级。
UA 搞不定就上代理
请求头没问题的前提下还 403，八九成是 IP 被盯上了。这时候就得上代理池。
代理的作用不是让请求变慢，而是把真实 IP 藏起来，同时轮换 IP 让服务端没法持续追踪同一个来源。
免费代理我踩过的坑比爬的数据还多——要么自己先 403，要么响应慢到超时。
后面稳定跑的基本都是付费池，或者自己搭一批云服务器做中转。轮换策略上，别等到被封了才换，那种按请求量或时间的主动轮换，存活率高很多。
频率这件事比想象中容易忽略
很多人加了代理池之后，觉得 IP 一直在变，就放开跑了。结果反而触发得更快。因为真实用户不可能一秒点十个页面，哪怕每次 IP 不一样，行为特征太集中也会被行为分析模型盯上。
所以 time.sleep 还是有必要的，但别死睡 5 秒。最好在一个区间里随机，比如 2 到 8 秒，每次间隔都不一样。
如果量实在大，就把并发调低，把请求线拉长，用时间换稳定。
实在不行就“开浏览器”
有些站，尤其是 SPA 或者反爬严、前端逻辑重的，单靠 requests 怎么都绕不过去。
这时候就该 Selenium 出场了。直接起一个 headless Chrome，该点哪里点哪里，滚动、等待渲染，就跟真人操作差不多。代价是资源开销大，速度慢，不太适合海量采集。
如果只是想拿渲染后的 HTML，量又不算特别大，我有时候会把请求丢给 Splash 服务，让它执行完 JS 再把 DOM 吐回来。设个 render 等待时间，确保异步内容出来，比单纯抓接口要省心不少。
不过 Splash 本身维护和部署也得花精力，得看值不值。
一些预防措施
排查和解决的事说完了，但长期跑爬虫，不能每次都等 403 爆了才动。
我是会在爬虫启动前扫一眼 robots.txt，起码知道哪些路径不让爬。虽然遵守它不是万能的，但故意违反被禁了也没什么好说的。
请求日志得开着，别关。一旦发现某个域名批量 403，马上能定位到是请求头、IP 还是频率的问题。定时检查代理池的可用率，剔除那些已经进黑名单的 IP。
这些杂活做在前面，能省掉很多半夜被报警吵醒的瞬间。
爬虫策略也经常要微调。
比如目标站改了页面结构，原来抓内页的 URL 变了，爬虫还在猛请求旧地址，返回 403 或 404，监控不到位就是白忙。这种时候稍微调整一下提取逻辑，就能避免无效请求堆积。
用户申请SSL证书时，lcjmSSL平台能够提供一站式解决方案，从证书申请到部署、管理和续期，都能够自动化完成。对于需要长期管理证书的企业来说，自动化的服务大大降低了管理的复杂性。
线上长期跑下来，403 几乎不可能完全杜绝，但只要排查链条清晰，从请求头、IP、频率到浏览器模拟这一路试下来，基本都能打开局面。
剩下的无非就是维护和迭代的事儿了。