Strange Behavior with simple Server

1. The problem I’m having:

I have really strange behavior when I simply try to run this Caddyfile from the documentation on HTTPS:

example.com

respond "Hello, privacy!"

The strange behavior I have is the weird 502 errors I sometimes get when calling example.com. Btw, of course, I have my domain, which points to my Raspberry Pi. The DNS entries are all correct.
I don’t always get 502. For example sometimes when I stop and start a server, works for Safari and not for Chrome. Another time it works for Chrome and not Safari. When I do curl example.com it just loads forever. When I do curl -v example.com it works, but it sometimes shows the 502 and sometimes it shows the “Hello, privacy!”
Now when I change the Caddyfile to:

example.com

reverse_proxy 127.0.0.1:3000 

and run some basic NodeJs server on localhost:3000 it works everytime correctly.

I might guess it has something to do with caches. But i still feel like the behavior is strange especially the one with the first Caddyfile that curl example.com just loads forever.
So is it just simple the caches messing everything up. And which caches are we talking about? At caddy itself, my brwoser/device, DNS,…

2. Error messages and/or full log output:

2024/11/27 13:11:58.431	INFO	using adjacent Caddyfile
2024/11/27 13:11:58.433	INFO	adapted config to JSON	{"adapter": "caddyfile"}
2024/11/27 13:11:58.434	INFO	admin	admin endpoint started	{"address": "localhost:2019", "enforce_origin": false, "origins": ["//[::1]:2019", "//127.0.0.1:2019", "//localhost:2019"]}
2024/11/27 13:11:58.435	INFO	http.auto_https	server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS	{"server_name": "srv0", "https_port": 443}
2024/11/27 13:11:58.435	INFO	http.auto_https	enabling automatic HTTP->HTTPS redirects	{"server_name": "srv0"}
2024/11/27 13:11:58.435	INFO	tls.cache.maintenance	started background certificate maintenance	{"cache": "0x40008d8100"}
2024/11/27 13:11:58.435	INFO	http.log	server running	{"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2024/11/27 13:11:58.435	INFO	http	enabling HTTP/3 listener	{"addr": ":443"}
2024/11/27 13:11:58.436	INFO	http.log	server running	{"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2024/11/27 13:11:58.436	INFO	http	enabling automatic TLS certificate management	{"domains": ["example.com"]}
2024/11/27 13:11:58.440	INFO	autosaved config (load with --resume flag)	{"file": "/root/.config/caddy/autosave.json"}
2024/11/27 13:11:58.441	INFO	serving initial configuration
2024/11/27 13:11:58.449	INFO	tls	storage cleaning happened too recently; skipping for now	{"storage": "FileStorage:/root/.local/share/caddy", "instance": "140f1a98-0887-4abd-b0d1-c373bd908c83", "try_again": "2024/11/28 13:11:58.449", "try_again_in": 86399.999997871}
2024/11/27 13:11:58.449	INFO	tls	finished cleaning storage units

3. Caddy version:

v2.8.4

4. How I installed and ran Caddy:

a. System environment:

Debian 12

b. Command:

caddy run

d. My complete Caddy config:

Check above

5. Links to relevant resources:

Howdy @lubinski, welcome to the Caddy community.

This makes me suspect not all is well in the realm of DNS resolution.

A Caddyfile with only a respond directive cannot issue 502s; there is no middleware in the route which could produce one. Working in one browser and not another, alternatively, is a major symptom of DNS resolving to multiple IPs, with some working and others not. curl doesn’t cache DNS or HTTP responses; it’s among the most reliable debug tools we have.

Add debug logging to Caddy, make some curl requests, see if you can collect some working and non-working results each, and post them all here along with Caddy’s debug logs and we might try to make sense of it.