Cannot disable auto-SSL and other problems (initial install)

1. Caddy version (caddy version):

v2.4.3

2. How I run Caddy:

caddy runs as a service (autostart-ed)

a. System environment:

No Docker… Just plain vanila DietPi v7.3.2 (a lightweight flavor of Debian)

b. Command:

"service caddy status" confirms it is running.

c. Service/unit/compose file:

Not using Docker , not using Kubernetes

d. My complete Caddyfile or JSON config:

{
	auto_https off
}
:80 {
	root * /var/www/html
	file_server
}

3. The problem I’m having:

Using curl -v http://x.x.x.x:9992  gives.... 
* Expire in 0 ms for 6 (transfer 0x3a98b0)
*   Trying  x.x.x.x...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x3a98b0)
* Connected to x.x.x.x (x.x.x.x) port 9992 (#0)
> GET / HTTP/1.1
> Host: x.x.x.x:9992
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location: https:// x.x.x.x/
< Server: Caddy
< Date: Sun, 18 Jul 2021 09:04:38 GMT
< Content-Length: 0
< 
* Closing connection 0

I cannot make it stop using https .
So I am TRYING to disable https but it always seems to use it. The reason I am trying to disable it - and also likely the cause of my problems - is this… My external link only allows me incoming on ports above 5000. So I redirect 9991 → 443 and 9992 → 80 in my router before sending to the caddy server. It means the caddy server uses standard ports of 80 and 443. With no config I successfully get the “Caddy Works!” welcome page when I go to http://x.x.x.x:9992 … I just want to get the http (not “s” ) working , but I cannot make it stop using https.

4. Error messages and/or full log output:

I do not see any error messages.

5. What I already tried:

I have tried with an actual named domain also by just using the address… also using “auto_https off” as shown above.

6. Links to relevant resources:

Use backticks (```) for code blocks (it’s the key to the left of 1, above tab, on US keyboard layouts anyway), not dots (…)

This question is asking for your systemd service file – the question is there to make sure you didn’t deviate from the one that ships with Caddy.

Are you sure you’re hitting the right instance of Caddy? Are you sure you reloaded Caddy after changing your Caddyfile? Your logs for Caddy will show you when you last reloaded Caddy. You can run journalctl -u caddy --no-pager | less to see them.

1 Like

thanks for the reply:) I have edited my post to change to backticks… sorry… am not used to this system.

I did not deviate from the one that ships with caddy. I just installed it and did nothing more… I was amazed that the “Caddy Works!” page came up so quickly… The problem now is I can get no other page to show - not with http or https . I just get nothing else to show…

Um… you think it may be possible that more than one instance of caddy is running ? hmmm… I did not even think of that! I do know that after any change to the CaddyFile I always did a service caddy restart … and some times, if there was a typo, it would show errors until I fixed that typo. That gave me some reassurance than the caddyfile I was changing was in fact being used… But I am open to any ideas , as I cannot get it to work at this point in time…

I tried journalctl -u caddy --no-pager | less and it gave like 1000 lines… I am just trying to find some relevant items in there… I will post something from that log shortly. Thanks again for your assistance

You can hit Shift+G to jump to the bottom then scroll back up from there.

After making any config changes, you need to reload the config with sudo systemctl reload caddy. Restarting has a similar effect but incurs downtime because it has to shutdown Caddy completely first. It’s preferred to reload the config if you only changed your Caddyfile.

It should not be possible for more than one instance to be running if you only used service commands, since the service ensures there’s only one instance running. If you did run caddy run or caddy start yourself, then that might be the case.

1 Like

I have a wild theory - that may be completely stupid - but I will ask anyway… As that server is exposed to the internet I locked down the SSH on it like this - no access except by public-certs , passwords are disabled… I was thinking that maybe that restriction is preventing any SSL (including https) into the machine (e.g. not from a known-host )… Please tell me that is unrelated… and I will go back to looking at the caddy logs :thinking: … I think (hope) those restrictions only apply to access on port 22 and therefore could not be to blame (but other people have much more knowledge about this than me. ) .

:scream: the log file has lots of error messages about: solving challenges: [mydomain.me] authorization took too long in there… but HTTPS should actually be OFF per my settings. That seems to prove a few things (1) https is not “off” and (2) https does not work on my system (yet) (3)and, I still cannot cannot tell if http is working, because it always redirects to https which I know is not working.

here’s the startup log:

Jul 18 07:06:42 batopi systemd[1]: Starting Caddy...
Jul 18 07:06:42 batopi caddy[2376]: caddy.HomeDir=/var/lib/caddy
Jul 18 07:06:42 batopi caddy[2376]: caddy.AppDataDir=/var/lib/caddy/.local/share/caddy
Jul 18 07:06:42 batopi caddy[2376]: caddy.AppConfigDir=/var/lib/caddy/.config/caddy
Jul 18 07:06:42 batopi caddy[2376]: caddy.ConfigAutosavePath=/var/lib/caddy/.config/caddy/autosave.json
Jul 18 07:06:42 batopi caddy[2376]: caddy.Version=v2.4.3 h1:Y1FaV2N4WO3rBqxSYA8UZsZTQdN+PwcoOcAiZTM8C0I=
Jul 18 07:06:42 batopi caddy[2376]: runtime.GOOS=linux
Jul 18 07:06:42 batopi caddy[2376]: runtime.GOARCH=arm64
Jul 18 07:06:42 batopi caddy[2376]: runtime.Compiler=gc
Jul 18 07:06:42 batopi caddy[2376]: runtime.NumCPU=6
Jul 18 07:06:42 batopi caddy[2376]: runtime.GOMAXPROCS=6
Jul 18 07:06:42 batopi caddy[2376]: runtime.Version=go1.16.5
Jul 18 07:06:42 batopi caddy[2376]: os.Getwd=/
Jul 18 07:06:42 batopi caddy[2376]: LANG=C.UTF-8
Jul 18 07:06:42 batopi caddy[2376]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Jul 18 07:06:42 batopi caddy[2376]: NOTIFY_SOCKET=/run/systemd/notify
Jul 18 07:06:42 batopi caddy[2376]: HOME=/var/lib/caddy
Jul 18 07:06:42 batopi caddy[2376]: LOGNAME=caddy
Jul 18 07:06:42 batopi caddy[2376]: USER=caddy
Jul 18 07:06:42 batopi caddy[2376]: INVOCATION_ID=5d8cf6bddb85497bacdcf11c02420a15
Jul 18 07:06:42 batopi caddy[2376]: JOURNAL_STREAM=8:28189
Jul 18 07:06:42 batopi caddy[2376]: {"level":"info","ts":1626606402.215514,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
Jul 18 07:06:42 batopi caddy[2376]: {"level":"info","ts":1626606402.2185223,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
Jul 18 07:06:42 batopi caddy[2376]: {"level":"info","ts":1626606402.2188501,"logger":"http","msg":"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}
Jul 18 07:06:42 batopi caddy[2376]: {"level":"info","ts":1626606402.2188885,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
Jul 18 07:06:42 batopi caddy[2376]: {"level":"info","ts":1626606402.2189515,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x40003f1490"}
Jul 18 07:06:42 batopi caddy[2376]: {"level":"info","ts":1626606402.2194757,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/var/lib/caddy/.local/share/caddy"}
Jul 18 07:06:42 batopi caddy[2376]: {"level":"info","ts":1626606402.2195323,"logger":"tls","msg":"finished cleaning storage units"}
Jul 18 07:06:42 batopi caddy[2376]: {"level":"info","ts":1626606402.2196467,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["emupay.me"]}
Jul 18 07:06:42 batopi caddy[2376]: {"level":"info","ts":1626606402.220256,"msg":"autosaved config (load with --resume flag)","file":"/var/lib/caddy/.config/caddy/autosave.json"}
Jul 18 07:06:42 batopi caddy[2376]: {"level":"info","ts":1626606402.2214699,"logger":"tls.obtain","msg":"acquiring lock","identifier":"emupay.me"}
Jul 18 07:06:42 batopi caddy[2376]: {"level":"info","ts":1626606402.220584,"msg":"serving initial configuration"}
Jul 18 07:06:42 batopi systemd[1]: Started Caddy.

here’s the errors about solving challenges: taking too long…

Jul 18 09:19:51 batopi caddy[2376]: {"level":"info","ts":1626614391.6940823,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"emupay.me","challenge_type":"tls-alpn-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}
Jul 18 09:19:53 batopi caddy[2376]: {"level":"error","ts":1626614393.2774553,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"emupay.me","challenge_type":"tls-alpn-01","status_code":403,"problem_type":"urn:ietf:params:acme:error:unauthorized","error":"Cannot negotiate ALPN protocol \"acme-tls/1\" for tls-alpn-01 challenge"}
Jul 18 09:19:53 batopi caddy[2376]: {"level":"error","ts":1626614393.2776291,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"emupay.me","error":"authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - Cannot negotiate ALPN protocol \"acme-tls/1\" for tls-alpn-01 challenge","order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/20381613/105158168","attempt":1,"max_attempts":3}
Jul 18 09:19:55 batopi caddy[2376]: {"level":"info","ts":1626614395.3374019,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"emupay.me","challenge_type":"http-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}
Jul 18 09:19:57 batopi caddy[2376]: {"level":"error","ts":1626614397.1676013,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"emupay.me","challenge_type":"http-01","status_code":403,"problem_type":"urn:ietf:params:acme:error:unauthorized","error":"Invalid response from http://emupay.me/.well-known/acme-challenge/u6TvfZlJMlD4FskTyqzVSQcIBIdVtVCUlM-M6ePf0oE [194.124.229.155]: \"<html><head><title>407 Proxy Authentication Required</title></head>\\r\\n<body><h2>407 Proxy Authentication Required</h2><h3>Access \""}
Jul 18 09:19:57 batopi caddy[2376]: {"level":"error","ts":1626614397.1680732,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"emupay.me","error":"authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - Invalid response from http://emupay.me/.well-known/acme-challenge/u6TvfZlJMlD4FskTyqzVSQcIBIdVtVCUlM-M6ePf0oE [194.124.229.155]: \"<html><head><title>407 Proxy Authentication Required</title></head>\\r\\n<body><h2>407 Proxy Authentication Required</h2><h3>Access \"","order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/20381613/105158204","attempt":2,"max_attempts":3}
Jul 18 09:19:59 batopi caddy[2376]: {"level":"error","ts":1626614399.5733008,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"emupay.me","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[emupay.me] solving challenges: emupay.me: no solvers available for remaining challenges (configured=[http-01 tls-alpn-01] offered=[http-01 dns-01 tls-alpn-01] remaining=[dns-01]) (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/20381613/105158227) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"}
Jul 18 09:19:59 batopi caddy[2376]: {"level":"warn","ts":1626614399.5743074,"logger":"tls.issuance.zerossl","msg":"missing email address for ZeroSSL; it is strongly recommended to set one for next time"}
Jul 18 09:20:02 batopi caddy[2376]: {"level":"info","ts":1626614402.2213292,"logger":"tls.issuance.zerossl","msg":"generated EAB credentials","key_id":"moefLIChxxtUM1J5FPkkcg"}
Jul 18 09:20:06 batopi caddy[2376]: {"level":"info","ts":1626614406.5493288,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"emupay.me","challenge_type":"http-01","ca":"https://acme.zerossl.com/v2/DV90"}
Jul 18 09:25:08 batopi caddy[2376]: {"level":"error","ts":1626614708.1273289,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"emupay.me","issuer":"acme.zerossl.com-v2-DV90","error":"[emupay.me] solving challenges: [emupay.me] authorization took too long (order=https://acme.zerossl.com/v2/DV90/order/NjKIfJD520974tXJuDpqCw) (ca=https://acme.zerossl.com/v2/DV90)"}
Jul 18 09:25:08 batopi caddy[2376]: {"level":"error","ts":1626614708.1274927,"logger":"tls.obtain","msg":"will retry","error":"[emupay.me] Obtain: [emupay.me] solving challenges: [emupay.me] authorization took too long (order=https://acme.zerossl.com/v2/DV90/order/NjKIfJD520974tXJuDpqCw) (ca=https://acme.zerossl.com/v2/DV90)","attempt":9,"retrying_in":1800,"elapsed":8305.887880503,"max_duration":2592000}

Are you editing the wrong Caddyfile? The default location is /etc/caddy/Caddyfile as you can see in your logs. Where’s emupay.me coming from?

SSH has nothing to do with TLS certificates (SSL is the deprecated/old term for it btw, it’s now “TLS”)

2 Likes

There is only one Caddyfile on the entire server. It is in /etc/caddy it is the only one that I have ever editted… I mentioned in other things I have tried that I have tried to add domain name in the Caddyfile.

Lets back back to the very basics here. When I simply try to curl to localhost with Caddyfile like this:

localhost {
        respond "Hello localhost"
}

I get all this , including 308 Permanent Redirect ???

[Sun Jul 18] root@batopi: /etc/caddy$ curl -v http://localhost/
* Expire in 0 ms for 6 (transfer 0xaaaac61c0f30)
* Expire in 1 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 1 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 1 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 2 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 2 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 2 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 2 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
* Expire in 0 ms for 1 (transfer 0xaaaac61c0f30)
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0xaaaac61c0f30)
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location: https://localhost/
< Server: Caddy
< Date: Sun, 18 Jul 2021 16:32:33 GMT
< Content-Length: 0
<
* Closing connection 0

When I remove the auto_https off and try the curl to https://localhost I get this:

[Sun Jul 18] root@batopi: ~$ curl -v https://localhost/
* Expire in 0 ms for 6 (transfer 0xaaaaebd7ef30)
* Expire in 1 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 1 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 1 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 2 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 2 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 2 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 2 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
* Expire in 0 ms for 1 (transfer 0xaaaaebd7ef30)
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0xaaaaebd7ef30)
* Connected to localhost (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* 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 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Caddy is HTTPS by default. The Automatic HTTPS features have to do with setting up automated certificate management and HTTP->HTTPS redirects.

A site block of simply localhost will enable Caddy’s internal CA, which issues certificates signed by the root CA managed by Caddy; those are not publicly trusted certificates.

Everything I’m seeing in your recent post shows that it’s working as intended.

Change your config to this, to only handle HTTP requests:

http:// {
	respond "Hello world"
}

or

:80 {
	respond "Hello world"
}
1 Like
  1. Can you explain why localhost in Caddyfile gives a 308 Permanent Redirect error, yet http:// works ? I mean I was just following the caddyserver.com documentation… which says put localhost in the Caddyfile and then can used curl https://localhost . I only gave the curl command localhost and it resolved to the http not https (seems not using its default)
localhost {
	respond "Hello localhost" 
}
http:// {
        respond "hello http:// "
}
https:// {
        respond "hello https://" 
}
  1. The https still does not work… the curl still gives same messages s above. Am doing that curl from the actual server, from the /etc/caddy directory… and the messages (above) indicate that no local certificates could be issued. I mean ( with https enabled) curl localhost gives errors and also curl https://localhost gives errors. Are you saying localhost in the Caddyfile will only resolve to https (which is not working on this system) ?

Redirects are not errors, those are completely expected responses telling the browser to try again at a different location (see the Location header in the response).

Caddy’s Automatic HTTPS sets up HTTP->HTTPS redirects, so requests to http://localhost will be redirected to https://localhost.

You can tell curl to follow redirects with the -L flag:

curl -vL http://localhost

Browsers follow redirects by default (up to a limited amount of times to avoid infinite loops).

2 Likes

ok - thank you - so that explains the redirect ( i.e. the 308 is Caddy redirecting http → https ) but I am still getting so many errors about HTTPS ?? Like - “no CAfile - " “unable to get local issuer certificate” , " unknown CA (560)” , And , curious, why should it still redirect to https even when using auto_https off as a global setting ?

This is because curl doesn’t trust the certificates Caddy issued, because they’re issued by Caddy’s internal CA like I said earlier, which are not publicly trusted.

TLS involves trust. Clients need to trust that the server that encrypted the request used a set of keys that are validated/authorized to do so.

Systems ship a list of certificate authority roots which are trusted (as in the companies/entities issuing them have been vetted to be doing it properly, and securely; such as Let’s Encrypt for example, and many others, majority of which are non-free).

Caddy can ask Let’s Encrypt to issue certificates for your domains, but only if your server is publicly accessible (public DNS, and with ports 80/443 reachable).

For names like localhost or IP addresses, Caddy won’t attempt to get a publicly trusted certificate, because localhost can only ever resolve to 127.0.0.1, i.e. “this same machine”. So to deal with that, Caddy sets up it’s own internal CA to issue certificates with, but those are not publicly trusted.

It shouldn’t, and I haven’t seen any evidence that it does. Make absolutely sure that you’re running Caddy with the config you think you are, that it has properly reloaded after your changes by looking at the logs. You can also run caddy adapt --config /etc/caddy/Caddyfile to make sure that your Caddyfile properly adapts to a valid JSON config.

ok - my head is spinning - so the bottom line is … I will never be able to use Caddy to serve a page to my domain - either HTTP or HTTPS - because ( as I mentioned in first post on this thread) , my server has 80 and 443 available outbound , but inbound only ports above 5000 are allowed (though can be, and are being, redirected to 443 and 80 in router before getting to the server) , :sob:

Seems the “Caddy Works!” welcome page is a mirage

You can serve HTTP sites over any port, but you need to tell Caddy to listen on that port.

:5000 {
	respond "Hello"
}
curl -v http://example.com:5000

But yes, if your ISP is preventing you from using ports 80 and 443, then there’s not much you can do.

The alternative is to host your server on a VPS (virtual private server) instead of at home.

The higher port numbers e.g. 5000 are being redirected to 80 and 443.
(Inbound) Port 9991 is redirected to 443.
(Inbound) Port 9992 is redirected to 80.

Obovuosly their restriction is Inbound only… redirectiions work for everything else… i can use port 22 (ssh) port (9 WOL ) port 3389 (RDP) inbound … simply by portforwarding in the router… But Caddy cannot work with that it seems. . The “Caddy Works!” page gave me premature hope…

When it gets to the Caddy Server - Caddy picks it up on ports 443 and port 80. …

I’m sorry, I’ve been trying to follow this thread, but there are so many things wrong that it’s hard to make any sense of it. Let’s take this back to square 1.

I’m glad you’re not using containers; that helps simplify things a bit. As far as I can tell according to my experiments, Caddy does work properly for your given configs. This config:

:80 {
	respond "Yahaha! You found me!"
}

outputs this:

$ go run -exec ./setcap.sh main.go run
2021/07/18 18:07:15.432 INFO    using adjacent Caddyfile
2021/07/18 18:07:15.434 INFO    admin   admin endpoint started  {"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["localhost:2019", "[::1]:2019", "127.0.0.1:2019"]}
2021/07/18 18:07:15.434 INFO    http    server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server {"server_name": "srv0", "http_port": 80}
2021/07/18 18:07:15.434 INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc000450690"}
2021/07/18 18:07:15.434 DEBUG   http    starting server loop    {"address": "[::]:80", "http3": false, "tls": false}
2021/07/18 18:07:15.434 INFO    tls     cleaning storage unit   {"description": "FileStorage:/home/matt/.local/share/caddy"}
2021/07/18 18:07:15.434 INFO    autosaved config (load with --resume flag)      {"file": "/home/matt/.config/caddy/autosave.json"}
2021/07/18 18:07:15.434 INFO    serving initial configuration
2021/07/18 18:07:15.465 INFO    tls     finished cleaning storage units

and it behaves like this:

$ curl -v "http://127.0.0.1"
*   Trying 127.0.0.1:80...
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.74.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: Caddy
< Date: Sun, 18 Jul 2021 18:07:24 GMT
< Content-Length: 21
< 
* Connection #0 to host 127.0.0.1 left intact
Yahaha! You found me!

But you’re reporting that it’s issuing a redirect. Ok, I believe you’re seeing a redirect. But I’m not. So how can I reproduce the behavior you’re seeing?

1 Like

See here:

For public domain names:

These are common requirements for any basic production website, not just Caddy. The main difference is to set your DNS records properly before running Caddy so it can provision certificates.

  • If your domain’s A/AAAA records point to your server,
  • ports 80 and 443 are open externally,
  • Caddy can bind to those ports (or those ports are forwarded to Caddy),
  • your data directory is writeable and persistent,
  • and your domain name appears somewhere relevant in the config,