Inconsistent TLS issues when connecting to domain from the server its hosted on

1. The problem I’m having:

when connecting to a domain from the machine the domain is hosted on, or the machine the caddy reverse proxy is hosted on, i inconsistently get issues with tls. this mainly crops up with my authentik instance, which often struggles to properly authorize accounts due to this

2. Error messages and/or full log output:

here i use curl as an example. in my experience i get this error maybe 75% of the time, with the other 25% actually working

 > wget https://auth.bunnieslove.me/application/o/vaultwarden/
--2026-07-08 12:34:31--  https://auth.bunnieslove.me/application/o/vaultwarden/
Resolving auth.bunnieslove.me (auth.bunnieslove.me)... 65.245.181.41
Connecting to auth.bunnieslove.me (auth.bunnieslove.me)|65.245.181.41|:443... connected.
GnuTLS: The TLS connection was non-properly terminated.
Unable to establish SSL connection.

3. Caddy version:

v2.11.4

4. How I installed and ran Caddy:

i installed caddy as a podman quadlet file, running through systemd

a. System environment:

OS: AlmaLinux 10.2 (Lavender Lion) x86_64

Podman version: 5.8.2

i connect to my backend servers over tailscale, if thats important?

b. Command:

n/a?

c. Service/unit/compose file:

[Container]
AddCapability=NET_ADMIN
EnvironmentFile=./caddy/.env
Image=caddy:latest
Volume=./caddy:/etc/caddy
Volume=./caddy/data:/data
Volume=./caddy/config:/config
PublishPort=80:80
PublishPort=443:443
Network=host
[Service]
Restart=always

[Install]
WantedBy=multi-user.target default.target

d. My complete Caddy config:

# jellyfin
https://jellyfin.emiii.ca {
   reverse_proxy 100.69.33.4:8096
}
# copyparty
https://copyparty.emiii.ca {
   reverse_proxy 100.69.33.4:3923
}
# immich
https://immich.emiii.ca {
   reverse_proxy 100.69.33.4:2283
}

# cobalt api
https://api.cobalt.emiii.ca {
   reverse_proxy 100.69.33.4:9003
}
# cobalt web
cobalt.emiii.ca {
   route {
      reverse_proxy /outpost.goauthentik.io/* http://100.69.33.4:9000
      #   header_up Host {http.reverse_proxy.upstream.host}
      #}
      
      forward_auth https://auth.bunnieslove.me {
         uri /outpost.goauthentik.io/auth/caddy
         copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Entitlements X-Authentik-Email X-Authentik-Name X-Authentik-Uid X-Authentik-Jwt X-Authentik-Meta-Jwks X-Authentik-Meta-Outpost X-Authentik-Meta-Provider X-Authentik-Meta-App X-Authentik-Meta-Version
         trusted_proxies private_ranges
     }     

      reverse_proxy 100.69.33.4:8787
   }
}

# proxytest
https://statustest.emiii.ca {
   respond 200
}

# fluxer
https://bunnieslove.me {
   header * {
      -Content-Security-Policy
      Content-Security-Policy "connect-src 'self' data: https://*.fluxer.app wss://*.fluxer.app https://*.fluxer.media wss://*.fluxer.media https://fluxer-uploads.ewr1.vultrobjects.com https://hcaptcha.com https://*.hcaptcha.com https://fluxerstatus.com https://fluxer.media http://127.0.0.1:21863 http://127.0.0.1:21864 https://bunnieslove.me https://bunnieslove.me/media wss://livekit.gaycatgirl.sex wss://turn.gaycatgirl.sex wss://voice.bunnieslove.me wss://turn.bunnieslove.me" 
   }

   log

   handle /livekit/* {
      reverse_proxy localhost:7880
   }

   reverse_proxy 100.69.33.4:3993
}


https://voice.bunnieslove.me {
   reverse_proxy localhost:7880
}

# authentik
https://auth.bunnieslove.me {
   reverse_proxy 100.69.33.4:9000
}

# kutt
https://s.emiii.ca {
   reverse_proxy localhost:3000
}

# vaultwarden
https://vw.bunnieslove.me {
   reverse_proxy 127.0.0.1:8899 {
      header_up X-Real-IP {remote_host}
   }
}

5. Links to relevant resources:

Type here

Can you test with gnutls-cli instead of wget, so that some debug information is available?

sure! heres the result of that

 > gnutls-cli https://auth.bunnieslove.me/application/o/vaultwarden/
Processed 388 CA certificate(s).
Resolving 'https://auth.bunnieslove.me/applicati'...
Cannot resolve https://auth.bunnieslove.me/applicati: Servname not supported for ai_socktype

Sorry, gnutls-cli just takes a hostname. ie gnutls-cli auth.bunnieslove.me.

From here the server seems to just hang up without trying to negotiate TLS at all.

oops! sorry! heres the full thing

 > gnutls-cli auth.bunnieslove.me
Processed 388 CA certificate(s).
Resolving 'auth.bunnieslove.me:443'...
Connecting to '65.245.181.41:443'...
- Certificate type: X.509
- Got a certificate list of 4 certificates.
- Certificate[0] info:
 - subject `CN=auth.bunnieslove.me', issuer `CN=YE2,O=Let's Encrypt,C=US', serial 0x05a493cc58b67b1942c0eed896c15dc9f83a, EC/ECDSA key 256 bits, signed using ECDSA-SHA384, activated `2026-06-24 04:23:44 UTC', expires `2026-09-22 04:23:43 UTC', pin-sha256="lHTjINso6H7RN5wTkyRJFV3sqN0l+LpQrCZUXL1w0hQ="
        Public Key ID:
                sha1:9fc76d0e83b8beca257ec98fa2df0b631cbc9f72
                sha256:9474e320db28e87ed1379c13932449155deca8dd25f8ba50ac26545cbd70d214
        Public Key PIN:
                pin-sha256:lHTjINso6H7RN5wTkyRJFV3sqN0l+LpQrCZUXL1w0hQ=

- Certificate[1] info:
 - subject `CN=YE2,O=Let's Encrypt,C=US', issuer `CN=Root YE,O=ISRG,C=US', serial 0x4df3b15dd6c0784c507cd37b58e6f115, EC/ECDSA key 384 bits, signed using ECDSA-SHA384, activated `2025-09-03 00:00:00 UTC', expires `2028-09-02 23:59:59 UTC', pin-sha256="s/tdAOmUzd8syaTuqfgGvFcn6DzA5Cmb+Vby1ST+U3Y="
- Certificate[2] info:
 - subject `CN=Root YE,O=ISRG,C=US', issuer `CN=ISRG Root X2,O=Internet Security Research Group,C=US', serial 0x00872165fc34b6e5fba8add5b3705fb53a, EC/ECDSA key 384 bits, signed using ECDSA-SHA384, activated `2026-05-13 00:00:00 UTC', expires `2032-09-02 23:59:59 UTC', pin-sha256="sCkq5UWXjg+7mKu9lMhhYF5bGLsy7VI/UNW3tccdR7w="
- Certificate[3] info:
 - subject `CN=ISRG Root X2,O=Internet Security Research Group,C=US', issuer `CN=ISRG Root X1,O=Internet Security Research Group,C=US', serial 0x6c8f1dc727c7117f7baf853ac980f9cd, EC/ECDSA key 384 bits, signed using RSA-SHA256, activated `2026-05-13 00:00:00 UTC', expires `2032-09-02 23:59:59 UTC', pin-sha256="diGVwiVYbubAI3RW4hB9xU8e/CH2GnkuvVFZE8zmgzI="
- Status: The certificate is trusted.
- Description: (TLS1.3-X.509)-(HYBRID-X25519-MLKEM768)-(ECDSA-SECP256R1-SHA256)-(AES-128-GCM)
- Session ID: 9A:F3:A4:7D:1C:B4:30:AE:68:73:06:0B:01:EF:CC:87:D7:27:65:97:01:F1:D0:CE:54:02:AE:87:01:B1:06:CD
- Options:
- Handshake was completed

- Simple Client Mode:


HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8
Connection: close

400 Bad Request- Peer has closed the GnuTLS connection

at the end i just hit enter, which i assume is where the bad request comes from. i think you should try running it again yourself, since my server was down at the time you tried :‌p


very fast edit: it sometimes gives what i put above, and sometimes gives this

 > gnutls-cli auth.bunnieslove.me
Processed 388 CA certificate(s).
Resolving 'auth.bunnieslove.me:443'...
Connecting to '65.245.181.41:443'...
*** Fatal error: The TLS connection was non-properly terminated.

another small update, i set caddy to debug mode, and when i got the tls issue there was zero logs to speak of, so im really lost on where else i could look. every command i run doesnt give me much info on the root of the problem. does anyone know what else i could try as a diagnostic? im pretty lost here, and this is causing me alot of issues

Yeah it still seems to work for a few connections then stop. You don’t have some sort of rate limiter configured do you?

i dont, as far as i know. and looking at my logs i dont see anything that would suggest that either

It doesn’t look like you ever posted Caddy logs in here. Can you include the log from a failure?

i did say above caddy doesnt show any logs at all when it fails, even with debug mode on, maybe i configured it wrong?

You don’t have debug mode on in the Caddyfile you posted. Are you sure there are no logs? That would be weird. Though I still think it could be something in front Caddy dropping connections, do you have a home router there for example?

i did run it with debug mode on after i posted, sorry for not putting debug in the caddyfile i sent. i do have a home router infront of caddy, though i dont have direct access to it (using caddy as a reverse proxy from a friends place). sorry for taking so long to respond, as well, life got in the way