为什么个人项目我更推荐使用Caddy?

为什么个人项目我更推荐使用Caddy?
- 前言
- 什么是Caddy?
- Caddy是够用且省心的
- 简单的配置
- 自动化 https
- 结尾
- 参考链接

前言

最近我把自己一些项目里面的 nginx 换成了 caddy，运转相当良好，比较开心，所以写了这篇文章，也推荐给大家使用。

什么是`Caddy`?

Caddy 和 nginx 一样，也是一个非常棒的跨平台 web server，它是用 go 写的，而 nginx 则是 c。核心功能上比较类似。

谁更牛逼？很明显是 nginx，nginx功能多，性能强，而且还有 OpenResty 这种神级项目(国人章亦春大佬写的)，这个第一，绝对是当之无愧的。

那么nginx这么强，为啥要换成Caddy呢？

`Caddy`是够用且省心的

对我们个人项目而言，很多时候往往只需要用到 web server 中的一小部分功能，比如重要的反向代理，https，或者设置额外的 Header，又或者前端那种 history 路由，设置的 try_files 策略等等…

这些功能，往往都已经内置在各个成熟的 web server 内部功能中，我们只需要添加对应的配置，就能够开启并进行使用。

另外相比 nginx，虽然 Caddy 性能差一点(对应有benchmark)，但是够用。更重要的是，Caddy 使用起来足够的省心。这个特点主要体现在，足够简单的配置文件和校验和自动化的 https.

简单的配置

是的，Caddy 的配置文件: Caddyfile 非常的简单且语义化, 它由一个一个可嵌套的块 (block) 组成:

Caddy 内部也提供了格式化和校验配置文件合法性的cli命令。而且它还内置了一套 admin 的 restful api 用来动态的改变配置。

而且它为了适配各种配置格式，还维护了不少的配置文件适配器，比如nginx-adapter,caddy-mysql-adapter
等等。

不过笔者尝试过直接用 nginx.conf 直接起 Caddy，效果一般，还是推荐用官方最原生的 Caddyfile 以避免转化过程中出现的奇奇怪怪的问题。

比如你从 nginx 迁移过来：

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_pass http://localhost:port;
    }

在 Caddyfile 里就可以这样写:

example.com {
    # reverse_proxy 和 localhost:port 中间有个 [<matcher>] 
    # 这里不写代表 all，和 glob 里的 * 同理
    # 你也可以显式配置成自己想要的，比如 /api/*
    reverse_proxy localhost:port
}

为什么没有设置 Host，X-Forwarded-For？因为 Caddy 默认自动设置好了这些 Header。而且这个配置同时也设置好了 websocket，而 nginx 还要去配置一些协议升级到http 1.1的配置块。

自动化 `https`

这个可能是 Caddy 的一大特色之一了，正如官方宣传的那样：

Caddy is the first and only web server to use HTTPS automatically and by default.

然而，实际上早就有很多自动化的https项目了，比如nginx + acme.sh/ certbot 也能做到啊。

是的，都可以做到，只不过 Caddy 是直接内置了 ACME protocol server 处理方法，默认开启，而且配置也极其简单。

比如nginx+acme.sh,我们需要配置 nginx 配置的 ssl目录，然后执行 acme.sh 成功之后，还要 systemctl reload nginx.service 即:

acme.sh --install-cert -d mydomain.com \
--cert-file /etc/nginx/certs/mydomain.com/cert \
--key-file /etc/nginx/certs/mydomain.com/key \
--fullchain-file /etc/nginx/certs/mydomain.com/fullchain \
--reloadcmd "systemctl reload nginx.service"

假如 nginx 运行在一个容器里，那就需要给所在容器打上 label，然后设置许多的环境变量。假如你使用 neilpang/acme.sh 镜像，也需要很多的额外操作，容易卡壳，这对我们开发者来说，显然大大提升了错误发生的可能，开发体验不够友好。

而 Caddy 呢，直接帮你把所有站点的 https 给配置好了，同时连 80 跳 443 的策略也弄好了（可关闭此策略）。省去了调试配置的时间，是为省心。

值得注意的是，对于本地的 hostname 和 ip地址，Caddy 的自动 https 策略，是直接生成自签名 ssl 证书，它会向你要求一定的权限，需要你进行授权。

而对于可被DNS解析的域名,它就会去请求免费证书了，如下图所示：