Clash/Mihomo 配置里的 client-fingerprint 会隐藏浏览器指纹吗？
Mihomo 的 client-fingerprint 只改变部分代理协议连接节点时的 TLS ClientHello，不会修改网页看到的浏览器、Cookie 或设备特征；同时解释旧全局字段的弃用边界。
先看重点client-fingerprint 只影响 Mihomo 与 VMess、VLESS、Trojan、AnyTLS 节点建立 TLS 时的 uTLS ClientHello。它不会把浏览器变成 Chrome，也不会修改 Cookie、页面脚本可读的设备特征或账号信息。v1.19.27 的官方发布记录已写明移除全局 global-client-fingerprint；当前文档要求按需设置在具体代理项中。
订阅配置里出现 global-client-fingerprint: chrome，或者某个节点带着 client-fingerprint: chrome，名字很容易让人误会：它是不是把浏览器伪装成 Chrome，从而躲过网站追踪？日志又提示全局字段已弃用时，是否说明连接已经不安全？
都不是。这项设置改的是 Mihomo 连接代理节点时的一小段 TLS 握手外观，不是网页里的浏览器身份。 弃用提示也不等于订阅泄露，它说明旧配置字段与当前内核的配置方式已经错位。
它改的是哪一段 TLS
日常打开 HTTPS 网站时，容易把两条连接看成一条：浏览器先把流量交给本机的 Mihomo，Mihomo 再通过代理协议连接节点；节点把浏览器原本要发往网站的数据继续转出去。
Mihomo 官方文档把 client-fingerprint 定义为客户端 uTLS 指纹，并把适用范围限定在 VMess、VLESS、Trojan 和 AnyTLS。它作用在 Mihomo 与这类节点建立 TLS 的 ClientHello 上。uTLS 项目对自己的边界也写得很窄：握手仍由 Go 的 TLS 实现完成，它主要改变 ClientHello 部分。
普通的端到端 HTTPS 访问中，网站与浏览器之间的 TLS 和网页交互仍在隧道里继续。节点外层看起来更像某类浏览器的 ClientHello，不会顺带改掉浏览器发给网站的 Cookie、登录状态或页面脚本能读取的设备信息。代理服务能看到什么，可另看HTTPS 经过机场时的可见范围；client-fingerprint 不会扩大或消除那条边界。
chrome 不是把浏览器变成 Chrome
官方支持的值里有 chrome、firefox、safari、iOS、android 和 random 等名称。这里的名称描述的是 ClientHello 模板，不是安装了哪个浏览器，更不是把当前浏览器完整复制一份。
MDN 对浏览器指纹的定义包含浏览器版本、语言和时区、可用编解码器、字体、设置状态、屏幕尺寸等多种特征，网站还可以通过 JavaScript 与 CSS 组合这些信息。Mihomo 的一个 TLS 配置项并不控制这些浏览器环境。
因此，把值设为 chrome 不能解决“网站仍认出同一设备”“账号仍被关联”或“页面仍显示原浏览器”这类问题。选 random 也只是改变这层 uTLS ClientHello 的生成方式，不会生成新的 Cookie、设备或账号身份。
三种“指纹”别混用
| 名称 | 实际对象 | 不能据此推断 |
|---|---|---|
client-fingerprint |
Mihomo 连接部分代理协议时的 uTLS ClientHello | 浏览器已经隐身，或网站看不到设备特征 |
fingerprint |
Mihomo 用来核对 TLS 服务端证书的证书指纹 | 它与 client-fingerprint 是同一个开关 |
| 浏览器指纹 | 网站从浏览器和系统环境组合出的识别特征 | 换一个代理节点就会自动重置 |
第二项尤其不能误删。Mihomo 的 TLS 文档把 fingerprint 用于证书校验，它解决的是“连接到的服务端证书是否符合预期”，而不是模仿客户端握手。遇到证书错误时，也不要拿 client-fingerprint 代替校验，更不要顺手打开 skip-cert-verify；两者的安全边界见跳过证书校验的风险说明。
旧的全局字段已经退场
当前 Mihomo 通用配置文档明确标注：全局 TLS 指纹已弃用，应把 client-fingerprint 放在具体代理项中。v1.19.27 的官方发布记录则写明移除 global-client-fingerprint，迁移方向同样是按代理设置。
这不意味着应该把旧值机械复制到每一个节点。官方列出的适用协议只有 VMess、VLESS、Trojan 和 AnyTLS；看到 Shadowsocks、Hysteria2、TUIC 等节点时，没有依据仅凭旧全局字段给它们补同名选项。配置由订阅或客户端生成时，直接修改生成文件还可能在下次更新时消失，订阅更新与自定义配置的边界解释了为什么运行时配置才是判断依据。
什么时候才该处理这条配置
如果只是看到旧全局字段或弃用警告，节点仍能正常连接，这条提示本身不能证明有隐私事故。应确认配置由谁维护、实际节点协议是什么，以及当前内核加载后的配置是否还使用该字段，再决定让订阅提供方、客户端维护者或自有配置跟进官方格式。
如果内核更新后恰好只有某类 TLS 节点无法连接，client-fingerprint 可以列入核对范围，但协议参数、SNI、证书验证和服务端兼容性仍是不同变量。本文没有对你的订阅或节点做连接测试，不能把一次超时归因给这个字段。
而当问题是网站识别、验证码、账号风控或浏览器追踪时，方向就不在这项配置上。此时应分别看出口 IP、账号状态和浏览器隐私设置，不要把节点 TLS 的 ClientHello 当成一键匿名开关。
资料来源
以下来源于 2026/8/22 复核。版本、支持平台和发布状态以后续官方页面为准。
持续更新
收到新教程，也欢迎纠错
想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。
读者互动
这篇内容对你有帮助吗？
最新评论
- 正在加载评论……