最近调试公众号网页，遇到一个很常见的拦截：

请在微信客户端打开
请使用微信扫描二维码访问
当前浏览器不支持，请在微信中打开
​

但我明明是在电脑上调试页面，难道每次改一行代码，都要把链接发到手机微信里再看？

当然不用这么麻烦。

如果网站只是通过 User-Agent 判断当前是不是微信浏览器，我们可以先用 Chrome DevTools 模拟一个微信 UA，在电脑上完成大部分页面调试。

不过这里要先说清楚：模拟 UA 只能改变请求中携带的客户端标识，不能把 Chrome 完整改造成微信。

微信内置浏览器的 JSBridge、登录态、域名白名单、支付环境和真实设备能力，单靠改 UA 都模拟不出来。

这篇先把能解决的问题解决掉，再把不能解决的边界讲明白。

先认识 UA

UA 是 User-Agent 的缩写，也就是用户代理。

浏览器发送 HTTP 请求时，通常会在请求头中带上 User-Agent，服务器可以根据它大致判断：

• 客户端是什么操作系统
• 是电脑浏览器还是手机浏览器
• 使用了什么浏览器内核
• 是否来自某个 App 内嵌 WebView
• 浏览器的大致版本

在 Chrome DevTools 的 Network 面板里，可以看到类似这样的请求头：

User-Agent: Mozilla/5.0 ... Chrome/xxx Safari/xxx
​

微信内置网页的 UA 通常会出现 MicroMessenger 标识，例如 iPhone 微信 UA 里可能包含：

Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X)
AppleWebKit/605.1.15 (KHTML, like Gecko)
Mobile/15E148 MicroMessenger/8.0.XX NetType/WIFI
​

这里的微信版本、系统版本和 WebKit 版本会变化，调试时不要机械照抄某一条旧 UA。

真正重要的是目标网站检查的标识。

有的网站只检查 MicroMessenger，有的网站还会检查移动端标识、系统信息甚至其他请求头。

手机模式和 UA 不是一回事

Chrome DevTools 里有一个手机图标，点击后可以切换 Device Mode。

快捷键通常是：

Windows / Linux：Ctrl + Shift + M
macOS：Command + Shift + M
​

打开后可以选择 iPhone、Android 等设备，也可以自定义屏幕宽度和高度。

电脑 Chrome
     │
     │ 切换 Device Mode
     ▼
模拟手机尺寸、像素比、触摸操作
​

手机模式主要影响：

• viewport 尺寸
• 页面缩放比例
• device pixel ratio
• 触摸事件模拟
• 部分设备特征

而 UA 是 HTTP 请求头和浏览器环境中的另一组信息。

有些内置设备会同时切换 UA，但不能简单认为“屏幕变窄了，服务器就一定认为这是手机”。

如果网站根据 UA 判断客户端类型，就要额外检查 User-Agent 是否真的改变。

// 在 Chrome Console 中查看当前页面看到的 UA
navigator.userAgent
​

所以调试时建议把两件事分开看：

• 页面布局不对：先切换手机尺寸
• 被判断成电脑或非微信：再检查 UA

Chrome 怎么模拟手机 UA

先做最常用的手机网页调试。

打开设备模式

1. 用 Chrome 打开目标网页
2. 按 F12 打开开发者工具
3. 点击左上角的手机和平板图标
4. 在顶部设备下拉框里选择 iPhone 或 Android
5. 刷新页面，观察布局和请求变化

Chrome 也允许自定义设备尺寸。

在设备下拉框中选择 Edit 或 Add custom device，就可以配置名称、宽高、设备像素比和 UA 类型。

如果只是测试响应式布局，这一步通常就够了。

确认 UA 是否变化

打开 Console，执行：

navigator.userAgent
​

或者在 Network 面板点击页面主文档请求，在 Request Headers 中查看 User-Agent。

不要只看页面外观。

有时页面已经变成手机尺寸，但请求头仍然不是目标客户端。

Chrome 怎么模拟微信 UA

如果设备模式没有满足需求，可以手动设置 UA。

Chrome 新版 DevTools 的入口大致如下：

1. F12 打开开发者工具
2. 点击右上角三个点
3. 进入 More tools
4. 找到 Network conditions
5. 在 User agent 区域取消 Use browser default
6. 从下拉框选择预设 UA，或者选择 Custom
7. 粘贴目标微信 UA
8. 刷新页面并重新观察请求

如果菜单里找不到 Network conditions，可以按下面的方式打开：

Ctrl + Shift + P
输入：Show Network conditions
选择对应命令
​

不同 Chrome 版本的菜单位置可能会有一点变化，但搜索 Network conditions 基本都能找到。

操作后的流程大概是：

打开 DevTools
      │
      ▼
Network conditions
      │
      ▼
取消浏览器默认 UA
      │
      ▼
选择预设或粘贴 Custom UA
      │
      ▼
刷新页面
      │
      ▼
Network 面板确认请求头
​

这里最容易漏掉的一步是取消 Use browser default。

不取消的话，下面选了自定义文本也可能仍然使用 Chrome 默认 UA。

一个微信 UA 示例

可以准备一条包含 MicroMessenger 的移动端 UA：

Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X)
AppleWebKit/605.1.15 (KHTML, like Gecko)
Mobile/15E148 MicroMessenger/8.0.XX NetType/WIFI
​

粘贴后不要直接相信页面结果，应该在 Network 面板确认请求实际发送的 User-Agent。

页面里的 navigator.userAgent 也可以再次检查。

怎么获取目标 UA

如果你手里有一台手机，最简单的方式是让手机微信访问一个显示 UA 的页面。

页面里执行：

document.body.innerText = navigator.userAgent
​

然后复制页面显示的字符串，粘贴到 Chrome 的 Custom User agent 中。

也可以在 Chrome Console 中直接执行：

navigator.userAgent
​

如果页面被拦截到无法继续，可以先做一个简单的 UA 查看页：

<!doctype html>
<html lang=zh-CN>
<body>
<pre id=ua></pre>
<script>
  document.querySelector('#ua').textContent = navigator.userAgent
</script>
</body>
</html>
​

把这个页面部署在一个不做 UA 拦截的地址上，再分别用电脑 Chrome、手机 Safari、手机微信访问，就能拿到不同客户端的 UA。

实际项目中建议把 UA 记录到调试日志里，不要依赖网上复制的一条历史字符串。

被拦截时怎么排查

模拟 UA 后，如果页面还是提示请在微信里打开，可以按下面的顺序查。

先看主文档请求

打开 Network 面板，刷新页面，找到最上面的 Document 请求。

重点看：

• Request Headers 里的 User-Agent
• Response Status Code
• Response Headers
• 返回的 HTML 内容
• 是否发生 301 或 302 跳转

如果主文档请求里的 UA 还是 Chrome，说明模拟没有生效。

如果 UA 已经包含 MicroMessenger，但服务端仍然拦截，再继续看后面的判断逻辑。

再看页面脚本

有些网站不是服务端直接拦截，而是页面打开后执行 JavaScript：

读取 navigator.userAgent
        │
        ├── 不包含 MicroMessenger
        │       └── 显示请在微信打开
        │
        └── 包含 MicroMessenger
                └── 继续加载页面
​

这种情况下，模拟 UA 通常可以绕过第一层判断。

但如果脚本还继续检查 window.WeixinJSBridge、微信授权结果或业务签名，单改 UA 就不够了。

注意跳转缓存

服务端返回的 302、前端路由状态和浏览器缓存，也可能让你误以为 UA 没生效。

可以尝试：

• 勾选 Network 面板中的 Disable cache
• 保持 DevTools 打开后再刷新
• 使用硬刷新
• 清理当前站点缓存和 Cookie
• 用无痕窗口重新测试
• 检查是否跳到了另一个域名或路径

很多时候不是 UA 不对，而是第一次访问已经被重定向到了拦截页。

模拟 UA 能解决什么

模拟 UA 对下面这些场景很有帮助：

• 调试服务端的移动端页面分流
• 检查服务端是否只判断 MicroMessenger 标识
• 调试手机页面布局和部分移动端交互
• 验证不同客户端返回的 HTML 是否不同
• 复现简单的浏览器类型判断问题
• 对比电脑端和微信端的请求响应

比如服务端根据 UA 返回不同页面：

普通 Chrome UA      -> 返回桌面页面
iPhone Safari UA    -> 返回移动页面
含 MicroMessenger   -> 返回微信页面
​

这种逻辑可以在电脑上快速验证，不用每次都拿手机操作。

模拟 UA 解决不了什么

UA 只是一个可以修改的字符串，不能当成完整的微信环境。

下面这些能力通常无法仅靠模拟 UA 获得：

• 微信 JSBridge 和 wx 相关接口
• 微信授权登录和真实 OAuth 流程
• 微信内置 Cookie、登录态和用户身份
• 公众号网页域名白名单校验
• 微信支付、实名和风控校验
• 真实设备的摄像头、定位、扫码能力
• App 内嵌 WebView 的生命周期行为
• 服务端基于签名、票据或设备信息的二次校验

可以用下面的比喻理解：

模拟UA = 给请求换了一张名片
真实微信 = 名片 + App 容器 + 登录态 + JSBridge + 业务凭证
​

如果页面只看名片，模拟 UA 就够。

如果页面还要验证容器和身份，还是要用真实微信或专门的测试环境。

微信对象不存在怎么办

有些代码会这样判断：

if (navigator.userAgent.includes('MicroMessenger')) {
  // 继续执行微信页面逻辑
}
​

模拟 UA 后，这个判断可能通过。

但如果后续代码直接调用微信 JSBridge，电脑 Chrome 里仍然没有对应对象。

开发时可以把微信能力抽象成适配层，在非微信环境提供 mock：

function chooseImage() {
  if (isWechat()) {
    return callWechatBridge()
  }
  return useBrowserFileInput()
}
​

这样模拟 UA 负责验证分流，mock 负责让页面继续跑，真实微信再做最终联调。

不要把 UA 当安全凭证

UA 很容易伪造。

浏览器开发者工具能改，命令行工具能改，脚本也能改。

所以服务端不能只因为 UA 中出现 MicroMessenger，就把它当成可靠的身份认证。

下面这些事情不能只靠 UA 判断：

• 登录身份
• 用户权限
• 支付资格
• 管理后台访问
• 敏感数据返回
• 防刷和风控结论

UA 适合做展示分流和兼容性判断，不适合做安全边界。

如果一定要根据微信环境开放能力，至少还要结合登录票据、签名、服务端会话和业务授权校验。

小结

Chrome 模拟微信 UA 的核心操作可以浓缩成几步：

1. F12 打开 DevTools
2. 手机图标切换 Device Mode，必要时调整屏幕尺寸
3. 通过 Network conditions 取消默认 UA
4. 选择预设 UA 或粘贴包含 MicroMessenger 的自定义 UA
5. 刷新页面，在 Network 和 Console 中确认 UA 确实生效

这套方法适合快速调试 UA 分流和移动端页面。

但要记住：模拟 UA 只是模拟请求身份，不是真正模拟微信运行环境。

遇到公众号网页拦截，先确认是服务端 UA 判断、前端脚本判断，还是微信授权和 JSBridge 校验。

能用 Chrome 解决的先用 Chrome 解决，必须依赖真实微信能力的部分，再回到手机或专门的联调环境。这样调试效率高，也不容易把问题方向带偏。