Let's say the upstream server is apple.com. The TLS handshake is always performed by the real apple.com servers, and the ShadowTLS server is only a middle man forwarding raw TCP contents.

If both sides are ShadowTLS (client & server) holding the same key, they will stealthily switch to a different encryption protocol after the handshake, disregarding the TLS key exchange. The TLS handshake is a facade to fool the deep packet inspection of the censor.

In all other cases, such as the censor actively probing the ShadowTLS server, the server will keep forwarding the encrypted traffic to apple.com without anyway to decrypt it (it's not a MitM proxy). To the active prober, it is just apple.com all the way.

My understanding is that the way it works is that your proxy server pretends to be a server ran by some legitimate entity (e.g. cloudflare, aws, etc.). When setting up the server, you will instruct it respond using the cert from the façade domain. To the censor, it would appear that you are approaching a server ran by the legitimate entity. If the censor becomes suspicious of the IP and decides to probe the server to see if it is a circumventing proxy, it would see valid certs but no actual content (as if the server at the IP is broken/down). However, there is actually a secret path+password that you can use to make the server aware that you are a real client and the proxy server would start proxy your traffic normally.

iirc, the clients use the certs but ignore them. but to the censor they see the certs are well known, so allow them thru