Stealth stack, který používáme pro citlivou klientskou práci

When clients need infrastructure that won't be traced, linked, or detected, they come to us. Not because we sell anti-detect browsers or proxies — because we build complete operational systems where every layer is designed to work together.

This is the technology stack. Not a shopping list — an architecture. Each component exists for a specific reason, integrates with the layers around it, and has been tested against real-world detection systems.

The Stack Overview

Five layers, each handling a different dimension of operational security:

┌─────────────────────────────────────────┐
│         Monitoring & Alerting           │
│    (detection, health, cost tracking)   │
├─────────────────────────────────────────┤
│         Identity Management             │
│   (accounts, credentials, personas)     │
├─────────────────────────────────────────┤
│        Network Infrastructure           │
│    (proxies, DNS, VPN, routing)         │
├─────────────────────────────────────────┤
│         Browser Layer                   │
│ (anti-detect, fingerprints, profiles)   │
├─────────────────────────────────────────┤
│       Physical Infrastructure           │
│   (servers, devices, environments)      │
└─────────────────────────────────────────┘

Each layer depends on the layer below it. A perfect browser configuration on compromised infrastructure is worthless. Perfect infrastructure with a leaking browser fingerprint is wasted. The stack works as a system or it doesn't work at all.

Browser Configuration

Anti-Detect Browser Selection

We use different browsers for different operational tiers:

Tier 1 (High-value accounts): Multilogin with Mimic engine. The hardware-based canvas noise, dual-engine support, and TLS fingerprint matching justify the premium cost for accounts where detection means significant financial loss.

Tier 2 (Mid-value operations): Dolphin Anty. Good fingerprint coverage, excellent team collaboration, and the automation API integrates with our operational scripts.

Tier 3 (Scraping and data collection): Custom Chromium builds with targeted patches, driven by Playwright. No commercial browser overhead — just the specific modifications needed for the target's detection.

See our full comparison for detailed analysis.

Profile Management

Each profile is a self-contained identity with:

• Unique fingerprint configuration matching a real device that exists in the real world (not randomized — specifically matched to a real hardware/OS/browser combination)
• Bound proxy in the correct geographic region with verified ASN classification
• Consistent persona data — timezone, language, screen resolution all matching the proxy's location
• Warming history — how long since creation, what activities have been performed, current trust score estimate

We maintain a profile database that tracks:

Profile ID → Browser (Multilogin/Dolphin/Custom)
           → Fingerprint hash (for consistency verification)
           → Proxy binding (provider, type, geo)
           → Account associations (which accounts use this profile)
           → Health status (last check, detection score)
           → Creation date and warming stage

Configuration Checklist

Before any profile goes live, it passes a 20-point validation:

1. Canvas fingerprint is deterministic (same hash on repeated tests)
2. WebGL renderer matches claimed GPU
3. Audio fingerprint is consistent with claimed platform
4. Font list matches claimed OS
5. Screen resolution matches a real device
6. Navigator properties are internally consistent
7. Timezone matches proxy geolocation
8. Language and Accept-Language match timezone region
9. WebRTC is either disabled or properly proxied
10. DNS resolution routes through the proxy
11. TLS fingerprint matches claimed browser version
12. No automation artifacts detected (CDP, webdriver)
13. HTTP/2 settings match claimed browser
14. Cookie and storage are isolated
15. Proxy health check passes
16. Proxy ASN classification matches expected type
17. Proxy IP is not in known blacklists
18. Proxy geographic location verified against independent database
19. CreepJS shows no "lies" detected
20. Pixelscan shows no anti-detect detection

Network Infrastructure

Proxy Architecture

We run a three-tier proxy system:

Primary pool: ISP proxies (datacenter-speed, residential-ASN) for persistent account operations. These provide the best balance of speed, stability, and trust score. Pool size: 500+ IPs across 20+ countries.

Secondary pool: Residential proxies for high-scrutiny platforms and operations where ISP proxies aren't sufficient. Bandwidth-based pricing means we optimize for minimal data transfer.

Scraping pool: Rotating datacenter proxies for high-volume data collection where detection consequences are low and cost efficiency matters.

Each pool has dedicated health monitoring that tests every IP against target platforms every 30 minutes and removes degraded IPs from active rotation.

DNS Resolution

DNS leaks are a common detection vector. Our architecture forces all DNS resolution through the proxy connection:

• Browser profiles configured to use DNS-over-HTTPS (DoH) through the proxy
• System-level DNS is not used — all resolution happens at the browser/proxy level
• DNS server selection matches the proxy's geographic region (using the same region's public resolver)

VPN Layer

We don't use VPNs for operational traffic — VPN detection rates are too high. VPNs serve two purposes in our stack:

1. Infrastructure access — WireGuard VPN for team access to our management infrastructure
2. ISP privacy — encrypting the connection between operator workstations and our proxy gateway, so the local ISP sees VPN traffic rather than proxy connections

Traffic Isolation

Every client's traffic is isolated at the network level. Client A's proxies, profiles, and accounts never share infrastructure with Client B's. This prevents cross-contamination — if one client's operations trigger detection, the blast radius is contained.

Identity Management

Account Creation Protocol

Account creation follows a standardized process:

1. Persona generation — name, demographic details, profile photo (AI-generated, unique, not reverse-searchable), background story
2. Infrastructure assignment — profile created, proxy bound, fingerprint configured
3. Email creation — unique email address (preferably custom domain, not Gmail/Outlook for high-value accounts)
4. Phone verification — real SIM or persistent virtual number (not temporary/disposable)
5. Account registration — create the platform account using the persona's details
6. Warming — follow the platform-specific warming timeline before operational use

Credential Storage

All credentials are stored in an encrypted vault with:

• AES-256 encryption at rest
• Access logging (who accessed what, when)
• Automatic session invalidation after 30 minutes of inactivity
• Backup encrypted with a separate key stored offline

No credentials are stored in browser profiles, plain text files, spreadsheets, or any other insecure medium. The vault is the single source of truth.

Persona Continuity

Each persona maintains behavioral consistency across all interactions:

• Writing style (if the persona writes content)
• Active hours (matching the persona's timezone)
• Interest patterns (consistent browsing behavior)
• Device consistency (same fingerprint, same location pattern)

Persona drift — an account that gradually shifts behavior — triggers detection faster than a new account with consistent behavior from day one.

Monitoring and Alerting

Detection Monitoring

We run continuous detection tests against every active profile:

Automated checks (every 6 hours):

• Fingerprint consistency verification (has the configuration drifted?)
• Proxy health and blacklist check
• CreepJS and Pixelscan scan for new detection vectors

Platform health checks (daily):

• Account status verification (active, restricted, suspended)
• Feature availability check (can the account still perform its operational function?)
• Trust score indicators (CAPTCHA frequency, verification prompts, reduced visibility)

Alert Thresholds

Signal	Yellow (investigate)	Red (immediate action)
CAPTCHA frequency	>1 per session	>3 per session
Proxy blacklist	IP on 1 list	IP on 3+ lists
Fingerprint drift	1 parameter changed	3+ parameters changed
Account restriction	Feature limitation	Suspension
Detection score	CreepJS warning	Pixelscan fail

Cascade Prevention

When one account is detected, the question is: will detection cascade to related accounts? Our isolation model prevents this:

• Each account uses a unique profile with unique fingerprint
• Profiles don't share proxies (one proxy = one account)
• Accounts don't share credentials, email addresses, or phone numbers
• No cross-account activity (one profile never accesses another account's platform)

If account A is suspended, accounts B through Z remain unaffected because there are no linkable signals between them.

Cost Tracking

Operational cost per account:

Component	Monthly cost
Anti-detect browser (per profile)	$1-3
ISP proxy (dedicated)	$5-8
Phone number (maintenance)	$2-5
Monitoring infrastructure	$0.50-1
Total per account	$8.50-17

At 100 accounts, that's $850-1,700/month in infrastructure costs. The accounts need to generate more value than this to justify the operation.

FAQ

How much does this entire stack cost to set up? Initial setup for a 50-account operation: $5,000-15,000 depending on browser licenses, proxy commitments, and whether you build custom infrastructure or use managed services. Ongoing monthly: $1,500-3,000 for 50 accounts. The cost scales roughly linearly with account count.

Can this stack be operated by one person? Up to 20-30 accounts, yes. Beyond that, the monitoring, warming, and operational workload requires either additional team members or significant automation investment. We recommend one operator per 30-50 active accounts, with shared monitoring infrastructure.

What happens when a detection method changes? Our monitoring catches detection changes through daily platform health checks and regular fingerprint validation. When a new detection vector is identified: assess which profiles are affected → update configurations → revalidate → resume operations. The typical response time is 24-48 hours for configuration updates and 1-2 weeks for anti-detect browser vendor patches.

How do you handle disaster recovery? Profile data (fingerprint configs, cookies, credentials) is backed up encrypted daily. Infrastructure configuration is managed as code (Terraform/Ansible). In a total failure scenario, we can rebuild the operational environment in 4-8 hours — but account warming history is the real cost, which is why prevention (cascade isolation) matters more than recovery.