The SNI is encapsulated in an outer layer of TLS, which is removed before forwarding traffic to Signal. That's what nginx-terminate is doing.
The SNI header is not dropped to upstream because it's used whether the reverse proxy is operated by the intended recipient (Signal) or not (the proxy). That's precisely the reason why people have been promoting Encrypted SNI for some time now.
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.