TLS Fingerprint (JA3 / JA4)
A hash of the TLS ClientHello that uniquely identifies the client library — used to flag proxy traffic.
When a TLS client connects to a server, it sends a ClientHello message before encryption starts. The ClientHello lists cipher suites, extensions, supported groups, and signature algorithms — and the exact set differs by client library. Chrome's BoringSSL orders them one way, Firefox's NSS another, Go's crypto/tls a third. A hash of this list (or the list itself) is the TLS fingerprint. The most common format is JA3 (a 32-char MD5); JA4 is the newer, more human-readable successor.
Services like Cloudflare use TLS fingerprinting to differentiate a real Chrome browser from a Go-based HTTP client. A request claiming to be Chrome but presenting a Go-crypto/tls fingerprint is suspicious — and the service responds with a challenge, a captcha, or a block. This is why naive Go-based proxy tools get flagged even when their IP and headers look fine. The fix is uTLS (a Go library that lets you pick a fingerprint) or curl-impersonate (a patched curl that mimics a specific browser's handshake).
TLS fingerprinting is not bypass-proof. The fingerprint has to match a known browser, but a determined attacker can replay a recorded ClientHello byte-for-byte. Modern detectors add entropy checks (timing, packet sizes, TCP-level quirks), but the cat-and-mouse continues. IPCombo doesn't surface fingerprinting directly today — but if a target consistently shows your exit IP as a residential IP yet still blocks you, fingerprinting is a likely culprit.