Caddy not working after changing drives/resetting Windows

dingdongyo · January 11, 2025, 6:46pm

1. The problem I’m having:

Summary - Trying to start Caddy in Windows 11, but it shows a “timeout during connect” error and then hangs on “trying to solve challenge.”

Background info - I was successfully using Caddy as a reverse proxy to host my family home videos Emby server for years. When I tried upgrading the NVMe drive, I had issues and ended up reinstalling Windows, which undid a lot of the Caddy config. It didn’t erase the CaddyFile, dynamic DNS (provided by No-ip), or any of my router’s network settings. I downloaded Caddy again from the website, cleared out the cache folders, and added the firewall rules back. But it’s still failing with the errors described above and I can’t figure out what’s wrong.

Happy to provide more info, I’m just stumped and would appreciate some help looking. I’m not a networking pro, apologies if I’m missing basic things (and don’t be afraid to suggest them). Thank you!

2. Error messages and/or full log output:

No logs actually get created in the “logs” folder, but this is the error message in Command Prompt. I cut a lot out because I was way over character limit. Please let me know if you need a more specific line and I’ll get it:

2025/01/11 18:16:23.275 ERROR   challenge failed        {"identifier": "dingdonghonk.gotdns.ch", "challenge_type": "http-01", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "71.181.79.164: Fetching http://dingdonghonk.gotdns.ch/.well-known/acme-challenge/ehI7K6HmgcEoWzw12B4b_wLz6RRG1jF5qQXeTQwo6JI: Timeout during connect (likely firewall problem)", "instance": "", "subproblems": null}}
github.com/mholt/acmez/v3.(*Client).pollAuthorization
        github.com/mholt/acmez/v3@v3.0.0/client.go:557
github.com/mholt/acmez/v3.(*Client).solveChallenges
        github.com/mholt/acmez/v3@v3.0.0/client.go:378
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:136
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73
2025/01/11 18:16:23.275 ERROR   validating authorization        {"identifier": "dingdonghonk.gotdns.ch", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "71.181.79.164: Fetching http://dingdonghonk.gotdns.ch/.well-known/acme-challenge/ehI7K6HmgcEoWzw12B4b_wLz6RRG1jF5qQXeTQwo6JI: Timeout during connect (likely firewall problem)", "instance": "", "subproblems": null}, "order": "https://acme-v02.api.letsencrypt.org/acme/order/2163030015/343319742995", "attempt": 1, "max_attempts": 3}
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:152
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73
2025/01/11 18:16:23.298 DEBUG   http request    {"method": "POST", "url": "https://acme-v02.api.letsencrypt.org/acme/authz/2163030015/459162479545", "headers": {"Content-Type":["application/jose+json"],"User-Agent":["Caddy/2.9.1 CertMagic acmez (windows; amd64)"]}, "response_headers": {"Boulder-Requester":["2163030015"],"Cache-Control":["public, max-age=0, no-cache"],"Content-Length":["1090"],"Content-Type":["application/json"],"Date":["Sat, 11 Jan 2025 18:16:24 GMT"],"Link":["<https://acme-v02.api.letsencrypt.org/directory>;rel=\"index\""],"Replay-Nonce":["2NJzUBzXd0_Iv2aMLwJa9VFz8YpOTDrk0nhdxitI51mdq6uKwI4"],"Server":["nginx"],"Strict-Transport-Security":["max-age=604800"],"X-Frame-Options":["DENY"]}, "status_code": 200}
2025/01/11 18:16:23.300 ERROR   challenge failed        {"identifier": "dingdonghonk.ddns.net", "challenge_type": "http-01", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "71.181.79.164: Fetching http://dingdonghonk.ddns.net/.well-known/acme-challenge/8NeCg2jdH47V7MfFLjbMPTyt7Zlr1kv3yJGN77u1Io0: Timeout during connect (likely firewall problem)", "instance": "", "subproblems": null}}
github.com/mholt/acmez/v3.(*Client).pollAuthorization
        github.com/mholt/acmez/v3@v3.0.0/client.go:557
github.com/mholt/acmez/v3.(*Client).solveChallenges
        github.com/mholt/acmez/v3@v3.0.0/client.go:378
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:136
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73
2025/01/11 18:16:23.301 ERROR   validating authorization        {"identifier": "dingdonghonk.ddns.net", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "71.181.79.164: Fetching http://dingdonghonk.ddns.net/.well-known/acme-challenge/8NeCg2jdH47V7MfFLjbMPTyt7Zlr1kv3yJGN77u1Io0: Timeout during connect (likely firewall problem)", "instance": "", "subproblems": null}, "order": "https://acme-v02.api.letsencrypt.org/acme/order/2163030015/343319743075", "attempt": 1, "max_attempts": 3}
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:152
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73

3. Caddy version:

v2.9.1 h1:OEYiZ7DbCzAWVb6TNEkjRcSCRGHVoZsJinoDR/n9oaY=

4. How I installed and ran Caddy:

I downloaded the .exe with no addons from caddyserver.com yesterday.
I’m using the same CaddyFile that had been working before.

a. System environment:

Windows 11 Home (OS Build 26100.2605)

b. Command:

caddy start

c. Service/unit/compose file:

d. My complete Caddy config:

{
        debug
        email soulsaturn@yahoo.com
}

# import *.CaddyFile

### Photoprism ###
dingdonghonk.gotdns.ch {
        reverse_proxy http://127.0.0.1:2342

        basicauth * {
                R****** [****************************80-char-password-hash*****************************]
        }

        #basicauth /library/index/files/Mom* {
        # M****** [****************************80-char-password-hash*****************************]
        #}
        #
}

### Emby ###

dingdonghonk.ddns.net {
        reverse_proxy http://127.0.0.1:8096
}

#basicauth * {
#  R****** [****************************80-char-password-hash*****************************]
#}

5. Links to relevant resources:

dingdongyo · January 12, 2025, 4:27pm

All the error messages state issue “likely the firewall,” so I tried disabling both the firewall and my antivirus temporarily and retried starting Caddy, and I still get the same error. I also get “connection refused” lines, which may be different than before:

2025/01/12 16:20:54.310 ERROR challenge failed {"identifier": "dingdonghonk.gotdns.ch", "challenge_type": "tls-alpn-01", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "71.181.79.164: Connection refused", "instance": "", "subproblems": null}}

Appreciate any troubleshooting ideas, thank you!

dingdongyo · January 14, 2025, 4:48am

Today I tried creating a new noip domain with a new noip account and using a CaddyFile reconfigured with that domain, and nothing changed. Exact same errors, with both the firewall on and off. So I put back the original ones.

Whenver i try to ping or tracert to either domain from outside the network, it hits a dead end. However, I can ping the domains from inside my network fine. I am also able to SSH into my computer using a private key and that domain name from outside the network, so I think the domains are working and routing where they are supposed to.

None of the network profiles on the PC are set to “block incoming connections.”

I can’t figure out what this behavior indicates and I’m very confused and frustrated. It can’t be a firewall setting if the connection is refused while the firewall isn’t even on, can it? Does anybody have any ideas? Please?

fds · January 15, 2025, 11:15pm

I can explain exactly what part is failing, but not entirely sure as to why it is failing, or how you would go about solving it. It certainly seems like a firewall/router configuration or an ISP issue.

Caddy is trying to automatically retrieve a valid TLS certificate from Let’s Encrypt for your host name. In order to get a certificate issued, you have to prove that you are in control of that host name. By default this is done through serving a mutually agreed random string of characters, a “challenge” through either HTTP (TCP port 80) known as the HTTP-01 challenge, or via the HTTPS (TCP port 443) TLS ALPN handshake, aka the TLS-ALPN challenge.

Your first log shows failing the http-01 challenge (TCP port 80)

challenge failed
"challenge_type": "http-01"
http://dingdonghonk.ddns.net/

And your second log shows the tls-alpn-01 challenge also failing (TCP port 443). Essentially Let’s Encrypt’s verification servers tried to connect back to your machine, and failed (in the first case, timed out unsuccessfully waiting for an answer that never came, or refused connection immediately in the second).

I’d double-check on your router that TCP ports 80 and 443 are correctly set up to forward to your Windows machine’s LAN private address, same as it is apparently working for ssh (TCP port 22). (Assuming that SSH server is also running on the same machine as Caddy.) While you’re at it, make sure UDP port 443 is also forwarded to Caddy on the correct machine, so you get to enjoy HTTP/3 support, although this part is unnecessary for your immediate issue.

dingdongyo · January 16, 2025, 2:57am

Thank you so much for the detailed answer!

Unfortunately not working yet. My router’s port forwarding requires adding an “External port” and “Internal port” for each forwarding rule. I mapped incoming port 80 to port 80 on the Caddy server, and same with 443. (FWIW, I didn’t have these entries before and the Caddy server was somehow working before the drive switch, don’t know if that’s interesting).

What’s likely interesting is the new error message. I still get the timeout errors, but after those it is now showing “unauthorized” errors. These seem to be different than the “too many attempts” errors I’ve gotten before.

github.com/mholt/acmez/v3.(*Client).pollAuthorization
        github.com/mholt/acmez/v3@v3.0.0/client.go:557
github.com/mholt/acmez/v3.(*Client).solveChallenges
        github.com/mholt/acmez/v3@v3.0.0/client.go:378
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:136
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73
2025/01/16 02:37:01.405 ERROR   validating authorization        {"identifier": "dingdonghonk.ddns.net", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "71.181.79.164: Timeout during connect (likely firewall problem)", "instance": "", "subproblems": null}, "order": "https://acme-v02.api.letsencrypt.org/acme/order/2168805585/344811143275", "attempt": 1, "max_attempts": 3}
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:152
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73
2025/01/16 02:37:01.454 ERROR   challenge failed        {"identifier": "dingdonghonk.gotdns.ch", "challenge_type": "tls-alpn-01", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "71.181.79.164: Timeout during connect (likely firewall problem)", "instance": "", "subproblems": null}}
github.com/mholt/acmez/v3.(*Client).pollAuthorization
        github.com/mholt/acmez/v3@v3.0.0/client.go:557
github.com/mholt/acmez/v3.(*Client).solveChallenges
        github.com/mholt/acmez/v3@v3.0.0/client.go:378
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:136
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73
2025/01/16 02:37:01.457 ERROR   validating authorization        {"identifier": "dingdonghonk.gotdns.ch", "problem": {"type": "urn:ietf:params:acme:error:connection", "title": "", "detail": "71.181.79.164: Timeout during connect (likely firewall problem)", "instance": "", "subproblems": null}, "order": "https://acme-v02.api.letsencrypt.org/acme/order/2168805585/344811143135", "attempt": 1, "max_attempts": 3}
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:152
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73
2025/01/16 02:37:02.666 INFO    trying to solve challenge       {"identifier": "dingdonghonk.ddns.net", "challenge_type": "http-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
2025/01/16 02:37:02.713 INFO    trying to solve challenge       {"identifier": "dingdonghonk.gotdns.ch", "challenge_type": "http-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
2025/01/16 02:37:03.048 ERROR   challenge failed        {"identifier": "dingdonghonk.ddns.net", "challenge_type": "http-01", "problem": {"type": "urn:ietf:params:acme:error:unauthorized", "title": "", "detail": "71.181.79.164: Invalid response from http://dingdonghonk.ddns.net/.well-known/acme-challenge/3vvtrg8fBZCit5WJ0Xqczd2Yweu2XYUI2h4XuFAX6og: 404", "instance": "", "subproblems": null}}
github.com/mholt/acmez/v3.(*Client).pollAuthorization
        github.com/mholt/acmez/v3@v3.0.0/client.go:557
github.com/mholt/acmez/v3.(*Client).solveChallenges
        github.com/mholt/acmez/v3@v3.0.0/client.go:378
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:136
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73
2025/01/16 02:37:03.049 ERROR   validating authorization        {"identifier": "dingdonghonk.ddns.net", "problem": {"type": "urn:ietf:params:acme:error:unauthorized", "title": "", "detail": "71.181.79.164: Invalid response from http://dingdonghonk.ddns.net/.well-known/acme-challenge/3vvtrg8fBZCit5WJ0Xqczd2Yweu2XYUI2h4XuFAX6og: 404", "instance": "", "subproblems": null}, "order": "https://acme-v02.api.letsencrypt.org/acme/order/2168805585/344811182775", "attempt": 2, "max_attempts": 3}
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:152
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73
2025/01/16 02:37:03.052 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "dingdonghonk.ddns.net", "issuer": "acme-v02.api.letsencrypt.org-directory", "error": "HTTP 403 urn:ietf:params:acme:error:unauthorized - 71.181.79.164: Invalid response from http://dingdonghonk.ddns.net/.well-known/acme-challenge/3vvtrg8fBZCit5WJ0Xqczd2Yweu2XYUI2h4XuFAX6og: 404"}
2025/01/16 02:37:03.056 INFO    tls.issuance.acme       waiting on internal rate limiter        {"identifiers": ["dingdonghonk.ddns.net"], "ca": "https://acme.zerossl.com/v2/DV90", "account": "soulsaturn@yahoo.com"}
2025/01/16 02:37:03.056 INFO    tls.issuance.acme       done waiting on internal rate limiter   {"identifiers": ["dingdonghonk.ddns.net"], "ca": "https://acme.zerossl.com/v2/DV90", "account": "soulsaturn@yahoo.com"}
2025/01/16 02:37:03.057 INFO    tls.issuance.acme       using ACME account      {"account_id": "https://acme.zerossl.com/v2/DV90/account/__LSaY58na9wvLgHA4QHtw", "account_contact": ["mailto:soulsaturn@yahoo.com"]}
2025/01/16 02:37:03.104 ERROR   challenge failed        {"identifier": "dingdonghonk.gotdns.ch", "challenge_type": "http-01", "problem": {"type": "urn:ietf:params:acme:error:unauthorized", "title": "", "detail": "71.181.79.164: Invalid response from http://dingdonghonk.gotdns.ch/.well-known/acme-challenge/_YfJJ_F12v2dG5BFYUlbrLuYHSs5nizsmt2aZEwyMhY: 404", "instance": "", "subproblems": null}}
github.com/mholt/acmez/v3.(*Client).pollAuthorization
        github.com/mholt/acmez/v3@v3.0.0/client.go:557
github.com/mholt/acmez/v3.(*Client).solveChallenges
        github.com/mholt/acmez/v3@v3.0.0/client.go:378
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:136
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73
2025/01/16 02:37:03.105 ERROR   validating authorization        {"identifier": "dingdonghonk.gotdns.ch", "problem": {"type": "urn:ietf:params:acme:error:unauthorized", "title": "", "detail": "71.181.79.164: Invalid response from http://dingdonghonk.gotdns.ch/.well-known/acme-challenge/_YfJJ_F12v2dG5BFYUlbrLuYHSs5nizsmt2aZEwyMhY: 404", "instance": "", "subproblems": null}, "order": "https://acme-v02.api.letsencrypt.org/acme/order/2168805585/344811183115", "attempt": 2, "max_attempts": 3}
github.com/mholt/acmez/v3.(*Client).ObtainCertificate
        github.com/mholt/acmez/v3@v3.0.0/client.go:152
github.com/caddyserver/certmagic.(*ACMEIssuer).doIssue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:477
github.com/caddyserver/certmagic.(*ACMEIssuer).Issue
        github.com/caddyserver/certmagic@v0.21.6/acmeissuer.go:371
github.com/caddyserver/caddy/v2/modules/caddytls.(*ACMEIssuer).Issue
        github.com/caddyserver/caddy/v2@v2.9.1/modules/caddytls/acmeissuer.go:249
github.com/caddyserver/certmagic.(*Config).obtainCert.func2
        github.com/caddyserver/certmagic@v0.21.6/config.go:626
github.com/caddyserver/certmagic.doWithRetry
        github.com/caddyserver/certmagic@v0.21.6/async.go:104
github.com/caddyserver/certmagic.(*Config).obtainCert
        github.com/caddyserver/certmagic@v0.21.6/config.go:700
github.com/caddyserver/certmagic.(*Config).ObtainCertAsync
        github.com/caddyserver/certmagic@v0.21.6/config.go:505
github.com/caddyserver/certmagic.(*Config).manageOne.func1
        github.com/caddyserver/certmagic@v0.21.6/config.go:415
github.com/caddyserver/certmagic.(*jobManager).worker
        github.com/caddyserver/certmagic@v0.21.6/async.go:73
2025/01/16 02:37:03.109 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "dingdonghonk.gotdns.ch", "issuer": "acme-v02.api.letsencrypt.org-directory", "error": "HTTP 403 urn:ietf:params:acme:error:unauthorized - 71.181.79.164: Invalid response from http://dingdonghonk.gotdns.ch/.well-known/acme-challenge/_YfJJ_F12v2dG5BFYUlbrLuYHSs5nizsmt2aZEwyMhY: 404"}
2025/01/16 02:37:03.111 INFO    tls.issuance.acme       waiting on internal rate limiter        {"identifiers": ["dingdonghonk.gotdns.ch"], "ca": "https://acme.zerossl.com/v2/DV90", "account": "soulsaturn@yahoo.com"}
2025/01/16 02:37:03.111 INFO    tls.issuance.acme       done waiting on internal rate limiter   {"identifiers": ["dingdonghonk.gotdns.ch"], "ca": "https://acme.zerossl.com/v2/DV90", "account": "soulsaturn@yahoo.com"}
2025/01/16 02:37:03.111 INFO    tls.issuance.acme       using ACME account      {"account_id": "https://acme.zerossl.com/v2/DV90/account/__LSaY58na9wvLgHA4QHtw", "account_contact": ["mailto:soulsaturn@yahoo.com"]}
2025/01/16 02:37:03.330 INFO    trying to solve challenge       {"identifier": "dingdonghonk.ddns.net", "challenge_type": "http-01", "ca": "https://acme.zerossl.com/v2/DV90"}
2025/01/16 02:37:03.363 INFO    trying to solve challenge       {"identifier": "dingdonghonk.gotdns.ch", "challenge_type": "http-01", "ca": "https://acme.zerossl.com/v2/DV90"}

Is there an ID string or something I can get from No-ip and add to the Caddy config to prove ownership somehow? Trying to think what else I could possibly do.

Yes, the working SSH server/connection is running on the same machine as Caddy.

fds · January 16, 2025, 3:21am

dingdongyo:

2025/01/16 02:37:03.048 ERROR   challenge failed        {"identifier": "dingdonghonk.ddns.net", 
"challenge_type": "http-01",
 "problem": {"type": "urn:ietf:params:acme:error:unauthorized",
 "title": "", 
"detail": "71.181.79.164: Invalid response from 
http://dingdonghonk.ddns.net/.well-known/acme-challenge/3vvtrg8fBZCit5WJ0Xqczd2Yweu2XYUI2h4XuFAX6og:
 404", "instance": "", "subproblems": null}}

Your error message now implies it’s successfully talking to a web server at that address but that it is receiving a 404 Not Found error – which it should not if it actually talked to your Caddy instance.

Took the liberty of testing your server myself, like this:

curl -i http://dingdonghonk.ddns.net

And it’s replying:

HTTP/1.1 200 OK
Server: nginx/1.27.3
[…]
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

That’s clearly not your trusty Caddy web server we expected to find but nginx! Any idea where that nginx might be coming from? Were you experimenting with other web servers, and it’s squatting on the same port Caddy’s trying to use? Or maybe you set the port forwarding to the wrong machine inside your LAN?

That configuration should be correct yet the port is not going to your Caddy instance somehow. Also, things magically working without it previously is definitely interesting, and worth exploring, since there has to be an explanation. Among the possibilities I could think of: the port forwarding getting set up automatically by the client through UPnP or a similar protocol; using a “DMZ Host” setting on the router redirecting all ports by default to that machine rather than setting up ports one by one; or having (in the past) a direct IPv6 address instead of IPv4 behind NAT, making forwarding unnecessary.

dingdongyo · January 16, 2025, 5:40am

Yes, thank you again! Each one of these steps is getting closer to working!

So sorry about the nginx confusion! I just started messing with nginx a few hours ago today - before realizing there was a reply here in the community - and I didn’t kill the process before my last attempt, so you found it with your test. That was not part of the original problem, but it definitely helped here because Caddy is now starting successfully!

Ultimately, the only thing I’ve changed so far to get Caddy to start was adding those port forwarding rules.

Something still isn’t quite right though, and it may not be a Caddy problem. When I go to the URL in a browser, it’s supposed to redirect to my Emby server. I’ve verified that Emby is running, and going to the reverse proxy destination URL on the server itself (http://127.0.0.1:8096) successfully connects and loads my home videos library in the browser.

However, when I try to go to https://dingdonghonk.ddns.net in a browser, it fails to load with ERR_CONNECTION_TIMED_OUT

I tried going to the https port for Emby on the server itself (https://127.0.0.1:8920) and it shows ERR_CONNECTION_REFUSED

I’ll add the latest cmd output in case it has anything useful:

c:\caddy>caddy start
2025/01/16 05:10:00.459 ←[34mINFO←[0m   using adjacent Caddyfile
2025/01/16 05:10:00.461 ←[33mWARN←[0m   config.adapter.caddyfile        the 'basicauth' directive is deprecated, please use 'basic_auth' instead!
2025/01/16 05:10:00.463 ←[34mINFO←[0m   adapted config to JSON  {"adapter": "caddyfile"}
2025/01/16 05:10:00.463 ←[33mWARN←[0m   Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies    {"adapter": "caddyfile", "file": "Caddyfile", "line": 2}
2025/01/16 05:10:00.487 ←[34mINFO←[0m   admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2025/01/16 05:10:00.487 ←[34mINFO←[0m   tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc000556380"}
2025/01/16 05:10:00.487 ←[34mINFO←[0m   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}
2025/01/16 05:10:00.488 ←[34mINFO←[0m   http.auto_https enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2025/01/16 05:10:00.490 ←[34mINFO←[0m   http    enabling HTTP/3 listener        {"addr": ":443"}
2025/01/16 05:10:00.490 ←[34mINFO←[0m   http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2025/01/16 05:10:00.490 ←[33mWARN←[0m   http    HTTP/2 skipped because it requires TLS  {"network": "tcp", "addr": ":80"}
2025/01/16 05:10:00.491 ←[33mWARN←[0m   http    HTTP/3 skipped because it requires TLS  {"network": "tcp", "addr": ":80"}
2025/01/16 05:10:00.491 ←[34mINFO←[0m   http.log        server running  {"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2025/01/16 05:10:00.491 ←[34mINFO←[0m   http    enabling automatic TLS certificate management   {"domains": ["dingdonghonk.ddns.net", "dingdonghonk.gotdns.ch"]}
2025/01/16 05:10:00.494 ←[34mINFO←[0m   tls     storage cleaning happened too recently; skipping for now        {"storage": "FileStorage:C:\\Users\\mobilebackup\\AppData\\Roaming\\Caddy", "instance": "760c6cc6-9925-4f1b-86de-6e8180aea7a2", "try_again": "2025/01/17 05:10:00.494", "try_again_in": 86400}
2025/01/16 05:10:00.494 ←[34mINFO←[0m   tls     finished cleaning storage units
2025/01/16 05:10:00.496 ←[34mINFO←[0m   autosaved config (load with --resume flag)      {"file": "C:\\Users\\mobilebackup\\AppData\\Roaming\\Caddy\\autosave.json"}
2025/01/16 05:10:00.496 ←[34mINFO←[0m   serving initial configuration
Successfully started Caddy (pid=15588) - Caddy is running in the background

fds · January 16, 2025, 6:13am

Looks like we are past the early start-up issues, and Caddy should be able to function properly now. There’s only something amiss with that reverse_proxy setup.

Some things to try:
caddy start makes Caddy go in the background which is unhelpful when you’re still trying to solve basic functionality. I’d do a caddy stop and switch to testing with caddy run instead for now, which lets it stay in the foreground, dumping log entries to your console, until you have your configuration perfected.
Or you could set up logging into a file.

Reverse proxying to plain http on localhost will be just fine, making that other service also go through https would only complicate matters and waste resources. And since you say it loads fine when opened directly on your computer, you must be very close to a working setup.

Maybe it’s just the common case of needing an updated Host header, extend your reverse_proxy setting as follows:

reverse_proxy 127.0.0.1:8096 {
	header_up Host {upstream_hostport}
}

In case there are still issues, it might be nice to confirm at least that Caddy at a basic level is working fine now, and it’s only the reverse_proxy that needs solving by temporarily commenting it out, and adding something simple like

respond "Hello, world!"

instead.

dingdongyo · January 18, 2025, 4:25am

Thank you again for the help! Took me a few days to get back to this.

I tried your recommendations first to see if I could get an easy win, but no luck unfortunately. I wasn’t sure if your Host header suggested addition was supposed to be literal or fill in the port instead, so I tried it both ways:

reverse_proxy 127.0.0.1:8096 {
	header_up Host {upstream_hostport}
}

reverse_proxy 127.0.0.1:8096 {
	header_up Host {8096}
}

Neither made a difference. Then I tried commenting out everything and adding the simple output:

dingdonghonk.ddns.net {
  respond "Hello, world!"
  #reverse_proxy http://127.0.0.1:8096 {
  #   header_up Host {upstream_hostport}
  #}
}

In all three of those tests, going to dingdonghonk.ddns.net afterward still resulted in a “took too long to respond” error in the browser. Nothing loaded.

I checked out the log tutorial and set up a simple log.:

dingdonghonk.ddns.net {
#respond "Hello, world!"
   log {
	output file c:\caddy\logs\emby.log
   }
   reverse_proxy http://127.0.0.1:8096 {
      header_up Host {upstream_hostport}
   }
}

Then I tried accessing dingdonghonk.ddns.net again a few times on the same machine. That didn’t seem to register any log entries at all.

I tried accessing it from outside my home network and got a log entry:

{"level":"info","ts":1737173103.2932813,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"198.255.243.29","remote_port":"52263","client_ip":"198.255.243.29","proto":"HTTP/1.1","method":"GET","host":"dingdonghonk.ddns.net","uri":"/","headers":{"Accept-Language":["en-US,en;q=0.9"],"Connection":["keep-alive"],"Dnt":["1"],"Upgrade-Insecure-Requests":["1"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.0.0"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7"],"Accept-Encoding":["gzip, deflate"]}},"bytes_read":0,"user_id":"","duration":0.0007369,"size":0,"status":308,"resp_headers":{"Server":["Caddy"],"Connection":["close"],"Location":["https://dingdonghonk.ddns.net/"],"Content-Type":[]}}

That attempt also hit a “took to long to respond” browser error, and nothing loaded.

All I can think of that would explain this behavior is a problem with the firewall on the Caddy server, but the ports are all configured correctly. I’ll keep poking in there to see if I can find something stupid I missed.

In the meantime, if you have any more thoughts or ideas, they are greatly greatly appreciated!

dingdongyo · January 18, 2025, 4:34am

It occurred to me that I hadn’t tried connecting with the firewall off since you helped me get Caddy actually running again. I just temporarily shut it off and retried from outside the network, and the browser error changed from “took too long to connect” to “connection refused.”

I also temporarily disabled Avira antivirus, no change.

Turned them both back on, now getting “took too long to connect” again.

None of those connection attempts added any entries to the emby.log file.

dingdongyo · January 19, 2025, 5:58am

I removed, reinstalled, and reconfigured Emby Server just to rule it out. Still behaving the same.

Tried a few other un-noteable tweaks to the CaddyFile with no success.

I have no idea what troubleshooting to do next. Trying to summarize so it’s less annoying to read through:

*Goal: I want to use Caddy as a reverse proxy for my Emby server. Caddy and Emby are on the same Windows 11 machine. I had this setup working for years, but lost much of the config after upgrading to a larger OS drive and needing to reinstall Windows. I’m now trying to get it functional again, but putting all the old config files back did not work.

I can still successfully authenticate to the server using an SSH key from outside my home network. I’m also connecting using a dynamic DNS URL from No-ip. This would suggest that:
– as long as the proper port is open, traffic can reach the server.
–The No-ip dynamic DNS setup is working
Emby server is running and accessible using the HTTP port on the Caddy server
In a temporary test, I mapped Emby’s insecure HTTP port from external to internal, and it worked. (i.e. I could get Emby to load from outside the home network by going to http://dingdonghonk.ddns.net:8096). More confirmation that the routing is all working.
Disabling antivirus doesn’t change anything.
I can’t load Emby via the HTTPS, port even on the server itself. This results in “connection refused.” If I try to access it from outside the LAN via my No-ip URL as intended, the error is “took too long to respond.” However, if I turn Windows Firewall off in the server, the error from outside the network is “connection refused.”
The above behavior occurs whether or not Caddy is running. Caddy seems to be able to start successfully, but it’s not making any noticeable difference.
I set up basic logging in the CaddyFile, but it’s not really telling me anything. My own connection attempts aren’t logging any new entries. I’m just seeing entries from IPs I don’t recognize from different continents. Latest example:

2025/01/19 05:17:28.142 ←[34mINFO←[0m   http.log.access handled request {"request": {"remote_ip": "148.113.210.254", "remote_port": "42800", "client_ip": "148.113.210.254", "proto": "HTTP/1.1", "method": "GET", "host": "71.181.79.164", "uri": "/", "headers": {"User-Agent": ["Mozilla/5.0 (compatible; ModatScanner/1.0; +https://modat.io/)"], "Accept": ["*/*"], "Accept-Encoding": ["gzip"]}}, "bytes_read": 0, "user_id": "", "duration": 0, "size": 0, "status": 308, "resp_headers": {"Connection": ["close"], "Location": ["https://71.181.79.164/"], "Content-Type": [], "Server": ["Caddy"]}}
2025/01/19 05:23:02.232 ←[34mINFO←[0m   http.log.access handled request {"request": {"remote_ip": "92.255.57.58", "remote_port": "47462", "client_ip": "92.255.57.58", "proto": "HTTP/1.1", "method": "GET", "host": "71.181.79.164:80", "uri": "/console/", "headers": {"User-Agent": ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"], "Accept-Encoding": ["gzip"], "Connection": ["close"]}}, "bytes_read": 0, "user_id": "", "duration": 0, "size": 0, "status": 308, "resp_headers": {"Server": ["Caddy"], "Connection": ["close"], "Location": ["https://71.181.79.164/console/"], "Content-Type": []}}
2025/01/19 05:24:22.527 ←[34mINFO←[0m   http.log.access handled request {"request": {"remote_ip": "92.255.57.58", "remote_port": "42918", "client_ip": "92.255.57.58", "proto": "HTTP/1.1", "method": "GET", "host": "71.181.79.164:80", "uri": "/_ignition/execute-solution", "headers": {"Content-Type": ["application/json"], "Accept-Encoding": ["gzip"], "Connection": ["close"], "User-Agent": ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"]}}, "bytes_read": 0, "user_id": "", "duration": 0, "size": 0, "status": 308, "resp_headers": {"Server": ["Caddy"], "Connection": ["close"], "Location": ["https://71.181.79.164/_ignition/execute-solution"], "Content-Type": []}}
2025/01/19 05:29:31.200 ←[34mINFO←[0m   http.log.access handled request {"request": {"remote_ip": "146.19.24.18", "remote_port": "60912", "client_ip": "146.19.24.18", "proto": "HTTP/1.1", "method": "GET", "host": "71.181.79.164:80", "uri": "/", "headers": {}}, "bytes_read": 0, "user_id": "", "duration": 0, "size": 0, "status": 308, "resp_headers": {"Content-Type": [], "Server": ["Caddy"], "Connection": ["close"], "Location": ["https://71.181.79.164/"]}}
2025/01/19 05:32:12.230 ←[34mINFO←[0m   http.log.access handled request {"request": {"remote_ip": "92.255.57.58", "remote_port": "49274", "client_ip": "92.255.57.58", "proto": "HTTP/1.1", "method": "GET", "host": "71.181.79.164:80", "uri": "/", "headers": {"User-Agent": ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"], "Content-Type": ["application/json"], "Accept-Encoding": ["gzip"], "Connection": ["close"]}}, "bytes_read": 0, "user_id": "", "duration": 0, "size": 0, "status": 308, "resp_headers": {"Server": ["Caddy"], "Connection": ["close"], "Location": ["https://71.181.79.164/"], "Content-Type": []}}
2025/01/19 05:37:11.361 ←[34mINFO←[0m   http.log.access handled request {"request": {"remote_ip": "5.181.190.248", "remote_port": "36092", "client_ip": "5.181.190.248", "proto": "HTTP/1.1", "method": "GET", "host": "71.181.79.164:80", "uri": "/", "headers": {}}, "bytes_read": 0, "user_id": "", "duration": 0, "size": 0, "status": 308, "resp_headers": {"Server": ["Caddy"], "Connection": ["close"], "Location": ["https://71.181.79.164/"], "Content-Type": []}}
2025/01/19 05:38:11.441 ←[34mINFO←[0m   http.log.access handled request {"request": {"remote_ip": "92.255.57.58", "remote_port": "38410", "client_ip": "92.255.57.58", "proto": "HTTP/1.1", "method": "GET", "host": "71.181.79.164:80", "uri": "/", "headers": {"User-Agent": ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"], "Accept-Encoding": ["gzip"], "Connection": ["close"]}}, "bytes_read": 0, "user_id": "", "duration": 0, "size": 0, "status": 308, "resp_headers": {"Server": ["Caddy"], "Connection": ["close"], "Location": ["https://71.181.79.164/"], "Content-Type": []}}

I’ve had some excellent help here which I’m very grateful for, but I’m still not working and wasting hours spinning my wheels. I could really use some fresh ideas.