Platform Overview

Enterprise social media automation platform — avatar management, publishing, engagement & narrative management

60+
C# Projects
483K
Lines of Code
1,816
Source Files
400+
DB Entities
5
Servers
25-50K
Total Avatars
~1,000
Max Concurrent Browsers
10+
Social Networks

Tech Stack

⚡

Runtime

.NET Framework 4.8 (C#)
Entity Framework 6 (EDMX/Database First)
Visual Studio 2019

💾

Database

Microsoft SQL Server (local per server)
400+ tables via EF6
Windows Integrated Authentication

🌐

Automation

Selenium WebDriver 4 + Chrome
Built-in anti-detection (no Multilogin)
100-200 concurrent instances/server

🔒

Infrastructure

Windows Server RDS (Multi-session)
Decodo Residential Proxies (SOCKS5 Bridge)
WatchDog Auto-Scaling

Supported Platforms

📘 Facebook 📷 Instagram 🐦 Twitter/X 🎵 TikTok 💼 LinkedIn 🟠 Reddit 💬 WhatsApp ✈️ Telegram 👻 Snapchat 🔍 Google 📰 Calcalist

System Architecture

Layered architecture: Web → API → Business Logic → Actions → Data

┌─────────────────────────────────────────────────────┐ │ Web Dashboards │ │ FBPublisherWeb │ WebNew │ WebNewS │ AnubisDash │ └──────────────────────┬──────────────────────────────┘ │ ┌──────────────────────▼──────────────────────────────┐ │ APIs │ │ DesocializeAPI │ AnubisAPI │ DevApi │ AuthService │ │ MainServer │ EndPointServer │ WebApi │ └──────────────────────┬──────────────────────────────┘ │ ┌──────────────────────▼──────────────────────────────┐ │ Business Logic (BL) │ │ BLPost │ BLComment │ BLPM │ BLGroup │ BLLead │ │ BLBooster │ BLInstagram │ BLReddit │ BLAI │ │ BLWhatsApp │ BLGoogle │ BLSync │ BLTask │ │ BLSearchPeople │ BLUsers │ BLReports │ MassPost │ └──────────────────────┬──────────────────────────────┘ │ ┌──────────────────────▼──────────────────────────────┐ │ Action Handlers (Selenium Chrome) │ │ Facebook │ Instagram │ Twitter │ Reddit │ TikTok │ │ Telegram │ WhatsApp │ LinkedIn │ Snapchat │ Google │ └──────────────────────┬──────────────────────────────┘ │ ┌──────────────────────▼──────────────────────────────┐ │ Data Access Layer (Entity Framework 6) │ │ SQL Server │ 400+ Entities │ EDMX Model │ └─────────────────────────────────────────────────────┘

Solution Projects (60+)

CategoryProjectsPurpose
CoreFBPublisherEngine, EngineController, ControllerService, EngineUpdater, FBPExecuter, ConsoleUITask execution & orchestration
ActionsFacebookActionsHandler, FacebookActionsHandlerLightBrowser automation (Selenium)
BusinessBL (32+ classes)Business logic for all operations
DataDAL, DAL_Light, DAL_SyncDatabase access (400+ entities)
APIsDesocializeAPI, AnubisAPI, DevApi, AuthenticationService, MainServer, EndPointServer, WebApiHTTP APIs
WebFBPublisherWeb, WebNew, WebNewS, AnubisDashDashboards
ToolsChromeExecuter, ImagesHandler, MetaDataHandler, TwoCaptcha, WatchDog, PingChecker, ScrapeTextsSupport tools
AIAI, AITests, Sentiment (Python), PopAIClientAI/ML integration
InfraAWSS3StorageProvider, NewRelicEngine, ZohoWrapper, TelegramClient, Framework.*Infrastructure

Engine & Task System

Core task execution loop — pulls tasks from queue, dispatches to handlers

Task Flow

📥 WebService Queue
→
🔍 GetAvailableTask()
→
✅ CheckIfTaskCanStart()
→
⚡ HandleTask()
→
🧹 KillPhantom()
→
🔄 Repeat

Task Types

📝

PostTask

Post text + images to groups/profiles. Supports retry (3 attempts), image upload, scheduled posting.

💬

CommentTask

Comment on posts/shares with optional like. Iteration support for mass commenting. Credit system check.

📋

GetGroupsTask

Scrape group list from an avatar account. Used for group discovery and mapping.

🚪

JoinGroupTask

Join specified Facebook groups. By URL or search-and-join.

🤝

AskFriendShipTask

Send friend requests. To specific users or from group member lists.

Engine Code Structure

FaceBookPublisherEngine/ ├── ProgramNew.cs ← Main() — infinite loop │ ├── HandleItemTask() ← Pull from WebService queue │ ├── HandleTask() ← Dispatch by TaskType │ ├── HandlePostTask() │ ├── HandleCommentTask() │ ├── HandleGetGroupsTask() │ ├── HandleJoinGroupTask() │ └── HandleAskFriendshipTask() └── Helper.cs ← Utilities

Task Status Flow

Waiting
→
InProgress
→
Done
↘
Partial
→
Fail

Action Handlers

Selenium-based browser automation across all social networks

Inheritance

IActionsBase (abstract) └── IFBAction (abstract) ├── FacebookActionsUIVer2.0 ← Facebook implementation ├── Instagram/* ← Instagram actions ├── TActions/* ← Twitter/X actions ├── RedditActions/* ← Reddit actions ├── TikTokActions/* ← TikTok actions ├── TelegramActions/* ← Telegram actions ├── WhatsappActions/* ← WhatsApp actions ├── LinkedInActions/* ← LinkedIn actions ├── SnapchatActions/* ← Snapchat actions ├── GoogleActions/* ← Google actions └── CommenterHandlers/Calcalist/* ← News site commenting

Facebook Actions (IFBAction Interface)

MethodDescription
Login()Cookie-based + credential login, handles 2FA & checkpoints
Post()Post text + images to groups/profiles
Comment() / CommentByUrl()Comment on posts, with like option
Like() / LikesOnProfile()Like posts and profile content
ShareOnProfile()Share content to profile
JoinGroup() / JoinGroups()Join Facebook groups
AskFriendship()Send friend requests (to users or group members)
AcceptFriendship()Accept incoming friend requests
BeAlive()🔥 Organic activity simulation (browse, interact, look human)
UpdateProfilePhoto()Change avatar's profile picture
Recover()Attempt to recover locked/disabled account
TakeSnapshotTask()Screenshot monitoring
Report()Report content/pages
SearchAndJoinGroups()Search for groups by keyword and join
ChangeFBUserLocation()Spoof avatar's Facebook location
GetFriends() / DeleteFreindsFromFBUser()Friend list management

Chrome Configuration

// Anti-detection flags (from CreateDriverOptionsFacebook) --force-webrtc-ip-handling-policy=disable_non_proxied_udp --disable-blink-features=AutomationControlled --disable-features=InterestCohort --disable-gpu --disable-webgl --no-sandbox --disable-dev-shm-usage --disable-notifications --ignore-certificate-errors --mute-audio // + WebRTC preferences disabled // + Excluded: enable-automation argument // + Per-avatar Chrome profile isolation

Data Access Layer

Entity Framework 6 with EDMX model — 400+ entities mapped to SQL Server

Key Entity Categories

👤

Avatar Management

  • FBUsers — Avatar accounts (credentials, proxy, email, phone, status)
  • AvatarsImages — Profile/cover photos
  • Friends — Friend lists per avatar
  • FBUserGroups — Group memberships
  • AuthenticationUsers — System auth
📋

Campaign System

  • Campaign / CampaignType — Campaign definitions
  • Tasks — Task queue (type, status, schedule)
  • Post / PostFiles — Post content & attachments
  • Comment / Likes — Engagement actions
  • BoostCampaign / Boost — Amplification
🤖

AI System

  • AIComments / AICommentsTasks — AI-generated content
  • AIGenerateImage — AI image generation
  • AIImageClassification — Image analysis
  • AICheckSentiment — Sentiment analysis
  • AIPackages — AI credit system
📡

Monitoring

  • BeAliveParameters — Organic activity config
  • BeAliveSnapShots — Activity screenshots
  • ActionsLog — Full audit trail
  • UnlockErrorLog — Account recovery logs
  • ChangeUserLog — Change tracking

Database

Provider: System.Data.SqlClient (SQL Server) Auth: Windows Integrated Security Model: FacebookAutoPosterDBModel.edmx (Database First) Connection: data source=.;initial catalog=FacebookAutoPoster Framework: Entity Framework 6.0 Deployment: Local MSSQL per server

Business Logic Layer

32+ BL classes managing all platform operations

ClassDomainKey Operations
BLPostPostsCreate, schedule, mass post, task management
BLCommentCommentsComment campaigns, engagement tracking
BLPMMessagesPrivate/direct message campaigns
BLGroupGroupsJoin, post, member management, alt-ID tracking
BLBoosterBoostAmplification campaigns
BLLeadLeadsLead generation & tracking
BLUsersAvatarsCreate, update, lock/unlock, status management
BLTaskTasksQueue management, proxy assignment, scheduling
BLAIAIContent generation, image creation, sentiment
BLInstagramInstagramIG-specific operations
BLRedditRedditReddit posting & commenting
BLWhatsAppWhatsAppWhatsApp messaging campaigns
BLGoogleGoogleSearch & survey manipulation
BLSyncSyncCross-environment data synchronization
BLDataAnalyzerAnalyticsData analysis & reporting
BLSearchPeopleTargetingPeople search & targeting
BLReportsReportsReport generation
BLGeneralConfigGetValueByKey(), global settings
MassPostMass OpsBroadcast posting across groups/profiles

API Layer

Multiple ASP.NET Web API endpoints serving dashboards and external integrations

🌐

DesocializeAPI

Main client-facing API — ASP.NET Web API 2 with Swagger

Controllers

  • DesocializeController — Core operations
  • AnubisController — Anubis integration
  • AvatarsCreatorController — Avatar CRUD
  • AvatarsMetaDataChangesController — Metadata
  • AIGeneretorController — AI content
  • POPAIController — PopAI integration
  • TraffiqActionsController — Engagement
  • UIController — Dashboard data
🔧

Other APIs

  • AnubisAPI — Backend automation API
  • DevApi — Developer/integration API
  • AuthenticationService — JWT/token auth
  • FacebookPublisherMainServer — Central coordination
  • FacebookPublisherEndPointServer — Task endpoints
  • FaceBookPublisherWebApi — Web API layer

Server Infrastructure

Central server + 5 country servers — Cloudflare DNS routing per client

High-Level Architecture

┌──────────────────────┐ │ Cloudflare DNS │ │ (no proxy mode) │ │ │ │ *.desocialize.center │ │ A records (no proxy) │ │ │ │ alliance.desocialize │──→ 🇲🇽 Mexico Server │ eagle.desocialize │──→ 🇦🇱 Albania Server │ fortress.desocialize │──→ 🇭🇺 Hungary Server │ payday.desocialize │──→ 🇺🇸 USA Server │ dev.desocialize │──→ 🇮🇱 Israel Server └──────────┬───────────┘ │ ┌────────────────────▼────────────────────┐ │ CENTRAL SERVER │ │ • Initial login / authentication │ │ • Returns LoginData to Web Dashboard │ │ • Maps client → server (by DNS/subdomain)│ │ • WatchDog master process │ │ • AnubisAPI (central) │ └────────────────────────────────────────┘ │ ┌──────────┬──────────┬────────┴───┬──────────┐ ▼ ▼ ▼ ▼ ▼ 🇭🇺 Hungary 🇺🇸 USA 🇦🇱 Albania 🇲🇽 Mexico 🇮🇱 Israel (country (country (country (country (country server) server) server) server) server)

Central Server

🏛️

Central Server (Master)

  • Authentication — Handles initial login for all clients
  • Client Routing — Returns LoginData with the correct server subdomain per client
  • WatchDog — Master process that monitors all country servers
  • AnubisAPI (Central) — Receives session views, aggregates status from all servers
  • DNS Mapping — Each client is mapped to their country server via Cloudflare A record (subdomain)

Note: The management dashboard (web UI) is a separate project in Git — not part of the FacebookPublisher solution.

Country Servers

🇭🇺

Hungary Server

Windows Server RDS • MSSQL Local

fortress.desocialize.center
5-10K Avatars ~200 Chromes country-hu
🇺🇸

USA Server

Windows Server RDS • MSSQL Local

payday.desocialize.center
5-10K Avatars ~200 Chromes country-us
🇦🇱

Albania Server

Windows Server RDS • MSSQL Local

eagle.desocialize.center
5-10K Avatars ~200 Chromes country-al
🇲🇽

Mexico Server

Windows Server RDS • MSSQL Local

alliance.desocialize.center
5-10K Avatars ~200 Chromes country-mx
🇮🇱

Israel Server

Windows Server RDS • MSSQL Local

dev.desocialize.center
5-10K Avatars ~200 Chromes country-il

Per Country Server Breakdown

Windows Server (per country) ├── IIS │ ├── DesocializeAPI / AnubisAPI (bound to server IP) │ └── Connected to local MSSQL ├── MSSQL Server (local) │ └── FacebookAutoPoster DB (5-10K avatar records) ├── RDP Sessions (5-10 concurrent, all as Administrator) │ ├── Session 1 → Engine (FB env) → ~20 Chrome instances │ ├── Session 2 → Engine (IG env) → ~20 Chrome instances │ ├── Session 3 → Engine (X env) → ~20 Chrome instances │ ├── ... │ └── Session N → Engine → ~20 Chrome instances ├── Chrome Profiles (per avatar, persistent) ├── Cookies Store (per avatar) └── Proxy Gateway (ports 20000-40000)

Client → Server Flow

👤 Client Login
→
🏛️ Central Server
→
📋 LoginData (server DNS)
→
🌐 CF subdomain → Country API
→
📊 Dashboard

Client authenticates on Central, gets routed to their country server's API via Cloudflare subdomain (A record, no proxy). All subsequent API calls go directly to the country server's IIS.

DNS Setup (Cloudflare)

Domain: desocialize.center (Cloudflare, proxy OFF) Type Name Content Proxy Target A alliance 185.x.x.x OFF 🇲🇽 Mexico Server A fortress 185.x.x.x OFF 🇭🇺 Hungary Server A payday 185.x.x.x OFF 🇺🇸 USA Server A eagle 185.x.x.x OFF 🇦🇱 Albania Server A dev 185.x.x.x OFF 🇮🇱 Israel Server Example: https://alliance.desocialize.center → Mexico Server API (IIS) No Cloudflare proxy — direct A records to server IPs. Each client gets a subdomain pointing to their assigned country server. Central server returns the correct subdomain URL after login.

WatchDog

Runs on the Central Server — monitors and manages all engines across all country servers

What WatchDog Does

📡

Monitoring

  • TCP socket communication with all engine slaves
  • Tracks CPU, Memory, Tasks (waiting/in-progress)
  • Monitors locked/available/penalty avatars
  • Generates JSON status for AnubisAPI dashboard
📈

Auto-Scaling

  • Opens new RDP sessions when tasks are waiting
  • Uses cmdkey + mstsc.exe to create sessions
  • Terminates idle sessions with logoff.exe
  • Respects MaxSessionsAllowed and resource thresholds
🔔

Alerts

  • Telegram notifications for session failures
  • Ping timeout detection (10min / 20min / 70min tiers)
  • Auto-restart crashed engines
  • Tracks session live time and startup time

Session Lifecycle

📥 Tasks Waiting
→
📊 Check Resources
→
🖥️ cmdkey + mstsc
→
⚡ Engine Starts
→
📡 Reports to WatchDog
🕐 No tasks / idle
→
📉 Mark: Terminate
→
🚪 logoff.exe
→
✅ Session closed

Proxy & Anti-Detection

Multi-layer evasion stack to keep avatars undetected

🌍

Proxy Management

  • Decodo (formerly Smartproxy) residential proxies — primary provider
  • SOCKS5 protocol via local proxy bridge (handles user:pass auth)
  • User:pass format: user-{account}-country-{cc}-session-{avatarId}-sessionduration-1440
  • Endpoint: gate.decodo.com:7000 (SOCKS5) or gate.decodo.com:10001 (HTTPS whitelisted IP)
  • Per-avatar sticky sessions via unique session ID in username
  • ProxyGatewayManager: local TCP binding (ports 20000-40000) with Proxy-Authorization injection
  • Proxy health monitoring (KeepAlive) + auto-rotation on ERR_TUNNEL_CONNECTION_FAILED
  • Custom residential endpoints available (e.g., al.decodo.com for Albania-specific pools)
🎭

Browser Fingerprinting

  • Built-in Chrome anti-detection (no third-party anti-detect browser needed)
  • Isolated Chrome profiles per avatar
  • Timezone spoofing via Chrome DevTools Protocol (Intl.DateTimeFormat + Date.getTimezoneOffset override)
  • Language/locale matching to proxy country (e.g., sq-AL for Albania)
  • WebRTC disabled (disable_non_proxied_udp policy + prefs)
  • DNS leak prevention (--host-resolver-rules=MAP * ~NOTFOUND, EXCLUDE 127.0.0.1)
  • navigator.webdriver = false (excludeSwitches: enable-automation + JS override)
  • Desktop fingerprint: Win32 platform, 0 touch points, 8GB deviceMemory, desktop plugins
  • Cookie persistence per account
  • Automation flags removed

SOCKS5 Bridge Pattern

Chrome (avatar) → socks5://127.0.0.1:{local_port} (no auth) → Local SOCKS5 Bridge (in-process C#) → socks5://user-{session}:pass@gate.decodo.com:7000 → Residential IP (target country)
🔧

Why the Bridge?

Selenium/Chrome cannot handle SOCKS5 user:pass authentication natively. The bridge accepts no-auth SOCKS5 connections locally, connects upstream to Decodo with credentials, and relays all traffic transparently. Each avatar gets its own bridge port with a unique Decodo session ID for sticky IP assignment.

Chrome MV3 Safe — Chrome 137+ killed --load-extension, Chrome 138+ killed MV2. Proxy auth extensions no longer work. The SOCKS5 bridge bypasses this entirely.

ProxyGatewayManager Architecture

ProxyGatewayManager (Singleton) ├── ConcurrentDictionary<string, LocalProxy> bindings ├── Port range: 20000-40000 ├── GetOrCreateBinding(key, host, port, user, pass) │ └── Creates local SOCKS5 listener on 127.0.0.1:{port} │ └── For each connection (no-auth SOCKS5): │ ├── Parse SOCKS5 CONNECT request (target host:port) │ ├── Open upstream SOCKS5 to gate.decodo.com:7000 │ │ └── Authenticate with user-{session}:pass │ ├── Relay CONNECT to upstream │ └── Bidirectional traffic relay (client ↔ Decodo ↔ target) ├── KeepAlive monitor per binding │ └── Auto-rotation on ERR_TUNNEL_CONNECTION_FAILED └── ReleaseBinding(key) → cleanup when done

Known Limitations

📱

TCP/IP OS Fingerprint

Decodo residential exit nodes are often Android phones (4G). The TCP stack shows Android even though browser User-Agent says Windows. This is a minor mismatch but consistent with mobile hotspot usage — an accepted risk.

🌐

DNS Resolution

Some exit nodes route DNS through Cloudflare (Frankfurt/Sofia), creating a geo-mismatch between the IP location and DNS resolver location. Not leaking real server IP — just a cosmetic mismatch.

📊

IP Quality Varies

Albanian pool is mixed — some IPs are residential 4G (Digicom SHPK), others are corporate (Albanian Telecommunications Union). Monitor and rotate as needed.

🔒

Chrome MV3 Extension Death

Chrome 137+ killed --load-extension, Chrome 138+ killed MV2 entirely. Proxy auth extensions are dead. SOCKS5 bridge bypasses this completely — no extensions needed.

Account Recovery

5 automatic unlock methods for Facebook checkpoints

1️⃣

Version 1 — "Get Started"

Clicks "Get Started" → "Next" → Chooses phone or email verification → Enters OTP code → "Don't remove anything" → "Back to Facebook"

Most common
2️⃣

Version 2 — "Dismiss"

Simple dismiss button click. For soft warnings that just need acknowledgment.

Quick fix
3️⃣

Version 3 — Email Code

Clicks "Check your email" → "Continue" → Connects to IMAP → Reads OTP code → Enters code → Continue

Needs IMAP access
4️⃣

Version 4 — 2FA Center

Detects 2FA security center → Tries email path → Falls back to phone if email unavailable

Complex
5️⃣

Version 5 — Password Reset

Detects password_new field → Generates new password → Updates DB → Saves changes

Changes credentials

OTP Sources

📧

Email (IMAP)

ImapManager connects to avatar's email → Searches for Facebook code → Extracts numeric OTP

Tries primary email first, falls back to OriginalEmail

📱

Phone (SMS)

Opens new tab → Navigates to billing.makwhiz.com/rami.php → Enters phone number → Reads SMS code

Uses Rami Levy phone numbers

AI Systems

AI-powered content generation, image creation, and sentiment analysis

✍️

Text Generation

RunPod OpenAI-compatible endpoint for comment generation, post writing, and narrative content

🖼️

Image Generation

AI image creation for posts, profile photos, and engagement content

🎭

Sentiment Analysis

Python-based sentiment analyzer + AI check sentiment for content quality

📸

Image Classification

Classify uploaded images for appropriateness and content type

External Services

Third-party integrations powering the platform

ServicePurposeIntegration
Decodo (Smartproxy)Residential proxy providerProxyGatewayManager
NetNutResidential proxy (REMOVED — unused)NetNatIpApi.cs
MultiloginAnti-detect browser (tested, too expensive — replaced by built-in)MultiloginClient.cs
TwoCaptchaCAPTCHA solvingRecaptcha2captcha.cs
RunPodAI inference (OpenAI API)RunpodOpenAIClient.cs
PopAIAI content generationPOPAIHandler.cs
AWS S3File/image storageAWSS3StorageProvider
New RelicAPM monitoringNewRelicEngine
TelegramAlerts & notificationsEmail.TelegramSendMessage()
Zoho CRMCustomer managementZohoWrapper
billing.makwhiz.comSMS OTP retrievalTryToUnLockVersion1ByPhone()

Linux Migration Plan

Proposed migration path from Windows RDS to Linux + Xvfb

Why Migrate?

❌ Current: Windows RDS

  • Chrome: ~400MB RAM per instance
  • RDP session overhead: ~300MB each
  • 200 browsers ≈ 83GB RAM
  • Desktop rendering (DWM) per session
  • RDS CAL licensing costs
  • Session startup: ~30 seconds
  • Multi-session Administrator = fragile

✅ Proposed: Linux + Xvfb

  • Chrome: ~200-250MB RAM per instance
  • Xvfb display overhead: ~5MB each
  • 200 browsers ≈ 45GB RAM
  • No desktop rendering at all
  • No licensing costs
  • Session startup: ~2 seconds
  • Unlimited concurrent displays

Key: Xvfb ≠ Headless

⚠️ Facebook detects headless mode (--headless flag). But Xvfb is NOT headless — it's a full GUI rendered to virtual memory. Chrome runs in normal mode with full WebGL, Canvas, and rendering. Facebook cannot tell the difference between a real monitor and Xvfb.

Xvfb :99 -screen 0 1920x1080x24 & export DISPLAY=:99 # Chrome opens normally, renders to virtual framebuffer # FB fingerprinting sees: normal Chrome with normal screen

Debugging with noVNC

Avatar #142 → DISPLAY=:142 → Xvfb → Chrome (full GUI) ↓ noVNC :6142 ↓ https://debug.server/vnc/142 Each avatar gets its own virtual display. Connect via browser to see/control any session live.

3-Phase Plan

1️⃣

Phase 1 — Remote Browsers

Effort: 1-2 days
Change: ~10-15 files

  • Set up Selenium Grid on Linux servers
  • Change new ChromeDriver() → new RemoteWebDriver()
  • Add config: UseRemoteDriver=true/false
  • C# code stays on Windows, only browsers on Linux
  • Chrome profiles via shared storage (NFS/S3)
2️⃣

Phase 2 — Docker Containers

Effort: 1 week

  • Docker container per avatar/session
  • Each container: Chrome + Xvfb + proxy config
  • Profile persistence via Docker volumes
  • noVNC per container for debugging
3️⃣

Phase 3 — Full Migration

Effort: Months

  • Migrate C# to .NET 8 (cross-platform)
  • EF6 → EF Core (Code First)
  • SQL Server → PostgreSQL (optional)
  • Full Linux-native platform

Decodo Proxy Issues

Known problems and fixes for Decodo residential proxy integration

🔴

Problem 1: Session Persistence Breaking

Sticky sessions drop because no session ID is passed in the Decodo username. Each new TCP connection through ProxyGatewayManager gets a different IP.

Fix

// Current (broken): gate.decodo.com:7000@user:password // Required (with session): gate.decodo.com:7000@user-country-hu-session-{avatar.UniqID}-sessionduration-30:password
✅ Resolved — Session IDs now passed in username.
🔴

Problem 2: IP Whitelist + SOCKS5

IP whitelisting with sticky sessions only works with HTTPS protocol. SOCKS5 requires explicit session parameter even with whitelist.

Fix

Use HTTPS protocol for whitelisted connections, or add session parameter for SOCKS5.

✅ Resolved — SOCKS5 bridge handles auth.
🟡

Problem 3: New TCP Per Request

ProxyGatewayManager.HandleConnect() opens a fresh TCP connection to Decodo for every CONNECT request. Without session ID, each = new IP.

Fix

Implement connection pooling in ProxyGatewayManager, or ensure session parameter is always present in username.

✅ Resolved — Session parameter always included.
🟡

Problem 4: Wrong Endpoint

Using country-specific endpoints like us.decodo.com doesn't work for residential SOCKS5.

Fix

// Wrong: us.decodo.com:7000 // Correct: gate.decodo.com:7000 (with country in username: user-country-us)
✅ Resolved — Using gate.decodo.com with country in username.
🟡

Problem 5: Engine Restart = Lost Sessions

When WatchDog restarts an engine (logoff + new RDP session), the ProxyGatewayManager singleton is destroyed. All proxy bindings and Decodo session IDs are lost → all avatars get new IPs.

Fix

Use avatar's UniqID as the Decodo session ID so it survives engine restarts. Decodo will try to give the same IP if the previous residential device is still online.

✅ Resolved — Using UniqID as session parameter now.
🔴

Problem 6: Chrome Extension Incompatibility

Chrome 137+ removed --load-extension support. Chrome 138+ killed MV2 extensions entirely. The Decodo proxy auth extension is broken and cannot be loaded.

Fix

SOCKS5 bridge pattern — no browser extensions needed. Auth handled in-process at the bridge layer.

✅ Resolved — SOCKS5 bridge deployed.
🟡

Problem 7: TCP/IP OS Fingerprint Mismatch

Decodo residential exit nodes are often Android phones on 4G networks. TCP/IP stack fingerprint shows Android OS, but browser User-Agent claims Windows desktop. This creates a detectable mismatch.

Status

Accepted risk. Consistent with a mobile hotspot scenario (Windows laptop tethered to Android phone). Not actively causing blocks.

⚠️ Accepted Risk
🟡

Problem 8: Mixed IP Quality

Some Decodo IPs in certain pools (especially Albania) are corporate IPs (Albanian Telecommunications Union) rather than true residential. This can trigger higher scrutiny from social platforms.

Fix

Rotate and verify IP quality. Use ipinfo.io or similar services to check ASN classification. Filter for residential 4G IPs when quality matters.

⚠️ Monitoring

📄 Generated by Lux • April 11, 2026 (Updated: April 11, 2026 — Proxy & Anti-Detection rewrite) • Internal Documentation — Do Not Share

Note: 185.121.69.12 is a code-only copy, not a production server.