After deploying innocent IP mixing and collaborative spy detection, VPN Gate raised server reachability from China from a low of ~30% to 78.5% by June 19, 2013, sustaining 60–70% reachability through end of August. On August 29, 2013, VPN Gate served 9,000 daily unique IP addresses from China versus Tor's estimated 3,000.

Collaborative spy detection aggregates VPN connection logs (complete, incomplete, and tiny calls) across all volunteer nodes to a central log analyzer, which identifies censor probe IPs by looking for clusters of incomplete or tiny calls from the same /24 block, then distributes a Spy List back to every server so probing packets are silently dropped before the handshake completes. A single server cannot distinguish a spy from a regular client in time; the cross-server aggregate makes pre-response spy identification feasible.

§4.3 defense

After VPN Gate blocked the GFW's original probe IP (210.72.128.200, operated by China Science and Technology Network / CSTNET), the GFW authority immediately pivoted to Amazon EC2 and commercial hosting (Gorilla Servers) to enumerate relay lists, using a Python-urllib user agent at fixed polling intervals. Following this adaptation, approximately 80% of all VPN Gate servers became unreachable from China.

§6.3, Figure 13 detection

The GFW authority discovered VPN Gate and deployed an automated IP-blocking tool within four days of launch: the List Server was blocked on March 11, 2013 (day 3), and automated scanning of the full server list began by March 12 (day 4). This automated tool polled and blocked all listed IP addresses several times per day.

§6.3 detection

Innocent IP mixing — inserting IP addresses of critical Internet infrastructure (DNS roots, Windows Update servers, popular mail servers) into the relay list distributed to users — forces the censor to manually verify each address before blocking. In March 2013, the GFW blocked every IP VPN Gate mixed in within 30 minutes, demonstrating it was trusting the list without verification; after the technique was noticed (March 20), the GFW switched to verifying IPs first, substantially slowing its blocking cadence.

§4.2, §6.3 defense

CensorLess's function refresher automatically retires serverless bridges and deploys fresh ones in batches across diverse regions; the expected time until a bridge is identified and blocked in practice is 2 days (per Fifield et al.), while Tor bridges in China are discovered within 2–36 days. The old bridge is only removed after all clients have completed live migration to a new URL, maintaining uninterrupted connectivity.

2026-kang-censorless-serverless §4.5 active-probingip-blocking

CensorLess's threat model explicitly relies on a rational-censor assumption: the censor will not block entire cloud-provider IP ranges or domain namespaces because the collateral damage to legitimate business services would be politically and economically unacceptable. AWS Lambda's inherent IP-address ephemerality (new IPs on each invocation, function lifetime up to 15 minutes) means even censors willing to attempt enumeration face a continuously shifting target distributed across the cloud provider's global address space.

2026-kang-censorless-serverless §4.2 ip-blockingasn-blackholingactive-probing

Address blocking is a losing strategy for the censor: with n=8 endpoints and µ/λa = 1 (discovery as fast as rotation), address-denial probability falls below 10^-2, and even when the censor discovers twice as fast as the defender rotates (µ/λa = 0.5), 7 endpoints keep address denial below 10^-2 (Lemma 1, Figure 1). The collateral budget γ means the censor cannot even block all addresses it discovers, and Corollary 1 gives the explicit threshold: n ≥ ln(1/ε) / ln((λa+µ)/λa) endpoints suffice for any target ε.

2026-maiti-block-a-mole-sustainability-frontier §5, §8.1, §8.10, Lemma 1, Corollary 1, Figure 1 ip-blockingactive-probing

Community members propose a two-hop architecture as a potential mitigation for Iran's current DPI upgrade: a first-hop server inside Iran's whitelisted datacenter ranges (where outbound traffic faces lighter inspection) proxying to a foreign exit node, with Reality masquerading as a legitimate Iranian organization's domain. The architecture's effectiveness under active TCP reassembly and handshake probing is explicitly unverified.

2026-pooribitwise-iran-advanced-dpi Issue body — Description active-probingip-blocking

A community scan of the I2P network database (netDb) in July 2026 identified a cluster of suspicious router nodes uniformly running I2P version 0.9.66 (three versions behind the current 0.9.69), all hosted in Chinese domestic data centers rather than residential broadband. The nodes exhibit anomalous uniformity in their router capabilities (Caps) configuration and self-reported versions, a pattern inconsistent with organic user deployments.

2026-thewizard0fbsod-quirky-chinese-i2p Issue body active-probingip-blocking

The suspicious Chinese I2P nodes rotate their IP addresses regularly and simultaneously as a coordinated group, and some of the observed IPs have prior history of malicious behavior (SSH brute-forcing, remote exploitation) in threat-intelligence databases. Simultaneous coordinated IP rotation distinguishes state-run infrastructure from organic users and is a fingerprint of centrally managed probe fleets.

2026-thewizard0fbsod-quirky-chinese-i2p Issue body active-probingip-blocking