You can spin up the proxy and check yourself.
Alternatively, you can ask yourself "why go through the trouble of setting up a legitimate ca-signed certificate if Signal domains are already leaking in plaintext"? The whole point of the ca-signed cert is to make the traffic blend in. Why go through that trouble when a simple regular expression could identify it?
I just did, and you are right. I stand corrected, sorry for spreading FUD. Other criticism of Signal still applies. I would edit my original message to reflect that, however i can't because it's been posted a while ago.
An attacker (such as the government) may not drop connections in real-time to Signal proxies without considerable efforts (i.e. for every HTTPS stream, verifying whether the remote server is a Signal proxy). However, after passively recording SNI headers, the attacker check those remote servers to figure out whether they are Signal proxies. As a conclusion, this Signal proxy is an effective censorship-circumvention tool, but does not protect users from the consequences of circumventing government censorship (which may be harsh).
A possible mitigation would be to have the virtualhost terminating the outer TLS connection serve the reverse proxy only from a specific folder/location, which cannot be well-known. So the attacker would see you are connecting to https://proxy.example, but as long as https://proxy.example serves legit-looking pages on /, and the Signal proxy is served from https://proxy.example/foobar, the attacker may not passively discover the actual reverse proxy. Of course, every Signal proxy would need to use a different subfolder.