瀏覽器指紋檢測：免費線上檢測 Canvas、WebGL、AudioContext 及裝置獨特性

僅修改 User-Agent 字串不僅無法實現有效偽裝，反而極易產生致命的「跨層指紋矛盾」，被高階風控系統判定為主動偽造：一是應用層與傳輸層協議棧矛盾，若在 Windows 電腦上將 UA 改為 iPhone Safari，應用層聲稱是 Apple 移動端，但底層 TCP 握手包依然是 Windows 核心（無 TS 選項且選項排列為 MSS, NOP, WS, NOP, NOP, SACK_PERM），與 Apple 專屬的 8 項選項序列完全相悖；二是 HTTP/3 與 HTTP/2 協議實現差異，Chromium、WebKit 和 Gecko 核心在 HTTP/3 單向流對映（Chromium 為 2:control,10:encoder，WebKit 為 2:control,6:encoder）以及 HTTP/2 偽頭順序（Chromium 嚴格為 m,a,s,p，非 Chromium 為 m,s,a,p）上存在硬編碼差異。修改 UA 僅變更了一個請求頭，卻與底層傳輸層和協議層形成無法調和的衝突。

💡 詳情可參考 代理匿名度檢測 中的跨層協議棧推斷分析。

防關聯/指紋瀏覽器通常透過定製 Chromium 核心或注入 JavaScript Hook 腳本，重寫 navigator 屬性、向 Canvas/WebGL 影象注入細微隨機噪點，並偽造螢幕解析度與音訊上下文來生成獨立指紋。但高階風控依然能從深層捕獲破綻：一是原型鏈與原生函式篡改痕跡，JS Hook 容易破壞 Function.prototype.toString、屬性描述符（getOwnPropertyDescriptor）及原型鏈繼承結構；二是著色器與底層硬體規律，注入的噪點雖改變了 Canvas 雜湊，但物理 GPU 的浮點運算精度與著色演算法規律依然存在，非自然的人工噪點反而形成了高區分度的「加噪特徵」；三是底層網路協議棧未同步模擬，絕大多數指紋瀏覽器無法偽造宿主機的作業系統 TCP/TLS 握手特徵。

不能。無痕模式（Incognito Mode）的設計初衷是防止「本地裝置留下瀏覽痕跡」，而不是防禦「遠端伺服器的特徵識別」：無痕模式在關閉視窗後會自動清除當次會話的 Cookie、LocalStorage、瀏覽歷史與表單快取；但指紋追蹤是透過 JavaScript 採集你裝置的物理硬體與執行環境特徵（如顯示卡型號、Canvas 渲染畫素差異、WebGL 著色器引數、系統已安裝字型、音訊取樣衰減、CPU 核心數與螢幕色彩深度等）。在無痕模式下，你的物理硬體、顯示卡驅動和瀏覽器核心未發生任何變化，遠端伺服器計算出的硬體指紋雜湊與正常模式完全一致。

這不是誤判，而是 iOS 平臺的底層執行機制使然：一是 Apple App Store 政策約束，蘋果應用商店稽核指南明確規定，所有執行在 iOS/iPadOS 上的第三方瀏覽器（包括 Chrome、Edge、Firefox 等），其底層渲染引擎與網路層必須強制使用 Apple 提供的 WebKit / WKWebView 框架，禁止內建 Chromium Blink 或 Gecko 引擎；二是協議層實測驗證，iOS 上的 Chrome（CriOS）在 HTTP/3 單向流對映中嚴格輸出 WebKit 專屬特徵（2:control,6:encoder），與桌面及 Android 平臺的 Chromium 特徵（2:control,10:encoder）完全不同。因此 iOS 版 Chrome 本質上是基於 WebKit 封裝的瀏覽器，識別為 WebKit 核心是完全準確的技術事實。

能，但有明確的條件和上限，而且這跟「身份認證」完全不是一回事。本站的身份恢復按四層加權：一是硬體錨定層（GPU 型號串、音效卡基準延遲、媒體裝置數量）；二是系統高熵層（已安裝字型列表、語音合成包列表）；三是瀏覽器可變層（Canvas 渲染雜湊、AudioContext 運算雜湊）；四是顯示環境層（螢幕解析度、時區）。四層累加之後，必須同時滿足兩個條件才允許認領一個既有身份：總分過線，並且至少命中一項高熵核心特徵（字型列表、語音包、Canvas、Audio 四者之一）。第二個條件是刻意加的——GPU 型號、時區、螢幕解析度這類公開低熵屬性在同一批裝置裡大量重複，無論怎麼組合都不允許單獨構成身份；早期版本沒有這道門時，僅憑這三項就足以把一臺陌生裝置錯認成他人。此外硬體錨定層是一票否決：CPU 邏輯核心數不同、記憶體相差超過 4GB、音效卡基準延遲相差超過 0.005 秒、最大觸控點數不同，任一條成立即判為不同機器，根本不進入打分。

⚠ 這套機制的目標是讓同一臺裝置的多次觀測能穩定對齊，不是證明你是誰——它不構成身份認證，也不應被當作認證使用。

兩者都屬於「系統高熵特徵」，共同點是不需要任何許可權、頁面上也看不到動靜。AudioContext 指紋：在 OfflineAudioContext 裡把一個振盪器（Oscillator）接進動態壓縮器（DynamicsCompressor）離線渲染一段波形，讀回浮點取樣值再取雜湊。同一張音訊圖在不同瀏覽器實現、不同數學庫與浮點後端上會產生末位差異，全程靜音、不播放聲音。與它相鄰但相互獨立的是 AudioContext.baseLatency：這個值反映音效卡輸出緩衝區大小，由音訊驅動與硬體決定，本站把它當作硬體錨定使用（雙方差值超過 0.005 秒即判為不同機器），而不是當作身份雜湊——兩者來源不同，不要混為一談。字型列舉指紋：逐個測量候選字型列表裡每種字型渲染同一串文字的寬高，與回退字型不一致即說明該字型已安裝。裝了哪些字型高度依賴你裝過什麼軟體（Office、Adobe 套件、開發工具、輸入法各自會帶一批字型），所以字型列表通常是全套特徵裡區分度最高的單項。

💡 穩定性上的差別在於變化的誘因：Canvas 與 Audio 雜湊會隨瀏覽器版本升級而改變（渲染棧和數學庫一直在動），而字型列表只在你裝卸軟體時才變——這就是它權重最高的原因。

MSS（Maximum Segment Size）是 TCP 握手時通告的單包最大載荷，本站直接從你的 SYN 包裡讀到，不需要你安裝或配置任何東西。把它加回 IP 與 TCP 頭開銷就還原出這條鏈路的 MTU：IPv4 加 40 位元組，IPv6 加 60 位元組。常見取值有明確含義：1500 是標準乙太網／雲主機裸鏈路；1492 是 PPPoE 撥號（DSL / FTTH 家庭寬頻），PPPoE 頭正好佔掉 8 位元組；小於等於 1420 說明流量被再封裝了一層，典型來源是 WireGuard / Tailscale 一類的 VPN 隧道，或者經過 CDN 回源。

⚠ 關鍵在於：MSS 描述的是鏈路，不是裝置。它只能告訴你「這條路徑上存在封裝」，單獨並不能證明你在用代理——家庭寬頻的 PPPoE 同樣不是 1500。真正有意義的是矛盾：應用層聲稱的位置與鏈路特徵長期對不上（比如聲稱本地直連、MSS 卻穩定落在隧道區間），那才構成訊號。詳見 代理匿名度檢測。

這是我們最在意的一類錯誤（誤合併），防線有三道，任何一道攔下都不會認領。一是分桶硬隔離：候選身份先按作業系統平臺與瀏覽器核心分桶，跨桶絕不比較——所以同一臺機器上的兩個不同核心瀏覽器，哪怕硬體引數完全一致，也永遠不會被合併成同一個身份。二是硬體錨定一票否決：CPU 邏輯核心數、記憶體容量（容差 4GB）、音效卡基準延遲（容差 0.005 秒）、最大觸控點數，任一項在雙方都測到且衝突，直接排除，不進入打分環節。三是核心特徵准入：即便分數很高，只要沒有命中任何一項高熵核心特徵（字型、語音包、Canvas、Audio），也不允許認領——這道門專門用來擋「一堆公開低熵屬性湊出高分」的情況。

⚠ 誠實說明：我們目前沒有基於自然流量的誤合併率實測值可以公佈。這個指標要靠長期真實訪問量才統計得出來，樣本量足夠之前給出任何數字都是不誠實的。