Engineers built and deployed IP-list and SNI-wildcard signatures to block Cloudflare WARP (the 1.1.1.1 app), including wildcard SNI blocking of *.cloudflare.com. A CTO-level engineer (name redacted) personally flagged the SNI-based rule as likely to cause false positives against unrelated Cloudflare-fronted traffic, given Cloudflare's role as a major CDN.

TSG/CM ships with pre-built, first-class 'Learning Object' entries specifically for Freegate (Object ID 18) and Psiphon3 (Object ID 19), plus a generic 'Top Server IP' object (ID 20) -- default product features, not customer-commissioned custom signatures. The Psiphon3 object auto-learns and dynamically updates a live blocklist that reached roughly 70,000 IPs at one deployment before a database issue temporarily dropped it to ~50,000.

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.

TSG maintains a traffic-volume-ranked "Top SNI" / "Top Server IP" allowlist (Galaxy component, learned from live traffic, capped at top ~2000 SNIs / ~40000 server IPs per Nacos config) that is checked before a VPN/circumvention-tool deny policy (including a Psiphon3-specific policy) is enforced. Confirmed empirically: Psiphon3 client traffic whose destination SNI was in the Top SNI list passed through undenied, while traffic to the same client IPs with an SNI not yet in the list was blocked. A 2022-06 incident over-blocked TikTok/BBC/CNN/NYTimes because their SNIs were not yet in the learned allowlist at the time.

Multi-week TSG engineering investigation of iTOP VPN (requested by an Ethiopia deployment, cross-tested in a Myanmar environment) found blocking only takes effect for VPN sessions established AFTER a detection policy is pushed; a VPN already connected before the policy loads is never blocked or logged, regardless of signature type (SNI or server-IP).