Please investigate the GFW source code leak and improve IPFS/Kubo to circumvent the blockade.
Geedge & MESA Leak: Analyzing the Great Firewall’s Largest Document Leak
The Great Firewall of China (GFW) experienced the largest leak of internal documents in its history on Thursday September 11, 2025. Over 500 GB of source code, work logs, and internal communication
Default bootstrap node addresses (since at least 2019, see kubo#5993)
GFW can detect and block IPFS traffic patterns in some cases
Some regions (e.g. Shanghai) report wholesale P2P blocking except for enterprise-whitelisted traffic
What still works (?):
My understanding of GWF may be outdated, but last time I looked into it:
Some VPNs
P2P connectivity itself largely functions. Academic research from 2023 found that “the GFW has little measurable impact on P2P functionality” and that NAT is actually the main impediment.
QUIC transport has an advantage over TCP. GFW detection is primarily TCP-focused, and P2P QUIC connections use IP addresses directly (no SNI/hostname to censor).
Many public community-hosted HTTP gateways remain accessible, including Tor Onion Services (volunteer-run, useful as last resort when running your own node is not possible or not safe).
Kubo releases can be fetched from any working gateway (incl. Tor ones) via DNSLink (resolved by gateway, so not impacted by DNS censorship in China): https://<gateway>/ipns/dist.ipfs.tech/kubo/
Workarounds:
Make sure you have QUIC transport enabled
Bootstrap nodes are only needed for initial peer discovery. Once connected, Kubo remembers peers.
You can discover peer addresses by other means, for example by querying a delegated routing endpoint(s) for providers of popular content (example) (e.g. over Tor).
Regarding the Geedge/MESA leak:
The leak is real and significant, but published analyses focus on VPN blocking and application-layer censorship - no mentions of IPFS/libp2p so far. The technical details about how GFW detects encrypted traffic were already documented in academic research from 2023, so the leak doesn’t appear to reveal new information relevant to IPFS. If this is not true, and you find specific references in the leaked documents, please share.
Thanks for replying! I can see that there is discussion of encrypted traffic pattern detection there, but is there something specific showing the ability to detect IPFS traffic, or is it just a general extension on the other results?
my read is that is a general extension: there is no published evidence of GFW specifically targeting IPFS/libp2p traffic. what is documented:
IP/DNS blocking of ipfs.io and default bootstrap node IPs (kubo#5993) – not protocol detection, and likely due to general abuse (phishing) of this public good gateway, not IPFS per se
encrypted traffic heuristics (USENIX Security 2023) target proxies (Shadowsocks, VMess, obfs4) that don’t look like TLS/HTTP/SSH. libp2p is not even a topic here because it uses standard TLS 1.3 or Noise, so regular TLS analysis tools work – no need to build anything IPFS-specific
empirical measurement (Balduf et al. 2023) found “the GFW has little measurable impact on P2P functionality” for IPFS – NAT is the bigger problem
Geedge/MESA leak covers VPN blocking and app-level censorship, no mentions of IPFS or libp2p
GFW blocks were so far targering IPFS public goods bootstrap/proxy/gateway infrastructure, not the protocol. spotting IPFS traffic via connection patterns, ALPN values (go-libp2p literally says libp2p there), or known peer IPs is doable with regular TLS tools, but there is no evidence of it happening today