# Encrypted Mobile Proxy: Building an Undetectable Fingerprint With VLESS and Carrier IPs

VPNs encrypt traffic but get flagged by fingerprinting systems. Standard proxies pass IP checks but expose traffic to the proxy operator. Combining VLESS/Xray encryption with real 4G/5G carrier IPs creates a dual-layer setup where the connection is both encrypted and indistinguishable from legitimate mobile traffic.
This guide covers the architecture, configuration, and operational details for building that setup.
## Why VPNs Get Detected
VPN detection in 2026 does not rely on deep packet inspection alone. Platforms fingerprint connections across multiple signals simultaneously.
**TLS fingerprinting** identifies VPN protocols by their handshake patterns. OpenVPN and WireGuard produce distinctive TLS Client Hello signatures that commercial fingerprinting services (Fingerprint, DataDome, PerimeterX) match against known VPN profiles. Even with obfuscation, the underlying protocol structure leaks through metadata patterns.
**IP reputation scoring** flags VPN exit nodes based on aggregate behavior. When thousands of users share the same exit IP, the traffic patterns diverge from what a single residential or mobile user generates. IP intelligence databases from IPQualityScore, MaxMind, and Scamalytics maintain risk scores that platforms query in real time.
**ASN classification** reveals the network type behind an IP address. VPN providers operate on hosting ASNs (Amazon AWS, DigitalOcean, Hetzner). Platforms check ASN records and flag connections originating from datacenter infrastructure rather than ISP or carrier networks. Cloudflare's [ASN documentation](https://www.cloudflare.com/learning/network-layer/what-is-an-autonomous-system/) explains how these classifications work at the routing level.
**DNS resolver mismatches** create correlation gaps. A connection claiming to originate from a Verizon mobile IP but resolving DNS through Google's 8.8.8.8 reveals that the traffic is not coming from a genuine Verizon device. Platforms cross-reference the DNS resolver against the expected carrier resolver for the claimed network.
A real mobile proxy from carrier infrastructure passes all four checks by default. The IP is on a carrier ASN, the TLS signature matches the device OS, DNS resolves through carrier servers, and the IP reputation reflects normal mobile user behavior. The missing piece is encryption between the client and the proxy endpoint.
## VLESS + REALITY: Why This Protocol
VLESS is a lightweight proxy protocol running on [Xray-core](https://github.com/XTLS/Xray-core). Combined with REALITY transport security, it produces a connection that is indistinguishable from normal HTTPS traffic to any observer between the client and the proxy server.
REALITY eliminates server-side TLS fingerprint characteristics that identify traditional proxy protocols. Instead of presenting its own TLS certificate (which can be fingerprinted), a REALITY server mimics the TLS behavior of a legitimate website. Deep packet inspection sees what appears to be a standard HTTPS connection to a real domain.
Key properties of the VLESS + REALITY stack:
- Zero distinguishable TLS fingerprint on the server side
- Forward secrecy maintained across sessions
- Certificate chain attacks rendered ineffective
- Traffic indistinguishable from standard HTTPS to network observers
- Minimal protocol overhead compared to VMess or OpenVPN
The client-side configuration uses `xtls-rprx-vision` flow, which implements XTLS Vision for enhanced obfuscation. The `fingerprint` parameter in REALITY settings can be set to mimic Chrome, Firefox, Safari, or iOS Safari TLS signatures.
## Architecture: Dual-Layer Setup
The setup chains two layers:
```
Client Device
│
├── Layer 1: VLESS+REALITY tunnel (encrypted, undetectable)
│ │
│ ▼
│ Proxy VPS (relay node)
│ │
│ ├── Layer 2: SOCKS5 to mobile proxy (carrier IP)
│ │ │
│ │ ▼
│ │ Mobile Proxy Device (real 4G/5G SIM)
│ │ │
│ │ ▼
│ │ Target Website
│
└── Result: Encrypted tunnel + carrier-grade mobile IP
```
**Layer 1** encrypts all traffic between the client and a relay VPS. No observer (ISP, network admin, DPI system) can determine the traffic is proxy-related. The VPS sees the decrypted requests but only forwards them.
**Layer 2** routes the decrypted traffic from the VPS through a dedicated mobile proxy. The target website sees a real carrier IP from a 4G/5G network with matching ASN, DNS resolver, and device fingerprint characteristics.
The result: the ISP sees encrypted HTTPS traffic to an unremarkable server. The target sees a legitimate mobile connection. Neither layer exposes the full picture.
## Server Configuration (Relay VPS)
The relay VPS runs Xray-core with VLESS inbound and SOCKS5 outbound pointing to the mobile proxy.
```json
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "YOUR-UUID-HERE",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"dest": "www.microsoft.com:443",
"serverNames": ["www.microsoft.com"],
"privateKey": "YOUR-PRIVATE-KEY",
"shortIds": [""]
}
}
}
],
"outbounds": [
{
"protocol": "socks",
"settings": {
"servers": [
{
"address": "MOBILE-PROXY-HOST",
"port": 1080,
"users": [
{
"user": "PROXY-USERNAME",
"pass": "PROXY-PASSWORD"
}
]
}
]
}
}
]
}
```
The `dest` and `serverNames` in REALITY settings should point to a high-traffic website (Microsoft, Apple, Google) so the TLS mimicry blends with legitimate traffic patterns.
Generate keys with:
```bash
xray x25519
```
This outputs a private key (for the server) and a public key (for the client).
## Client Configuration
The client connects to the relay VPS using VLESS + REALITY. All traffic exits through the mobile proxy on the other end.
```json
{
"inbounds": [
{
"listen": "127.0.0.1",
"port": 1080,
"protocol": "socks",
"settings": {
"udp": true
}
}
],
"outbounds": [
{
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "VPS-IP-ADDRESS",
"port": 443,
"users": [
{
"id": "YOUR-UUID-HERE",
"flow": "xtls-rprx-vision",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"fingerprint": "ios",
"serverName": "www.microsoft.com",
"publicKey": "YOUR-PUBLIC-KEY",
"shortId": ""
}
}
}
]
}
```
Setting `fingerprint` to `ios` makes the TLS Client Hello signature match iOS Safari. For anti-detect browser setups where the profile spoofs an iPhone, this creates consistency between the TLS layer and the browser fingerprint layer.
Other fingerprint options: `chrome`, `firefox`, `safari`, `random`.
## Mobile Proxy Selection
The second layer requires a mobile proxy that provides real carrier IPs, not port-forwarded CGNAT addresses shared between dozens of users.
[VoidMob](https://voidmob.com/proxies) provides dedicated mobile proxies on physical SIM hardware with exclusive device ownership. Each proxy runs on a single device with a single SIM card on a single carrier connection. The technical properties that matter for this setup:
- **Carrier-native DNS resolution.** DNS queries route through carrier-assigned resolvers, not public DNS servers. This eliminates the DNS mismatch that exposes standard proxy setups.
- **Real ASN classification.** The IP registers on a carrier ASN (AT&T, T-Mobile, Vodafone), not a hosting provider ASN.
- **Full SOCKS5 with UDP support.** The relay VPS connects via SOCKS5, and UDP relay support means WebRTC, streaming, and real-time protocols work natively without TCP-only limitations.
- **OS fingerprint matching.** The device sends TTL values, TCP window sizes, and network stack signatures consistent with a real mobile device, not a desktop OS forwarding through a mobile IP.
- **IP trust scores above 95%.** No inherited abuse history from shared pools. VoidMob covers the technical details of their dedicated proxy architecture in their setup guides.
For multi-account operations, pairing this proxy setup with [non-VoIP SMS verification](https://voidmob.com/sms) from the same carrier network creates full signal consistency across IP, phone number, and carrier metadata. Their analysis of how platforms detect virtual numbers explains why carrier matching matters for verification pass rates.
## Anti-Detect Browser Integration
The encrypted mobile proxy chain outputs a local SOCKS5 endpoint at `127.0.0.1:1080`. Any application that supports SOCKS5 proxy configuration can route through it.
For [browser fingerprint](https://fingerprint.com/blog/browser-fingerprinting-techniques/) management with anti-detect browsers:
**GoLogin / Multilogin / AdsPower** all support SOCKS5 proxy input per browser profile. Create a profile with:
- Proxy: `socks5://127.0.0.1:1080`
- OS fingerprint: iOS (matching the VLESS `fingerprint: ios` setting)
- Timezone: matching the carrier IP's geographic region
- Language: matching the carrier IP's country
- WebRTC: disabled or set to the proxy IP
The consistency between TLS fingerprint (iOS), browser fingerprint (iOS profile), carrier IP (mobile ASN), and DNS resolver (carrier DNS) creates a signal stack that platform detection systems evaluate as a legitimate mobile user.
## Operational Considerations
**Latency.** The dual-layer adds latency from the extra hop through the relay VPS. Placing the VPS geographically close to the mobile proxy minimizes this. Expect 30-80ms added round-trip time depending on VPS location.
**VPS selection.** Use a VPS provider that allows port 443 traffic and does not inspect or filter HTTPS connections. Standard providers (Hetzner, Vultr, DigitalOcean) work. The VPS IP itself is not exposed to the target, so its ASN classification does not matter.
**Key rotation.** Generate new REALITY keypairs periodically. While the protocol is resistant to fingerprinting, rotating keys is good operational hygiene.
**Session persistence.** For account management, use sticky sessions on the mobile proxy side to maintain the same carrier IP across a browsing session. VoidMob's dedicated proxies maintain consistent IPs by default since the device and SIM are exclusively assigned.
**Monitoring.** Verify the setup is working correctly by checking your exit IP against the expected carrier, confirming DNS resolution through carrier servers (not public resolvers), and testing for [WebRTC leaks](https://voidmob.com/tools/webrtc-leak-test) that could expose the relay VPS IP or your real IP.
## What This Setup Defeats
| Detection Method | Standard VPN | Standard Proxy | VLESS + Mobile Proxy |
|---|---|---|---|
| TLS fingerprinting | Detected | N/A (unencrypted) | Passes (REALITY mimicry) |
| IP reputation | Flagged (shared VPN IP) | Varies | Passes (carrier IP, 95%+ trust) |
| ASN classification | Datacenter ASN | Varies | Carrier ASN |
| DNS mismatch | Common leak | Common leak | Carrier-native DNS |
| DPI detection | Protocol signatures visible | Unencrypted traffic | Indistinguishable from HTTPS |
| OS fingerprint | Desktop through VPN | Desktop through proxy | Matches mobile device |
The combination addresses every layer that platforms use to classify and block non-organic traffic. The encryption layer handles network-level detection. The mobile proxy layer handles application-level detection. Neither layer alone is sufficient, but together they cover the full detection surface.
---
**Source:** [VoidMob Blog - Encrypted Mobile Proxy: Undetectable Fingerprint Setup](https://voidmob.com/blog/undetectable-fingerprint-encrypted-mobile-proxy)