结论：sublime text 中应匹配 http/1.1 403 forbidden、503 service unavailable 或响应体含 cloudflare、security check、rate limited 的行，结合非贪婪多行正则 ^.?(403|429|503).?(\r?\n.?){0,3}?(cloudflare|check|blocked|rate.?limit|waf|security|captcha) 精准定位反爬拦截。
如何用 Sublime Text 正则匹配反爬拦截响应特征
直接说结论：日志里真正有用的反爬拦截信息，往往藏在 HTTP/1.1 403 Forbidden、HTTP/1.1 503 Service Unavailable 或返回体含 cloudflare、security check、rate limited 的行中——不是所有 4xx/5xx 都是反爬，得结合上下文判断。
Sublime Text 默认用 PCRE（Perl 兼容正则），支持 .*? 非贪婪匹配和多行模式，但不支持 \K 重置匹配起点，所以得靠捕获组 + 手动筛选。
- 先打开日志文件 → Ctrl+H（Windows/Linux）或 Cmd+H（macOS）调出替换面板
- 勾选
Regular Expression（右下角图标）和Match Case（避免误匹配小写forbidden） - 搜索模式建议用：
^.*?(403|429|503).*?(\r?\n.*?){0,3}?(cloudflare|check|blocked|rate.*?limit|waf|security|captcha) - 注意：
(\r?\n.*?){0,3}是为了跨行抓取紧邻的关键词，避免只匹配单行而漏掉HTTP/1.1 403后隔一行才出现cf-ray的情况
为什么不能只搜状态码？常见误匹配场景
单纯搜 403 会把 CDN 缓存失效、源站宕机、甚至测试时故意写的 response.status_code = 403 日志全捞出来——这些和反爬无关。
真正要提取的是「被策略主动拦截」的痕迹，典型信号包括：
- 响应头含
X-Frame-Options: DENY或X-Content-Type-Options: nosniff（多数无关，但配合 403 出现时可能是 WAF 行为） - 响应体 HTML 中含
data-ray、jschl-answer、turnstile等 Cloudflare / Turnstile 特征字段 - 日志中同一 IP 短时间内连续出现
429 Too Many Requests+Retry-After头 - URL 中带
?__cf_chl_f_tk=或&_cfduid=参数（说明已被 Cloudflare 挑战）
提取后如何快速定位真实拦截点
正则只能帮你筛出候选行，最终确认还得看上下文。Sublime Text 里最实用的操作是：
- 用
Ctrl+Click（Windows/Linux）或Cmd+Click（macOS）跳转到该行所在请求的完整 request block（通常以[INFO] GET http://...开头） - 检查该请求是否携带了可疑 header：
User-Agent: python-requests、缺失Accept-Language、Referer为空 - 对比正常请求与拦截请求的
Cookie字段长度差异——很多反爬会校验 session token 有效性 - 如果日志格式支持，用
Ctrl+Shift+P→ 输入Sort Lines对 IP 地址列排序，再手动观察哪些 IP 被集中拦截
容易被忽略的编码与换行问题
爬虫日志常混用 \n 和 \r\n，尤其 Windows 下生成的日志。Sublime Text 默认按当前系统换行符解析，若日志来自 Linux 服务器却在 Windows 上打开，^ 和 $ 可能无法正确锚定行首/行尾。
解决办法：
- 先执行
File → Line Endings → Unix统一换行符 - 正则中显式写
\r?\n替代\n，比如匹配响应头：^HTTP\/1\.1 (403|429|503).*?\r?\n.*?content-type: text\/html - 如果日志含中文或特殊符号，确认右下角状态栏显示编码为
UTF-8，否则[\u4e00-\u9fa5]类 Unicode 范围会失效
真正麻烦的不是写不出正则，而是日志格式不统一——有的记录响应体前加 Response Body: 前缀，有的直接贴 raw HTML，还有的把 JSON 响应压缩成一行。这种时候，宁可多写几条针对性正则，也别强求一条通吃。
