I just finished running an experiment that has shed some light on the issue. It has not yet been solved though.

I setup another nginx server with the same configuration with an upstream app that always responds with HTTP 200. I included JS on each page load in production to make a single request to this server.

I ran tcpdump on the test server and what I found was very interesting. Client connections producing the above "inappropriate fallback" on the test server all appear to do some form of the following:

(Client and Server successfully complete 3-way handshake)
Client: Client Hello TLSv1.2
Server: RST
Client: ACK
Server: RST
(Client and Server successfully complete 3-way handshake)
Client: Client Hello TLSv1.1
Server: RST
Client: ACK
Server: RST
(Client and Server successfully complete 3-way handshake)
Client: Client Hello TLSv1.0
Server: Encrypted Alert (Content Type: Alert (21))
(Client sends RST, which the server acknowledges, and the connection ends)

I don't know what the alert is, but I can only assume it's related to TLS_FALLBACK_SCSV since the client closes the connection right after.

What's interesting here is that there is little consistency to these RSTs. Sometimes a client downgrades to TSLv1.1 before getting the Encrypted Alert (Content Type: Alert(21)). Sometimes a client tries the same version over and over again, each time getting an RST from the server, and eventually gives up. Later many of these IP addresses are observed establishing successful connections.

Am I correct to assume Nginx is sending these RST packets?