caddy开机自启配置

简介

Caddy 是用 Go 编写的开源 Web 服务器，支持 HTTP/1.1、HTTP/2、HTTP/3，默认自动 HTTPS，配置文件格式简洁。直接用命令行界面运行 Caddy 时，进程会随终端会话结束而退出，服务器重启后站点也随之消失。本页整理的 caddy 开机自启配置，围绕 systemd 服务管理器展开：让 Caddy 在系统重启后自动启动，并把 stdout/stderr 输出交给日志系统捕获，同时给出 Docker Compose 的容器自启做法。适合自建博客、反向代理、多站点虚拟主机以及生产环境的运维者，核心优势是启动可预期、日志可追溯、重启后无需人工干预。

核心功能

• 执行 systemctl enable caddy，通过创建符号链接把 caddy.service 文件加入开机自启动的服务列表。
• systemd 在启动阶段自动加载并启动这些已启用的服务，无需人工逐次拉起进程。
• 服务管理器会捕获 Caddy 的 stdout/stderr 日志，避免命令行窗口关闭后输出丢失。
• 用 journalctl --boot -u caddy.service 查看本次启动以来该服务产生的日志。
• 用 sudo systemctl start caddy.service 手动启动服务，用于验证配置是否能正常加载。
• Docker 部署可用 Docker Compose 编写 docker-compose.yml，由容器运行时负责重启后拉起。
• Caddy 还提供管理配置的接口，可配合自动化脚本实现配置管理与集成发布。

使用场景

• 自建博客或个人站点部署在云服务器上，希望机器重启后站点自动恢复访问。
• 作为反向代理托管多个虚拟主机与站点，需要服务常驻并持续对外提供 HTTPS。
• 生产环境要求进程状态可查询、日志可用 journalctl 统一检索与排查。
• 用 Docker Compose 跑 Caddy 容器，由编排文件声明启动顺序与自动运行策略。
• 通过 GitHub Actions 配合 self-hosted runner 部署 Caddyfile，部署完成后服务需保持运行。
• 从 Nginx 迁移过来的用户，希望减少手工证书与服务守护方面的维护工作。

安装与获取步骤

1. 准备系统环境：更新系统、安装必要依赖，添加 Caddy 的 GPG 密钥与 APT 软件源（以官方页面为准）。
2. 写好 Caddyfile 配置文件，确认站点域名、监听地址与反向代理目标已按需填写。
3. 执行 sudo systemctl start caddy.service 启动服务，先确认配置能被正常加载。
4. 执行 journalctl --boot -u caddy.service 查看本次启动日志，确认服务输出与报错信息。
5. 执行 systemctl enable caddy，创建符号链接把 caddy.service 加入开机自启列表。
6. 改用容器方式时，创建 docker-compose.yml 并用 Docker Compose 启动，更多细节参见 Docker Hub 上的文档。

与同类方案的区别

Nginx 需要手动申请与续期证书，而 Caddy 默认自动 HTTPS，社区文章常用三行配置替代 Nginx 的手动 SSL 管理；两者在 HTTP/2 支持上能力接近，Caddy 还支持 HTTP/3。守护方式上，命令行直接运行 Caddy 与交给 systemd 托管是两条路线：前者进程随终端退出，后者由服务管理器负责重启后自动启动并集中收集日志。

• 证书管理：Caddy 默认自动处理，Nginx 需自行维护证书文件与续期任务。
• 配置格式：Caddyfile 为简化的人类可读格式，同时保留功能更强的原生 JSON 配置。
• 守护与日志：systemd 托管可捕获 stdout/stderr，Docker Compose 则由容器运行时负责拉起。

注意事项

• enable 与 start 作用不同：前者只把服务加入自启列表，后者才真正拉起进程，两者通常都需要执行。
• caddy.service 单元文件的具体路径与内容以官方页面为准，不同发行版的写法可能不同。
• 若仍然直接用命令行界面运行 Caddy，终端关闭后进程会退出，重启后站点不会自动恢复。
• 排查启动失败时优先看 journalctl --boot -u caddy.service 的输出，报错通常会打印在其中。
• 执行 systemctl 相关命令需要相应权限，命令行中一般以 sudo 前缀运行。
• Docker 方式的配置细节参见 Docker Hub 上的 Compose 文档，本页命令仅作流程参考。