流量伪装

代理供应商

首先需要了解代理供应商提供的网络流量特征。

https://datadome.co/bot-management-protection/how-proxy-providers-get-residential-proxies/

https://www.novada.com/blog-ordinary/the-core-difference-and-application-scenarios-between-static-isp-and-rotating-residential-proxies/

静态代理：ip 来源

Most Static Residential IPs are created through a business deal between a Proxy Provider and a Consumer ISP.

• The ISP (e.g., AT&T, Comcast, or a regional ISP): They have millions of IPs.
• The Proxy Provider: They have servers in a datacenter.
• The Deal: The Proxy Provider pays the ISP to "announce" a block of IPs (e.g., a /24 subnet) but route the traffic physically to the Proxy Provider's datacenter servers.

How it looks in databases:

• WHOIS/RIR: The ISP uses a mechanism called SWIP (Shared Whois Project) to register that specific block with the ISP's name (e.g., "Comcast Cable").
• The Result: When ipinfo.io or a website checks the IP, they see ASN: Comcast and Type: ISP.
• The Reality: The physical cable goes into a rack in a data center, not a house.

静态代理：数据移动链路

Your machine -> proxy server -> target website

When they give you 1.2.3.4:8000:user:pass, here is what is happening on their end:

• The Server: They have a physical Linux server (or VM) sitting in that datacenter.
• The Interface: They bind the "Residential" IP (1.2.3.4) to that server's network card.
• The Software: They run proxy software (like Squid or 3proxy) on that server.
  • It listens on port 8000. It sees your attempt to connect to 1.2.3.4 and accept.
  • It checks your user:pass against an internal list.
  • It routes your outgoing traffic through 1.2.3.4.

动态代理：数据移动链路

Residential proxy providers do not give you a direct list of 10 million IP addresses. Instead, they give you a single Gateway Address (e.g., us-geo.provider.com:8000).

Your machine -> gateway / entry node -> exit node -> target website

Here is the chain of events when you make a request:

• Step A: You Connect to the Gateway (The "Entry Node")

  What it is: A massive, high-speed server located in a Datacenter (e.g., AWS or Google Cloud). This is often called the "Super Proxy" or "Load Balancer."

  What happens: You send your request here. The connection is fast (low latency) because this server is built for speed.

  The "Mask": This Gateway handles your authentication (Username/Password) and decides which Exit Node to assign you based on your request (e.g., "Give me a US IP").

• Step B: The Gateway Tunnels to the Exit Node

  The Search: The Gateway looks at its live pool of millions of connected devices and picks one (e.g., Bob’s Android phone in Texas).

  The Tunnel: The Gateway sends your request through a pre-established, encrypted tunnel to Bob’s phone.

  Latency Spike: This is where the lag happens. The data has to travel from the Datacenter Gateway to a random consumer device on a (potentially slow) home Wi-Fi or 4G network.

• Step C: The Exit Node Hits the Target

  The Request: Bob’s phone receives the instruction and makes the actual HTTP request to google.com.

  The Appearance: Google sees the request coming from Bob's Residential IP (Comcast/AT&T). It has no idea the Gateway or You exist.

动态代理：Exit Nodes 来源

• The mobile "SDK" Model (Ethical)

  This is how legitimate, big-name providers operate. They effectively "buy" bandwidth from regular users.

  The Deal: A developer makes a free app (e.g., a Free VPN, a casual game, or a weather app).

  The SDK: The developer installs a "Monetization SDK" (like Honeygain, Peer2Profit, or Bright Data SDK) into the app.

  The Consent: When a user installs the app, the Terms of Service say: "Allow us to use your idle bandwidth in exchange for an Ad-Free experience."

  The Result: When the user's phone is charging and on Wi-Fi, it quietly connects to the Proxy Gateway and starts routing traffic for customers like you. The user gets a free app; you get a residential IP.

• Browser extensions

  Proxy providers contact popular browser extension developers, offering payment to include their proxy code in app updates. This approach works because browser extensions have broad permissions and run constantly in the background, while users rarely read privacy policies or understand what permissions they’re granting.

  Security researchers from GitLab found that compromised extensions affected over 3.2 million users in early 20253. Extensions marketed as ad blockers, VPNs, and productivity tools secretly routed traffic through users’ connections.

• The "Botnet" Model (Unethical / Illegal)

  This is how cheap, "unlimited bandwidth" providers often operate.

  Malware: Hackers infect routers, smart TVs, ip cameras, or fridges with malware (like Mirai).

  Forced Proxying: These devices are turned into zombie proxies without the owner knowing.

  Risk: These IPs are often flagged faster because they behave erratically and send spam.

  常见被黑的设备包括：router, firewall, WAP, gateway, broadband router, webcam, security-misc, DVR, media device, storage-misc。

• Mobile proxy farm

  专门提供移动代理的商家一般都是使用自己的设备，要么是很多台手机，要么是很多台可插 sim 卡的 4g 模块。

设备伪装

Windows VS Mac

Mac 不同产品线都有一个特点，配置确定的情况下，所有机器的硬件都是一样的。比如最低配的 Mac mini m4，世界上所有的机器，硬件都是一样的。

检测移动设备伪装

If you can pass CreepJS with a high trust score, you are beating 99% of detections.

There are absolutely tools and specific techniques to detect this. In fact, distinguishing a "Fake Mobile" (desktop spoofing Android) from a "Real Mobile" is one of the easiest checks for modern anti-fraud systems.

Because your underlying hardware (Intel CPU, NVIDIA GPU, wired power source) is physically different from a phone's hardware (ARM CPU, Adreno/Mali GPU, battery), your browser leaks these differences in dozens of tiny ways.

1 The "Silver Bullet" Detection Tools

You can check your own browser against these tools to see if you are leaking:

• BrowserLeaks (WebGL & JavaScript): Go to browserleaks.com/webgl. If the "Unmasked Renderer" says "NVIDIA", "AMD", or "Intel", you are 100% busted. Real Android phones use "Adreno" (Qualcomm), "Mali" (Samsung/MediaTek), or "PowerVR".

• CreepJS: A rigorous fingerprinting tool that looks for "lies" in your browser environment. It will explicitly flag "Worker Mismatch" or "Platform Mismatch" if your spoofing is incomplete.

• DeviceInfo.me: Provides a deep dive into your sensor data. If your accelerometer and gyroscope data is null or perfectly static, it knows you are on a desktop.

2 How They Detect You (The Technical Vectors)

Here are the specific signals security systems use, ranked from easiest to hardest to fix.

• The GPU Lie (WebGL)

  This is the most common giveaway.

  The Check: The website asks your browser to render a 3D graphic and checks the GPU name string.

  Real Android: Adreno (TM) 740 or Mali-G710.

  Your Spoof: NVIDIA GeForce RTX 4070 or Intel UHD Graphics.

  Verdict: Phones do not have desktop RTX cards. Instant Block.

  Fix: Your anti-detect browser must allow you to "Rename" the WebGL Vendor/Renderer.

• The Sensor Lie (Gyroscope/Accelerometer)

  Mobile phones are always moving slightly (micro-jitters), even when sitting on a table. Desktops are perfectly still.

  The Check: The site listens to DeviceOrientationEvent and DeviceMotionEvent.

  Real Android: Returns constant streams of changing data for alpha/beta/gamma rotation (e.g., 0.00231, -0.0019).

  Your Spoof: Returns null, undefined, or a perfectly static 0 that never changes.

  Fix: Advanced anti-detect browsers inject "Noise" (fake random jitter) into these APIs.

• The Battery Lie

  The Check: navigator.getBattery().

  Real Android: charging: false, level: 0.89 (variable).

  Your Spoof: charging: true, level: 1.0 (100%).

  Verdict: A device that is permanently 100% charged and plugged in is usually a server or desktop.

• The Touch Lie (maxTouchPoints)

  The Check: navigator.maxTouchPoints.

  Real Android: Returns 5 or 10 (multitouch).

  Your Spoof: Often returns 0 or 1 if you are just using Chrome DevTools "Device Mode" without a specialized tool.

  Note: Even if you spoof this to "5", some tests check for Touch Events (ontouchstart). If you click with a mouse, the event has "mouse-like" properties (no pressure, precise radius) that differ from a fat finger tap.

各类检测手段对代理流量的检测

IP

静态代理的 IP 一般就是 ISP IP，不用过多担心。

动态代理的 IP 可能各种类型都有，要看供应商的好坏，比如 business isp mobile。同时不同 ip 检测商给出的检测结果也不一样。

移动代理是一种特殊的动态代理，ip 是手机运营商分配的，只可能是 mobile 类型。

business 类型的 ip 最好不要用。

TCP/IP fingerprint

这个问题实际上没那么重要。

动态代理的真实情况

首先说一下真实家庭中路由器的作用。路由器起 NAT 作用，只改 ip，对 tcp 特征基本不改变。

动态住宅代理网络的本质，就是由全球成千上万个真实用户的设备组成的 P2P 网络。这些 IP 的来源主要有三种：

• SDK 嵌入（最主要来源）： 很多免费的手机 APP（手电筒、日历、游戏等）内置了代理商的 SDK。用户为了免费使用 APP，同意在“连接 WiFi 且充电”的状态下共享带宽。

  结果： 大量的 Android 手机 和 iPhone 变成了代理出口节点。tcp 指纹就是安卓和 iPhone 的。

• 带宽共享软件（如 Honeygain）： 用户主动在电脑上安装软件挂机赚钱。

  结果： 很多 Windows PC 和 Mac 电脑 变成了出口节点。就算用户家庭里面有路由器，tcp 指纹还是 windows 和 mac 的。

• Botnet：黑客通过漏洞控制了家庭中的智能设备（路由器、摄像头、智能音箱、电视盒子）。

  结果：很多 iot 设备变成了出口节点。iot 设备和家庭里面其他设备一样，也连接路由器。iot 设备发起的请求的 tcp/ip 特征完全由 iot 设备自己的 os 决定，一般是嵌入式 linux。

  很多路由器自己也会变成出口节点。这种情况下，路由器发起的请求的 tcp/ip 特征完全由路由器自己的 os 决定，一般是嵌入式 linux。

我们进行的模拟

• 已验证的真实情况

  • Windows 电脑连接 iPhone 手机热点，iPhone 使用蜂窝网络，browserleaks 看到的是 Windows tcp 指纹
  • Windows 电脑连接 iPhone shadowrocket 直连，iPhone 使用 wifi，browserleaks 看到的是 iOS tcp 指纹
  • Windows 电脑连接 iPhone shadowrocket 直连，iPhone 使用蜂窝网络，browserleaks 看到的是 iOS tcp 指纹
  • Mac 下的 Windows 虚拟机，访问互联网，browserleaks 看到的是 mac tcp 指纹
  • Windows 电脑直接访问互联网，browserleaks 看到的是 Windows tcp 指纹

• 使用 Windows UA + 安卓/iPhone 手机出口节点（安卓/iOS tcp 指纹）+ 手机使用 wifi/蜂窝网络

  真实热点场景中，标准的热点模式下，手机其实是 NAT，理论上是透明的。网站看到的是电脑的 tcp 指纹。

  但是，很多用户为了绕过运营商的热点限速，会在手机上开一些绕开限制的软件。

  安卓比较方便，热点增强软件（如 PdaNet），往往会重写或标准化 TCP 包，导致指纹变得模糊或接近移动端特征。

  另外，安卓和 iPhone 还可以开代理软件，让电脑连接上。手机本身可以使用 wifi 或者蜂窝网络。这种情况下，TCP 指纹就变成了手机的。

  所以 Windows UA + 安卓/iOS tcp 指纹 + 手机使用 wifi/蜂窝网络可能会出现在现实生活中。

• 使用 Windows UA + Mac 出口节点

  这也是安全的，虽然比 iPhone 热点稍微少见一点点，但依然有合理的解释：

  mac 上开启 clash 或者 surge 代理软件，开启局域网共享。Windows 电脑连接上 mac。

  Windows 运行在 Mac 的虚拟机（Parallels Desktop / VMware）里，且网络模式使用了 NAT。

  这时，浏览器是 Windows，但底层的网络包是由宿主机 macOS 发出的。

• 使用 Windows UA + Windows 出口节点

  这也是安全的。并且 100% 安全。

  移动 ip 真实场景：用户将一个 USB 4G/5G 上网卡（Dongle）直接插在 Windows 笔记本上上网。或者使用的是带有内置 SIM 卡槽的高端商务本（如 ThinkPad X1 Carbon）。这种情况下，Windows 系统直接管理拨号连接。TCP 连接是由 Windows 自己的内核发起的，没有经过路由器的 NAT 转发（或者 Dongle 处于 Modem 模式）。

  桌面 ip 真实场景：一台不挂代理的 Windows 电脑访问互联网，tcp/ip 指纹本来就是 windows 的，不管有没有路由器。

• 使用 Windows UA + linux tcp 特征（包括iot 设备、路由器设备）

  真实情况下，这种场景比较少见，反爬系统可能会认为有嫌疑。反爬系统还会去查 ip 纯净度和行为特征。

  但是有两点很重要。

  • 第一、上面已经说过使用 Windows UA + 安卓手机是完全没问题的。
  • 第二、因为使用 Windows UA + 安卓手机也会有 linux tcp 特征，所以使用 Windows UA + iot 设备/路由器设备也可以被看作使用 Windows UA + 安卓手机，
  • 第三、所以使用 Windows UA + iot 设备/路由器设备应该也没什么问题。

  场景 1：在中国以及很多对隐私/网络自由有追求的国家，大量极客用户会在家里使用 OpenWrt、PfSense、Ubiquiti 等“软路由”或高级路由器。

  用户在路由器上挂了梯子（VPN/Clash）、去广告插件（AdGuard Home）或防火墙。

  流量变化： 为了过滤广告或分流流量，这些路由器上的软件会**接管（Hijack）**局域网内的所有流量。电脑发出的 TCP 包，被路由器的软件截获。路由器软件分析后，以路由器的名义重新向目标网站发起 TCP 连接。

  结果： 网站看到的是 Windows UA，但 TCP 指纹变成了 OpenWrt (Linux)。

  反爬视角： “这可能是一个注重隐私的高级用户，或者用了去广告路由器的家庭用户。不能杀。”

  场景 2：很多公司、学校、公共 WiFi（星巴克、机场）都有**“行为管理审计设备”或“安全网关”**（如 Deep Packet Inspection 设备）。

  你带着 Windows 笔记本去图书馆或公司。

  流量变化： 所有的 HTTP/HTTPS 流量都要穿过一个 Linux 内核的安全网关（中间人代理）。网关会终结你的 TCP 连接，检查有没有病毒或敏感词，然后再建立一个新的 TCP 连接去访问外网。

  结果： 网站看到 Windows UA，但 TCP 指纹是网关的（Linux Enterprise）。

  反爬视角： “这可能是一个在公司上班或在学校上课的用户。不能杀。”

TLS fingerprint

target website 得到的 TLS fingerprint 是链路开头的 fingerprint。链路开头就是指纹浏览器或者 BAS 用的 CEF。

另外安全公司一般只能从 TLS fingerprint 中获取浏览器的种类和版本（通过 SSL/TLS library 判断），不能获取操作系统。

使用指纹浏览器时，user agent 里的 chrome 版本要和实际浏览器用的 chrome 引擎版本对上。不然很容易就露馅了。

Latency detection

这个问题同样棘手。TCP timing 是链路中的最后一环到网站的时间。Websocket timing 是整条链路的时间。

静态代理的链路一般是：my machine -> proxy server -> target website。我们可以缩短 machine 到 proxy server 的物理距离，或者直接在 proxy server 上进行软件操作。

但是静态代理有一个非常大的问题：因为代理服务器在数据中心中，网络设施比较好，TCP Timing 非常小而且基本不变。这和普通用户不符。普通用户因为各种原因，TCP timing 会来回波动。

动态代理的链路一般是：my machine -> gateway -> exit node -> target website。我们可以缩短 my machine 到 exit node 的物理距离，让 my machine gateway exit node 都在一个区域（尽量不要距离太远，小国家跨国可以，但是比如美国，从美西到美东，距离太远了，会有明显 latency）。

移动代理的链路一般是：TODO。

如果 my machine 在 CN，还要在链路中加一个代理，那情况更是雪上加霜。

Javascript fingerprint

通过 bablosoft 动态指纹或者指纹浏览器，一般很好解决。

静态 ip 解决方案

买来的静态 ip 基本 tcp/ip 指纹全是 linux，加上 tcp timing 没有波动，模仿不了真实用户。

• 解决方案一：用家庭宽带真实机器

  租用远程家庭宽带 windows 物理机器，不使用指纹浏览器。

  淘宝上有很多国内的机器，最低价一个月 50。CN ip 应该可以直接访问广告联盟网站。

  台湾虾皮上搜索「遠端主機 租賃」、「遠端主機 模擬器多開 出租」。

  其他地区，包括国外的很难找。

  租用远程家庭宽带 mac mini 机器也可以，不使用指纹浏览器。

  淘宝上有很多，基本 200 一个月。

  租用真实手机也可以。

• 解决方案二：用家庭宽带真实机器加指纹浏览器

• 解决方案三：windows vps + 指纹浏览器模拟 windows 用户 + 移动 ip

  用 tcp/ip spoofing 把 tcp/ip 指纹改成 windows 的。在网站看来，就是使用移动 ip 的 windows 用户。

• 解决方案四：windows vps + 指纹浏览器模拟安卓手机 + 移动 ip。

  在网站看来，就是使用移动 ip 的安卓用户。

动态 ip 解决方案

• chrome on windows -> 住宅代理 -> 网站

  网站看到：linux/安卓系统，chrome 某个版本 tls 指纹，windows user agent，卒。

• chrome on windows -> 移动代理 -> 网站

  网站看到：linux/安卓系统，chrome 某个版本 tls 指纹，windows user agent，卒。

• chrome on windows -> 带 tcp/ip spoofing 的移动或者住宅代理 -> 网站

  网站看到：windows 系统，chrome 某个版本 tls 指纹，windows user agent，好。

  ip 是移动或者住宅都可以。

• 模拟安卓上的 chrome -> 住宅代理 -> 网站

  网站看到：linux/安卓系统，chrome 某个版本 tls 指纹，安卓 user agent。

  但是，安卓手机不能使用住宅 ip，卒。

• 模拟安卓上的 chrome -> 移动代理 -> 网站

  网站看到：linux/安卓系统，chrome 某个版本 tls 指纹，安卓 user agent。

  ip 也是移动 ip，好。

浏览器热身

"Building a small history of browsing" (often called "Cookie Profile Building" or "Account Warm-up") is the process of making your browser look "lived-in" before you visit your target link.

When you open a fresh Chrome instance in your automation software, it is "sterile." It has no cookies, no cache, no history, and no "Ad Interest" profile.

Ad networks (like Google Ads, Taboola, Outbrain) hate sterile browsers. A user with zero history who appears out of nowhere, clicks an ad, and disappears is the #1 signature of a bot.

Here is the technical breakdown of what "building history" actually does and why your 1-minute plan is risky.

1. The "Cookie Sync" (The Most Important Part)

Ad networks track users across the internet.

• Real User: Visits nytimes.com, then youtube.com, then amazon.com.
  • On New York Times, Google/Doubleclick drops a cookie: ID=123.
  • On YouTube, Google sees ID=123 again and adds "Likes News" to the profile.
  • On Amazon, Google sees ID=123 again and adds "Shopper" to the profile.
• Your Bot (Minute 1): Opens browser -> Visits Ad Link.
  • Google sees: "No Cookie ID." Creates ID=999.
  • Verdict: This is a brand new, unknown user. Low Trust.
• The Goal of "Building History":
  • Before visiting your target ad, your bot should visit 3-5 popular "High Trust" websites (e.g., CNN, Wikipedia, Amazon, Reddit).
  • Why? These sites have ad trackers on them. By visiting them first, you pick up the tracking cookies before you hit the target ad. When you finally land on the target page, the ad network sees: "Ah, this is the user we just saw on CNN and Reddit. They are real."

2. Chrome's Local "Topics API"

Modern Chrome doesn't just rely on cookies; it builds an internal profile of you called the Privacy Sandbox (Topics API).

• Chrome analyzes the pages you visit and stores "Topics" locally (e.g., "Sports," "Technology").
• When an ad loads, the browser tells the ad network: "My user is interested in Sports."
• Your Bot: Has visited 0 pages. Chrome tells the ad network: "No topics found."
• Verdict: Suspicious. Real humans always have topics.

3. The "Referrer" Chain

"Building history" also means fixing how you arrive at the page.

• Direct Access (Bad): Opening the browser and pasting the link.
  • Referrer: (none)
• Organic Access (Good): Visiting Google, searching for a keyword related to the video, and clicking a result.
  • Referrer: https://www.google.com/