移动端流量占比接近七成、CDN缓存键只按URL生成、验收要求是爬虫与真实访客分别获得对应页面版本且互不污染——这几个条件叠加时，爬虫UA行为配置与版本错配的排查会从单点问题变成链路问题。投放侧常见到“规则改了不生效”，运维侧常见到“缓存还在吐旧版本”，审核侧则拿到驳回样本与线上内容不一致。下面按“先拆条件、再逐项回答”的方式，处理四个高频疑问。
一、UA规则同时命中爬虫和移动端浏览器时，谁先匹配？
先拆条件：移动端流量占比高，意味着大量真实UA里带iPhone、Android、Mobile；而部分爬虫UA也会带Mobile或智能机标识。此时如果规则把“Mobile”当作爬虫特征，误判会立刻升高。
回答分三步。第一，用强爬虫标识做精确匹配，例如Googlebot、Bingbot、Baiduspider、Bytespider，并限定在UA中的comment段或完整字符串匹配，不要只匹配“bot”这类过宽词。第二，对真实移动端UA放行，以AppleWebKit和Mobile/Android的组合作白名单，必要时可加上Chrome或Safari版本段。第三，未命中任何特征的请求进入默认分支，不要直接按爬虫处理。若必须进一步区分，可以在UA之后接IP段或反向DNS校验，但这会带来时延，参见流量识别链路时延优化。
规则命中顺序一旦写反，后续即使配置正确也会被短路。因此不建议把“先大范围放行移动端，再判断爬虫”的顺序用于强隔离场景，更稳妥的是“先精确匹配强爬虫、再放行真实移动端、最后默认待验证”。
二、页面版本被CDN缓存串了，先查UA还是先查缓存键？
这个问题的前提是：源站已经按UA返回不同版本，但线上请求看到的版本仍然一样。拆成两个独立条件：源站识别是否正常、边缘缓存是否按UA隔离。
建议先绕开CDN直接请求源站，用curl分别带移动端UA和爬虫UA，比较两个响应中的版本标识是否不同。若源站返回两个版本，说明UA行为配置基本正常，问题在缓存层。若源站返回一致，说明UA规则没有命中或顺序被覆盖，先回到规则层。
缓存层重点看三个配置。一是缓存键是否包含UA分类值，只按URL生成缓存键会让先到的请求覆盖后到的。二是响应头是否返回Vary: User-Agent，且CDN是否真正尊重该头。三是回源请求是否保留了原始User-Agent，部分CDN会改写或丢弃该头。
通用Nginx写法中，可先把UA分类写入变量，例如set $ua_class "real"; if ($http_user_agent ~* "Googlebot") { set $ua_class "crawler"; }，再把这个变量写进proxy_cache_key。如果缓存键只写$scheme$host$request_uri，就会把两类访客的页面版本混在一起。该链路容易和静态页面缓存混在一起，具体可看UA配置与缓存一致性疑问。
三、审核驳回后重查UA行为配置，优先核对哪几项？
审核驳回通常不是单条件结果。可拆为：审核抓取入口是否命中爬虫规则、返回的是否为标准页、标准页内容是否合规、缓存是否把完整页暴露给审核来源。
按链路核对比按感觉改规则更可靠。第一步，拿到驳回样本的时间、IP或UA，先在访问日志里还原这条请求。第二步，核对UA规则是否因顺序短路被后续规则覆盖，可参考规则条件短路顺序调优。第三步，确认标准页本身内容符合平台政策，而不仅是版本选择正确；如果标准页标题、资质、跳转按钮缺失，即便版本正确也会被驳回。第四步，检查该请求是否命中边缘缓存，若缓存键不区分UA，前面的规则都会被缓存结果抵消。
如果日志显示审核来源命中的是标准页，但驳回截图却是完整页，可以优先怀疑CDN按URL缓存了完整页而未隔离UA，而不必先改UA规则。
四、分流失效后，排查顺序从哪一层开始？
当错误率突然升高，建议从离访客最近的边缘层开始，逐层向源站推进。原因是边缘缓存的放大效应最明显，且最容易验证。
第一步，用不同UA请求线上URL，看响应头与HTML是否不同；如果相同，先查缓存键和Vary。第二步，查UA行为配置是否被变更，日志中UA是否完整传入，是否存在大量空UA。空UA、默认UA占比突然变大，可能是回源链路丢失User-Agent，或接入层把UA截断，此时应先修传输，再调识别规则。第三步，查规则库是否热更新成功，是否存在旧版本仍在分发，参见规则库热更新链路。第四步，回到源站确认页面文件实际版本。
这个顺序的好处是：前两步能低成本排除最大面积的影响，后两步再定位规则与发布问题。
UA行为配置与版本错配通常不是单一配置出错，而是UA规则、缓存键、规则顺序、源站发布四层中某一层被前置条件放大。排查时先还原请求样本，再确定每一层应该返回的页面版本，最后找出最先偏离预期的那一层。把条件拆开，比同时修改多个配置更容易收敛。
常见问题
为什么爬虫UA规则明明命中了，返回的还是旧版本？
通常是CDN边缘缓存已经按URL缓存了首轮响应，后续请求没有回源。需要检查缓存键是否包含UA分类或是否发送Vary响应头；若缓存键只含URL，就需要把UA分类结果纳入缓存键，或者对爬虫与真实访客使用不同URL子路径。
UA行为配置会影响落地页加载速度吗？
UA判断本身通常在毫秒级完成，基本不会影响加载速度。更常见的是把UA校验放到同步链路里，又叠加多次外部查询或规则库读取，才会增加响应时间。建议对UA规则做内存级布尔匹配，避免每条请求都走数据库查询。
审核驳回后需要先查UA还是先查标准页？
建议先查驳回样本能否还原当时的UA和IP线索，再确认该请求是否命中正确页面版本；如果版本正确但内容仍被驳回，问题大概率不在UA配置而在标准页内容或素材合规。
移动端真实访客被误判为爬虫怎么办？
先检查UA规则是否用了过宽关键词，例如只写“Mobile”或“AppleWebKit”导致移动端真实浏览器被命中。然后补充强爬虫标识做精确匹配，把真实移动端UA放到放行分支，并观察错误率是否下降。
延伸阅读
如果还处在选型阶段，需要比较不同斗篷工具在UA处理与缓存策略上的差异，可以读一下这篇工具对比补充判断依据。
