Bandwidth limitation in the censorship systems

Question

Recently, Iran’s government has launched a sort of new censorship system that manipulates bandwidth as I will describe below.

• When a user connects to a VPN server and does an Ookla speed test, the download speed is good, but the upload speed drops dramatically after a few seconds. But meanwhile, the VPN still keeps connected, and if the user starts another speed test right after the previous one (with the same VPN session), again the same thing would happen (upload speed is good at first but drops suddenly after a few seconds).

• But when no VPN is on, the upload speed is good.

My question is what is the (of course, possible) mechanism behind this method? How do they detect that this stage is the “initial stage” of the uploading, since both kinds of connections (with and without VPN) are encrypted, and they reduce the bandwidth after that only for the second type of connection? And are there any methods to bypass it, I mean how can I do something so the system intercepts that my connection is always in its “initial state”?

Edit: I tested with a VPN with a domain behind a Cloudflare IP, so IP limitation could not be the case. Also, I've read this question, which did not help me. I have to add that I use v2ray VPN protocol that looks like a normal HTTPS, (or sometimes SSH) connection.

A note about the answer: The answer provided by Steffen Ullrich was helpful. Also, I noticed that the behavior I described only was happening to certain Cloudflare IPs, so by manually changing the domain IP to another Cloudflare IP that was not designated to Iran using this project + using websocket tunnel instead of v2ray, partly the problem of upload speed solved (though it may be a temporary solution) It seems that the censoring system manipulates the DNS requests in a way that the best IP for the domain behind a cloud is not returned.

Answer 1

How do they detect that this stage is the “initial stage” of the uploading, since both kinds of connections (with and without VPN) are encrypted, and they reduce the bandwidth after that only for the second type of connection?

There is no need to specifically "detect" the "initial stage" of uploading for causing the behavior you see. A simply bandwidth shaping which allows fur bursts is sufficient, i.e. something like leaky bucket.

As for behaving differently between v2ray and direct connection: There are established DPI techniques to analyze encrypted connections which include information about TLS fingerprint, traffic pattern etc. These are also used in commercial products as part of heuristics to distinguish between normal browsers and unwanted HTTP clients (malware, bots ...). See Summary on Recently Discovered V2Ray Weaknesses from 2020. While some issues reported there might be fixed it looks like detection of v2ray is actively attempted, as this comment from 2021 suggests:

Hello
From yesterday, Iran is actively blocking VLess + TLS traffics from v2ray v4.32.1. However, it seems that v2ray v4.34.0 is working fine. (I haven't tested v4.33.0) I'm not sure if Iran is using the same thing said here or not, but, any vless + tls traffic to port 443 even with fallback web server and legit certificate is getting ACTIVELY blocked: The client's hello message won't get delivered to server. ...