shadowsocks   Shadowsocks family

Chinese users treat full proxy/VPN (Shadowsocks, V2Ray/Clash, commercial VPNs) as the '终极大杀器' (ultimate solution) for bypassing GitHub DNS poisoning, implying that lighter-weight DNS-only fixes fail in some network environments where the censor adds firewall-layer blocking beyond DNS.

2026-anon-6-github-dns §3 使用代理或 VPN deployment

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

Rule-based proxy tools (Clash, Shadowsocks, V2Ray) are documented as the most reliable solution for accessing GitHub from China, with split-tunneling rules routing only GitHub traffic through the proxy while keeping domestic traffic on the direct path. Git command-line tools require explicit proxy configuration (git config --global http.proxy http://127.0.0.1:7890) to route clone/push operations, as they do not inherit system proxy settings automatically.

2026-anon-github-2026-6-dns §方法二 defense

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

Under April 2026 enforcement pressure, surviving VPN resellers converged on three strategies: raising prices to cover higher infrastructure costs, switching from transit to direct-connect (higher latency, worse peak-hour performance), or deploying proprietary protocols with dedicated clients — the last option breaking compatibility with standard Clash and Shadowrocket clients and fragmenting the interoperable ecosystem.

2026-ermao-april-airport-outage §5月以后机场可能怎么-活下去 deployment

I2P payload entropy was measured at close to 8 bits per byte across sampled packets (Figure 9), confirming that payload content is cryptographically indistinguishable from random noise and provides no usable signal for classification. All experimental variants using raw payload alone achieved poor and high-variance accuracy (72.5–76.5%), while excluding payload improved accuracy to 99.5% in lab conditions.

2026-rohrer-convolutional-neural-networks-deanonymisation-i2p §IV-A / §V Discussions detection

Six widely deployed VPN and circumvention tools—OpenVPN, WireGuard/NordLynx, NordWhisper, Orbot (Tor on Android), Lantern, and Psiphon—all failed to block internal IP inference, connection-state detection, and TCP reset injection under identical adversarial conditions on fully patched Android 16. Application-layer obfuscation in Lantern and Psiphon did not prevent TCP-layer disruption; Orbot's VPN-style encapsulation of Tor traffic was bypassed via the same tunnel-level side channels.

2026-tolley-architectural §5.2, §5.4–5.5 evaluation

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

Three families of VPN apps with combined Google Play download counts exceeding 700 million share not only common ownership but hardcoded cryptographic credentials, including Shadowsocks passwords embedded in their APKs. An attacker who extracts these hardcoded passwords can passively decrypt all traffic of users of these apps. Business filing and APK analysis linked the families to the same operators; one previously-identified family (Innovative Connecting / Autumn Breeze / Lemon Clove) had already been linked to the People's Liberation Army.

2025-mixon-baca-hidden Abstract, §4, §5 detection

Shaperd introduces a constraint-agnostic traffic shaping system that operates on both packet content and timing in real time, designed for drop-in integration with any existing FEP. The system uses a four-component constraint definition (function, value, comparison operator, target packets) capable of expressing any rule based on a computable deterministic function over packet contents.

2025-wilson-extended §2 defense

Internal Geedge documentation lists nine commercial VPNs as 'resolved,' providing staff with documented methods for identifying and filtering each protocol's traffic. The leak shows employees reverse-engineering popular circumvention tools to develop blocking signatures, consistent with GFW practices that have rendered most commercial VPNs inaccessible inside China.

2025-wkrp-leak-geedge-networks body 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

The paper evaluates two short-term mitigations—TCP delayed ACK on the proxy server and connection multiplexing—but finds both are limited: delayed ACK produces atypical ACK timing that may itself be fingerprintable, and multiplexing only adds entropy without eliminating the RTTdiff signal. Critically, obfs4 and ScrambleSuit's delay-based timing obfuscation are described as 'fundamentally limited' because they manipulate inter-arrival times without eliminating the underlying transport/application-layer session misalignment. The paper concludes no existing obfuscation scheme provides a principled defense against timing-based proxy fingerprinting.

2025-xue-discriminative §VII, §I defense

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

Achieving active security (FEP-CCFA) requires that on any AEAD decryption failure a fully encrypted protocol silently return the empty string and keep the channel open indefinitely, never emitting a channel-closure signal. Any observable behavioral difference — including connection termination timing — leaks information about ciphertext-boundary locations to an active adversary.

2023-fenske-security §2.3 defense

Shadowsocks transmits a fixed-size AEAD-encrypted length field followed by the AEAD-encrypted payload with no support for reducing ciphertext size via fragmentation, while Obfs4 permits input-side padding but not output fragmentation. These designs impose distinct minimum output message lengths, allowing a passive adversary to distinguish between them — and identify short-message sessions — based solely on the minimum observed message length.

2023-fenske-security §2.4 detection

No existing fully encrypted protocol — including Obfs4, Shadowsocks, VMess, and Obfuscated OpenSSH — simultaneously satisfies passive indistinguishability (FEP-CPFA), active-manipulation resistance (FEP-CCFA), and output-length shaping. The paper presents a novel stream-based construction that provably satisfies all three using AEAD-authenticated length blocks, an output buffer supporting arbitrary fragmentation, and a padding mechanism allowing the sender to emit exactly p output bytes on demand.

2023-fenske-security §2–3 defense

Shadowsocks 'stream cipher' methods lacked integrity protection on ciphertexts, enabling a decryption oracle: an attacker who can guess as few as 4 bytes of plaintext prefix (5 bytes without controlling a /24) can replay a recorded session with a modified 7-byte target header, causing the server to send the decryption of the entire recorded stream to an attacker-controlled host. This provides an efficient active test for identifying Shadowsocks servers; once identified, a censor can block by IP address.

2023-fifield-comments §2 detection

The GFW detects Shadowsocks by flagging apparently high-entropy connections that are not TLS or HTTP, but this detection is brittle: connections are explicitly allowed if the first 6 bytes of the first packet of a flow are all printable ASCII characters (range 0x20–0x7E). Adding a 6-byte alphanumeric preamble to the Shadowsocks message definition is sufficient to bypass this heuristic and requires only a short patch to the protocol specification file.

2023-wails-proteus §3.2 detection

A complete Noise NK handshake protocol — including Curve25519 ECDH key exchange with server authentication, HMAC-based key chaining, and ChaCha20-Poly1305 AEAD-encrypted data phase — was expressible in Proteus in less than 4 hours, demonstrating that a safety-bounded DSL with built-in crypto primitives and declarative message-format definitions is sufficient to prototype complex cryptographic transport protocols rapidly.

2023-wails-proteus §3.3 evaluation

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

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

OpenVPN's application-layer P_ACK packets — uniform in size and concentrated only in the handshake phase — provide a timing and count fingerprint detectable via threshold comparison over 10-packet bins. Tunnel-based obfuscation wrappers (Stunnel, SSH, obfs2/3, Shadowsocks) that do not add random padding preserve the 1:1 packet correspondence with the underlying OpenVPN stream, leaving 16 of 20 tested tunnel-based obfuscated configurations vulnerable to ACK fingerprinting.

2022-xue-openvpn §6.2, §9.1 detection

The GFW's passive classifier uses two features of the first data packet to flag probable Shadowsocks traffic: (1) high Shannon entropy (per-byte entropy > ~7 bits strongly correlates with replay probability, which is nearly 4x higher at entropy 7.2 than at 3.0) and (2) packet length in the range 160–700 bytes with specific remainders mod 16. A single data packet after the TCP handshake is sufficient to trigger the downstream active-probing pipeline.

2020-alice-shadowsocks-detection §4.2 detection

Once passive analysis flags a connection, the GFW sends seven distinct active probe types in staged sequence: five replay-based (R1–R5, where R1 is an identical replay and R2–R5 alter specific byte offsets to attack stream vs. AEAD cipher variants) and two non-replay random-length probes (NR1, NR2). The system operates in stages: R3/R4/R5 probes are withheld until the server responds to R1/R2, meaning a server with replay protection (like Shadowsocks-libev ≥ v3.3.1) never receives stage-2 probes, while one without (original OutlineVPN) escalates to full probing.

2020-alice-shadowsocks-detection §3.2, §4.2, §5.3 detection

The protocol filter's HTTPS fingerprint requires only that the first 5 bytes match a TLS header (type 0x16, version 0x03 0x01–0x03, correct length field); all subsequent bytes of the Client Hello are unchecked. Any TLS-based circumvention tool naturally satisfies this fingerprint and will bypass the filter by default. Furthermore, any one of the three permitted fingerprints (DNS, HTTP, HTTPS) can be used on any of the three monitored ports to whitelist an entire flow.

2020-bock-detecting §4.3 defense

Manually-crafted decision trees combining probe non-response, FIN/RST close type, and connection timing achieved a false-positive rate below 0.001% for obfs4, Lampshade, Shadowsocks, and OSSH across 1.9 million endpoints; for OSSH specifically, 7 of 8 flagged Tap endpoints were confirmed genuine Psiphon proxies by developers. MTProto was the sole exception, producing 3,144 false positives (0.56% of Tap, 0.02% of ZMap) because its infinite-timeout behavior is shared by a non-negligible population of common hosts.

2020-frolov-detecting §V-A, Table IV evaluation

Endpoints that never close a connection and never respond to any probe ('infinite timeout') represent 0.7% of the ISP Tap dataset and 42% of the ZMap active-scan dataset; this is the single most common probe-indifferent behavior in both datasets. MTProto already exploits this: its strategy of keeping failed connections open indefinitely produces the highest false-positive rate (0.56% of Tap) among all tested protocols, making it effectively uncountable at acceptable collateral-damage thresholds.

2020-frolov-detecting §VI, Fig. 13 defense

Across 433,286 endpoints from a 10 Gbps university ISP passive tap, 94% responded with data to at least one of 8 protocol probes (TLS, HTTP, STUN, S7, Modbus, DNS-AXFR, random bytes, empty); all five tested probe-resistant proxies (obfs4, Lampshade, Shadowsocks, MTProto, OSSH) never responded with data to any probe. This single filter reduces the suspect set from 433,286 to ~26,000 endpoints and rules out 94% of ISP-observed hosts as non-proxies with zero false negatives against the tested protocols.

2020-frolov-detecting §V, Table III detection

Each probe-resistant proxy exposes a unique TCP close-threshold fingerprint: obfs4 closes with FIN at 8,192–16,384 bytes and RST at the next multiple of 1,448 bytes beyond that; Lampshade at FIN 256 bytes / RST 257 bytes; Shadowsocks-python and -outline both at FIN 50 bytes (outline also RST at 51); OSSH at FIN 24 bytes / RST 25 bytes. A binary-search tool using random probes can discover these thresholds remotely without knowing any shared secret, providing a protocol-specific fingerprint independent of payload content.

2020-frolov-detecting §IV-C, Table II detection

The GFW was observed detecting Shadowsocks servers by sending follow-up active probes after an initial Shadowsocks-sized client message, including permuted replays of the client's message and random-data probes of various sizes up to and exceeding Shadowsocks' unique 50-byte data limit. This defeats shadowsocks-libev's replay cache because the GFW permutes the replayed bytes rather than resending them verbatim.

2020-frolov-httpt §2 Background detection

Frolov et al. (2020) found that over 94% of Internet servers respond with data to at least one popular protocol probe, making probe-resistant proxies that remain entirely silent statistically anomalous. Censors can further fingerprint silent proxies by their unique timeout or data-limit behaviors before connection close (e.g., Lampshade closes immediately after 256 bytes of unrecognized data, or waits exactly 90 seconds before timing out).

2020-frolov-httpt §2 Background detection

Anonymization and circumvention tools (VPNs, Tor, etc.) are among the three most commonly blocked content categories across all commercial filters surveyed, alongside pornography and gambling. This holds across diverse products including Fortinet, Cisco, and government-deployed firewalls in Iran, Saudi Arabia, and Bahrain.

2020-raman-measuring §V-A-1, Fig. 7 evaluation

Frolov et al. (2020) found that obfs4, Shadowsocks Outline, Psiphon's OSSH, and Lantern's Lampshade are all identifiable by TCP flag and timing patterns when servers close connections on error, because each tool's timeout value and FIN/ACK behavior are distinct. Their recommended mitigation—'forever read' on errors so the prober always closes first—forces the server to terminate with FIN/ACK consistently across all code paths.

2020-v2ray-weaknesses §Our comments defense

Frolov and Wustrow show that every major TLS-based circumvention tool (Tor Browser, Lantern, OpenVPN, Psiphon, etc.) produces a TLS ClientHello fingerprint that is statistically distinguishable from real Chrome or Firefox: differences include cipher-suite ordering, extension set, extension ordering, ALPN values, and curve preferences. A passive observer with a classifier over ClientHello fields can identify the tool with high precision without decrypting any traffic.

2015-frolov-the-use-of-tls §3–4 detection

The classifier uses a 3,000-dimension binary vector recording which upstream and downstream packet sizes appear across the full session, combined with aggregate biflow statistics (total packets, burst length, transmission time, incoming/outgoing fractions). This packet-size histogram is the highest-dimensionality feature in the set.

2017-deng-random §IV.B, Table 1 detection

The authors trained on 1 GB of captured Shadowsocks traffic and 1 GB of non-Shadowsocks traffic from a single host, then tested on over 1 GB of each from 26 randomly selected hosts. The cross-host generalization of the model is demonstrated but no explicit false-positive or false-negative rates are reported.

2017-deng-random §V.B–C evaluation

A Random Forest classifier with 100 CART trees and a sqrt(C) feature-selection strategy achieves over 85% accuracy detecting Shadowsocks traffic from biflow statistics. Accuracy increases monotonically with train-set and test-set size before plateauing.

2017-deng-random §V, Abstract detection

Shadowsocks traffic appears as ordinary TCP with no payload keywords or obvious protocol markers because the entire payload is encrypted; firewalls cannot distinguish it from generic TLS without behavioral flow analysis. This makes signature- and keyword-based detection ineffective against it.

2017-deng-random §III.A detection

The paper identifies that Shadowsocks can also serve as a transport layer for Tor and VPN connections, meaning a Shadowsocks flow detector functions as a first-stage classifier that unmasks compounded anonymity systems. The authors explicitly cite this as a motivation for detection.

2017-deng-random §II detection

Measured packet loss rates under GFW censorship (Feb–Apr 2017, client at Tsinghua University/CERNET): Tor with meek obfuscation suffers 4.4% average PLR; Shadowsocks (AES-256-CFB) suffers 0.77% PLR; native VPN (PPTP/L2TP) and OpenVPN both achieve ~0.21% PLR. For comparison, the same tools accessed from a US vantage point show PLR below 0.1%, confirming the excess loss is GFW-induced. The GFW's DPI and active probing techniques specifically target Tor and Shadowsocks protocol signatures.

2017-lu-accessing §4.3 evaluation

Shadowsocks imposes an extra per-session TCP connection for user/password authentication plus a 10-second keep-alive timeout, causing an average page load time of 3.7 seconds and a sharp PLT inflection when concurrent clients exceed 60. In contrast, ScholarCloud (split-proxy, no per-session auth handshake) achieves 1.3 seconds average PLT with linear scalability up to 180 concurrent clients. Native VPN and OpenVPN also scale linearly; Shadowsocks is the only tested solution with a non-linear degradation point.

2017-lu-accessing §4.3 evaluation

The GFW sends protocol-specific probe payloads tailored to each circumvention tool: Tor bridges receive a TLS ClientHello mimicking Tor's own; obfs2/obfs3 servers receive random-looking payloads; Shadowsocks servers receive random bytes. A server that responds differently to these crafted probes versus innocent traffic (e.g., by sending a valid protocol handshake in response to a probe) reveals itself and is subsequently blocked.

2015-ensafi-active-probing §5 detection