JA3 與 JA4 TLS 指紋詳解（以及如何測試你自己的）

你的爬蟲送出完美的 Chrome 標頭，跑在乾淨的住宅 IP 後面，卻在第一個請求就拿到 403。沒有驗證碼、沒有挑戰頁、沒有任何可破解的東西。網站在交換任何一個 HTTP 位元組之前就辨識出了你——在 TLS 握手期間。

本文解釋 JA3 與 JA4 指紋實際上如何運作、為何它們是 2026 年每個主要反機器人系統默默運轉的主力，以及如何在十秒內看到你自己的指紋。如果你想先看繞過工具，我們在 用 curl_cffi & tls-client 繞過 TLS 指紋 講過了——這篇是談偵測端如何運作的姊妹作。

十秒測試

在談理論之前，先看看你自己的握手。打開我們免費的 JA3/JA4 檢查器——它會把你的用戶端剛剛呈現的 TLS 指紋回傳給你，並告訴你它匹配到什麼：

# From a terminal - see what curl's TLS looks like:
curl https://www.jibaoproxy.com/tools/fingerprint.html

# Then open the same URL in Chrome and compare.

兩個都跑一遍，你就會看見整篇文章的重點：curl 與 Chrome 產生完全不同的指紋，不管你設了什麼 User-Agent 標頭。

TLS 握手裡發生了什麼

每個 HTTPS 連線都以一則 ClientHello 訊息開始，在任何加密開始之前以明文送出。在其中，你的用戶端宣告：

• 它支援的 TLS 版本
• 它接受的密碼套件有序清單
• 擴充功能的有序清單（SNI、ALPN、key share、session tickets…）
• 支援的橢圓曲線與點格式

偵測的洞見在這裡：這些清單以及它們的確切順序，是寫死在你用戶端編譯時所連結的 TLS 函式庫裡的。Chrome 的 BoringSSL 宣告某一個特定組合。Python 的 OpenSSL 宣告另一個不同的。Go 的 crypto/tls 又是第三個。你無法用標頭改變這一點——它是在 HTTP 層之下、由函式庫本身協商的。

JA3：把握手雜湊化

JA3（Salesforce，2017）把 ClientHello 的五個欄位——TLS 版本、密碼、擴充功能、曲線、點格式——串接成一個字串，再做 MD5 雜湊：

771,4865-4866-4867-49195-49199,0-23-65281-10-11-35-16,29-23-24,0
              |
              v  MD5
        cd08e31494f9531f560d64c695473da9

每個 TLS 堆疊一個雜湊。Windows 上每一份 Chrome 137 都產生（幾乎）相同的 JA3；OpenSSL 3.x 上每個 python-requests 都產生那個相同而不同的 JA3。防禦方維護查找表：雜湊 X ＝ Chrome、雜湊 Y ＝ requests、雜湊 Z ＝ Go 機器人。如果你的 User-Agent 說是 Chrome，但你的 JA3 說是 OpenSSL，你就被封鎖了——即時、無聲、廉價。

JA4：2026 標準

JA3 有它的問題：Chrome 在 2023 年開始隨機化擴充功能順序（讓天真的 JA3 失效），而 MD5 沒有結構——一個雜湊無法告訴你兩個用戶端為何不同。JA4（FoxIO，2023）把兩者都修好了，而且是當今認真的廠商在跑的：

JA4 = t13d1516h2_8daaf6152771_b0da82dd1658
       |            |             |
       a: protocol  b: ciphers    c: extensions
       (TLS 1.3, 16 ciphers,      (sorted, truncated
        h2 ALPN, domain SNI)       SHA256)

• 排序而非有序的密碼／擴充功能雜湊——對 Chrome 的隨機化免疫。
• 三個可讀的區段——防禦方能對部分指紋做匹配（「任何只帶 ALPN h1 的 TLS 1.2 用戶端」）。
• 一整個家族：JA4H（HTTP 標頭）、JA4T（TCP 選項）、JA4X（憑證）——跨層一致性檢查。一個 Chrome JA4 配上 curl 的 JA4H，本身就是一個警示。

誰拿這個來對付你

每個重要的系統：Cloudflare 在其機器人管理規則中直接揭露 JA3/JA4；DataDome 與 PerimeterX 把它餵進它們的網路層評分（參見我們的 DataDome/PerimeterX 指南）；Akamai 跑 TLS 指紋比任何人都久。它之所以流行，是因為它計算免費、無法從 HTTP 層偽造，且能在任何 JavaScript 需要執行之前抓到 90% 的天真自動化——有史以來寫過的每個 requests/httpx/axios/Go-http 腳本。

為何單靠代理沒用

這讓人意外：代理改變你的 IP，但你的 TLS 握手原封不動地通過。CONNECT 隧道（或 SOCKS5 串流）把你的 ClientHello 位元組原樣帶到目標。住宅 IP ＋ requests 函式庫的 JA3 ＝「一個跑在住宅 IP 上的機器人」。比機房 IP 好，仍然是個機器人。

IP 與 TLS 指紋是獨立的訊號，兩者你都需要乾淨：

IP	TLS 指紋	2026 的判定
機房	函式庫（requests/Go）	在所有在意的地方都被封鎖
住宅	函式庫	在檢查 JA4 的網站上被封鎖
機房	瀏覽器模擬	因 IP 信譽被封鎖
住宅	瀏覽器模擬	通過網路層檢查

讓你的指紋與你的故事相符

依工具分兩條路：

HTTP 用戶端——使用一個重新實作瀏覽器確切 ClientHello 的模擬函式庫：curl_cffi（Python）、tls-client（Python/Go）、got-scraping（Node）。完整可用的程式碼在 curl_cffi 指南 裡：

from curl_cffi import requests

r = requests.get(
    "https://target.example",
    impersonate="chrome",
    proxies={"https": "socks5h://USERNAME:[email protected]:913"},
)

真實瀏覽器（Playwright、瀏覽器代理人、反偵測瀏覽器）——在 TLS 層無事可做；指紋貨真價實就是 Chrome 的。你的風險在別處：IP 信譽與 CDP 偵測。

然後要驗證，別假設。版本會漂移——一個釘死在 Chrome 120 握手的模擬函式庫，在 2026 年讀起來像「可疑地過時的瀏覽器」。每次相依套件更新後都重新測試：

總結

• JA3/JA4 對 TLS 函式庫做指紋，而非標頭——偵測發生在 HTTP 存在之前。
• JA4 是 2026 標準：防隨機化、可讀、跨層（JA4H/JA4T/JA4X）。
• 代理碰不到你的 TLS 指紋；IP 與握手是獨立訊號——兩者都要乾淨。
• HTTP 用戶端用 curl_cffi/tls-client 模擬；真實瀏覽器天生乾淨。
• 每次更新後到 www.jibaoproxy.com/tools/fingerprint.html 驗證。