冰川思想库“你的用户，可能根本不是人”，这句话我第一次认真对待，是在某个活动大促之后的复盘会上。我们连夜盯着数据看板，发现从凌晨三点到早上六点，有一个“用户群体”的访问量大得离谱，点击路径完美得像是照着产品手册走了一遍，但转化率是零，注册量是零，连页面滚动深度都惊人地一致。当时我就意识到，盯着这块看板的我们，和这些“用户”之间，有一方肯定是机器。
这不是什么都市传说，而是每一个网站、App、小程序运营者早晚都会撞上的现实。所谓的“非人用户”，指的就是爬虫、脚本机器人、僵尸网络、刷量程序这类自动化流量。它们会消耗你的服务器资源，污染你的数据报表，薅走你的优惠券，甚至把你的整站内容搬走。这篇文章，我就想把这些年识别、分析、对抗这些“假用户”的经验整理出来，从怎么认出来，到怎么处置，再到怎么避免误杀真用户，一次性讲透。内容主要面向做产品、做运营、做数据分析的朋友，后端开发也能在其中找到可以直接落地的思路。
1. 流量里的“幽灵”：这些非人用户到底从哪来
1.1 爬虫不只有搜索引擎那一类
很多人一说爬虫，第一反应是搜索引擎的蜘蛛。像百度蜘蛛、谷歌的Googlebot，它们日夜不停地在互联网上抓取内容，这是整个搜索生态正常运转的基础。绝大多数网站对这类搜索引擎爬虫是持欢迎态度的，因为它决定了你的站点能不能被别人搜到。
但问题是，爬虫这个物种远远不止搜索引擎蜘蛛这一种。
我见过大量的恶意爬虫，它们的目标通常是这几类：
- 内容搬运：把你的原创文章、商品详情、图片视频批量抓走，然后搬到别的站点，直接做个“镜像站”来抢你的流量。
- 价格监控：电商平台的竞争对手用爬虫实时抓你的价格和库存，然后动态调价，让你在价格战里永远被动。
- 票务与库存抢购：演唱会门票、限量球鞋、补贴券，机器脚本比人手快得多，普通人还在加载页面的时候，机器已经把库存清空了。
- 数据收集：批量抓取用户公开信息、企业信息，整合成所谓的“大数据产品”去卖。
- AI训练数据采集：这两年特别突出，一些大模型公司需要海量语料，会派出专门的爬虫（比如常见的GPTBot、ClaudeBot等）抓取开放网页内容。
如果你发现公司的接口请求量比平时翻了好几倍，但业务量纹丝不动，那就要警惕，可能已经被某个团队盯上了。
1.2 机器流量占比远比想象中庞大
根据一些第三方安全机构和云厂商发布的数据，全球互联网流量里，机器人流量长期在四成到五成之间徘徊，其中还有相当比例是恶意机器人。这意味着你的网站每收到10个请求，可能有4个根本不是人发出来的。
这不是危言耸听。我自己维护过一个小型的行业资讯站点，日活用户只有几千人，但服务器日志里显示的请求量是真实用户请求量的七八倍。扒开日志一看，绝大部分是各种爬虫，有来抓文章的，有来扫漏洞的，有来测你后台地址的，还有纯粹乱逛的。
所以说，流量数据里的“水分”是常态。如果不把这些非人用户识别出来，你看KPI、看留存、看转化，本质上是在给机器人做报表分析。
1.3 为什么“假用户”的生意经久不衰
有人可能会问，为什么会有这么多机器人？核心原因就三个字：有利益。
薅羊毛是利益。某平台发了一张满199减100的券，脚本就可以批量注册新号来领券，转手低价卖掉。刷量也是利益。内容平台的阅读量、电商的销量、短视频的点赞，都是可以直接或间接变现的资产。就连最简单的撞库攻击，背后也是利益链——拿着在其他平台泄露的账号密码，批量试探你平台的账号，能登进去就是一套新数据。
要理解对抗非人用户这件事，必须先理解对手的动机。他们不是闲得无聊，他们是在用程序化手段降低成本、放大收益。而我们要做的，就是提高他们做这件事的成本，让收益变小。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 一个“非人用户”的完整画像：我是怎么认出来的
2.1 先从访问日志里看端倪
要识别非人用户，第一步永远是从最原始的访问日志看起，而不是看各种可视化报表，因为报表已经做过聚合处理，很多细节被抹掉了。
我自己看日志的习惯，是重点盯三个维度：用户代理（UA）、访问频次、访问路径。
先看UA。正常浏览器的UA长这样：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ... Chrome/120.0.0.0 Safari/537.36，里面有操作系统、浏览器内核、内核版本这些信息。而一些脚本爬虫的UA要么是空的，要么是简单的Python-requests/2.31.0，要么是伪造得半真半假。伪造UA是一个猫鼠游戏：你去封一个UA，对方换一个，看起来是主流浏览器的UA，但一配上其他特征就露馅了。
再说访问频次。在日志里看单IP的请求频率，正常用户一个会话内发几十个请求很正常，但一个IP在一秒钟内发出几十个请求，那就基本不可能是人手点的。我见过最夸张的，一个IP在2小时内请求了6万多次，平均每秒将近9次请求，摆明了是脚本在跑。
最后看访问路径。真实用户访问网站是有“人的行为”的，会回退、会停留、会跳转，路径发散且无序。而爬虫，尤其是去抓结构页面的爬虫，路径规律性极强——按ID递增依次访问文章页，或者按照Sitemap的排列顺序挨个抓取。你只要在日志里看到访问序列是/article/1、/article/2、/article/3，心里就该有数了。
2.2 注册与业务层的机器人痕迹
访问日志是第一步，等到机器人开始深入到注册、登录、下单这类业务环节时，特征会变得更明显。
在业务层，我总结了几类典型的机器人痕迹：
- 账号ID生成太规律。比如批量注册的账号，用户名通常是
user_20250101_001、user_20250101_002这种顺序号，因为脚本生成账号时懒得做随机化。 - 设备指纹缺失或不一致。正常用户的浏览器能稳定地提供Canvas指纹、WebGL渲染结果、字体列表等信息。而很多自动化脚本（尤其是不开真实浏览器的）根本拿不到这些数据，或者每次拿到的结果都不一样。
- 操作时间不合理。注册填表、阅读协议、输入密码，每一步都需要时间。机器人可以把整个注册流程压缩到几百毫秒完成，而人手再快也要两三秒，更不用说还要算上阅读和理解的时间。
- 行为轨迹过于“直线”。真实用户用鼠标点击，会留下弧线轨迹、有加速和减速。自动化工具的点击通常是瞬间从坐标A跳到坐标B，中间没有任何曲线。
2.3 一个我实际做过的识别案例
有一年我们运营一个抽奖活动，规则是每个账号每天可以抽三次，活动奖品价值不低。活动上线的第二天，运营同事就发现异常——中奖名单里出现了大量ID格式高度相似的账号，而且这些账号的注册时间集中在前一天晚上的几分钟之内。
我们把日志拉出来，做了三件事：
- 按注册时间排序，发现这些账号的注册间隔非常均匀，基本是1.2秒到1.5秒一个，像是生产线上的零件。
- 查这些账号的注册IP，发现来自同一个C段，也就是在同一个IP地址段内。
- 再看这些号的活动行为，抽取次数几乎都是标准的每天3次，一次不多一次不少，而且抽取的时间点是整点之后几分钟内。
这三条一叠加，结论就很清楚了——是脚本在批量注册账号参加抽奖，规避了每人三次的限制，把中奖概率人为拉高了。后来我们把抽奖条件改成需要绑定手机号并完成一笔小额支付验真，这批“用户”就消失了大半。
3. 识别bot的四板斧：从入门到进阶
3.1 基础层：UA识别与IP信誉库
最基础的识别手段，就是做UA过滤和IP信誉库。
UA过滤很好理解：维护一个已知爬虫UA的黑名单，命中就直接拦截或者标记。这个黑名单不需要自己从零积累，很多开源项目现成就能用，比如常见的php-user-agent、bot list这类库，也可以定期从一些社区维护的列表同步。
IP信誉库则要复杂一些，主要分两块：一块是恶意IP黑名单，另一块是IDC机房IP段列表。很多云厂商的IP段是公开信息，像阿里云、腾讯云、AWS都有对应的IP范围文件，而正常家庭用户不太可能从这些IP段发访问请求。所以，如果看到一个IP来自某云厂商的机房，又在短时间发起大量请求，基本可以判定是有问题的。
不过这套方案现在顶多算“基础中的基础”，因为对抗它的成本太低了。稍微专业的操作者会用代理池，每次请求换一个IP，UA也是随机伪造的，单纯靠UA和IP已经很难识别。
3.2 中间层：行为分析与频率控制
UA和IP识别不了的时候，就要上行为分析了。行为分析的核心思想是：不看你“是谁”，而看你“怎么做”，人和机器的行为模式差异是很难完全隐藏的。
在Web端，可采集的行为信号非常多：
- 鼠标移动轨迹：人手的移动有惯性、有抖动，机器移动是直线。
- 键盘敲击节奏：人打字有快有慢，间隔不均匀，机器输入间隔几乎恒定。
- 页面停留时间：正常人看一篇文章再怎么快也要几十秒，脚本可能瞬间滚到底。
- 触屏手势：移动端上，人的滑动手势有加速度变化，机器往往匀速。
在服务端，做频率控制则更加直接有效。比较常用的是基于滑动窗口的限流算法。举个例子，可以规定每个IP在1分钟内的最大请求数是60次，超过的就触发验证码或暂时封禁。但要注意，确定这个阈值不能拍脑袋，要根据业务形态慢慢调。我见过一个教程型的网站，用户可能一下子打开很多篇文章图片，每篇文章要加载十来个图片资源，这时候频率阈值定太低，就会误伤正常使用。
3.3 进阶层：浏览器指纹与验证码
行为分析再往上，是浏览器指纹技术。
浏览器指纹的原理是利用浏览器在渲染网页时暴露出来的各种环境信息，组合成一个高熵值的标识。常见的维度包括Canvas指纹（浏览器绘制同一张图，不同显卡、不同驱动绘制出的像素会有细微差异）、WebGL相关信息、系统字体列表、屏幕分辨率、时区、语言等等。把这些信息拼在一起，得到的指纹值，在普通人之间是有区分度的，而对一个集中的脚本攻击来说，它们的指纹高度一致，一抓一个准。
指纹识别本身只解决“认出它们”的问题，真正拦住它们还得靠验证码。验证码这几年的演进路径很明显：从最初的图形数字验证码，到滑块验证码，再到滑动拼图、点选文字、无感验证。
这里有一个我个人的实操建议：别一上来就上最复杂的验证码，体验成本太高了。建议按风险分层来：
| 风险等级 | 触发条件 | 应对策略 |
|---|---|---|
| 低风险 | 正常行为，无异常特征 | 不打扰，直接放行 |
| 中风险 | 行为特征可疑，频率偏高 | 出滑块验证码验证一下 |
| 高风险 | 命中IP黑名单、指纹异常等 | 强制二次验证并限流 |
这样既不给普通用户添堵，又能把大部分机器人拦在门外。
3.4 灵活策略层：蜜罐与JS挑战
除了上面三板斧，还有一些更灵活的对抗手法，我试用过之后觉得效果也不错。
蜜罐（Honeypot）的做法很巧妙。在你的表单或页面上，埋一个真实用户看不见、但机器人会去填的隐藏字段。比如注册表单里放一个CSS隐藏的输入框<input name="website" style="display:none">，正常用户根本看不到这个框，自然不会填；而机器人脚本在自动填表的时候，会把页面上所有可填写的字段都填一遍，这样你就能非常确定地给这个请求打上“机器人”标签。这个方案的误判率极低，因为触发的几乎都是非人行为。
JS挑战是另一种思路。它的实现方式是：服务器先返回一个带有特定脚本的页面，正常浏览器会自动执行这个脚本、计算出正确的token，然后再带着token去请求真正的资源；而普通的HTTP客户端（比如没有执行JS能力的爬虫脚本）无法完成这步计算，自然拿不到数据。这个方案对服务器资源消耗也不高，还可以用Proof-of-Work的思路，要求客户端先做一个有一定计算量的运算再放行，人为提高爬虫的抓取成本。
4. 从识别到应对：一套可落地的处置流程
4.1 先分层策略，再动手拦截
识别的最终目的是处置，但处置千万不能不分青红皂白一刀切。我的习惯是先把爬虫分成善意和恶意两大类，再分别制定政策。
善意爬虫（搜索引擎蜘蛛、监控大站连通性的可用性探测），应该直接放行，甚至要主动告诉他们“欢迎来抓”。因为这些爬虫的UA明确，抓取频率也遵守robots协议，对服务器的压力有限，还能给站点带来搜索流量。
可容忍爬虫（友好但频率高的），比如一些行业数据聚合商，可以先限流，把请求速度压到对服务器无害的水平，然后观察它对服务器资源的占用。这类如果影响不大，也可以放行。
恶意爬虫（内容搬运、扫描攻击、薅羊毛脚本），要坚决阻断。阻断的手段可以组合上：接口层面做签名校验、关键路径上验证码、频率控制、封禁IP或IP段。
4.2 别让假流量弄脏了数据分析
处理这些非人用户，不光是运维和开发的事，数据分析那边也得跟着调整。如果你不做任何过滤，报表里的PV、UV、停留时长、页面深度全是假的，基于这些数据做的任何决策都很危险。
我在实践中摸索出了一套相对可靠的“洗数据”流程：
- 在日志采集层就打标记。Nginx日志或前端埋点数据里，凡是命中爬虫规则（UA命中、频率异常、蜜罐触发）的请求，统一打上
is_bot=1的标签。 - 数据分析工具层配置过滤。像Google Analytics、友盟、神策这类分析工具，都支持自定义过滤条件和爬虫过滤规则，主动配置好。
- 关键指标要准备“纯净版”和“含bot版”两套口径。对公司管理层汇报业务数据时用纯净版，做容量规划和成本评估时参考含bot版，因为服务器成本确实是被真实流量和bot一起撑起来的。
- 定期抽检。每隔一段时间，从日志里重新做一次人机分类，看看误判率和漏判率，及时调整规则。
4.3 拦截过程中我踩过的坑
和机器人对抗了这么多年，大大小小的坑踩过不少，有几个特别值得单独拿出来说。
第一个坑是误杀真用户。有一次我们为了提高注册转化率，限制了一个IP只能注册3个账号。结果有家做地推的代理公司，他们整个办公室都走同一个公网IP出口，一天下来40多个人注册，把后注册的全挡在外面了。后来我们把限制维度从IP改成设备指纹，这个问题才解决。这件事给我的教训是：单维度限制永远有漏洞，要么误杀，要么漏杀，尽量多维交叉判断。
第二个坑是验证码滥用。有一段时间我们防薅羊毛防得比较狠，所有登录都要求过滑块验证，结果后台收到大量用户投诉，说登录不上去。原因是那批用户在用老版本的浏览器，样式兼容性有问题，滑块组件根本渲染不出来。验证码这类反机器人手段，一定得先做好兼容性测试。
第三个坑是性能开销。有一些开源的指纹采集方案，在页面里嵌入了大量的指纹采集JS，导致页面加载时间多了近一秒钟，对移动端用户尤其不友好。后来我们把采集逻辑改成异步加载，并且只在高风险场景时才动态加载指纹采集脚本，页面性能才恢复正常。
5. 常见问题与排查技巧实录
5.1 遇到这几类“假用户”，别急着下结论
在实际对抗过程中，有几类情况很容易误判，我把它们列出来，方便你排查时对号入座：
- 内网监控或外部门禁系统：这类系统UA特征不明显，而且访问路径非常规律，容易被误判成爬虫。
- 预加载与浏览器扩展：很多浏览器会在后台预加载链接，比如笔者的Chrome装了“鼠标悬停预读”插件，会在你鼠标悬停到某个链接上时预先请求内容。这类请求没有鼠标轨迹之外的额外特征。
- 用户自己电脑中了木马：受害者的浏览器会周期性发出请求，行为模式和正常用户有差异，但这种情况下你不能直接封IP，否则会把一个无辜用户永久挡在门外。
- 第三方支付/短信服务商回调：它们的回调接口路径固定，频率也会有一定的周期性，容易触发频率限制，但它们是业务的关键链路，必须加白名单。
5.2 实用工具与排查工作流
工欲善其事，必先利其器。这些工具我实测下来比较靠谱：
- 流量分析：GoAccess（轻量级、直接解析Nginx日志）、Matomo（开源、支持识别主流爬虫）。
- 反爬网关：Cloudflare Bot Management（功能最全，能区分AI爬虫、搜索蜘蛛、恶意bot）、阿里云WAF（国内访问速度好，入门门槛低）。
- 自研识别：用轻量级的规则引擎，比如OpenResty结合Lua脚本做Nginx层的实时UA/IP判断，或者用Redis存滑动窗口计数实现限流。
- 开源指纹库：FingerprintJS（浏览器指纹采集开源库，成熟度高）。
我个人的排查工作流通常是这样的：先通过日志分析工具（GoAccess或者自写脚本）找出异常流量的IP和UA集合，再把它们导入到规则引擎里实时打标，接着用行为分析和指纹采集对可疑流量做二次确认，最后对确认的恶意流量分层处置——封禁、验证码、限流三选一。整个过程最好是半自动化的，定期人工介入检查规则有没有失效。
5.3 一个高性价比的起步方案
如果你是一个中小规模站点的负责人，团队里没有专职的安全工程师，我建议你按下面这个最小可行方案起步，不需要一上来就搭很重的系统：
- 第一周：先给日志采集加上UA识别和IP黑名单，把明显的善意爬虫和恶意爬虫分开统计。
- 第二周：在关键路径上加上频率限制，注册、登录、搜索、下单这四类接口是重灾区，优先保护。
- 第三周：接入一个第三方的验证码服务，把中高风险验证的流程跑通。
- 第四周：回头分析第一周以来的日志，把误判和漏判的案例整理出来，微调规则。
这个方案大概只需要一个懂点后端和运维的同事投入一半精力，一两周就能看到明显效果。
最后分享一点我的体会
跟非人用户打了这么多年交道，我最大的感受是：你不可能一次性把它们彻底消灭，它们的技术也在迭代，今天还在扫UA，明天就上了无头浏览器，后天直接把模型接到真实浏览器内核上模拟人手操作。识别和对抗，更准确地说是一场持续的博弈。保持对数据的敏感度，定期从日志里看看有没有新的异常模式，比装任何一套固定的“反爬系统”都管用。
还有一个小技巧，是最近做AI产品时发现的：现在很多AI厂商推出的大模型爬虫，都会在各自的官方文档里公布自己的UA和IP段。与其费力去猜，不如直接去官方文档把它们拉进名单。但也别急着全封，如果你的内容确实希望被AI搜索引用，可以有针对性地放行并设置抓取频率上限。把未知的威胁变成可控的合作，这才是面对技术演进时，一个更从容的姿态。