上个月一个做二类电商的朋友跑过来找我，说新账户刚充了2万，跑了两天就被百度风控盯上了。账户后台显示异常流量，页面还没过审就收到了警告信。他问我，不是说好了做AB页跳转吗，怎么还会被封？
我问了他一句：你的跳转，是不是什么流量都直接甩到推广页？他愣了一下，说不然呢？不跳转的话，审核那关怎么过？
问题就出在这。AB页跳转本质上是一个筛选器，它的核心任务不是“跳转”，而是“区分”。你要区分出哪些是审核人员，哪些是真实用户，然后只对真实用户跳转。如果见人就跳，那和裸奔没什么区别。这篇就讲清楚，AB页跳转怎么防检测，具体怎么配置才靠谱。
防检测的逻辑：先搞清楚对方在看什么
百度或者Google的审核系统，检测一条跳转链接的时候，主要看这几个维度：请求头里的User-Agent、来源IP段、Cookie记录、浏览器指纹、行为特征。它们会根据这些信息判断“你是一个普通浏览者还是带着任务来的审核员”。
防检测做的就是反方向的事：通过配置，让审核流量看到的永远是白页，让真实用户看到的才是推广页。下面这8个配置项是我用了快3年总结出来的，缺一个都有可能出事。
第一个配置：User-Agent过滤必须做细
UA是最基本的判断维度，但很多人做得太粗糙。常见错误是只拦Baiduspider，别的不管。实际上审核人员用的UA和搜索引擎爬虫完全不是一个东西。百度那边的人工审核，UA通常是一个完整的Chrome或者Windows浏览器UA，但会带上百度内部的标识字段。Google那边更复杂，不能只靠UA判断。
我的做法是把所有UA都拿来跟数据库比对，百度的爬虫UA、客户端UA、移动端UA分别建列表。比如Baiduspider的UA是"Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)"，这个必须放在白名单里放行。但审核用的UA往往是"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"这种，这看起来和真实用户一样，所以不能只看UA，必须配合其他配置。
一个实用的做法是维护一个黑名单UA列表，把你在后台日志里看到的可疑UA全部加进去。特别是那些访问频率异常、深夜时段集中出现的UA，基本可以判断是扫描工具。这个列表每周更新一次，别嫌麻烦，检测方也在换。
第二个配置：IP段拦截要分三类做
IP过滤是降低风险最直接的手段，但怎么做非常关键。我一般把IP分为三类：白名单IP、黑名单IP、灰名单IP。白名单是正常用户的IP段，放行跳转；黑名单是搜索引擎机房和审核机构的IP段，直接给白页；灰名单是数据中心IP、代理IP、机房IP，给一个安全提示页，不跳转，也不完全拒绝。
具体配置的时候，百度spider的IP段是公开的，定期从百度站长平台拉取，然后对接到你的跳转规则里。Google的Googlebot IP段同样有公开列表。这些属于爬虫IP，必须放行让它们看到白页。但审核人员的IP很难通过公开渠道拿到，只能靠积累。我自己的做法是，每次后台发现有异常的访问记录，就把IP段记录下来，归类到黑名单里。
还要注意CDN的IP。如果用了Cloudflare或者国内CDN，审核方看到的是CDN节点的IP，这时候IP段判断就失灵了。所以用CDN的情况下，需要多配置一个HTTP头字段来传递真实IP，比如CF-Connecting-IP或者X-Real-IP，然后基于这个真实IP做段位判断。很多人的跳转配置在CDN环境下失效，就是因为忘了这一层。
第三个配置：Cookie验证的两种用法
Cookie验证是防检测里性价比最高的一招。原理很简单：当访客第一次访问落地页时，服务器种下一个标识Cookie，同时展示白页。如果这个访客是真实用户，正常情况下他会继续浏览或点击，带着Cookie再次发起请求。如果他是审核系统里的机器人或人工审核员，大概率不会保留Cookie，或者说Cookie在无头浏览器里根本不会被持久化。
具体配置上，你可以设置一个60秒的Cookie观察期。第一次访问种Cookie给白页，第二次访问如果带上了正确的Cookie值，就执行跳转。第三方Cookie在2024年之后很多浏览器开始限制，所以尽量用第一方Cookie。种Cookie的时候把HttpOnly和Secure属性都打开，避免被JS读取到，也避免通过HTTP明文传输。
还有一个小技巧：Cookie的过期时间不要设太长。我一般设30分钟，超过30分钟重新种一次。这样做的目的是防采集工具，它们每次都是新的会话，永远凑不齐有效的Cookie组合。
第四个配置：设备指纹不能只用一个维度
设备指纹这块，很多跳转配置做得太简单，只采集Canvas指纹或者WebGL指纹，然后跟黑名单对比。其实审核人员的浏览器指纹和真实用户高度重合，单纯比对指纹库是防不住的，因为对方用的就是普通Chrome加普通Windows。
真正有价值的是指纹的组合校验。我自己的配置里同时采集Canvas、WebGL渲染器信息、屏幕分辨率、系统字体列表、时区、语言、CPU核心数、内存大小、触控点数量，然后用一个哈希算法生成指纹ID。这个指纹ID和Cookie绑定，只要指纹ID和Cookie对不上，就判定为可疑流量，不给跳转。这样做的好处是，即使对方用无头浏览器模拟了UA，也能从Canvas渲染结果、WebGL参数这些难模拟的维度发现异常。
配置的时候要注意，不要一上来就拦截所有指纹不一致的流量。建议先把指纹数据存下来，观察一周，看哪些维度的变化频率高，哪些维度稳定。然后只针对稳定维度做校验规则，这样误伤率会低很多。
第五个配置：行为检测的“度”要拿捏准
行为检测在AB页跳转防检测里一直有争议。有人说没用，有人说很灵。我的实际感受是，行为检测适合做辅助判断，不适合做主判断。你可以在页面里埋一段JS，统计鼠标移动轨迹、滚动深度、停留时长、点击事件。真实用户一定会移动鼠标、滚动页面、停顿思考，但审核机器人通常直接抓取HTML源码，根本不会触发这些事件。
具体配置上，我建议设置一个阈值：页面加载后3秒内没有任何鼠标移动或滚轮事件，并且直接发起了跳转请求，那这个流量大概率不是真人。这种流量直接送到白页。另一种情况是，页面加载不到1秒就请求跳转，这种也是典型的自动化行为。
但需要注意，行为检测的阈值不要调得太激进。有些真实用户打开页面后切到别的标签页，回头再操作，也可能触发拦截。所以遇到不确定的流量，宁可给白页也不要给推广页——安全永远是第一位的。
第六个配置：降级策略是保命用的
不管前面配置得多精细，总有判断不出结果的时候。比如一个IP没见过、UA是全新的Chrome、Cookie存在、指纹ID匹配，但各种参数组合出来非常可疑。这种情况下，硬要给一个跳转结果，风险很大。我一般配置三段降级策略。
第一段：高置信度，正常跳转。第二段：中置信度，给一个干扰页，页面内容和推广页相近但完全合规，等用户再次点击时重新评估。第三段：低置信度，直接给白页，不做任何跳转。这里的关键是，降级策略必须在服务端完成，不要在前端写setTimeout跳转，因为审核方可以直接从JS源码里看到跳转逻辑。
另外，降级策略要设置一个频率上限。同一个IP或者同一个指纹ID，如果一天内触发跳转超过3次，就直接把它拉进黑名单。很多封号就是因为跳转次数太频繁，被系统判定为恶意推广行为。
第七个配置：规则更新不能靠手动
百度每周都会调整爬虫UA和IP段，Google的规则变动更频繁。如果你还在手动更新UA列表或者IP段黑名单，肯定跟不上。我搭了一个自动更新机制，每15分钟从百度站长平台和Google Search Console拉取最新的爬虫UA列表和IP段列表，然后动态覆盖到跳转规则里。
UCloud或者阿里云的DDoS防护通常也有现成的IP信誉库接口，可以对接过来用。把那些信誉分低的IP段直接合并到黑名单里。同时，我每天会跑一次日志分析，把当天访问过白页但特征明显异常的IP加入高可疑名单。这个名单第二天自动生效，不需要人工干预。
规则更新这事，最大的坑是旧规则缓存。配置改了，但CDN节点上还是旧规则，导致部分流量走了错误的判断路径。所以每次更新规则后，记得手动刷新一下CDN缓存，不然白改。
第八个配置：日志记录必须留全
日志是防检测配置里最容易被忽略的一环。很多人在排查问题的时候，翻日志发现关键字段没记录，u_id没有、IP段没有、Cookie状态没有、指纹ID没有，根本没法定位问题。我建议每一笔跳转请求都记录：
- 完整UA字符串
- 来源IP和ASN号
- 是否命中UA黑名单
- 是否命中IP黑名单
- Cookie是否存在、是否有效
- 指纹ID和置信度得分
- 行为检测结果
- 降级策略决策原因
这些日志至少要保留30天。因为百度或者Google封号之后，你去申诉的时候需要提交访问记录。如果你拿不出完整的日志，申诉基本没戏。我自己的习惯是日志同时备份到本地和对象存储，双重保险。
场景一：百度竞价投放的防检测配置
今年年初，帮一个做保健品的朋友配置百度竞价的AB页跳转。他之前被封了3个账户，后来我接手的时候发现他的跳转配置有个致命问题：所有的判断逻辑全放在前端，后端完全不参与。
那等于把跳转规则直接暴露在HTML源码里。审核方一看就知道这是个AB页，直接标记风险。我帮他全部改成服务端判断，前端只留一段统一的统计代码。然后按上面说的8个配置项逐一落地，重点做了UA过滤和IP段拦截，因为百度的人工审核会从北京和深圳的几个固定IP段发起访问，这些IP段需要单独拉黑。
另外我特别加了一层处理，百度竞价的后台会有一个“页面审核”功能，审核时会模拟蜘蛛访问。但这个访问并不完全等同于百度爬虫，它可能带着Baiduspider的UA，但来自百度内部的审核服务器。所以单纯判断UA没有用，我得把百度的IP段区分出来，如果IP段属于百度官方审核服务器且UA是Baiduspider，给白页但记录一次异常；如果IP段是真实用户的运营商IP，哪怕UA是Baiduspider，也正常展示白页。这套逻辑上线之后，账户稳定运营了3个月，中间没有收到过任何风控警告。
场景二：Google Ads外贸站的跳转防检测
Google的审核比百度严格得多，特别是对跳转行为的检测。年初有个做机械设备外贸的客户，投Google Ads，落地页做的是产品目录，但实际要跳转到在线询盘页面。一开始用的是网上找的免费跳转工具，结果投放不到48小时，账户就被Google标记为“规避政策”，直接被暂停。
后来我重新给他配了一套规则，核心思路是：Google的审核非常看重用户意图的一致性。如果用户在落地页看到的内容和最终到达页面的内容完全不相关，那处罚率极高。所以我配置了一个内容相近度校验：落地页和推广页必须共用同一套CSS框架、同一套导航结构、同一品牌Logo，甚至页面标题都保持主题一致。然后通过Cookie验证+设备指纹双重校验，确认真实用户后才跳转到询价表单页。
配置了大约两周后，账户恢复稳定，没有再收到规避系统的警告。但我也注意到，Google现在会不定期用人工审核员访问你的落地页，他们的IP不固定、UA不固定、指纹也不固定。所以纯技术层面的防检测对Google来说不够，必须配合内容层面的策略，才能长期稳定。
常见问题排查
配置完了一直不跳转，怎么回事？
先看日志，你的跳转规则命中记录里，这几次访问是有记录还是完全没记录。如果完全没有记录，说明请求根本没到服务器，可能是CDN缓存了白页导致后续访问命中缓存。解决方法是关闭CDN对落地页的缓存，或者在缓存策略里排除Cookie。如果有记录但没跳转，说明置信度分数没达到你的跳转阈值，调整一下阈值就行。
跳转了每次都被封，为什么？
大概率是你的跳转路径太直接。落地页直接302到推广页，用户浏览器地址栏会变，审核方一抓一个准。建议改用JS生成表单提交按钮，用户点击之后才加载推广页内容，而且全程不用跳转URL，而是用history.replaceState来替换当前页面地址。这样地址栏始终显示落地页URL，但实际内容是推广页。
还有一种情况是，你用了公共跳转服务的JS脚本。审核方直接把这个JS脚本的域名加入黑名单，一检测一个准。所以跳转逻辑最好自己写，不要用公开的跳转平台。
白页误伤真实用户怎么办？
误伤最常见的原因是CDN节点IP被运营商共享给其他站点，导致一个正常用户的IP段出现在黑名单里。处理方式是把IP黑名单的粒度和时长都改小一点，比如同一个IP段如果3天内没有重复触发，就自动移出黑名单。另外，可以给真实用户准备一个“我不是机器人”的验证入口，点击之后重新执行一次设备指纹检测，通过后手动跳转。
手机端和PC端配置要分开吗？
必须分开。手机端的UA种类非常杂，iOS和Android的设备指纹参数差异也大，如果共用一套配置，误伤率会很高。我的做法是，PC端以Cookie+设备指纹为主，手机端以IP+行为检测为主。因为手机端用户的IP相对固定，而且从点击到转化的时间窗口很短，没太多时间做指纹采集。
用了代理IP为什么还是被检测？
代理IP池里有很多IP早被审核方标记了，你拿到手就已经是黑名单。所以配置里要加一道IP清洗流程，拿到新代理IP先测试它能否正常打开Google首页、能否通过百度的安全验证，如果连搜索引擎的验证都过不了，这个IP直接用不得。
还有一个容易被忽略的点：代理IP的国家和你的投放受众得匹配。你是投国内百度，结果一跳转IP跑到美国去了，这不是明摆着告诉风控系统你做了跳转设计？我用代理IP都是绑定到对应城市的机房，保持IP地理位置和用户语义一致。
最后的经验
AB页跳转防检测这事，没有一劳永逸的方案。审核方的技术也在升级，今天能用的配置，可能下个月就失效了。我自己的习惯是每个月做一次全面审计，把UA库、IP段、指纹规则全部过一遍，同时关注百度搜外的风控公告和Google的Policy Change日志，提前知道规则变动方向。另外，准备一套备用跳转方案，一旦主力方案出现异常，直接切到备用方案，别等封号了再临时抱佛脚。
还是那句话，AB页跳转
