一份完整的七步清單：逐項自查 UA、時區、GPU、字型與自動化標誌，搶在偵測系統標記你之前找出指紋矛盾。
偵測系統不只判斷你的瀏覽器指紋是否獨特——它們還會判斷指紋是否連貫，這正是指紋一致性：為何訊號矛盾會讓你被標記一文的主題。那是理論；這篇文章是實踐：一份可以對照自己瀏覽器逐項核對的清單，搶在真正的偵測系統之前完成自查。請在另一個分頁開啟 BrowserInsight 的指紋檢測，邊看邊核對下面每一項。
核心要點
- 逐一核對七項：UA 與作業系統/平台、時區與 IP 地理位置、
Accept-Language與 IP 所在地區、GPU/WebGL 廠商與所聲稱的作業系統、已安裝字型與所聲稱的作業系統、螢幕尺寸/裝置像素比的合理性，以及自動化標誌。 - 每一項都在比較兩個理應講述同一台裝置同一個故事的訊號——任何一處矛盾，都是一致性評分系統首先會捕捉的目標。
- 借助 BrowserInsight 的指紋檢測與核心檢測，大多數檢查一分鐘內即可完成，無需額外工具。
- 單一矛盾很少會單獨觸發警報；這份清單最大的價值，是發現隱私擴充功能、VPN 或反偵測設定檔遺留下的多處小矛盾累積在一起的情況。
- 把它當作自查，而非保證——真正的偵測系統還會衡量行為與網路層訊號，這些是靜態清單看不到的。
開始之前
在一個分頁開啟指紋檢測工具，再在另一個分頁開啟核心檢測工具。指紋檢測會把你的 user-agent、WebGL 渲染器、時區、語言陣列、螢幕參數與字型清單集中顯示在一處；核心檢測則會把你所聲稱的瀏覽器與 JavaScript 引擎內部的真實表現進行比對——這對捕捉一個 UA 聲稱與實際運作不符的偽裝特別有用。按順序完成下面七項檢查，每項都不超過一分鐘。
1. User-Agent 與作業系統/平台
把你的 user-agent 字串和 navigator.platform 放在一起看，它們指向的是同一個作業系統嗎？UA 聲稱是 "Windows NT 10.0"，platform 卻給出 MacIntel；或者一個 iPhone UA 卻配上 Win32 的 platform 字串——這些都是內部矛盾。這兩個值理應來自同一個作業系統層級的 API，在真實裝置上不可能互相矛盾。
通過： UA 與 platform 指向同一作業系統家族。
未通過： UA 聲稱一種作業系統，navigator.platform 回報的是另一種。
2. 時區與 IP 地理位置
檢查 Intl.DateTimeFormat().resolvedOptions().timeZone——你作業系統回報的系統時區——是否與IP 情報工具查到的 IP 地理位置所在地區相符。America/Chicago 時區配上一個新加坡 IP 是可以解釋的（旅行者、VPN 使用者），但當它與其他訊號一起被評分時，正是網站如何偵測 VPN一文裡提到的那類矛盾。
通過： 時區所在地區與 IP 地理位置基本吻合。 未通過： 時區與 IP 地理位置指向不同大陸或時差，且沒有旅行/VPN 之類的合理解釋。
3. Accept-Language 與 IP 所在地區
對比 navigator.languages（以及請求攜帶的 Accept-Language 標頭）與你 IP 所在地區通常使用的語言。navigator.languages 反映的是作業系統的語言排序，而不只是瀏覽器設定——所以一個聲稱「美國 Chrome」的工作階段，如果 navigator.languages 只有 ["zh-TW", "vi"]、完全不含英語，本身就已經不尋常，一旦再疊加上面時區檢查的失敗，可信度會迅速下降。
通過： 至少有一種回報的語言與 IP 所在地區的常見語言相符。 未通過： 整個語言清單與聲稱的位置嚴重不符，尤其是與其他矛盾同時出現時。
4. GPU/WebGL 廠商與所聲稱的作業系統
開啟指紋檢測的 WebGL 部分，查看未遮蔽的渲染器字串。某些渲染後端只存在於特定作業系統上——渲染器字串中的 Direct3D 標記只可能來自 Windows，而 ANGLE (Apple, ...) 或基於 Metal 的字串只可能來自 macOS。如果你的 UA 聲稱是 macOS，渲染器字串卻帶有 Direct3D 後端，這種組合不僅罕見——在真實裝置上根本不可能出現。
通過： 渲染器字串所用的後端與 UA 聲稱的作業系統一致。 未通過： 渲染器字串指向一個在所聲稱作業系統上並不存在的後端。
5. 已安裝字型與所聲稱的作業系統
每種桌面作業系統都自帶一套其他系統沒有的預設字型：Windows 內建 Calibri、Segoe UI 之類的字型，macOS 內建 San Francisco、Helvetica Neue，常見 Linux 發行版則兩者都沒有。把指紋檢測回報的字型清單與你聲稱的作業系統對照——一個「Windows」工作階段卻偵測不到任何 Windows 專屬字型，或者字型清單混雜著只屬於 macOS 和只屬於 Windows 的字型，都說明這個設定檔是拼湊出來的，而不是在真實機器上運作的結果。
通過： 偵測到的字型中至少包含一些所聲稱作業系統專屬的字型，且不含其他作業系統專屬的字型。 未通過： 字型清單與所聲稱的作業系統相矛盾，或混雜了不可能共存的多個作業系統的字型。
6. 螢幕尺寸/裝置像素比的合理性
如果你的 UA 聲稱是手機（iPhone 或 Android），螢幕尺寸和觸控支援理應與之匹配。一個手機 UA 卻回報 2560×1440 的螢幕解析度且沒有觸控事件，或者裝置像素比不對應任何已上市的手機型號——這是桌面自動化工具替換 UA 字串卻沒有同步調整底層裝置模型時，最常見的破綻之一。
通過： 螢幕尺寸、裝置像素比與觸控支援，都與所聲稱 UA 對應的真實裝置一致。 未通過： 手機 UA 卻回報桌面級解析度和/或沒有觸控支援，反之亦然。
7. 自動化標誌
最後，檢查直接的自動化標誌：navigator.webdriver 是否回報為 true？window.chrome 在你所聲稱的瀏覽器上是否理應存在？navigator.plugins 與 Permissions API 回傳的結果是否內部一致、並非空值？這些是機器人偵測流程最先檢查的項目，往往在上面提到的各類一致性比對之前就已經完成，無頭瀏覽器偵測一文對此有更深入的介紹。
通過： navigator.webdriver 為 false/undefined，外掛與權限資料表現得像正常的桌面瀏覽器。
未通過： navigator.webdriver 回報為 true，或者其周邊屬性看起來像是被人為動過手腳。
如何解讀檢查結果
單獨一項未通過，往往並不致命——真實使用者偶爾也會出現在不尋常的組合裡。真正拉高分數的是累積效應：時區不符，加上語言不符，再加上字型清單與所聲稱的作業系統不符，這與單獨出現任何一項完全是兩回事。如果你正在使用隱私瀏覽器、擴充功能或 VPN，時區/IP 這一項預期會正常「未通過」——這是刻意為之的取捨，而非缺陷——但 GPU、字型與自動化標誌這幾項，在真實裝置上依然應當通過，因為改變網路路徑或 UA 字串並不會影響它們。
常見問題
我需要每一項都通過嗎？
不一定。VPN 使用者往往會刻意「未通過」時區/IP 這一項——這本來就是使用 VPN 的目的——同時其他每一項都能通過。這份清單最有用的地方，是發現那些出乎意料的未通過項，尤其是那些你無法用自己正在主動使用的工具來解釋的項目。
哪一項最難用隱私工具「修復」？
GPU/WebGL 渲染器字串（第 4 項）和已安裝字型（第 5 項）最難，因為它們分別來自硬體和作業系統本身，而不是某個瀏覽器設定——要令人信服地偽造它們，需要的遠不止改一個標頭或一個 JavaScript 可讀屬性那麼簡單。
我可以在手機上跑這份清單嗎？
可以，不過第 5 項（字型）和第 6 項（螢幕/DPR）的意義有所不同——行動作業系統自帶的字型集更窄、更統一，對手機 UA 而言螢幕/觸控一致性才是主要的檢查項。行動裝置瀏覽器指紋識別一文詳細介紹了行動裝置上真正具有區分度的訊號。
結論
這七項檢查都不需要 BrowserInsight 現有用戶端工具之外的任何特殊手段。按順序逐一核對——UA/platform、時區/IP、語言/IP、GPU/作業系統、字型/作業系統、螢幕/觸控，以及自動化標誌——就能發現真正的一致性評分系統所尋找的同一批矛盾，且順序也與大多數偵測流程一致：先做代價低、幾乎不會誤判的檢查，再做機率性的檢查。一起執行指紋檢測與核心檢測，你就能在任何偵測系統之前，知道自己的設定講的是不是同一個前後一致的故事。
推薦閱讀：
