vless   VLESS (V2Ray)

Community-maintained public CIDR lists of Russian mobile whitelist ranges allow operators to identify specific whitelisted IP blocks within cloud providers: a /22 subnet inside Yandex Cloud's /16 pool appears on these lists, while the ephemeral addresses from a different /20 pool of the same provider do not. Reserving a static IP from the whitelisted /22 allows the Reality handshake to complete and traffic to proxy from external vantage points, though in-whitelist passage on a real mobile device remained unconfirmed at time of writing.

2026-amigocarra-bypassing-russian-federation-s Issue body — Yandex Cloud architecture paragraph deployment

VLESS+Reality with uTLS and decoy SNI pointed at popular domains (vk.com, cloudflare.com) bypasses standard DPI blocking on MTS and has operated stably for one real user over several weeks with thousands of connections logged. However, an identical configuration failed to establish a single connection for a second user on the same carrier but in a different network segment (Moscow number vs. regional/southern number), including during periods confirmed to be outside whitelist activation.

2026-amigocarra-bypassing-russian-federation-s Issue body — confirmed working / not working sections evaluation

As of 2026, AnyTLS lacks a standardized subscription link format (unlike VLESS/Trojan/Hysteria2), requires manual JSON configuration distribution, and is supported primarily by sing-box with limited support in v2rayNG and Shadowrocket. The guide explicitly warns it is unsuitable for production environments and recommends VLESS or Hysteria2 for production deployments and Hysteria2 for high-performance needs.

2026-anon-anytls-anytls-sing-box-2026 §1.4, §4.8, §8.2–8.3 deployment

Compared to peer protocols, AnyTLS rates 'medium' performance (vs. VLESS 'high', Hysteria2 'very high', TUIC 'high'), uses TCP/TLS transport (vs. UDP/QUIC for Hysteria2 and TUIC), and relies on padding-based obfuscation vs. REALITY/WebSocket (VLESS) or HTTP/3 framing (Hysteria2). Client ecosystem support is currently limited primarily to sing-box, vs. broad cross-client support for VLESS, Trojan, and Hysteria2.

2026-anon-anytls-anytls-sing-box-2026 §1.5, Table 1.5 evaluation

As of 2026-02-23, the dominant consumer GFW circumvention stack for mainland Chinese users is: Clash Verge Rev on Windows/macOS, Clash Meta for Android, and Shadowrocket (requiring a non-mainland Apple ID) on iOS — all configured via subscription URLs purchased from commercial 'airport' (机场) proxy services starting at ¥2/month.

2026-anon-b-2026-youtube 如何翻墙观看 deployment

The article documents that large-scale 'one-click' commercial VPN providers with static protocol stacks have become effectively non-viable in China, while subscription-based proxy node services using open-source clients (Clash, Shadowrocket) with server-side rapid IP and datacenter switching demonstrate substantially greater resilience to GFW blocking waves.

2026-anon-letsvpn-vpn §为啥傻瓜式一键VPN越来越难活 & §应该怎么选替代方案 evaluation

Adversarial pre-padding — prepending stochastic byte noise to packets — degrades ET-BERT encrypted traffic classification accuracy from >99% to 25.68%, exposing a structural vulnerability in all payload-byte-dependent detection systems. White-box adversarial attacks (Ayaka AH-MSI) additionally achieve evasion rates exceeding 99.5% against standard continuous-time sequence models via Manifold Shattering, where adversaries align malicious temporal distributions with benign baselines.

2026-ferrel-aegis-adversarial-entropy-guided §II, §VI-A detection

AEGIS, a flow-physics-only ML classifier using a Hyperbolic Liquid State Space Model evaluated on a 400GB adversarial corpus including VLESS Reality, GhostBear, and AMOI-morphed traffic, achieves F1-score 0.9952, 99.50% TPR, and 0.2141% FPR at 262.27 µs inference latency on an RTX 4090. The system discards all payload bytes and classifies traffic exclusively on 6-dimensional flow physics: packet size, inter-arrival time, directionality, TCP window size, TCP flags, and payload ratio.

2026-ferrel-aegis-adversarial-entropy-guided §V, Table III evaluation

Automated proxy engines (e.g., Xray-core running VLESS Reality in automated mode) generate deterministically rigid inter-arrival time distributions because they cannot synthesize the stochastic variance of human-driven IAT, even when volumetrically anchored to benign distributions ('Fat Middle' anchoring via AMOI). The AEGIS Thermodynamic Variance Detector identifies this rigidity via Shannon Entropy of hidden states across 1,000-packet causal windows, rendering volumetric anchoring mathematically distinguishable from genuine human traffic.

2026-ferrel-aegis-adversarial-entropy-guided §III-E, §V-B detection

Flow-physics classifiers face a fundamental 'Human Entropy Horizon': when VLESS Reality multiplexes true human entropy (a human actively browsing web applications), AEGIS achieves a detection rate of only 1.17%, because XTLS wrappers impart near-zero mechanical overhead and the temporal physics remain entirely stochastic. This implies adversaries operating at human interaction speeds can evade flow-based detection, but must abandon automated high-throughput C2 scripts.

2026-ferrel-aegis-adversarial-entropy-guided §V-G detection

On Beeline mobile internet (AS16345, Russia), enabling TUN mode with a VLESS+REALITY proxy consistently triggers ISP-level connection degradation after 5–15 minutes, while using the same proxy in HTTP/SOCKS5 proxy mode produces no such effect. The detection is reproducible across two independent GUI clients (v2rayN and Throne) with stock settings, suggesting the DPI trigger is the TUN traffic pattern rather than a client-specific artifact.

2026-gohoski-russia-possible-tun Issue body detection

The TUN-mode detection occurs exclusively on Windows 10 and does not manifest on Android using the same VLESS+REALITY server and Beeline SIM, nor when running as a system proxy on Windows. The effect is also observed to impact all devices sharing the Windows hotspot simultaneously, ruling out endpoint-local causes and confirming the classification occurs upstream at the ISP/TSPU layer.

2026-gohoski-russia-possible-tun Issue body detection

As of August 2026 in Fuzhou, Fujian, most censorship-resistant service providers are non-functional; a small number of providers using v2ray remain partially functional, while Tor Browser bridges and Snowflake are no longer usable.

2026-molotoves-wall-behind-wall Issue body deployment

Iran's DPI blocks VLESS/WS traffic routed through Cloudflare CDN in full-strict TLS mode with regularly rotated clean Cloudflare IPs, demonstrating that CDN-fronted traffic is not opaque to the censor and that IP-layer evasion (using clean CDN IPs) is insufficient when the SNI is fingerprinted.

2026-pooribitwise-iran-advanced-dpi Description detection

The Russian DPI maintains two whitelists that exempt flows from the freeze: (1) a SNI-based whitelist covering select domains (visible in the TLS ClientHello), and (2) a CIDR-based whitelist of IP subnets for trusted destination servers. The SNI whitelist can be exploited by VLESS+Reality clients using an allowed SNI value as the apparent destination; the CIDR whitelist requires routing through an IP from a whitelisted prefix, making circumvention 'extremely difficult' without an intermediate node in a whitelisted subnet.

2025-hyperion-cs-censor-has-new upd3, upd4 detection

Beyond business-filing cross-references, the paper introduces a method of linking VPN provider families by showing they share VPN server cryptographic credentials (Shadowsocks passwords, server TLS fingerprints) across distinct app identities. This extends prior ownership-attribution methods that relied solely on corporate registry data and code similarity, adding shared live infrastructure as a linkage signal that is harder for operators to obscure.

2025-mixon-baca-hidden §3 (Methodology), §4 evaluation

Iranian censors actively detected and blocked circumvention proxies in real time during the June 2025 shutdown: MTProto proxies, v2ray tunnels (VLESS and VMESS variants), and Tor bridges using both Snowflake and obfs4 all experienced mixed or degraded success as proxies were identified and blocked.

2025-pirooz-gthb-internet-completely-blocked Abstract / community testing thread detection

Per-flow RTTdiff detection rates are only ~20% because the majority of proxy flows connect to CDN-cached content (Cloudflare, Google, Fastly) that sits within 5ms of the proxy, suppressing the discrepancy. However, aggregating across flows per website visit yields detection rates exceeding 70%—and from the abstract, approximately 80% of top-5K domains generate at least one detectable flow—with half of those detections made within the first 60 packets. This means an adversary can reliably expose client and proxy IPs after just a few website visits.

2025-xue-discriminative §VI-C-2, Table II detection

Proxy users who resolve DNS locally (at the client) are approximately twice as susceptible to RTTdiff fingerprinting compared to users who resolve DNS at the proxy, across all tested client/proxy location combinations. Local DNS returns IPs optimally reachable from the client's region, which may be geographically distant from the proxy, increasing the proxy-to-server path distance and thus the RTTdiff discrepancy.

2025-xue-discriminative §VI-C-2 detection

Cross-layer RTT discrepancy (RTTdiff) is a protocol-agnostic fingerprint that exploits an inherent architectural property of all proxy setups: transport-layer sessions terminate at the proxy while application-layer sessions remain end-to-end. Evaluation across 10 proxy protocols—including VMess, Shadowsocks, VLESS, Trojan, XTLS-Vision, and obfs4-wrapped SOCKS—shows near-identical detection rates for all except obfs4, confirming the fingerprint is not tied to any specific obfuscation scheme. At FPR=0.01, per-website detection rates exceed 70% across all tested client and proxy location combinations.

2025-xue-discriminative §I, §VI-C detection

In Iran circa mid-2024, V2Ray-based protocols (VLESS/VMess via subscription services) emerged as the recommended practical replacement for failed DPI-bypass tools, with open-source clients MahsaNG and Oblivion cited as accessible entry points.

2024-arash1343-v2ray-v2ray-configuration Abstract / thread summary deployment

V2Ray NG and comparable clients require a third-party remote server to operate; user-side configuration alone is insufficient, establishing distributed server infrastructure as a necessary dependency for Iran-targeted circumvention as of 2024.

2024-arash1343-v2ray-v2ray-configuration Abstract / thread summary deployment

Obfuscated proxy traffic (including Shadowsocks, VMess, VLESS, Trojan, obfs4, and REALITY) can be reliably fingerprinted by detecting encapsulated TLS handshakes — the inner TLS ClientHello that appears inside an outer encrypted tunnel. This fingerprint is protocol-agnostic: any proxy that wraps TLS-bearing application traffic will produce it. The authors deployed a similarity-based classifier within a mid-size ISP serving over one million users and demonstrated detection with minimal collateral damage.

2024-xue-fingerprinting Abstract, §5, §7 detection

While stream multiplexing reduces the visibility of encapsulated TLS handshakes by merging inner connections, the paper cautions that multiplexing plus random padding alone is "inherently limited" as a long-term countermeasure. Censors can adapt by monitoring burst sizes and round-trip counts at the outer-connection level, which remain correlated with the number of inner TLS sessions regardless of padding.

2024-xue-fingerprinting §7 (Limitations and Future Work) detection

The GFW's fully-encrypted detector (deployed Nov 2021) operates by exempting likely-benign traffic and blocking the rest. Five inferred exemption rules applied to the first TCP payload (pkt): Ex1 — popcount(pkt)/len(pkt) ≤ 3.4 or ≥ 4.6 (bits/byte); Ex2 — first 6+ bytes are printable ASCII [0x20–0x7e]; Ex3 — more than 50% of bytes are printable ASCII; Ex4 — more than 20 contiguous printable ASCII bytes; Ex5 — first bytes match TLS or HTTP fingerprint. Traffic failing all five exemptions is blocked. Experiments confirmed all rules still held as of February 2023.

2023-wu-fully-encrypted-detect §4, Algorithm 1 detection

Starting October 3, 2022, more than 100 users reported simultaneous blocking of TLS-based circumvention servers running Trojan, Xray, V2Ray TLS+WebSocket, VLESS, and gRPC. Blocking was port-specific initially (mainly port 443, but also non-443 ports), then escalated to full IP blocking when users switched ports. Domain names were not added to DNS or SNI blocklists. naiveproxy was notably not affected. The blocking was dynamic in at least some cases (browsers could still reach the port, but circumvention tools could not), strongly indicating protocol-level identification rather than blind port blocking.

2022-blocking-tls-circumvention full post deployment

The October 2022 blocking wave is the confirmed operational deployment of the fully-encrypted-traffic detector later formalized in Wu et al. (USENIX Security 2023). The detector was therefore in live production from at least late 2022, more than a year before the academic paper describing it was published. This event establishes that the GFW's passive fully-encrypted classifier operates at scale in adversarial real-world conditions, not just in controlled experiments.

2022-blocking-tls-circumvention full post deployment

Iran's censorship infrastructure employs IP-list blocking of major media CDNs (Instagram, YouTube, Facebook) that remains effective against VLESS+TLS users on domestic VPS endpoints. Telegram's accessibility—because it is reachable directly by IP without domain resolution—confirms that the IP blocklist targets CDN address ranges specifically rather than applying blanket traffic inspection.

2022-oftenhamed-vless-tls-has Issue thread (abstract) detection

Community analysis of the Iran VLESS+TLS failure identified DNS poisoning as a primary root cause: domain-based resolution for services like Instagram, YouTube, and Facebook was disrupted even when traffic transited a VLESS+TLS tunnel from a domestic VPS, bypassing the transport-layer obfuscation entirely.

2022-oftenhamed-vless-tls-has Issue thread (abstract) detection

This primary-source community report documents that Iran's censorship is multi-layered: VLESS+TLS successfully evades transport-protocol detection but is defeated simultaneously by DNS poisoning and CDN IP-list blocking. A circumvention tool that addresses only one layer (transport obfuscation) is insufficient for consistent access in Iran.

2022-oftenhamed-vless-tls-has Issue thread (abstract) evaluation

Iran's censorship against VLESS+TLS users on domestic VPS infrastructure is selective by destination type: Telegram, which is accessed by IP, remained reachable, while Instagram, YouTube, and Facebook were blocked or partially inaccessible. This indicates blocking operates at the destination-IP/domain layer independently of the transport protocol.

2022-oftenhamed-vless-tls-has Issue thread (abstract) detection

Configuring client-side DNS settings within V2rayNG resolves the DNS poisoning component of Iran's multi-layer censorship when using VLESS+TLS from a domestic VPS. This workaround routes DNS queries through the tunnel rather than the local, poisoned resolver, restoring domain resolution for blocked services.

2022-oftenhamed-vless-tls-has Issue thread (abstract) defense

V2Ray clients emitted TLS ClientHello messages with a hardcoded, rarely-seen ciphersuite (fingerprint ID 8c48b95f67260663 on tlsfingerprint.io) that allowed a machine-learning classifier to identify V2Ray TLS traffic with 0.9999 accuracy; the same classifier could not accurately identify the traffic after the fingerprint was changed. The blocking rule based on the unique ciphersuite could be expressed in a single iptables line.

2020-v2ray-weaknesses §Unique TLS ClientHello Fingerprints detection