Most proxy providers compete on IP address "cleanliness": the number of reputation databases an address doesn't appear in, rotation speed, ASN reputation. These are important parameters — but they only solve half the problem. There is a layer of protection that operates deeper than any reputation database: passive OS fingerprinting of mobile proxies.
Antibot systems at major platforms — marketplaces, social networks, ad platforms — have learned to identify device type at the TCP connection level, before the client has sent a single byte of HTTP data. The technique is called passive OS fingerprinting. It requires no active probing from the server — the server simply inspects the parameters of the incoming SYN packet and, with high accuracy, determines: is this a Linux server or an Android smartphone, a Windows PC or an iPhone.
A server-side proxy with a pristine IP running on Linux exposes Linux TCP parameters. A mobile proxy on a physical Android device exposes Android TCP parameters. The difference is detectable in milliseconds. That is precisely why we implemented TCP fingerprint spoofing at the server infrastructure level — and in this article we explain how it works and what it means in practice.
What passive OS fingerprinting is and why it matters more than IP reputation
Passive fingerprinting: identification without asking a single question
Passive OS fingerprinting is a method of identifying the operating system and device type solely by observing network traffic, without any active interaction with the client. The server sends no additional probing packets and asks no questions — it simply analyzes what the client sends when establishing a normal TCP connection.
Every operating system implements the network stack in its own way. Linux developers chose certain initial TCP parameter values, Android developers chose others, Microsoft Windows chose yet another set. These parameters are transmitted in every TCP SYN packet, and their combination forms a unique OS "fingerprint."
The key property of passive fingerprinting: it is impossible to spoof at the application layer. A browser, scraper, or HTTP client does not control TCP SYN parameters — those are set by the OS kernel. You can change the User-Agent, Accept-Language headers, HTTP/2 header order to your heart's content — the TCP fingerprint will remain untouched. This makes it one of the most reliable signals for antibot systems.
Why IP reputation is not enough
Traditional proxy protection was built on IP address reputation. The logic is simple: if an IP isn't flagged in spam databases, isn't used in mass attacks, and belongs to a "good" ASN (for example, a mobile carrier) — it will be allowed through.
The problem is that antibot systems have long moved beyond IP reputation. Major platforms such as Wildberries, Amazon, and Facebook employ multi-layer verification. IP reputation is only the first filter. Behind it come: HTTP and TLS header analysis, behavioral request patterns, and finally — TCP/IP fingerprinting. Even a "perfect" mobile carrier IP originating from a Linux server will be flagged as suspicious, because mobile carriers simply do not use Linux servers for end-user traffic.
Passive OS fingerprinting of mobile proxies is exactly the detail that distinguishes "a datacenter proxy with a mobile IP" from "a proxy that looks like a real phone." And it is precisely this that the best antibot solutions have learned to check.
How long has this been in use
p0f, the de facto standard tool for passive OS fingerprinting, was released back in 2000. Its databases contain fingerprints for hundreds of operating systems and versions. Major CDN providers (Cloudflare, Akamai), large e-commerce platforms, and antifraud systems have long integrated similar checks into their protection layers. This is not an exotic technique — it is standard practice for serious antibot protection in 2024–2026.
How p0f and passive OS detection work
Anatomy of the TCP handshake
Every TCP connection begins with a three-way handshake: the client sends SYN, the server replies with SYN-ACK, the client confirms with ACK. All the information needed for passive OS fingerprinting is contained in the very first packet — the SYN. The client knows nothing about the server yet; it simply announces its capabilities and preferences through a set of TCP parameters.
These parameters are not set by the user or the application — they are set by the operating system kernel when opening a socket. Different kernels and different versions of the same OS use different values. This is precisely what creates a unique fingerprint.
What p0f analyzes in the SYN packet
p0f analyzes the following fields of each incoming SYN packet:
- TTL (Time to Live) — the initial packet lifetime. Linux starts at 64, Windows at 128, some BSD versions at 255. The actual TTL in the packet will be lower than the initial value (decremented at each router), but p0f can reconstruct the original value using standard hop counts.
- Window Size — the TCP receive window size. This is a key parameter: different operating systems choose different initial window values. Linux 3.x–5.x traditionally uses 29200, Android — 65535.
- Window Scale (wscale) — the scaling multiplier for the window (TCP option). A Linux server typically sets wscale=6 or 7, Android — 8, 9, or 10.
- MSS (Maximum Segment Size) — the maximum TCP segment size. Depends on the network interface MTU: 1460 for Ethernet, lower for some tunnels.
- TOS/DSCP (Type of Service) — the traffic prioritization field. Android sets TOS=0x28 (Expedited Forwarding), server Linux typically 0x00.
- TCP options and their order — the set and sequence of options in the SYN packet (MSS, SACK, Timestamps, NOP, WScale) are also characteristic of specific operating systems.
- DF bit (Don't Fragment) — the no-fragmentation flag. Most modern operating systems set it, but the details vary.
p0f aggregates all of this into a "signature" and compares it against a database of known operating systems. On a match, it returns a result: Android/6.x-9.x or Linux/3.x or Windows/10.
Where and how antibot systems use p0f
Antibot systems embed passive OS fingerprinting directly into the incoming connection handler. This happens before HTTP parsing, before TLS ClientHello inspection, before header analysis. In effect, at the TCP handshake stage the server already has a "verdict" on the client's device type and can factor it into its decisions.
The TCP fingerprint signal is combined with others: IP ASN membership, TLS fingerprint (JA3/JA4), behavioral patterns. If an IP belongs to a mobile carrier, the TLS fingerprint matches an Android browser, but the TCP fingerprint says "Linux" — that contradiction immediately raises the suspicion score. This is precisely where most proxies that route mobile IPs through server infrastructure get caught.
How a Linux server differs from an Android smartphone at the TCP level
Standard Linux server profile
A typical Linux server (Ubuntu 20.04, Debian 11, CentOS 7) sends a SYN packet with the following characteristics when establishing a TCP connection:
| Parameter | Typical Linux server |
|---|---|
| TTL | 64 |
| Window Size | 29200 |
| Window Scale (wscale) | 6 or 7 |
| MSS | 1460 |
| TOS | 0x00 |
| TCP options | MSS, SACK, Timestamps, NOP, WScale |
The value window=29200 with wscale=6 is the "classic" server Linux signature. It is so distinctive that p0f recognizes it from the very first packet. This is exactly the profile that antibot systems see when a server-side proxy connects to them — even if that proxy has a mobile IP.
Android smartphone profile
Android is based on the Linux kernel, but Google and device manufacturers configure the network stack differently from server distributions:
| Parameter | Android 6–12 (real device) |
|---|---|
| TTL | 64 |
| Window Size | 65535 |
| Window Scale (wscale) | 8, 9, or 10 |
| MSS | 1460 (LTE) or 1412 (PPPoE tunnel) |
| TOS | 0x28 (Expedited Forwarding) |
| TCP options | MSS, SACK, Timestamps, NOP, WScale |
The key differences are window=65535 and wscale=8–10. TTL matches server Linux (also 64), but the combination of window + wscale + TOS unambiguously points to Android. p0f distinguishes these profiles with high accuracy.
Why you can't simply "change server settings"
One might think it's enough to change the Linux server's sysctl parameters to "simulate" Android. In practice, this doesn't work for several reasons.
First, window=65535 and wscale=8 can be set in sysctl, but then all server connections (including those from the proxy users themselves) will get the same profile — which is unnatural. Second, some parameters (TOS/DSCP in particular) are set via iptables or specific applications, and global changes break other services. Third, real Android devices have parameter variability — subtle differences between firmware versions, manufacturers, and carriers. An identical fingerprint on all connections is itself an anomaly.
A correct implementation of TCP fingerprint spoofing requires intercepting traffic at the kernel level using real profiles from real devices — which is exactly how we implemented it.
Why TCP fingerprinting is critical for proxies
Marketplaces: Wildberries, Ozon, Amazon
Marketplaces are the most aggressive environment from an antibot protection standpoint. Wildberries processes tens of billions of rubles in monthly turnover, and fraud through fake reviews, bot-driven product stockpiling, and competitive scraping cause direct financial harm. As a result, the WB antibot system is one of the most advanced on the Russian market.
Our real-world data: a client with 90,000–134,000 requests per day to WB operates through a mobile proxy with the correct passive OS fingerprint. 95.9% of requests succeed. The specialized endpoint antibot.wildberries.ru, which checks every connection, issues a pass in 73% of cases specifically because it sees a valid Android profile. A server-side proxy on the same IP would show a fundamentally different picture.
For TCP fingerprint proxies, this means: a mobile IP is necessary but not sufficient. Without the correct fingerprint, the WB antibot "sees" a mismatch between the mobile carrier ASN and the Linux server TCP profile — and raises the risk score for that connection.
Social networks and ad accounts
Facebook, Instagram, TikTok, and VKontakte use fingerprinting to protect ad accounts from multi-accounting and fraudulent schemes. An ad account is money: fraud in Facebook Ads costs advertisers billions of dollars annually, and platforms have a strong interest in detecting unnatural patterns.
Mobile devices are the primary platform for consuming content on social networks. When a connection to Facebook arrives from a mobile IP but with a Linux TCP fingerprint — that is a contradiction. A "mobile user" with a Linux profile is a proxy, and security systems are trained to recognize this. The correct passive OS fingerprint of mobile proxies eliminates this contradiction.
Traffic arbitrage and multi-accounting
In traffic arbitrage, proxies are tools for account isolation. Each account operates through a separate proxy with a unique IP. But IP isolation is only the first layer. Arbitrage platforms track traffic fingerprints: if 20 accounts with different IPs all show the same Linux TCP fingerprint — that is a clear signature of proxy infrastructure.
A mobile proxy with fingerprint spoofing gives each account not just a unique IP, but a unique connection "character." 28 distinct Android profiles with varying wscale and window values introduce natural variability — exactly what you'd expect from real users with different phones.
Antifraud systems for financial services
Banks, payment systems, and insurance companies apply multi-layer verification for online operations. TCP fingerprint is part of the signal set alongside IP geolocation, browser device fingerprint, and behavioral analysis. A mismatch between the declared device type and the TCP connection profile is a classic fraud signal.
For working with financial services through a proxy, the correct TCP fingerprint proxy is not a "nice to have" — it is a prerequisite for passing antifraud checks without elevated scrutiny.
How we implemented TCP fingerprint spoofing
Principle: kernel-level interception
The key decision was a server-side fingerprint spoofing implementation, transparent to the user and to any application. We do not modify client software, do not require any special configuration from the user, and do not change global network stack parameters on the server (which would break other connections).
Instead, we intercept outgoing SYN packets at the Linux kernel network stack level — at the exact moment when the proxy server initiates a connection to the target site on behalf of the user. The packet is intercepted before being sent to the network, its TCP parameters are rewritten to match the target Android profile, and only then is the packet delivered to the recipient.
This means the target site sees exactly the TCP fingerprint characteristic of a real Android device. Neither routers, nor antibot systems, nor p0f proxy analysis can distinguish this connection from one made by an actual smartphone.
Database of real Android profiles
A critically important detail: we use not "synthetic" profiles invented manually, but real profiles from real Android devices. The profiles were collected from physical smartphones — the very same devices connected behind our USB routers with SIM cards.
Our database contains 28 unique Android profiles. Each profile contains a combination of parameters captured from a real device: specific TTL, window size, wscale, TOS values, and the order and parameters of TCP options. Variability between profiles reflects real-world diversity: Samsung Galaxy devices from different generations differ from Xiaomi, Redmi differs from OnePlus, and different firmware years of the same device produce different parameters.
This matters: an identical fingerprint on all connections is itself an anomaly. Real users use different devices. 28 profiles create a natural picture of an Android smartphone fleet.
How the system works in production
The system operates completely transparently. The user purchases a mobile proxy and connects to it in the standard way — through any HTTP/SOCKS5 client. No additional configuration is required. TCP fingerprint proxy spoofing happens automatically at the server network level on every outgoing connection.
The profile is assigned at the proxy session level and remains stable for the duration of the session — which also matches real device behavior. Upon IP change (rotation), the profile may change, simulating a switch between devices.
Verifying the result: p0f and external services
After implementation, we verified the results using several independent tools. p0f proxy analysis is the first test: p0f v3 with its OS fingerprint database is the standard tool used by antibot systems. The second verification channel is public TCP fingerprint checking services available on the internet. The third is specialized antibot analyzers such as Scrapfly.
The results confirmed the correctness of the implementation: connections through our mobile proxies are identified as Android smartphones, not Linux servers.
Results: before and after
Before: Linux server profile
Before implementing fingerprint spoofing, our mobile proxies (IPs from mobile carrier pools, real mobile traffic through SIM cards) had the following TCP profile when analyzed by fingerprinting tools:
| Parameter | Value | Interpretation |
|---|---|---|
| Window Size | 29200 | Server Linux |
| wscale | 6 | Server Linux |
| TOS | 0x00 | Standard Linux |
| p0f detection | Linux/3.x (or 4.x) | — not Android |
| Scrapfly score | ~5/10 | Suspicious traffic |
| Link type | VPN/Tunnel | Clear proxy signature |
Despite the IP belonging to a mobile carrier, the TCP fingerprint unmistakably revealed a Linux server. For antibot systems this was a contradiction: "mobile IP, but not a mobile device." Such a proxy would pass the initial IP filter but get flagged at the fingerprint analysis layer.
After: Android smartphone profile
After implementing fingerprint spoofing, the picture changed dramatically:
| Parameter | Value | Interpretation |
|---|---|---|
| Window Size | 65535 | Android |
| wscale | 8–10 | Android |
| TOS | 0x28 | Android (Expedited Forwarding) |
| MSS | 1460 (original) | LTE connection |
| p0f detection | Android/6.x–9.x | Real smartphone |
| Scrapfly score | 9/10 | Legitimate mobile traffic |
| Link type | Ethernet (physical channel) | No tunnel indicators |
An important detail: we intentionally preserve the original MSS — the one that came from the real user. Spoofing the MSS could create mismatches with the actual channel MTU and produce anomalies. The original MSS combined with Android window and wscale parameters yields the most natural final profile.
Practical result: Scrapfly score 9/10
Scrapfly is a specialized web scraping service that also provides proxy quality verification tools. Their score accounts for many factors: ASN reputation, TCP fingerprint, TLS fingerprint, presence in block lists. A score of 9/10 means "high-quality legitimate mobile traffic."
Before implementing fingerprint spoofing, our mobile proxies scored around 5/10 precisely because of the TCP profile mismatch. With the correct passive OS fingerprint of mobile proxies — 9/10. This translates directly into success rates on protected platforms.
The change in link type from VPN/Tunnel to Ethernet is equally telling: without the correct fingerprint, analyzers saw characteristic signs of tunneled (proxy) traffic. After the change, they see a "clean" channel indistinguishable from a direct connection from a real device.
Where fingerprint spoofing is available and how to get access
Exclusive to mobile elite proxies
The TCP fingerprint spoofing feature is available exclusively on the mobile elite proxy plan at Frigate Proxy. This is fundamental: the technology requires physical mobile devices with SIM cards — only that combination can provide a correct mobile ASN alongside the right fingerprint.
Server proxies (IPv4/IPv6) and residential proxies do not support this feature for architectural reasons. Passive OS fingerprinting of mobile proxies is an exclusive capability of the mobile plan, reflecting the physical infrastructure: real phones, real SIM cards, real mobile carrier networks in Russia.
Works automatically, no configuration needed
The implementation is entirely server-side. You do not need to:
- Install additional software or extensions
- Change browser, scraper, or antidetect browser settings
- Manually select or configure a fingerprint
- Use special connection parameters
Any application that connects to our mobile proxies — whether a browser, Python script, antidetect browser, or automation tool — automatically receives the correct Android fingerprint at the TCP level. This happens transparently at the server network layer, with no involvement from client software.
Fingerprint profile selection in the dashboard — coming soon
The next step in our development is the ability to select a fingerprint profile in the user dashboard. Soon users will be able to choose which device profile to use for each proxy:
- Android — various versions (Android 8, 9, 10, 11, 12) with corresponding network stack parameters
- Windows — Windows 10/11 profile for scenarios where a mobile profile is less preferable
- Automatic — profile rotation on IP change (current default behavior)
This is especially useful for specific scenarios: for example, when working with desktop ad accounts where a Windows profile looks more natural, or when testing antibot behavior against different fingerprints.
How to get mobile elite proxies with TCP fingerprinting
Mobile elite proxies with passive OS fingerprint spoofing are available on our website. This is our flagship product — physical SIM cards in mobile routers, real IPs from Russia's mobile carriers (MTS, Megafon, Beeline, Tele2), rotation by timer or on demand, HTTP/SOCKS5 support.
Buy mobile elite proxies with TCP fingerprinting →
FAQ: common questions about TCP fingerprinting in proxies
What is passive OS fingerprinting in plain terms?
It's a way to determine which device and operating system a network connection is coming from — purely by observing traffic, without asking the client anything. Every OS "speaks" on the network in its own way: Linux uses certain TCP connection parameters, Android uses others, Windows uses yet others. By analyzing these parameters in the first packet of each connection, antibot systems accurately determine: is this a real phone, or a server proxy pretending to be one.
Does a regular mobile proxy protect against fingerprint analysis?
No. A regular mobile proxy gives you a mobile IP address (from a carrier pool), but traffic flows through a Linux server. The TCP fingerprint remains server-grade: window=29200, wscale=6 — classic Linux. The antibot system sees a mobile IP but a Linux profile — a contradiction that triggers elevated scrutiny. Only TCP fingerprint spoofing at the server level eliminates this mismatch.
Is p0f the only fingerprint analysis tool?
p0f is the best-known and most widely used tool for p0f proxy analysis, but not the only one. There are proprietary implementations from Cloudflare, Akamai, PerimeterX, and other antibot vendors. The operating principle is similar: analysis of SYN packet parameters. Our profiles were tested against both p0f and commercial analyzers — the result is the same: Android.
Does fingerprint spoofing work with any client software?
Yes. Since TCP fingerprint spoofing is implemented at the server network stack level (Linux kernel + netfilter interception), it works transparently for any client application. Browser, antidetect browser (Dolphin Anty, Indigo Browser, AdsPower), Python requests, Scrapy, Puppeteer, Playwright, curl — everything works through the same proxy connection, receiving the correct fingerprint automatically.
Does fingerprint spoofing affect proxy speed?
The impact is minimal and imperceptible in practice. Intercepting and rewriting a SYN packet is a one-packet operation on roughly 60 bytes at the start of each connection. Subsequent traffic (HTTP requests, responses) is unaffected and not slowed down. The latency overhead is under 1 ms, which is below natural network jitter.
Can fingerprint spoofing be detected?
Theoretically — with specialized analysis accounting for the full sum of signals. Practically — no: our 28 profiles are collected from real devices, contain all the right parameters in the right combinations, and are rated by external analyzers as legitimate mobile traffic (9/10 score from Scrapfly). Neither p0f nor commercial fingerprint systems distinguish our passive OS fingerprint of mobile proxies from genuine Android devices.
For which tasks is this critical, and where does it not matter?
Critical when working with advanced antibot systems: Wildberries, Ozon, Amazon, Facebook/Meta, TikTok, Google, financial services. Less important for simple scenarios without strict antibot protection: scraping open catalogs, working with sites that have no JavaScript checks, performance testing. But since the feature works automatically and requires no configuration — it is simply present in every one of our mobile proxies, regardless of the use case.
Which carriers are available?
Our mobile proxies run on SIM cards from the following carriers: MTS (AS8359), Megafon (AS31133), Beeline (AS3216), Tele2 (AS41330). These are Russia's four largest federal carriers. The IP addresses belong to exactly these ASNs — mobile, not datacenter. Combined with the correct TCP fingerprint proxy, this delivers the most convincing profile of a "real user on a mobile network."
Services for checking your proxy's TCP fingerprint
Before launching production tasks, we recommend checking how your proxy looks from a passive OS fingerprinting perspective. Below is the list of tools we use ourselves.
- tools.scrapfly.io/api/fp/tcp — shows the JA4T fingerprint, Satori string, window/TTL/MSS/wscale values, and link type. For Android, expect a string like
65535:64:1:60:M1460,S,T,N,W8:.and link type Ethernet instead of VPN/Tunnel. - witch.valdikss.org.ru — classic p0f v3-based detector. Shows the identified OS and version. Target: Android, not Linux.
- browserleaks.com/ip — popular combined detector (p0f v3/v4). Displays the OS identified by TCP fingerprint alongside IP information.
- proxydetect.live/tcpip.html — specialized TCP/IP fingerprint detector. A solid tool for verifying that a profile matches a real mobile device.
- p0f.privateproxy.ru — p0f v4-based service. One of the few public tools with support for version four — its OS detection algorithm is more accurate than p0f v3.
How to check: open any of these URLs through your proxy. If the "OS" or "link type" field shows Android — the fingerprint is configured correctly. If you see Linux or an unknown OS — contact support.
