Caddy 2 "Getting Started failed"

Help
1

1. My Caddy version (caddy version):

Caddy 2 (devel) Built with go 1.14.2

2. How I run Caddy:

a. System environment:

Linux Debian Buster

b. Command:

sudo caddy start

c. Service/unit/compose file:

d. My complete Caddyfile or JSON config:

localhost {
	respond "Hello World"
}

3. The problem I’m having:

When trying to connect to the default localhost with curl http://localhost:2019

4. Error messages and/or full log output:

404 page not found

Log

2020/04/19 18:19:47.206	INFO	admin.api	received request	{"method": "GET", "host": "localhost:2019", "uri": "/index.html", "remote_addr": "127.0.0.1:53248", "headers": {"Accept":["*/*"],"User-Agent":["curl/7.64.0"]}}

5. What I already tried:

I have tried to change the Caddyfile to this:

localhost {
    root /var/www
}

There is, of course, an index.html in /var/www

6. Links to relevant resources:

nestat

tcp        0      0 127.0.0.1:2019          0.0.0.0:*               LISTEN      0          59611      5946/caddy          
tcp6       0      0 :::443                  :::*                    LISTEN      0          59259      5946/caddy          
tcp6       0      0 :::80                   :::*                    LISTEN      0          59260      5946/caddy
2

You should try curl http://localhost. Port 2019 is the admin API. Your config specifies localhost which by default will listen on ports 80 and 443 (i.e. http:// and https://)

3

No better. I mean no 404 anymore but curl doesn’t return the expected “Hello World”

4

This is incorrect, you need to do root * /var/www. In Caddy v2, the first argument of most directives is read as a matcher. In this case, since the first argument starts with / then it’s assumed to be a path matcher. Instead, you need to tell the root directive to use * as your matcher instead (i.e. match any request).

If that still doesn’t fix it, please be more specific – give us the full Caddyfile config you used, the command you used to run Caddy, the output of curl -v <url> and the exact commit hash you built from.

5

Ah I think I figured out your problem - when you use localhost as your site label, Caddy enables both HTTP and HTTPS, and adds an HTTP->HTTPS redirect. By default, curl doesn’t follow redirects, so you don’t see the final page. Instead, you can do curl -L http://localhost or curl https://localhost.

6

Indeed

$ curl -i http://localhost/index.html
HTTP/1.1 308 Permanent Redirect
Connection: close
Location: https://localhost/index.html
Server: Caddy
Date: Sun, 19 Apr 2020 18:57:39 GMT
Content-Length: 0


$ cat Caddyfile 
localhost {
	root * /var/www
}

I built following this page: Install — Caddy Documentation

1 Like
7

The Getting Started guide does specifically say to use curl https://localhost so I’ll call this user-error :stuck_out_tongue:

I’ll look into adding a note there that there’s an HTTP->HTTPS redirect.

8

With the “follow redirection” switch:

$ curl -iL http://localhost/index.html
HTTP/1.1 308 Permanent Redirect
Connection: close
Location: https://localhost/index.html
Server: Caddy
Date: Sun, 19 Apr 2020 19:08:11 GMT
Content-Length: 0

HTTP/2 200 
server: Caddy
content-length: 0
date: Sun, 19 Apr 2020 19:08:11 GMT

But still no return from my index.html

9

Ah right - you’re missing file_server

localhost {
    root * /var/www
    file_server
}

All root does it set an internal variable for the location of the site root.

You need to explicitly enable a file server in v2.

1 Like
10

@francislavoie that did it ! Thanks. I will gradually add my directives from caddy v1, one by one, and try to restore my web site. BTW, what are the main advantages of v2 vs v1?

1 Like
11

Caddy v2 is a complete rewrite and redesign from v1 (from scratch, pulling features back in one by one).

Now, Caddy uses JSON as the main configuration language, and provides Caddyfile as a translation layer to JSON. This makes configuration much more flexible.

The design of Caddy v1 had a lot of shortcomings that made it very difficult or impossible to implement new features, and had limited flexibility because of it.

Some more info:

12

Hi again,

I am progressing in my transition from v1 to v2:

  • gzip compression: done
  • php-fpm: done
  • using the import directive to import conf file with directives shared by multiple domains: done

A couple of remarks though:

  • Just for clarity, the useradd and groupadd commands in the Install section should be prefixed with sudo as these commands require root privilege.
  • I am using as this caddy.service file for systemd. Also for clarity reasons, the doc should maybe also mention to make sure that “caddy” user has access to the php-fpm socket otherwise systemd will launch caddy server with no error, but the php files will never be served. Took me some time before I checked syslog where the socket permission error was thrown.
  • could not find the import directive in the v2 directives list, but it works.

To be continued…

13

import is documented here:

Technically it’s not a directive because it’s a special keyword to deal with code reuse. That said, I agree it probably should be in the directives list.

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.