Actually I tested it several (2-3?) years ago a bit, in a VM. I remember running blockcheck on it, maybe goodbyedpi too.
The software didn’t have functionality to detect unknown traffic at that time.
I believe they’ve added it when Telegram started to use MTProto proxies, because the wiki says:
“Euristic DPI” option
With this option you can improve filtering quality of complex protocols, like the encrypted messengers’ traffic.
With the aid of proactive analysis, Carbon Reductor DPI X is able to block only what’s needed, which would improve your customers’ Internet quality, decreasing the number of blocks due to indecent resources.
We’re discussing the details of this option with Roscomnadzor right now.
Roscomnadzor was blocking my unencrypted HTTP proxy servers since November to the end of July, once in every 4-14 days. They’ve silently added IP addresses of the proxy servers to the registry, insisted that my IP addresses are used in Telegram infrastructure and refused to provide any details or proofs. I was running an experiment to understand what’s going on, how do they detect proxy servers and what triggers the detection.
At that time, I had two hypotheses: either they get dump of all IP addresses and ports the customers visit (netflow), and then recheck every IP-port combination as HTTP proxy without authentication, or they get some kind of exported data from DPI manufacturer or from DPI itself (Telegram, if used with HTTP proxy, has a very distinct fingerprint: it just uses HTTP Post request with the pattern of POST http://1.2.3.4:80/api, at least the desktop version at that time).
I tend to believe the latter during my experiment, and now I’m sure it was either Carbon Reductor or EcoDPI (Roscomnadzor’s “recommended DPI system”) data.