A MESA Lab researcher maintains a small repo explicitly named "quic-block" (LiFulian/quic-block) containing a single C++ source file "quic_lfl.cpp", indicating standalone development work on QUIC/HTTP-3 blocking logic; the repo's minimal size (5 files) and "studyGit" commit suggest early-stage or personal research rather than a shipped product module, so this should be read as evidence of active R&D interest rather than a confirmed deployed capability.

A production feature spec ("加密协议JG") requires detection-and-control capability for QUIC, ESNI, and ECH, with a per-connection log field c_encrypt_type explicitly distinguishing ClientHello encryption (0=unencrypted, 1=ESNI, 2=ECH) and a DF_QUIC_REGION rule table matching QUIC by SNI. The system computes a per-rule "CT" (穿透/penetration) rate from paired mirror-vs-functional RST-packet logs (TF-RST-LOG / TF-MIRROR-RST-LOG) to grade each block rule's effectiveness, and runs continuous active-verification probes against its own rules, deliberately varying the probe 4-tuple each run "to ensure it doesn't hit the blacklist" so the verification traffic itself reaches the target.

A previously-undocumented sapp plugin named 'Stellar' (repo stellar/quic_decoder, packaged as stellar-on-sapp, depending on sapp-devel and OpenSSL) implements 'quic_deprotection' — QUIC packet-protection removal — as a component distinct from the older MESA_Platform/gquic plugin, sharing the same test corpus of GQUIC/IETF-QUIC pcaps (RFC9000, chlo-fragment, no-SNI cases). This is a candidate new product entry for the taxonomy: a second, apparently newer QUIC-inspection engine alongside gquic.

The "stellar" QUIC decoder plugin implements a complete RFC 9001 QUIC Initial-packet header- and payload-deprotection pipeline (HKDF key derivation from the well-known public IETF/gQUIC initial salts, AES-128-GCM payload decryption, AES-CTR header-protection removal) to decrypt QUIC ClientHello messages in real time, reassembling CRYPTO frames fragmented across multiple UDP datagrams, and extracts SNI and User-Agent from the decrypted handshake. It separately parses legacy Google QUIC (gQUIC) CHLO tag-value blobs (TAG_SNI / TAG_UAID) for older/non-IETF QUIC variants, and recognizes version ranges for a long list of QUIC implementations (mvfst, quant, quicly, msquic, mozquic, picoquic). A config flag (DECRYPTED_SWITCH) toggles whether the decrypt-and-inspect pass runs.

A TSG-Application blocklist test found that disabling Facebook/Twitter in TSG's per-app policy did not stop Psiphon3 traffic from reaching those services in practice, because Psiphon3's dual-stack fallback drove the tunneled Facebook traffic over IPv4 QUIC, which TSG's classifier failed to attribute to Facebook -- in contrast to Taobao/Bilibili/Youku/JD, which TSG blocked successfully in the same test.

An internal TSG functional-requirements spec ('加密协议JG') defines device support for identifying and blocking ECH, ESNI and QUIC traffic via per-connection SNI/region-matching tables (e.g. DF_QUIC_REGION), plus a companion 'FD报文全流程感知' feature that both passively monitors and actively injects synthetic verification traffic end-to-end through the network path to compute a live per-rule 'CT率' (breakthrough/penetration rate) — the system self-measures how often its own QUIC/ESNI/ECH blocks fail to take effect, and separately throttles logging/blocking detail for rule IDs receiving unusually high hit counts (DF_ATTACK_PROTECTION, 'targeted attack detection').

A MESA Lab monthly report describes a 'web-proxy' engineering task that modified the open-source Ultraviolet web-proxy project to add keyword- and specific-URL-blocking, alongside deployment work (certificate issuance, redirect handling) and a document listing which sites the proxy is permitted to relay; the purpose (internal filtered access vs. a broader capability) is not stated in this excerpt.