Appending the /ncr (no-country-redirect) parameter to google.com requests successfully bypasses the forced redirect to google.cn/m for Chinese users on circumvention proxies. This workaround operates at the application layer and requires no changes to the underlying transport or proxy configuration.

The redirect from google.com to google.cn/m on proxied Android connections in China is ambiguous as to origin: it may represent GFW-side in-path HTTP redirect packet injection, or Google's server-side geo-redirect responding to signals (device locale, exit IP, or Accept-Language headers) that survive the proxy hop. The thread documents this as an unresolved mechanistic question requiring disambiguation.

Issue body / abstract detection

Chinese users accessing google.com on Android devices through circumvention proxies experience forced HTTP redirects to google.cn/m rather than the expected google.com destination. The behavior is observed specifically on proxied connections, suggesting either in-path HTTP redirect injection by the GFW or Google's own geo-targeting logic acting on IP or device signals that persist through the proxy.

Issue body / screenshot detection

Android users in China accessing google.com through circumvention tools report forced redirection to google.cn/m instead of the expected GFW block page. The thread investigates three possible mechanisms: GFW HTTP packet injection, Google's server-side geolocation redirect, or ISP-level interference—each implying a different interception layer.

Issue body / thread opening detection

The redirect behavior varies depending on which proxy type is used, indicating the interception is sensitive to how the proxy mediates the connection rather than being a blanket IP- or DNS-level block. This suggests the triggering condition is protocol- or flow-specific rather than purely destination-based.

Issue thread discussion evaluation

HTTP censorship blockpages in Iran fell into two distinct clusters distinguished by IP TTL values: type NTL1 (TTL 53–55) and type NTE1 (TTL 186–188); TCP RST injections targeting TLS and DNS-over-TCP exhibited the same two TTL ranges. The NTL1 injector was absent on June 11 but present on other days, leading the authors to conclude that an entire injector went offline rather than that a single injection pattern was selectively disabled.

2026-anon-insights-into-iranian §2.2.5 rst-injectionpacket-injectiondpi

An internet-wide scan of 500k IP addresses from an in-country VPS vantage point found TCP establishment-interception injections on 43,479 addresses (8.7% of scanned), with over 70% concentrated in two Akamai ASes (AS16625 and AS20940). The injection pattern — triggered by the first packet sent to these addresses — is consistent with targeted blocking of domain-fronting proxies hosted on Akamai CDN.

2025-alaraj-iran-refraction §4.1.2 packet-injectionrst-injectionip-blocking

Iran's censorship of refraction-networking proxies (Conjure via Psiphon) is not monolithic: different ISPs independently deploy different techniques and timelines. Over 800 million logged Conjure connections from July 2023–February 2025 across 10+ Iranian ASes show TCI (AS58224, ~33% of traffic) uses packet injection, while MCCI/Hamrah-e Avval (AS197207, ~22%) applies IP-based blocking, and some ASes (Parsonline AS16322, Shatel AS31549) show no proxy blocking at all.

2025-alaraj-iran-refraction §4 rst-injectionip-blockingpacket-injectiondpi

Wallbleed was a buffer over-read in the GFW's DNS injection subsystem that caused middleboxes to append up to 125 bytes of their own process memory to forged DNS responses. The bug persisted for at least two years (confirmed from October 2021); the GFW issued an incorrect partial patch in November 2023 (Wallbleed v2 remained exploitable) and fully patched it in March 2024. Over 5.1 billion Wallbleed responses were collected during continuous measurement, and an IPv4-wide scan found 242 million IP addresses across 381 autonomous systems receiving Wallbleed-injected responses — including some traffic whose source and destination were both outside China, due to routing through China's network border.

2025-fan-wallbleed §1–§3, §7 dns-poisoningpacket-injection

Iran's DNS censor now injects two distinct block-page IPs: 10.10.34.36 (≈87% of 47,633 censored domains) and 10.10.34.34 (≈13%). Both originate from the same network node at Iran's border. Prior research (Aryan et al. 2013) described only 10.10.34.34. The IP injected correlates strongly with the HTTP censorship method applied: domains with 10.10.34.34 in DNS receive TCP RST via HTTP (86.8% of RST cases), while domains with 10.10.34.36 in DNS receive HTTP block pages (84.6% of block-page cases).

2025-lange-i-ra-nconsistencies §3.1, Table 2 dns-poisoningrst-injectionpacket-injection

Over 2.5 months (Nov 2024–Jan 15, 2025), IRBlock scanned all 11M Iranian IPv4 addresses daily, finding 6.8M IPs subject to DNS poisoning and HTTP blockpage injection, and 5.4M IPs subject to UDP-based traffic disruption. Testing over 700M FQDNs (500M apex domains) revealed 6M banned FQDNs from 3.3M censored apex domains. Of 537 active ASes in Iran, 485 (90.3%) exhibited blocking for at least 25% of assigned IPs. DNS and HTTP censorship overlapped at >99% of censored IPs; UDP blocking was a strict subset of DNS-censored IPs, affecting ~5M addresses.

2025-tai-irblock §5.1, §1 dns-poisoningpacket-injectionhttp3-quic-block