wow. uh okey, quite a complex setup. But in this specific case it's not even reaching Angie Guardian.. Let alone Angie/Nginx.. It fails clearly at TLS handshaking and the non-TLS is unclear why it fails.

Here is an example if what I would have expected using curl via httpS:

curl -v https://angieguardian.org/
* Host angieguardian.org:443 was resolved.
* IPv6: (none)
* IPv4: 77.61.56.117
*   Trying 77.61.56.117:443...
* Connected to angieguardian.org (77.61.56.117) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=angieguardian.org
*  start date: Jul 25 12:33:40 2026 GMT
*  expire date: Oct 23 12:33:39 2026 GMT
*  subjectAltName: host "angieguardian.org" matched cert's "angieguardian.org"
*  issuer: C=US; O=Let's Encrypt; CN=YE2
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 3: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://angieguardian.org/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: angieguardian.org]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: angieguardian.org
> User-Agent: curl/8.5.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 403 
< server: Angie
< date: Thu, 13 Aug 2026 20:17:31 GMT
< content-type: text/plain; charset=utf-8
< content-length: 93
< cache-control: no-store
< referrer-policy: no-referrer
< x-content-type-options: nosniff
< content-security-policy: default-src 'none'; script-src 'unsafe-inline'; style-src 'unsafe-inline'; worker-src blob:; connect-src 'self'; base-uri 'none'
< 
proof-of-work challenge requires a document navigation: Accept must list text/html or text/*
* Connection #0 to host angieguardian.org left intact

But your non SSL is maybe even more interesting.. since that is also failing (port 80 has NO angie guardian protection btw), here I would expected the following:

curl -v http://angieguardian.org/
* Host angieguardian.org:80 was resolved.
* IPv6: (none)
* IPv4: 77.61.56.117
*   Trying 77.61.56.117:80...
* Connected to angieguardian.org (77.61.56.117) port 80
> GET / HTTP/1.1
> Host: angieguardian.org
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Server: Angie
< Date: Thu, 13 Aug 2026 20:22:16 GMT
< Content-Type: text/html
< Content-Length: 205
< Connection: keep-alive
< Location: https://angieguardian.org/
< 
<html>
<title>301 Moved Permanently</title>
<style>html{color-scheme:light dark;}</style>
</head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>Angie</center>
</body>
</html>
* Connection #0 to host angieguardian.org left intact

TDLR; clearly something else goes wrong with this setup.