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.
I guess if you have to defend against DDOS attacks going big is the only way.
It’s not.
Care to elaborate?
There’s loads of DDoS alternatives.
It’s a national security threat to give your httpa private keys to a US company. As a result, loads of alternatives exist for real DDoS attacks.
But also, almost any nonprofit social media site can just get away with a self hosted pow solution.
Ok, seems we have different ideas of what a real ddos attack is. I was thinking level 3 attacks.
No, that is why I created https://angieguardian.org/
But this only covers layer 7, doesn’t it?
That is right. I tried to be transparent what is it NOT: https://angieguardian.org/guide/threat-model#what-guardian-does-not-defend-against
Yeah something ain’t right here chief. Now I have to ask, what was the LLM policy in regards to the development of this software?
Uhm that is interesting. Are you using a VPN or some browser without cookie support maybe? I would like to debug this specific issue.
I’m using let’s encrypt certificates. Please I would really like to debug this problem, I can’t reproduce it.
iPhone > Safari webkit > WireGuard tunnel home network > PiHole DNS (Quad9 upstream) > WireGuard tunnel ProtonVPN endpoint
That is the flow of my current network.
Edit: I ran curl from my server
┌─[user@debian] - [~/compose] - [Thu Aug 13, 12:26] └─[$]> curl -v https://angieguardian.org/ * Host angieguardian.org:443 was resolved. * IPv6: (none) * IPv4: 77.61.56.117 * Trying 77.61.56.117: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 * Recv failure: Connection reset by peer * TLS connect error: error:00000000:lib(0)::reason(0) * OpenSSL SSL_connect: Connection reset by peer in connection to angieguardian.org:443 * closing connection #0 curl: (35) Recv failure: Connection reset by peer ┌─[user@debian] - [~/compose] - [Thu Aug 13, 12:27] └─[$]> curl -v 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 * using HTTP/1.x > GET / HTTP/1.1 > Host: angieguardian.org > User-Agent: curl/8.14.1 > Accept: */* > * Request completely sent off * Recv failure: Connection reset by peer * closing connection #0 curl: (56) Recv failure: Connection reset by peerCan confirm my PiHole is resolving the requests and forwarding them to Quad9.
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 intactBut 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 intactTDLR; clearly something else goes wrong with this setup.