vless   VLESS (V2Ray)

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

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

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

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

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

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