LetsVPN permanently exited the Chinese mainland market in late April 2026 after its technical team spent 20 days making hourly adjustments and confirmed it could not restore connectivity. The official announcement designated April 8, 2026 as the effective service-termination date and initiated a full refund program.

LetsVPN's exit is described as part of a broader pattern: a wave of 'airport' (proxy subscription service) outages across multiple providers in April 2026, documented in a companion article titled '2026年四月份各大机场断线详解,' indicating coordinated or systematic GFW blocking affecting the circumvention ecosystem broadly during this period.

§协议写死，特征太明显 (reference to companion article) deployment

Two documented enforcement actions against VPN users were reported in April 2026 in China: one user was summoned, given a warning, and fined 300 RMB for using LetsVPN to access foreign platforms; a second user in Dalian was fined 500 RMB on April 2, 2026 for using 快喵VPN to log into Telegram.

§流量形同裸奔，查水表隐患大 policy

The blog author, drawing on evaluation experience, concludes that LetsVPN's failure was not caused by IP exhaustion or ordinary node instability but by precise protocol-signature identification: once the GFW extracts a client handshake feature, it can simultaneously block all connections sharing that signature across hundreds of thousands of users.

§公告里的几句大实话 detection

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.

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

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 fully-encrypted-detectdpitls-fingerprintport-blocking

Stage 1 of the detection pipeline uses a lightweight heuristic: restrict analysis to IP addresses in "VPS-dense ASNs," which censors already target for resource-intensive inspection of fully-encrypted traffic. This pre-filter dramatically reduces the search space before applying the more expensive dual-role behavioral analysis. The evaluation was conducted without Stages 1 and 3 due to dataset limitations, meaning the reported 23% recall and 0.18% FPR are conservative lower bounds on the full pipeline's performance.

2026-almutairi-server §2.1, §2.2, §3.4 fully-encrypted-detectdpiml-classifier

AnyTLS is a TLS-based proxy protocol maintained by the sing-box team, designed in 2024 and first released in the sing-box dev-next branch. Its core mechanism wraps arbitrary proxy traffic in standard TLS and applies a configurable padding scheme (Padding Scheme) to enhance traffic concealment while maintaining compatibility with standard TLS infrastructure.

2026-anon-anytls-anytls-sing-box-2026 §1.1–1.3 tls-fingerprinttraffic-shapedpi

Explicitly disentangling packet headers (structured, low-entropy) from encrypted payloads (high-entropy, stochastic) into separate MoE branches yields consistent gains across six datasets: 86.85% F1 on 120-class TLS 1.3 traffic (CSTNET-TLS), 97.88% F1 on USTC-TFC2016 malware/benign flows, and 92.65% F1 on imbalanced IoT traffic (CIC-IoT2022), demonstrating that headers and payloads carry fundamentally different and independently exploitable discriminative signals.

2026-he-trafficmoe-heterogeneity-aware-mixture §III-A, §IV-B, Tables II–III ml-classifierdpifully-encrypted-detect

Obscura's browser-to-browser (B-B) WebRTC connections produce DTLS ClientHello and ServerHello messages indistinguishable from genuine browser traffic: across 100 captured handshakes compared against Facebook Messenger, Google Meet, Discord, and a reference WebRTC app using the dfind tool, no unique identifiers were found in C-C connections, and the sole Firefox-specific fingerprint (ServerHello length 86 bytes, cipher TLS_AES_128_GCM_SHA256, extension field length 46 bytes) matches the default Firefox WebRTC profile — meaning blocking it would also block all legitimate Firefox WebRTC users.

2026-vilalonga-obscura-enabling-ephemeral §5.2 tls-fingerprintdpi

Authoritarian regimes blocked Snowflake primarily through DPI targeting fingerprints in Pion's DTLS handshake and TLS fingerprints in complementary WebRTC protocols, not through ML-based traffic analysis — confirming that cost-effective censors consistently favor simple, deterministic methods over computationally expensive classifiers.

2026-vilalonga-obscura-enabling-ephemeral §1 dpitls-fingerprintactive-probing