Geedge fingerprinted several V2Ray-based VPN apps by their fixed API/bootstrap domains rather than protocol characteristics — blocking "V2 Pro" via pro.mucacherry.org, "V2 VPN" via v2.mucacherry.org, and "V2Net VPN" via api.v2net.live plus 5 rotating free-node domains (free1-5.v2n3t2.online / v2n3t.online) the app uses to fetch node lists.
219：V2 Pro - v2ray VPN-抓包发现VPN打开软件和点击连接，都会与$pro.mucacherry.org域名通信，使用此域名作为特征，即可实现阻断... 221：V2Net vpn...当前使用...这6个域名即可阻断VPN
Defense implications
- V2Ray-family clients hardcoding a small, static set of bootstrap domains for node discovery are trivially blockable; node-list distribution should avoid fixed domains or run over a resistant channel.
Related findings
A 2020 MESA Lab monthly report describes building an encrypted-DNS gateway device and a self-hosted DoH server that was wired directly into a live "TSG platform WAN net interface", alongside a passive DoH-service-discovery pipeline that found 39 new DoH-serving domains in a single day of backbone ("科技网") traffic; a related note documents actively probing known DoH-serving IPs' upstream resolvers via a proxy network across 196 countries to check which still function.
Geedge's TSG self-check test suite (run against firewall version v23.07.18-591aed7) enumerates the product's full interference capability set: SSL bypass/intercept (including handling of expired, self-signed, and untrusted-root certificates), HTTP/SSL proxy actions (redirect, block, replace, hijack, insert), three distinct firewall deny modes (silent drop, TCP RST, blockpage), and DNS deny modes (silent drop, A-record redirect, AAAA-record redirect, including TTL-range variants).
A confirmed bypass — TSG failed to extract SNI from TLS ClientHello when the SNI extension appeared later than expected in the extension list, letting those flows through unblocked (and incidentally TLS 1.3 flows generally, since clients fell back to 1.3 after 1.2 was blocked); fixed on-site via a patch to the "ssl.so" detection plugin.
A Deny policy using an SNI "Negate" condition fails to block after a page is refreshed multiple times, a duplicate of a prior known bug (TSG-18234) — indicating a reliability gap for negated-SNI-condition policies under repeated/retried connections.
A crash/perf bug report reveals Geedge's MAAT rule engine (libmaatframe.so, using Intel Hyperscan for literal/regex matching) running with 545,441 FQDN blocking rules and 404,141 IP address blocking rules loaded in a single instance as of 2024; loading 500,000 new FQDN rules via the full Hyperscan path took ~95 minutes, addressed by an automatic fallback to a second engine ("Rulescan") above 50,000 rules.
Root-caused an Ethiopia SNI-block-failure incident to the detection mechanism itself: APP_SKETCH's FQDN-scanning module -- which exists specifically to identify Psiphon3 and Freegate via top-N SNI matching -- was CPU-expensive enough to saturate cores, triggering sapp's fail-open DDoS bypass and letting some target connections through uninspected. A signature-structure fix roughly doubled throughput (33K/s to 73K/s new connections) and disabling the fail-open bypass restored reliable blocking.