فینگرپرینتینگ JA3 و JA4 در TLS به زبان ساده (و چطور فینگرپرینت خودتان را تست کنید)

اسکرپر شما هدرهای کاملاً Chrome-مانند می‌فرستد، پشت یک IP مسکونی تمیز اجرا می‌شود، و باز هم همان درخواست اول با ۴۰۳ رد می‌شود. نه کپچایی، نه صفحه چالشی، هیچ چیزی برای حل کردن. سایت شما را پیش از آنکه حتی یک بایت HTTP رد و بدل شود شناسایی کرده — درست در حین TLS handshake.

این مقاله توضیح می‌دهد که فینگرپرینتینگ JA3 و JA4 واقعاً چطور کار می‌کند، چرا این‌ها موتور خاموش اما اصلی هر سیستم ضدبات بزرگ در سال ۲۰۲۶ هستند، و چطور می‌توانید فینگرپرینت خودتان را در ده ثانیه ببینید. اگر اول دنبال ابزار عبور از این سد هستید، آن را در عبور از TLS Fingerprinting با curl_cffi و tls-client پوشش داده‌ایم — این مطلب همراهِ آن است و سمت تشخیص را توضیح می‌دهد.

تست ده‌ثانیه‌ای

پیش از تئوری، به handshake خودتان نگاه کنید. چکر رایگان JA3/JA4 ما را باز کنید — فینگرپرینت TLS که کلاینت شما همین الان ارائه داده را بازتاب می‌دهد و می‌گوید با چه چیزی منطبق است:

# از یک ترمینال - ببینید TLS مربوط به curl چه شکلی است:
curl https://check.jibaoproxy.com/api/fingerprint

# سپس همان URL را در Chrome باز کنید و مقایسه کنید.

هر دو را اجرا کنید و نکته اصلی کل این مقاله را می‌بینید: curl و Chrome فینگرپرینت‌های کاملاً متفاوتی تولید می‌کنند، فرقی نمی‌کند چه هدر User-Agent ای ست کنید.

در یک TLS Handshake چه می‌گذرد

هر اتصال HTTPS با یک پیام ClientHello شروع می‌شود که پیش از شروع هرگونه رمزنگاری، به‌صورت متن ساده فرستاده می‌شود. در آن، کلاینت شما این‌ها را اعلام می‌کند:

• نسخه TLS که پشتیبانی می‌کند
• یک فهرست مرتب از cipher suiteهایی که می‌پذیرد
• یک فهرست مرتب از extensionها (SNI، ALPN، key share، session ticket…)
• منحنی‌های بیضوی و point format های پشتیبانی‌شده

نکته کلیدی تشخیص این است: این فهرست‌ها و ترتیب دقیقشان در دل کتابخانه TLS ای که کلاینت شما با آن کامپایل شده، تثبیت شده‌اند. BoringSSL مربوط به Chrome یک ترکیب مشخص اعلام می‌کند. OpenSSL پایتون ترکیب دیگری. crypto/tls زبان Go ترکیب سومی. این را با هدرها نمی‌توانید تغییر دهید — این زیر لایه HTTP و توسط خودِ کتابخانه مذاکره می‌شود.

JA3: هش کردن Handshake

JA3 (سیلزفورس، ۲۰۱۷) پنج فیلد از ClientHello — نسخه TLS، cipher ها، extension ها، منحنی‌ها، point format ها — را به هم می‌چسباند و آن رشته را با MD5 هش می‌کند:

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

یک هش به ازای هر استک TLS. هر نسخه از Chrome 137 روی ویندوز (تقریباً) همان JA3 را تولید می‌کند؛ هر python-requests روی OpenSSL 3.x همان JA3 متفاوت را تولید می‌کند. مدافعان جدول‌های جست‌وجو نگه می‌دارند: هش X = Chrome، هش Y = requests، هش Z = بات Go. اگر User-Agent شما می‌گوید Chrome اما JA3 شما می‌گوید OpenSSL، بلاک می‌شوید — فوری، خاموش، و ارزان.

JA4: استاندارد ۲۰۲۶

JA3 مشکلاتی داشت: Chrome در سال ۲۰۲۳ شروع به تصادفی‌سازی ترتیب extension ها کرد (که JA3 ساده را می‌شکند)، و MD5 بدون ساختار است — یک هش هیچ چیزی درباره اینکه چرا دو کلاینت با هم فرق دارند به شما نمی‌گوید. JA4 (FoxIO، ۲۰۲۳) هر دو را حل کرد و چیزی است که وندورهای جدی امروز اجرا می‌کنند:

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

• هش کردن cipher/extension به‌صورت مرتب‌شده، نه به ترتیب اصلی — مصون از تصادفی‌سازی Chrome.
• سه بخش خوانا — مدافعان می‌توانند روی فینگرپرینت‌های جزئی منطبق کنند («هر کلاینت TLS 1.2 که فقط ALPN h1 دارد»).
• یک خانواده کامل: JA4H (هدرهای HTTP)، JA4T (آپشن‌های TCP)، JA4X (گواهی‌ها) — بررسی‌های سازگاری بین‌لایه‌ای. یک JA4 از جنس Chrome همراه با یک JA4H از جنس curl، خودش یک پرچم قرمز است.

چه کسانی این را علیه شما به کار می‌برند

هر سیستمی که اهمیت دارد: Cloudflare مستقیماً JA3/JA4 را در قوانین bot-management خود در دسترس می‌گذارد؛ DataDome و PerimeterX آن را وارد امتیازدهی لایه‌شبکه‌شان می‌کنند (راهنمای DataDome/PerimeterX ما را ببینید)؛ Akamai بیش از هر کس دیگری سابقه اجرای TLS fingerprinting دارد. محبوب است چون محاسبه‌اش رایگان است، جعل کردنش از لایه HTTP غیرممکن است، و ۹۰٪ اتوماسیون‌های ساده را — هر اسکریپت requests/httpx/axios/Go-http که تا به حال نوشته شده — پیش از آنکه نیاز به اجرای هیچ JavaScript ای باشد، می‌گیرد.

چرا پروکسی به‌تنهایی کمکی نمی‌کند

این برای خیلی‌ها تعجب‌آور است: پروکسی IP شما را عوض می‌کند، اما TLS handshake شما بدون تغییر عبور می‌کند. تونل CONNECT (یا جریان SOCKS5) بایت‌های ClientHello شما را عیناً به مقصد می‌رساند. IP مسکونی + JA3 کتابخانه requests = «یک بات که روی یک IP مسکونی اجرا می‌شود». بهتر از IP دیتاسنتر، اما همچنان یک بات.

IP و فینگرپرینت TLS دو سیگنال مستقل هستند و هر دو باید تمیز باشند:

IP	فینگرپرینت TLS	حکم در ۲۰۲۶
دیتاسنتر	کتابخانه (requests/Go)	همه‌جا که اهمیت می‌دهد، بلاک
مسکونی	کتابخانه	روی سایت‌هایی که JA4 چک می‌کنند، بلاک
دیتاسنتر	تقلید مرورگر	به‌خاطر اعتبار IP، بلاک
مسکونی	تقلید مرورگر	از بررسی‌های لایه‌شبکه عبور می‌کند

هماهنگ کردن فینگرپرینت با داستانتان

دو مسیر، بر اساس ابزار:

کلاینت‌های HTTP — از یک کتابخانه تقلید (impersonation) استفاده کنید که ClientHello دقیق یک مرورگر را بازپیاده‌سازی می‌کند: curl_cffi (پایتون)، tls-client (پایتون/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.

بعد هم تأیید کنید، فرض نگیرید. نسخه‌ها جابه‌جا می‌شوند — یک کتابخانه تقلید که روی handshake مربوط به Chrome 120 پین شده، در ۲۰۲۶ به‌صورت «مرورگر مشکوکاً قدیمی» خوانده می‌شود. بعد از هر آپدیت وابستگی دوباره تست کنید:

جمع‌بندی

• JA3/JA4 کتابخانه TLS را فینگرپرینت می‌کنند، نه هدرها را — تشخیص پیش از آنکه HTTP وجود داشته باشد رخ می‌دهد.
• JA4 استاندارد ۲۰۲۶ است: مقاوم در برابر تصادفی‌سازی، خوانا، و بین‌لایه‌ای (JA4H/JA4T/JA4X).
• پروکسی به فینگرپرینت TLS شما دست نمی‌زند؛ IP و handshake سیگنال‌های مستقل‌اند — هر دو را تمیز کنید.
• برای کلاینت‌های HTTP با curl_cffi/tls-client تقلید کنید؛ مرورگرهای واقعی ذاتاً تمیزند.
• بعد از هر آپدیت در check.jibaoproxy.com تأیید کنید.