懒是第一生产力，这话是非常有道理的。 Nginx作为老牌HTTP服务器，稳定快速，值得信赖，庞大的社区和用户使得任何问题，只要搜索一下就能得到解决办法。 我自从使用VPS以来，就一直选择Nginx作为HTTP服务器。 直到我想在全站开启HTTPS的时候……

说实话，Nginx要完成这个任务也很容易，网上现成的教程一大堆。 但说到底，都没有Caddy方便，这种开箱即用无需维护的免费HTTPS解决方案，着实吸引我这种很少维护服务器的用户。 还有一点小加分项，就是Caddy使用Go写的，而我现在正对Go语言有着浓厚的兴趣，什么问题都想着能不能用Go去实现（老实说，很多问题用Go都不是最优解）。 令人兴奋的是，Caddy的配置文件要比Nginx容易上手的多。 总体上，我在迁移的过程中，全程参考着官方文档（链接），就能完成90%以上的任务，剩下一些叽里旮旯的小问题，搜索一下都解决了。

由于Caddy v1和v2的差别有点多，本文所说的内容都是基于Caddy 2。

对于服务器的配置，官方提供了两种方案，一是基于CaddyFile的配置文件方案，另一种是基于JSON的方案。 虽说基于JSON的方案所提供的选项是最完整的，但是个人认为，JSON配置需要基于API去更新，更多适用于有动态更新需求或者有复杂配置需求的用户。 而像我这种配置完基本不会修改的，同时配置本身并不复杂的人来说，CaddyFile反而是更优的选择，因为它更容易阅读。 更激进地，我直接就把admin关了，省的动态配置。

{
    admin   off
}

虽然CaddyFile设计就是易于人阅读，但是刚上手还是会云里雾里，不知如何下手。 要理解CaddyFile，我觉得最有用的就是下面这张图（出处）

建议把这张图置顶，迷茫的时候就看一下，这是我迁移过程中最大的感受，剩下的过程基本就是照着文档做就行，一路砍瓜切菜。

值得注意的是配置的作用域，比如下面这个配置

1
2
3
4
5
6
7
8
9

server.example.com {
    handle_errors {
        rewrite * /static/404.html
        file_server
    }
    file_server * {
        root /home/blog
    }
}

这里容易搞错的是，第3行的/static/404.html，一般会认为是在第7行的/home/blog下。 但实际上并不是，因为第4行的file_server是独立于第7行的，所以第3行的路径是一个绝对路径。 如果是html文件是在/home/blog下的话，则需要写成/home/blog/static/404.html。 这里搞错的话，就会导致遇到404之类的错误的时候，直接显示空白页面。

最后贴一个实用片段，设置静态文件的缓存时间

1
2
3
4

@static {
    path_regexp \.(ico|css|js|gif|jpg|jpeg|png|svg|woff)$
}
header @static Cache-Control max-age=5184000