從 User-Agent 到 Client Hints：瀏覽器指紋的真實演進與業界誤區

在實際風控系統裡，CH 已被廣泛用於設備辨識、反作弊、環境一致性校驗。但市面上大量工具只會“填字段”，並不了解 CH 的真實行為規則，不知道不同字段之間的邏輯關係，也不了解 CH 與底層指紋系統是如何綁定的。

這篇文章從工程與風控的真實需求出發，講清楚三件事：CH 在真實世界為何重要？為什麼多數工具的 CH 模擬都是錯的？具體錯在哪裡？ AdsPower 如何讓 CH 與 UA、navigator、TLS 等指紋做到「裝置級一致」？

一、為什麼傳統 UA 已經不夠用了？

Chrome 明確表示：UA 字串將被逐步簡化，只保留最基礎的大版本號；細節能力資訊遷移到 Client Hints，高熵欄位只有在伺服器請求時才傳回。這意味著光偽造一個 UA，已經不可能讓系統相信這是真實設備。

風控系統最常見的判定方式是這種「不一致」：

• UA 顯示 macOS 14，但 CH-Platform-Version 卻是 macOS 13
• UA 是行動設備，但 CH-UA-Mobile 欄位仍是 ?0
• CH 是arm64，但 navigator.hardwareConcurrency 就是 x86
• 瀏覽器版本號一致，但 Full-Version-List 無法推導

這些矛盾都是非常典型的「假設備訊號」。

CH 與 UA 不一致，是目前市面上大部分指紋瀏覽器被抓到的核心原因。

二、Client Hints 的關鍵價值：「校驗一致性」

在反作弊與裝置識別的體系裡，CH 之所以敏感，不是因為它提供更多字段，而是因為：

1.它包含高熵欄位（High Entropy Values）

真實瀏覽器的 CH 是“按需返回”，高熵字段包含非常具體的設備信息，這些字段的特點是：唯一性強、難偽造、易判定設備是否“連貫”。

2.CH 不會被單獨判斷，而是與其他指紋協同校驗

真實風控系統會看：

• CH 與 UA 是否一致
• CH 與 TLS（JA3/JA4）是否來自同一種瀏覽器
• CH 與 navigator.xxx（platform / concurrency / DPR）是否連貫
• CH 與 OS 平台特徵是否相符（尤其 iOS / Android）

所以偽造字段並不難，困難的是「把所有字段變得像同一個設備」。 這也是為什麼很多工具看似“字段齊全”，但依然很容易被判定異常。

三、為什麼業界大部分 CH 模擬都是錯的？

我們在分析市面上多款指紋瀏覽器時，看到很多非常常見的錯誤，包括：

1.CH 與 UA 不一致（最常見的錯誤）

例如 UA 顯示 macOS 14.1，CH 卻回傳 macOS 101.0（非真實存在版本），這是風控系統一眼就能辨識的異常。

2. 移動 UA，但 CH-UA-Mobile 仍然是 ?0

真實行動裝置必須是 ?1。

3. Full-Version-List 的推導邏輯錯誤

例如 Chrome 120 的 Full-Version-List 卻傳回 115 的特性。這是大量「填字段型工具」常犯的問題。

4. DPR、Device-Memory 等值與真實設備矛盾

例如 Mac 設備 DPR 返回 1（真實 DPR >= 2）、iPhone DPR 返回 < 2（不可能）、Windows 機器 Device-Memory 返回 1GB（極少數超低端機才會出現）。

5. 無視瀏覽器差異與行為規則

如Safari 原本不支援的欄位卻被「偽造出來」、Firefox 不回傳 CH 但工具卻強行新增、iOS 平台回傳了不存在的 Model 欄位。這些行為在風控系統裡非常顯眼。

這些行為在風控系統中非常顯眼。

四、AdsPower 如何實現真正的 CH 一致性？

AdsPower 的核心不是“填值”，而是做到“整體環境一致性”。具體來說，包含以下工程能力：

① 自動產生與 UA 綁定的 CH（最關鍵）

AdsPower 在建立環境時會根據所選瀏覽器版本產生真實 CH 模式，依瀏覽器核心的真實邏輯推導平台版本，保證 CH 與 UA 完整對齊（Brand、Platform、Version）。這一點很重要，因為真實瀏覽器的 CH 與 UA 是有嚴格對應關係的，不可能隨便拼湊。

使用者無需手動設置，所有 CH 欄位都根據真實瀏覽器規則生成，確保從頂層到底層的統一性。如下圖位置可查看部分資訊：

② 遵循瀏覽器高熵欄位的「回傳策略」

不是所有 CH 都會預設返回，AdsPower 也遵循真實瀏覽器規則，預設發送低熵字段，高熵字段按瀏覽器行為模擬，不會返回 Safari 不支援的字段（否則直接暴露是假瀏覽器）

③ 與 navigator、screen、devicePixelRatio 一致

AdsPower 會同時保證DPR 與螢幕參數一致、Device-Memory 與平台類型一致、CH-Mobile 欄位與 UA 匹配、架構（Arm/x86）與整個系統邏輯一致。也就是說不是單獨偽造 CH，而是讓所有 JS 屬性、HTTP 頭、環境能力都自洽。

④ 與 TLS/JA3/JA4 指紋連動

CH 必須與 TLS 指紋組合保持一致，否則很容易被判定為類比瀏覽器。 AdsPower 會根據瀏覽器版號自動配對對應的 TLS 行為，確保整體指紋不衝突。

五、真實場景裡的價值：為什麼 CH 做不好用戶會出問題？

場景 1：同一個帳號，異地登入

如果 CH 模擬不真實、或 UA/CH 不一致，風控系統會認為你是「模擬設備」；或者同一帳號短時間出現兩個不同硬件，就容易高危。

場景 2：大量帳號批量養號

批量場景下最常見的封鎖原因：「設備太統一」導致同一工具產生的 CH 結構相同、熵值特徵一致。 AdsPower 的隨機化策略避免了這種「模板化設備」問題。

場景 3：透過代理切換到多個國家

如果切換了 IP，但 CH 的作業系統版本、設備型號等資訊仍完全一致，風控系統會懷疑你透過工具「假裝」是不同設備，帳號風險上升。 AdsPower 會幫助使用者自動維持跨區域環境的一致性邏輯，而不是簡單換 IP。

六、總結

在 UA 凍結時代，Client Hints 已變成裝置辨識的核心訊號之一。它的難點不在於“有哪些欄位”，而是如何讓 CH、UA、TLS、JS 環境、系統特徵一起組成邏輯一致的裝置畫像。而這正是 AdsPower 的技術能力所在，不是拼字段，而是建構「連貫的瀏覽器生態行為」。這才是決定指紋成功率、帳號安全的關鍵。

*本文旨在從技術與工程角度，解釋瀏覽器指紋、Client Hints 等機制在實際風控場景中的工作原則文中所提到的功能、行為模擬方式，僅用於幫助使用者瞭解瀏覽器環境一致性的重要性，並不保證可規避任何平台的偵測策略。各平台的安全策略會持續更新，請在遵守其使用規範與相關法規的前提下，合理使用相關工具和技術。