ASP检测手机客户端并跳转：User-Agent移动端分流实践

接手一个跑了快十年的 ASP 老站最怕的不是代码有多老而是需求方一句轻描淡写的话手机打开要自动进手机版。听起来就是几行 if 的事真做起来iPad 到底算不算手机、微信里点开算不算、搜索引擎的爬虫抓到的是哪个版本、用户手动点了“访问电脑版”下次还跳不跳一个个问题会接连冒出来。这个项目标题——ASP 检测手机客户端并跳转到相应页面——说的就是这么一件事用 ASP 在服务端读取User-Agent判断来访设备是不是移动端再决定把这次请求送去 PC 页面还是移动页面。我在 IIS 上折腾过好几个这种老站的分流改造从最粗暴的字符串包含判断到后来封装成公共函数、加 Cookie 记忆、处理缓存和爬虫白名单踩过的坑基本能凑成一本小册子。这篇内容适合三类人看还在维护 ASP/IIS 老站的运维和全栈、被外包甩过来接手“祖传代码”的开发者以及虽然不用 ASP 但想搞懂移动端分流底层逻辑的人。不管你用的是 VBScript 还是后来转到别的语言判断思路是通用的只是语法换了个壳。我会把方案怎么选、代码怎么写、哪里会出错、出错怎么查一层层拆开讲清楚代码可以直接抄去改。1. 先想清楚为什么要在服务端做设备分流1.1 老站点的现实处境一套代码要伺候两种屏幕很多跑了多年的企业站、行业站前端还是十几年前那套表格布局宽度写死 960px 或者 1000px图片是缩略图直接撑满导航是 hover 触发的下拉菜单。这种页面在手机上打开要么整体缩小到看不清字要么横向滚动条拉半天。想改成响应式CSS 全量重写、图片重新切、交互重做工作量不说样式表里那种“哪块浮左哪块浮右”的老写法一改就全乱。所以绝大多数老项目的现实选择是另起一套移动站主站不动。这时候就必须有一个东西来判断“来的人用的是不是手机”然后把他送到对应的站点去。这件事可以放在三个位置做前端 JS 判断、服务端 ASP 判断、Web 服务器层面IIS 的 URL 重写模块判断。前端 JS 判断的问题是首屏会闪一下——PC 页面先渲染出来脚本跑完才跳走用户体验很差而且搜索引擎爬虫大多不执行 JS收录会出问题。服务器层面判断性能最好但需要装额外的重写模块很多老机器上没装或者没权限装。所以最稳妥、最不需要额外依赖的做法就是在 ASP 页面里做判断请求还没输出 HTML 就已经决定去哪了干净利落。1.2 三条路线的取舍响应式、独立移动站、按需跳转在动手写代码之前我一般会先跟需求方把这三种方案摆到桌面上对比一遍因为选错了后面全是返工。这个对比表我几乎是原样复用的你可以直接拿去跟人讨论方案改造成本维护成本SEO 影响适用场景原站改响应式高CSS 和模板基本重写低一套代码最好URL 不变新项目或前端结构较干净的项目独立移动站 服务端分流中移动站可另起模板中两套模板要同步内容需要额外标注处理不好会被判重复内容老站改造、PC 端交互复杂同域名 /m/ 路径子站中同上中同上较好主域权重共享不想再买域名、Session 要共享第三条其实是第二条的变体区别在于移动站是m.example.com这样的子域还是www.example.com/m/这样的路径。子域的好处是移动站可以独立部署、独立缓存、独立做 CDN坏处是 Cookie 和 Session 默认不共享用户在主站登录了到移动站还是未登录状态得额外处理 Cookie 的 Domain。路径方式的好处是 Cookie、Session、登录态天然共享一套后台一套登录逻辑坏处是同一台服务器上要维护两套模板路由容易写混。我个人的偏好是如果站点有会员登录体系优先走路径方案如果是纯展示型站点子域方案更清爽。还有一个容易被忽略的点跳转是单向的还是双向的。很多项目只做了“手机访问 PC 页自动跳移动站”结果用户在手机上手动点了“访问电脑版”刷新一下又被弹回移动站气得直接关页面。所以完整的方案里必须留一个“用户主动选择优先于自动检测”的开关这个后面会讲怎么用 Cookie 实现。2. 核心原理ASP 到底是怎么“看见”手机的2.1 User-Agent 这串字符里藏着什么浏览器每次发请求都会在请求头里带一个User-Agent字段就是一串自报家门的文本。服务端拿到的就是这个字符串ASP 里通过Request.ServerVariables(HTTP_USER_AGENT)取出来。这串东西长这样简化过的Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1 Mozilla/5.0 (Linux; Android 13; SM-G991B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Mobile Safari/537.36 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36能看出来移动端的 UA 里通常会出现Mobile、Android、iPhone、iPod这类关键词PC 端一般没有。这就是全部判断逻辑的基础——关键词匹配。听起来很土但这么多年过去了业界主流做法依然是这样因为 UA 是唯一一个在请求到达服务端时就能拿到的设备线索CSS 媒体查询要等页面渲染JS 要等脚本执行。不过要注意HTTP_USER_AGENT是一个“客户端说了算”的字段任何人都可以伪造。所以这里的检测只能用来做体验优化不能用来做安全判断或者权限控制。我见过有人拿 UA 判断来做“移动端专属优惠”结果被脚本刷得很难看这个思路一定要纠正过来。2.2 为什么不能用“全量机型清单”去匹配新手最容易犯的错是去网上找一份几百行的手机 UA 清单然后一条条InStr比对。这个做法在 2010 年可能还行现在完全跑不通新机型每天都在出UA 里带的具体型号千奇百怪清单永远追不上。正确的思路是用少量高置信度关键词做“组合命中 反向排除”。我的判断顺序是这样的先看 UA 是否为空空的话按 PC 处理有些脚本请求不带 UA先做爬虫排除命中爬虫关键词的直接放行不跳转再做平板识别iPad、Android 平板这类先拎出来单独处理最后做手机识别命中任意移动关键词就判定为手机。这个顺序很重要因为iPad的 UA 里既有iPad又有Mobile老系统如果先判手机就会把 iPad 误判成手机而爬虫比如移动版搜索引擎蜘蛛UA 里也可能带Mobile不先排除就会把爬虫也跳走直接影响收录。顺序错了逻辑再对也是白搭。% 设备类型判断公共函数 返回值0PC 1手机 2平板 3爬虫/脚本 Function GetDeviceType(ua) Dim s, i GetDeviceType 0 If Len(ua ) 0 Then Exit Function s LCase(ua) ---- 第一优先级爬虫与命令行工具一律放行 ---- Dim bots bots Array(spider, crawler, slurp, archiver, _ baiduspider, googlebot, bingbot, yandexbot, _ sogou web spider, curl/, wget/, python-requests, _ okhttp/, go-http-client, headlesschrome) For i 0 To UBound(bots) If InStr(s, bots(i)) 0 Then GetDeviceType 3 Exit Function End If Next ---- 第二优先级平板 ---- If InStr(s, ipad) 0 Then GetDeviceType 2 Exit Function End If Android 平板 UA 通常不含 Mobile 关键字 If InStr(s, android) 0 And InStr(s, mobile) 0 Then GetDeviceType 2 Exit Function End If ---- 第三优先级手机 ---- Dim phones phones Array(mobile, iphone, ipod, windows phone, _ blackberry, symbian, opera mini, kindle, _ miuibrowser, micromessenger, ucweb, alipayclient) For i 0 To UBound(phones) If InStr(s, phones(i)) 0 Then GetDeviceType 1 Exit Function End If Next End Function %这段代码里有个细节值得说一下bots数组里我特意没有放单独的bot只放了bingbot、googlebot、yandexbot这种带前缀的完整词。原因是我真被坑过一次——某个国产手机品牌的英文名缩写里正好含bot三个字母用户用这款手机访问被判定成爬虫永远看不到移动版页面。这个 bug 在日志里几乎看不出来是用户投诉“我的手机打开是电脑版”才反查到的。关键词宁可写得长一点、具体一点也不要用两三个字母的短词去扫。3. 落地实现把判断逻辑封装成公共文件3.1 文件怎么放include 的位置很讲究ASP 没有命名空间也没有模块系统公共逻辑靠!--#include file...--引入。我一般会在站点根目录建一个inc目录里面放三个文件inc/device.asp设备判断函数纯逻辑不做任何输出inc/siteconfig.asp配置常量PC 站地址、移动站地址、是否开启跳转、白名单路径inc/boot.asp入口文件把前两个 include 进来然后执行“判断 跳转”的动作。这样拆分的好处是将来要改跳转规则只动boot.asp要加新的 UA 关键词只动device.asp互不干扰。然后每个页面顶部只写一行!--#include fileinc/boot.asp--注意路径是相对于当前文件的不是相对于站点根目录。如果页面放在子目录里就得改写成!--#include file../inc/boot.asp--或者干脆用virtual形式写绝对路径!--#include virtual/inc/boot.asp--。我强烈建议用virtual因为老站的目录层级往往很深改一个页面就得数一遍../太容易出错。3.2 boot.asp 的完整写法与几个关键判断% inc/boot.asp —— 移动端分流入口 必须在页面任何输出之前 include Dim PC_HOST, MOBILE_HOST, ENABLE_JUMP PC_HOST www.example.com MOBILE_HOST m.example.com ENABLE_JUMP True 总开关线上出问题一键关掉 Dim ua, deviceType, viewMode, curHost, curPath, curQuery, targetUrl If ENABLE_JUMP Then ua Request.ServerVariables(HTTP_USER_AGENT) deviceType GetDeviceType(ua) viewMode LCase(Request.Cookies(viewmode) ) pc / mobile / 空 curHost LCase(Request.ServerVariables(SERVER_NAME)) curPath Request.ServerVariables(URL) curQuery Request.ServerVariables(QUERY_STRING) 已经手动选择过尊重用户选择 If viewMode pc Then 什么都不做 ElseIf viewMode mobile Then If curHost PC_HOST Then Call JumpTo(MOBILE_HOST, curPath, curQuery) ElseIf deviceType 1 Then 手机访问 PC 站跳移动站 If curHost PC_HOST Then Call JumpTo(MOBILE_HOST, curPath, curQuery) ElseIf deviceType 0 Or deviceType 2 Then PC 或平板访问移动站跳回 PC 站 If curHost MOBILE_HOST Then Call JumpTo(PC_HOST, curPath, curQuery) End If deviceType 3爬虫不跳转让它看到当前页 End If %这里最核心的两个点是只在“跨站”时才跳以及爬虫完全不跳。第一条防的是死循环——如果移动站上的页面也 include 了这段代码而判断逻辑不检查当前域名那么在移动站上检测到手机又会跳一次移动站浏览器就一直转圈。我见过最离谱的一次页面在m站和www站之间来回弹最后是浏览器的“重定向次数过多”救了场。第二条防的是收录问题让爬虫按它请求的 URL 拿到对应内容PC 版和移动版各自被收录再用页面里的relcanonical/relalternate互相标注关系这才是对搜索引擎友好的做法。3.3 跳转函数把 URL 拼接这件事做干净跳转本身是Response.Redirect一行的事但拼接目标 URL才是真正容易出问题的地方。原始 URL 可能带查询串、可能带中文参数、可能是 HTTPS、可能带非标准端口直接字符串拼接很快就乱了。Sub JumpTo(hostName, path, queryStr) Dim scheme, port, url 协议跟随当前请求避免 HTTPS 页面跳到 HTTP If LCase(Request.ServerVariables(HTTPS)) on Then scheme https:// Else scheme http:// End If 非 80/443 端口要带上内网测试环境必须 port Request.ServerVariables(SERVER_PORT) If port 80 And port 443 Then port : port Else port End If If Len(path ) 0 Then path / url scheme hostName port path If Len(queryStr ) 0 Then url url ? queryStr Response.Status 302 Found Response.AddHeader Location, url Response.End End SubRequest.ServerVariables(URL)拿到的是当前请求的虚拟路径比如/news/detail.aspQUERY_STRING拿到的是问号后面那一截。两个拼起来就是完整的相对地址原样搬过去这样用户在手机上看某篇文章跳到移动站还是那篇文章而不是回到首页——这个细节做不好用户会非常恼火。中文参数的编码问题不用担心QUERY_STRING拿到的本来就是 URL 编码后的原始串原样透传即可如果是要自己构造新的参数值才需要用Server.URLEncode()处理。4. 跳转状态码与用户体验的那些细节4.1 302 还是 301不是随便选的Response.Redirect在 IIS 下默认吐的是 302 临时重定向。有人觉得“我这个跳转是永久规则应该用 301”于是改成Response.Status 301 Moved Permanently Response.AddHeader Location, url Response.End这个写法本身是有效的但要想清楚后果。301 会被浏览器和搜索引擎长期缓存一旦规则改错了用户手里的浏览器还记着旧地址你改了服务器也没用得等缓存过期。而移动端分流的规则是跟着设备走的同一台设备可能今天用手机访问明天用电脑访问跳转目标本来就不是永久固定的。所以我个人的做法是PC 站与移动站之间的设备分流用 302只有站点整体换域名老域名彻底废弃才用 301。如果你一定要用 301至少要在代码里留一个“紧急关闭”的总开关就是前面那个ENABLE_JUMP出问题的时候能立刻止血。这个习惯我保持了七八年救过至少两次。注意Response.Status和Response.AddHeader必须在任何 HTML 输出之前执行否则会抛ASP 0156 : 80004005的 Header Error。这个错误在后面的排查章节会详细讲。4.2 用户手动切换用 Cookie 记住选择移动站页面底部一般会放一个“访问电脑版”的链接PC 站上也常有“访问移动版”。这两个链接的实现方式很简单就是带上一个参数让入口逻辑把选择写进 Cookie 假设链接是 /setmode.asp?topcback/news/detail.asp % Dim toMode, backUrl toMode LCase(Request.QueryString(to) ) backUrl Request.QueryString(back) If backUrl Then backUrl / If toMode pc Or toMode mobile Then Response.Cookies(viewmode) toMode Response.Cookies(viewmode).Path / Response.Cookies(viewmode).Domain .example.com 主域与子域共享 Response.Cookies(viewmode).Expires DateAdd(d, 30, Date()) End If If toMode pc Then Response.Redirect http:// PC_HOST backUrl Else Response.Redirect http:// MOBILE_HOST backUrl End If %这里有两个关键参数。Domain要写成.example.com这种带前导点的形式主域和子域才能共享同一个 Cookie如果只写www.example.com那么在m.example.com上读不到这个值用户在移动站点的选择到了 PC 站就失效了。Expires一定要设置不设置的话它是会话 Cookie用户关掉浏览器就忘了下次打开又被强制跳一次体验很差。30 天是个比较合适的值太长了用户自己都忘了什么时候点过。另外提醒一句backUrl这种从 URL 里直接读出来就拼进跳转地址的写法是典型的开放重定向漏洞。一定要做白名单校验只允许以/开头的站内路径If Left(backUrl, 1) / Or InStr(backUrl, //) 0 Or InStr(backUrl, \) 0 Then backUrl / End If判断//是为了挡住//evil.com这种协议相对地址判断\是为了挡住某些浏览器会把它当斜杠处理的情况。这几行加上去心里踏实很多。4.3 POST 请求和 Ajax 请求怎么办设备分流最容易翻车的地方是表单提交。用户在手机上填了一屏表单点提交POST到/order/save.asp入口逻辑检测到是手机一个 302 把人跳到移动站地址——结果POST的数据全丢了用户看到的是一张空白表单。这个 bug 在测试阶段很难发现因为测试同学一般用电脑点上线后手机用户一提交就炸。处理办法很直接入口逻辑里判断请求方法POST一律不跳。If LCase(Request.ServerVariables(REQUEST_METHOD)) post Then POST 请求不做设备分流交给页面自己处理 Else 正常的分流逻辑 End If不跳 POST 之后页面得能正常往下跑。所以移动站的模板最好能兼容 PC 端提交过来的数据或者干脆在移动端页面里用相对路径提交保证提交地址本身就在移动站域名下。Ajax 请求同理XMLHttpRequest的 UA 和主请求一样但它期待的是 JSON 或者片段数据一旦被 302 到 HTML 页面前端解析直接报错。判断方法可以看X-Requested-With头If LCase(Request.ServerVariables(HTTP_X_REQUESTED_WITH)) xmlhttprequest Then Ajax 请求跳过分流 End If这两个判断加进去入口逻辑才算真正能上生产。5. 那些年骗过我的 User-Agent5.1 iPad、微信内置浏览器和“伪装”的移动端UA 判断写得再细也总有一些设备出乎意料。我整理了一张实际遇到过的对照表你可以对照着完善自己的关键词库UA 特征实际设备我的处理方式含iPadiPad老系统判平板走 PC 版或平板专用版含Macintosh且含MobileiPad新系统默认请求桌面版网站视为平板不强制跳移动站含Android但不含MobileAndroid 平板判平板含MicroMessenger微信内置浏览器按手机处理注意微信内下载和支付限制含AlipayClient支付宝内置浏览器按手机处理含UCBrowser/UCWEBUC 浏览器按手机处理注意它的 UA 会随版本变含Windows Phone已停更的 WP 机型归入手机别当成 PC含HeadlessChrome无头浏览器/截图服务归入爬虫放行不跳最坑的是 iPad 的新系统。从 iPadOS 13 开始iPad 默认请求桌面版网站UA 长得和 Mac 一模一样只在里面多一个Mobile字样。如果你的判断逻辑是“含Mobile就是手机”iPad 就会被当成手机跳去移动站用户在大屏上看到一列窄窄的手机版页面非常难受。所以我在判断顺序里把平板识别放在了手机识别前面并且明确写了iPad和“Android 且不含 Mobile”两条规则。至于微信内置浏览器它的 UA 里带MicroMessenger同时也带Mobile一般能被正常识别。真正要注意的是微信里做了跳转之后的行为差异微信内置浏览器对跨域跳转、下载文件、唤起 App 都有额外限制如果跳转目标是m子域还要确认公众号后台配置的业务域名包含该子域否则页面里的 JS-SDK 功能会失效。这个是配置层面的问题跟 ASP 代码无关但排查的时候特别容易被忽略。5.2 缓存与 CDN跳转逻辑“没生效”的隐形凶手有一种情况我遇到不止一次代码明明改对了本地测试也正常但线上一部分用户就是跳不过去。查了半天发现是页面被 CDN 缓存了。设备分流是在服务端根据User-Agent动态决定的但 CDN 默认是按 URL 缓存的它不区分访问者的 UA——第一个访问者的请求被缓存下来后面所有人拿到的都是同一份。解决办法有两个方向。一是给响应加上Vary头告诉缓存服务器“这份内容会随 UA 变化”Response.AddHeader Vary, User-Agent二是干脆让入口页面不被缓存对于跳转这种轻量逻辑成本几乎为零Response.AddHeader Cache-Control, private, no-store, max-age0 Response.AddHeader Pragma, no-cache Response.Expires 0我一般两个都加。Vary头虽然语义正确但它会让缓存服务器为每一种 UA 存一份副本缓存命中率暴跌CDN 的费用和回源压力都会上去。所以更彻底的做法是只让真正的内容页参与缓存跳转判断放在不缓存的入口上或者在 CDN 后台把.asp动态请求排除在缓存规则之外。提示如果你改完代码发现线上没变化先别怀疑代码用命令行带一个特定的 UA 去请求一次看看响应头里有没有X-Cache: HIT之类的标记。这一步能省掉一半的排查时间。6. 排查实录报错、死循环和“只对部分人失效”6.1 ASP 0156 报错九成是文件编码惹的祸Response object error ASP 0156 : 80004005 Headers already sent这个错误几乎是每个 ASP 开发者都会撞上的。字面意思是“响应头已经发出去了你现在才想改它”但真正的原因往往很隐蔽。我遇到过的几种情况第一种include 文件的保存编码是UTF-8 带 BOM。BOM 是文件开头那三个不可见的字节编辑器不显示但 IIS 会把它当内容输出于是响应头提前发送后面的Response.Redirect就报错了。解决办法是把所有 include 文件和页面文件统一存成UTF-8 无 BOM或者 ANSI编辑器里一般都有这个选项。这个坑我见过至少五次每次都要花半天才能定位。第二种boot.asp里在跳转代码前面多了一个空格或者空行。ASP 的% %指令块外面哪怕有一个空格都会被当成输出。所以入口文件的第一行必须干干净净从%开始。第三种页面顶部有 HTML 注释或者!DOCTYPE而 include 放在了它下面。这个属于引用位置错误改到最顶上就行。对应的排查动作很简单用浏览器开发者工具看响应头如果Content-Type前面已经出现了内容或者Response Headers里根本没有跳转相关的头就说明输出提前发生了。再用十六进制编辑器看一眼文件开头有没有EF BB BF三个字节基本一次定位。6.2 常见问题速查表现象最可能的原因排查动作解决方式页面报 ASP 0156输出提前发生查文件 BOM、查跳转前有无空格/HTML改存无 BOMinclude 放第一行浏览器提示重定向次数过多两个站互相跳查入口逻辑有没有判断当前域名只在跨站时才跳手机用户看到的还是 PC 页CDN 缓存 / UA 未命中关键词带 UA 请求看响应头、看X-Cache加Vary、关缓存、补关键词部分国产机型被当爬虫关键词太短误伤品牌名用用户提供的 UA 做单测关键词写全不用 3 字母短词手机提交表单数据丢失POST 被 302 跳走看请求方法POST 和 Ajax 不跳转点了“电脑版”又被弹回Cookie 未设置 Domain 或 Expires查 Cookie 作用域加.example.com和过期时间跳转后文章变成首页未透传QUERY_STRING看 Location 头拼接原始查询串HTTPS 站点跳成 HTTP协议写死看 Location 头的 scheme用HTTPS变量判断这张表我基本是贴在显示器旁边的新同事接手的时候直接看能省掉大量重复解释。其中“用用户提供的 UA 做单测”这一条特别值得强调每一个“我的手机打开不对”的反馈都要让对方把 UA 发过来然后拿到本地用Request.ServerVariables打印出来丢进函数里跑一遍问题基本就现形了。不要靠猜猜测的成本远高于让用户复制一段文本。6.3 上线前必做的四个验证动作第一个用真实设备各走一遍iPhone Safari、Android Chrome、微信内置浏览器、iPad、一台 PC。这五条路径覆盖了 95% 以上的场景。第二个用命令行伪造 UA 测试把常见爬虫和几个奇葩 UA 都跑一遍curl -I -A Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1 http://www.example.com/news/detail.asp?id123看返回的HTTP/1.1 302和Location头确认路径、查询串、协议都对。第三个关掉跳转开关再跑一遍确认开关真的有效——总开关失效这种事故在真正需要它的时候才发现就晚了。第四个检查移动站的页面里有没有指向 PC 站的绝对链接有的话用户点一下又跳回去了体验割裂。前三个是自动化能做的第四个只能人工点但必须点。7. 我个人在几个老站项目上的实际体会这套逻辑我在几个不同规模的 ASP 老站上都跑过最大的感受是代码本身只有两百行真正花时间的全是边界情况。第一次上线的时候我只写了最简单的“含 Mobile 就跳”测试环境一切正常上线第二天就收到三起投诉一个是 iPad 用户一个是提交订单丢了数据的还有一个是搜索引擎抓取异常导致收录掉了。三件事让我把判断顺序、POST 放行、爬虫白名单这三块彻底重写了一遍。后来我形成了一个习惯所有分流规则都写成可配置的数组而不是硬编码在 if 里。新增一个要识别的浏览器就在数组里加一行字符串不用改逻辑临时要放行某个渠道就把域名加进白名单数组。这套东西放到今天也不算先进但它在老环境里极其可靠——没有额外依赖不需要装模块改一行配置重启都不用。老技术栈的优势就在这儿它笨但它不会在你最忙的时候出意外。还有一个我一直在坚持的小技巧入口文件里永远留一行注释写清楚最后修改日期和改了什么。老项目最大的敌人不是技术难而是半年后你或者别人打开这个文件完全想不起来当初为什么要在deviceType 2的分支里加一个And InStr(s, mobile) 0。一行注释能省下半小时的考古时间性价比极高。