You guys were very curious about the above line in the config file. Not sure if you read my response:
Could the ssl_redirect.conf file that the "include" command points to be causing any of this. Although, theoretically, everything that is included in the actual config file should overwrite the ssl_redirect.conf directives, no?
I'm guessing that a big part of the confusion is why the named groups aren't being updated by the curve command, right?
Could you please try something?
I’ve setup a server in the same datacentre as your website, using a similar nginx and OpenSSL version: https://ny3dotest.cf
Could you please visit it from macOS Safari and let me know whether it loads or not?
(People who are not OP, please try not to visit it)
Works on MacOS Safari! Outputs "Hello."
Works on all the iPhone browsers as well!
I can confirm that I get the same curve groups when I rem out the curve command in nginx using 1.1.1 strictly.
So the command works in my config but not in his…
ssl_ecdh_curve sect571r1:secp521r1:brainpoolP512r1:sect409r1:brainpoolP384r1:secp384r1:sect283r1:prime256v1;
And I get the same 88 lines of output from
openssl ecparam -list_curves
No...I just put the url in my browsers
Thanks. Could you try one last time?
You get notified when I click the 
button, right?
So it succeeded the last time as well, right?
I gotta tell you guys…I’m amazed at how awesome and helpful you are. Seriously, it’s incredible. I wasn’t expecting to receive the level of dedicated support. Thanks you!
Unfortunately I’m out of ideas, unless you want to upload the packet captures from running the simultaneous Safari and server packet capture.
I thought I might be able to do this using my test server, but sadly my test server actually works for you.
The only remaining differences I can identify:
As @rg305 pointed out, using an nginx build that is actually built with the same OpenSSL version that it uses at runtime. To complicate matters, if you use Laravel Forge, I’n not really sure how you go about fixing this, since Laravel Forge is managing your nginx installation, right?
Second, trying to just change your domain/server’s IP address and seeing if it makes a difference. Or maybe sticking it behind Cloudflare, which would have the same effect.
This is probably the main crux in this issue.
We don't really know how/where it does what it does.
so the difference between your test server and mine was what, the named groups?
No, I copied the name groups as well.
The difference is the way nginx is built against OpenSSL.
I don’t think this is a config issue, honestly. Network filtering (either intentional or screwup by your ISP) still makes the most sense to me, because it’s the only thing I actually have evidence for.
Please check and show:
apt update
apt list --upgradable
(sorry, if you don’t use apt, then translate that into whatever you do use)
Well this looks like a TO DO:
nginx/bionic 1.15.6-0+bionic0 all [upgradable from: 1.15.5-0+bionic1]
nginx-common/bionic 1.15.6-0+bionic0 all [upgradable from: 1.15.5-0+bionic1]
nginx-full/bionic 1.15.6-0+bionic0 amd64 [upgradable from: 1.15.5-0+bionic1]
openssl/bionic 1.1.1-3+ubuntu18.04.1+deb.sury.org+3 amd64 [upgradable from: 1.1.0g-2ubuntu4.3]
So an ssl certificate, LE or another, applied outside of Forge should solve the problem, right?
Cuz I was trying to use certBot to put a LE cert on another domain that I created/hosted the exact same way. But somewhere along the way I got a conflict warning and the cert never successfully got applied.
I'm not sure what you mean. If the certificate is served by the same droplet, then probably it will make no difference. I feel bad repeating myself but I think the problem exists outside of your server (along the network path).
But who knows. Maybe upgrading all your packages will actually help. At least, it's one of the safer first options you have.
Agreed, try that first.
That means upgrading everything that's in the upgradable.txt file?