没必要 1T 硬盘吧。。。内存升级优先级大于硬盘

上海 1000 兆路过。。。

只是多了个上游而已

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

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;
}
}