What caused the loss of traffic during a chain of redirects through an https link?

Question

Nginx

Hello.
We make a service related to user analysis. The essence of the work is approximately the following:
- the user clicks on the link;
- the user is redirected to the address on our service;
- service makes magic;
- the service redirects the user to the landing page;
Domains on each of the addresses may not match. In some cases, you need to redirect via https, and then problems arise: up to a third of the test traffic is lost (does not reach our service). Opportunities to catch the user and ask "what's wrong?" no.
The conclusion about the losses is based on the comparison of users who clicked on the link and users who came to us (ie, those who established an ssl connection and made a url request).
Test traffic, to put it mildly, is cheap and bad and is lost even without using https (normal losses are about 10%), but with the inclusion of encryption, the losses increase dramatically. It is necessary to eliminate them or make sure that they are “natural” (for example, these are all bots).
Certificate purchased from Godaddy.
Services for checking ssl like https://www.ssllabs.com/ssltest/analyze.html?d=rou... say that the chain of trust is configured correctly.
According to the User-Agent analysis, the main losses occur in the latest versions of browsers (mainly Chrome, since traffic is mainly on this browser). Operating systems: Windows 7 (2 thirds of traffic), Windows XP (one third).

Part of the Nginx config with ssl settings

server {
        listen        route.land:80;
        server_name   route.land;

        listen route.land:443 ssl;

        ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers ALL;                                                                                                                                                                 

        ssl_stapling on;
        ssl_stapling_verify on;

        ssl_certificate /etc/nginx/ssl/route.land.crt;
        ssl_certificate_key /etc/nginx/ssl/route.land.key;
        ssl_trusted_certificate /etc/nginx/ssl/route.land.trusted.crt;

        resolver 8.8.8.8;
}

Link to the site https://route.land
Link to test the redirect chain: the-tale.org/test (should return to the-tale.org/ )
At the moment there are the following versions:
traffic is cheap and advertising (4% of users lost when switching to https directly in the User-Agent writes that it is bots).
- crooked pirate axes in which automatic pulling of root certificates is disabled (hard to believe, it's not clear why to disable it, I checked it on the pirate seven of 2010, everything works).
- some common corporate configurations that block the site (most of the tests were carried out on weekends, so it's unlikely).
- third-party software (antiviruses, etc.), I know for sure that Kaspersky can break ssl with some settings (they write it in their own way), but I don’t know the percentage of such breakdowns.
- one of the nuances of browsers with secure connections, which I could not google.
Tell me what else could be the problem, where to dig?
UPDATED:
According to nginx logs:
- we have very few errors at the handshake stage;
- in access log and error log with loglevel=error there are no entries about orphaned users.
Made two small tests with loglevel=info for error log (redirect via http and https):

• 5% of unique IPs don't try to connect to us at all in both tests;
  
• 17% of unique IPs close the connection after establishing an https connection (no loss with http). The error distribution is as follows:
  • 16% - client timed out (110: Connection timed out) while waiting for request;
    
  • 90% - client closed connection while waiting for request;
    
  • 4% - peer closed connection in SSL handshake while SSL handshaking.
    
  
  

The difference between the time users are redirected to our site and the error time (for users who did nothing but establish a connection) is 10-20 seconds.

Answer 1

As a result, it turned out that it took up to 0.5 seconds to establish a secure connection, apparently users are simply not ready to wait that long and close the page.

Answer 2

SSLv2 would be disabled, deprecated and insecure.