站台在 2026 年如何偵測無頭瀏覽器：CDP 洩漏、一致性檢查與什麼才有幫助

你從原生 HTTP 換到了真正的瀏覽器。TLS 指紋：貨真價實的 Chrome。IP：住宅。而站台還是知道。在 2026 年，無頭瀏覽器偵測早已遠遠超越 navigator.webdriver — 當前這一代檢查偵測的是自動化協定本身，而大多數「stealth」外掛在修補昨天的訊號的同時，卻大聲地展現著今天的訊號。

本文會盤點站台現在實際上會檢查什麼、大致依它們檢查的順序，以及在每一層真正有幫助的是什麼。它與 JA3/JA4 TLS 指紋（網路層）和 IP 信譽與 ASN（位址層）一起構成這個偵測三部曲 — 而這一篇是瀏覽器層。

第 1 層：經典項（已解決，但仍會被檢查）

• navigator.webdriver — 規範要求在自動化下為 true。Playwright/Puppeteer 的 stealth 設定會把它藏起來；Chrome 的 --disable-blink-features=AutomationControlled 原生就能處理。站台仍會檢查它，因為這免費又能抓到天真的機器人。
• 無頭 UA 字串 — User-Agent 裡的 HeadlessChrome/。用新的無頭模式（headless=new）即可修正，它會使用真正的 Chrome 二進位檔路徑。
• 缺少的瀏覽器配件 — navigator.plugins 為零、沒有 chrome.runtime、outerWidth 為 0×0。舊的無頭模式這些全都過不了；新的無頭模式大多能通過。

如果一個目標只檢查第 1 層，搭配 headless=new 的現代 Playwright 就能直接走過去。認真的目標多年前就往前走了。

第 2 層：CDP 偵測 — 2026 年的主力

Playwright 與 Puppeteer 透過 Chrome DevTools Protocol 來驅動 Chrome，而 CDP 會留下頁面 JavaScript 可觀察到的執行期副作用：

// The classic CDP leak: serialization callbacks
const err = new Error();
Object.defineProperty(err, "stack", {
  get() {
    // This getter fires DURING console serialization -
    // which only happens when DevTools/CDP is attached
    window.__cdp_detected = true;
  },
});
console.debug(err);

這類變體 — console 序列化期間的 getter 副作用、Runtime.evaluate 的時序異常、被修補過的原生函式上 toString() 的行為 — 存在於每一套商用反機器人套件裡。關鍵在於：這偵測的是協定，而不是無頭模式。一個有頭、打過 stealth 修補、看起來完美像人的 Chrome，只要是透過 CDP 驅動的，照樣會失敗。

有幫助的是：

• 打過修補的執行期 — 重新編譯的驅動程式（例如 patchright、rebrowser-patches），把 CDP 副作用移出頁面可觀察的範圍。它們落後於上游版本；要釘住版本，每次升版後重新測試。
• 非 CDP 的自動化 — 透過 OS 層級輸入或無障礙 API 驅動瀏覽器的工具，不會在頁面裡留下協定痕跡，代價是速度與 API。
• 專為此打造的 stealth 瀏覽器 — 像 Camoufox（強化版 Firefox）這類引擎完全繞開 Chromium-CDP 檢查；Firefox 的自動化介面不一樣，也較少被針對。

第 3 層：環境一致性

除了痕跡之外，現代系統還會檢查你的瀏覽器故事內部是否一致：

檢查項	機器人的破綻
Canvas / WebGL 渲染雜湊	SwiftShader/llvmpipe 軟體渲染 = 伺服器 GPU；或一個被一萬個「不同使用者」共用的雜湊
字型與編解碼器	Windows User-Agent 下卻是 Linux 伺服器的字型集合
時區 × 語系 × IP 地理位置	Intl 說 UTC，IP 說德州，Accept-Language 說 de-DE
螢幕度量	1920×1080 卻沒有工作列、devicePixelRatio 剛好是 1、視窗從未被調整大小
硬體並行數／記憶體	對一個自稱是手機的頁面回報 96 核心
行為微訊號	滑鼠沒有熵值、瞬間填完表單、以固定的 100px 步幅捲動

這就是 DIY stealth 的死亡之地：你套用的每個修補都必須與其他每個訊號一致。一個在 Linux 容器上偽造的 Windows UA，會同時和字型、GPU 字串與 TCP 指紋互相矛盾。一致性勝過完美 — 一個誠實的有頭 Linux Chrome，得分會比一個拙劣偽造的「Windows」更好。

而下面那一層仍然適用

如果位址層已經燒掉了，這一切都不重要：一個在資料中心 ASN 上完美無瑕的瀏覽器，仍然是「一個在資料中心裡完美無瑕的瀏覽器」— 而且無頭偵測的門檻是會隨 IP 信譽調整的。同一個瀏覽器從一個被標記的 IP 出去會收到更多 JavaScript 挑戰。住宅出口實際上降低了瀏覽器層需要存活下來的審查強度：

browser = p.chromium.launch(
    headless=False,                      # headed survives more checks
    args=["--disable-blink-features=AutomationControlled"],
    proxy={
        "server": "us.jibaoproxy.com:913",
        "username": "USERNAME", "password": "PASSWORD",
    },
)

實務檢查清單

1. 使用新的無頭模式或有頭模式；絕不用舊版無頭。
2. 對任何認真的目標都假設有 CDP 偵測 — 用打過修補的執行期、非 CDP 驅動程式，或一個強化過的非 Chromium 引擎。
3. 別盲目地疊加 stealth 外掛；每一個沒被修補的 toString() 本身就是一個訊號。少而一致的修補才會贏。
4. 讓整個故事相符：時區 = IP 地理位置 = 語系；GPU 對於宣稱的 OS 要說得通。
5. 加入輸入熵值 — 彎曲的滑鼠路徑、可變的延遲、偶爾往回捲。
6. 在面對真實目標之前，先對著一個中立的觀察者測試。

總結

• 第 1 層（webdriver 旗標、無頭 UA）是基本門檻 — 新的無頭模式就能通過。
• 第 2 層才是 2026 年偵測的所在：CDP 協定痕跡連有頭、打過 stealth 修補的 Chrome 都抓得到；用打過修補的執行期或非 CDP 驅動程式。
• 第 3 層是一致性：每一個偽造的值都必須與 OS、GPU、字型、時區與 IP 地理位置相符。
• 偵測門檻會隨 IP 信譽調整 — 乾淨的住宅出口能為你的瀏覽器爭取喘息空間。
• 每次更新相依套件後都用經驗驗證；stealth 腐壞得很快。