只是多了个上游而已

先用个一两个月再来谈体验

ls /etc/nginx/sites-enabled
如果有就 rm /etc/nginx/sites-enabled/example.com

先删除这个文件，再建链接

被扫无所谓的，用证书登陆就行了

我刚坏了一块 SSD。。。打算整个群晖了

@uptime #53
你看懂我说的东西了么？我和你讨论的东西和 Caddy 本身没有关系，而是 Linux 部署和安全策略的问题，不过看了看你的发帖历史，估计是对牛弹琴，你可能真的是不会用 Linux 的（笑

你现在过了 500 多天知道 sudo 是干啥用了么？要不要我教教你？
ref: https://www.v2ex.com/t/484337
https://wiki.archlinux.org/index.php/sudo

还有 400 天前的 caddy systemd 服务怎么写怎么配懂了么？不会还是用网上找的一键脚本吧？
ref: https://www.v2ex.com/t/522738
https://wiki.archlinux.org/index.php/Systemd

当然，对 Linux 我也不敢说太懂，只能算能折腾起来。对 Linux 的了解可能也只停留在 RH 的文档上。
我从 2010 年学校里学 Linux 的时候用 RHEL 5.5 开始算到现在也只有 10 年，用的时间也不算太长。

不浪费时间了，再发不友善的言论我只能 B 了你了

这里有文档 https://letsencrypt.org/zh-cn/docs/certificate-compatibility/

这里可以测兼容性 https://www.ssllabs.com/ssltest/

你这是来晒域名的？

找个有他的正常维护的软件源，添加之后 apt upgrade

@uptime 最后补充一句，个人环境怎么玩都可以，然而不是每个人用 Linux 都是像学生一样拿来玩的

@uptime 我确实不了解 Caddy。
可从你的发言来看，我觉得你
1. 只用过 Ubuntu 这种默认不开安全策略的发行版，或者起手禁用 SELinux
2. 不知道发行版发行策略的差异
3. 不知道 LTS 代表什么意思
4. 没了解过也不知道什么是 SELinux
5. 没有维护过个人服务器以外的服务器
6. 不会自建软件源
7. 没读过最新的 Caddy 文档
8. 不知道 Caddy 有除 curl 一键脚本以外的安装方式
9. 安装软件喜欢用一键安装脚本
10. 没有在正经企业了解过 Linux 运维和安全策略

如果你是在正经企业工作过的，请分清生产环境和个人环境。

@uptime 拜托了，自己学点东西吧，学学 Linux, 学学包管理怎么用吧。你的发言让我觉得你是个只用过一 Ubuntu，啥都不会的人。我说你是学生是因为我觉得你没在正经企业里工作过，什么都不懂。

给你科普一下，企业里部署的时候是不可能让你用未经审核的脚本和二进制安装的。除了软件源里的东西之外，通常都是需要代码审查后，自己编译源码搭建私有源，最终才能部署。而软件源里的软件都是经过测试和无数个公司审查的可信度极高。尤其是 SUSE 和 RHEL 这样的 Enterprise Linux 软件源的可靠性有公司的担保，拿来直接能用。

至于为什么我不愿意用你说的 curl 一键脚本安装，我是真的外来的被脚本坑过。比如说脚本里删除东西多打了一个空格，比如 rm -rf / tmp/foo/bar/* 这些事情不是没有发生过。此后我跑外来脚本都得自己读一遍才敢跑。
当然，你可以说你相信 Caddy 团队不会出这种问题，可从我的角度看他家的文档都写不清楚，版本管理混乱。文档里给的 Docker, Digitalocean, Fedora COPR 源里都是 beta 版，稳定版只有 curl 脚本安装。Fedora 和 EPEL 源有 Caddy 1 也没更新到文档的安装指南。从我的角度来看，作为初次使用者，不觉得他可靠度有多高。

而 Caddy 的特性与 nginx 相比较，它追加的特性也都是一些鸡肋和实验性功能。
鸡肋是指你吹捧的证书自动部署，企业级 http 服务器安全策略一般不会允许 httpd 主动向外发来请求。企业也不会用 LE 的证书，LE 没有担保，只是个证书而已。
实验性功能是指 QUIC, 在 http3 标准确立之前，QUIC 都不会被大规模使用，甚至 Google 自己都不用。

还有就是，不要再吹 Go 的单可执行文件部署了。并不是只有 Go 能做到单可执行文件。而且部署一个服务不是你随便一丢无脑 root 运行就万事大吉的。

@uptime 除了官方文档的这个之外，我只找到了 Fedora 的软件源和 EPEL 上有 Caddy，然而这都是 rpm 源 都是给 RH 系用的。

还有就是自己好好学点东西，什么叫老掉牙？你知道 Long-term support 是什么意思吗？知道发行版版本冻结的意思吗？知道为什么稳定版要冻结版本号吗？你觉得老只是因为 LTS 发行策略不同，RH 系 3 年一冻结 Ubuntu 2 年一冻结。

RHEL 和 CentOS 是 RH 系的 LTS 发行版，软件包版本三年一冻结。如果想用新技术可以用半年冻结一次的 Fedora。Fedora 的更新速度只比 Arch 这样的滚动更新慢一步。而且自己看看版本差异，现在 RH 系的最新 LTS 版的 RHEL/CentOS 8.1 不比 Debian/Ubuntu LTS 的老，这是去年 CentOS 8 和弦 Ubuntu 18.04 的对比，https://developpaper.com/version-comparison-of-some-software-between-centos-8-and-ubuntu-18-04/。

@uptime 自己学学 Linux 运维吧，自己编译安装没问题，我们一般是编译了部署到一个自建软件源，安装部署都是用包管理。

CentOS 系老掉牙？奇了怪了，你还真是不懂 Linux 啊，我现在只找到 Caddy 官方建立了 Fedora Copr 源，( https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/packages/)这是和 rpm 源哦，说明 Caddy 团队自己用的就是 CentOS/Fedora 开发

@Buges
对啊，我尽量用包管理装，就是因为软件包打包的时候都按各个发行版的最佳实践配置好了。

依赖冲突问题，我用的 Fedora 和 CentOS 上用包管理装的环境并没有发生过，只有工作前已经折腾安装脚本的时候碰到过。

本地调试并不需要自动部署 https 证书，负载均衡和 QUIC 这样的特性，用内置的 Web Server 足够了。

用 Nginx 也不用调太多参数，很多参数都是涉及性能调优，安全性和浏览器兼容性的，不涉及这部分测试的情况保持默认也能跑起来。

Nginx 配置 php 服务也并不比 Caddy 复杂

server {
listen 80 default_server;
listen [::]:80 default_server;

root /var/www/html;
index index.php index.html index.htm index.nginx-debian.html;

server_name server_domain_or_IP;

location / {
try_files $uri $uri/ =404;
}

location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}

location ~ /\.ht {
deny all;
}
}

@Buges #40
我觉得单可执行文件部署简单是个伪命题。成熟的软件基本都进各大发行版的软件源了，用包管理装单文件和多文件没有什么区别。部署都是半自动的，手动把配置文件放到 etc 里就行了。如果用 Docker 的话那就更加没区别了。

而单个可执行文件不用包管理安装，直接放到一个目录有些东西免不了自己写点脚本处理的。比如 Caddy 你把可执行文件放进去了，用户、权限、路径和 SELinux 上下文还有 systemd 的服务都得自己来设置。生产环境，总不至于真的随便下到里面直接拿 root 跑吧= =

配置文件，我没用过 Caddy 不敢怎么评价。Nginx 其实也不复杂，只是默认配置文件列出的可改的参数比较多，但是有个模板改改就行了。这些东西 Caddy 实际使用应该也需要调的，用默认的值一般都不靠谱。

@uptime #37

我不想在服务器上跑来历不明我也没读过的脚本，也懒得去读他的安装脚本。
我就想找个软件源或者用 Docker 装一下，谢谢。
这些 Caddy 1 的文档没有提供，Caddy 1 的文档都是不知道多少年之前的了，没有什么意义。

你说了半天就说了点废话，唯一给我的信息只有你知道 Caddy 能用 curl 安装，这种是个人都知道的东西。

嘛，看了看你的注册日期，估计还是个学生吧，呵呵。

@uptime #33
对了，我在 EPEL 源找到 caddy 了，https://rpms.remirepo.net/rpmphp/zoom.php?rpm=caddy
不过我不是很懂他们为什么不把 EPEL 源列到文档里，要用 curl 下载脚本这种笨办法