(本文含Debian 13的小bug；Let's Encrypt只能建1个https站点的严重基础bug和解决办法，请见本文最后) http3确实很有可能性能比http高。https是2018年互联网环境开始强推的模式，计划2026年10月某浏览器会对http进行页面阻拦。到了这个时间，如果不安装https，网站的流量会越来越少，环境强推所致。昨天进行测试http3，安装VPS供应商的Debian 13，安装完成之后，查看版本是Debian 13.7，这个系统是2026年9月12日发布的。

Debian 13.7比想象中好很多，仍然是节省内存(Debian比Ubuntu节省内存)。1G的内存，安装Apache、PHP 7/8之后，重启系统，Debian 11.1(PHP 7.4.33)剩余838420 KB(818.77 MB)，Debian 12.0(PHP 8.2.32)剩余795080 KB(776.45 MB)，Debian 13.7(PHP 8.4.27)剩余810580 KB(791.58 MB)。Debian 13.7，反而比Debian 12.0，节省15 MB的内存。

由于需要测试、加强PHP安全，我现在的5台VPS，安装的系统版本分别是：
Debian 11.1
Debian 12.0
Debian 13.7
Ubuntu 14.04 (2台，当时因为工作太忙，所以全都临时安装Ubuntu 14，因为当时自开发的一键安装命令只剩Ubuntu 14。)

Debian 13.7默认的PHP安装源是PHP 8.4.27，这个PHP 8.4.27正好在最近的0day漏洞的修复名单。

之后安装Let's Encrypt，命令可以在网上搜索。在安装Let's Encrypt之前，一定要先在Apache或Nginx的配置文件里建好站点。我使用的是Apache，相应的命名是：

apt -y install certbot python3-certbot-apache
certbot --apache

如何查看是否支持http3？Let's Encrypt是否支持http3？
安装好Let's Encrypt，或者自签名SSL之后，使用Firefox访问自己的站点。按F12，选择“网络”的标签，然后再按F5刷新一下网页，在网址列表里，找到当前网页的文件(因为列表里有很多JS、图片、CSS的元素)，点击之后，在右边可以看到网页的属性，是不是HTTP/1.1、HTTP/2、HTTP/3。

但很遗憾，目前最新的Debian 13.7，使用Let's Encrypt默认的官方安装命令，安装的https，仍然是HTTP/1.1。

我看了一下很多独立博客，大部分都是HTTP/2，极少部分是HTTP/3。

测试的结果，Debian 13.7内置的SSL程序，没有支持http3；Let's Encrypt的安装包里也没有内置支持http3。

http3需要额外手动安装，依赖包相当多，到这一步我已经放弃了。

Let's Encrypt当前的一个严重基础bug：只能建1个https站点
做程序开发的时间越长，你越会发现，“这世界是个巨大的草台班子”是实实在在的一个巨大真理，并非玩笑，这是因为部门之间的信息衔接不足，导致关键的地方出现bug，却无人处理。

和这句话同级别的巨大真理，还有一些，我最近思考了很多天，现在开始在笔记里整理这些人们发现的巨大型真理。因为这种巨大型真理，能让人的人生少走很久弯路。

这个严重的基础bug，是Apache下，安装Let's Encrypt，只能安装一个域名的SSL，我在Debian 11、Debian 12、Debian 13下安装Let's Encrypt，都是这个问题。

Nginx下，有可能不存在这个bug。因为我的服务器后台都是使用Apache，暂时没条件(时间)测试Nginx。现在绝大多数的博客，都是Nginx，几乎没有多少人使用Apache。

(很多人使用Nginx，是因为Nginx宣传中的并发数比Apache高很多。其实，PHP的瓶颈在于MySQL，由于Nginx不像Apache原生支持.htaccess，导致我只能选择Apache。)

因为使用Apache的人很少，导致这个基础bug出现。

昨天终于找到这个bug的原因。Let's Encrypt的站点配置文件，路径是/etc/apache2/sites-enabled/apache2-le-ssl.conf。

Let's Encrypt的bug如：

当给站点1建立SSL之后，站点1可以用https正常访问，SSL证书正常。
当给站点2建立SSL之后，站点2可以用https正常访问，此时站点1则变成自签名SSL，出现页面拦截。
再用安装命令，重装安装站点1，会出现选择，“是否尝试修复”，选这一项，之后站点1可以用https正常访问，站点2却又变成自签名SSL、页面拦截。

之后查看apache2-le-ssl.conf这个文件。bug的原因是出在这里，其实站点1和站点2的证书文件都已经安装正确、安装完成。

bug的原因是Let's Encrypt的开发人员，对apache2-le-ssl.conf这个文件的写入出现设计错误，里面的配置是张冠李戴。

正确的站点配置是站点1、站点2。而现在的apache2-le-ssl.conf，站点1的配置是站点1的站点路径，证书文件却是站点2的证书文件；在apache2-le-ssl.conf文件里，站点2却又变成80端口。

这种张冠李戴的现象，是因为开发人员没有进一步测试。他安装完一个站点，就停止测试了。

解决的办法：

1. 重装安装Debian、Ubuntu系统、Apache/Nginx、PHP，使配置文件处于干净状态。

2. 先建立80端口的站点，否则无法被Let's Encrypt识别。

3. 安装Let's Encrypt第1个站点。之后，立刻备份/etc/apache2/sites-enabled/apache2-le-ssl.conf文件，命名为apache2-le-ssl.conf2，查看他的SSL站点的标准配置。

4. 安装Let's Encrypt第2个站点。这时候会发现apache2-le-ssl.conf文件，站点的配置已经张冠李戴，完全错乱了。

5. 打开刚才的备份文件apache2-le-ssl.conf2，把站点1的配置复制一遍，并把新复制的内容的域名改为站点2，然后粘贴到这个文件。

之后把apache2-le-ssl.conf2改名为apache2-le-ssl.conf，替换已有的文件，重启Apache，这时候站点1、站点2、站点3……就都能支持https了。

Debian 13的小bug
我使用的VPS，现在是2家供应商。之前测试，同样是Debian 11，替换为相同的软件源，/etc/apt/sources.list这个文件，安装之后，系统环境也不一样，比如有一家VPS，默认自带sudoers、iptables，另一家VPS则不自带sudoers、iptables，需要手动安装。

现在使用的这家VPS供应商，Debian 13.7不自带sudoers、iptables，而且连wget都不自带。这3个都需要手动安装，安装命令也十分简单：

apt -y install sudo
apt -y install iptables
apt -y install wget

https的速度
Debian 11/12/13+Let's Encrypt，安装的https默认是HTTP/1.1，速度比http模式慢，之前的https测速，就是HTTP/1.1模式下的https。

http延迟平均0.39毫秒～1.2毫秒，HTTP/1.1模式的https的延迟平均在6.3毫秒～25毫秒，更多是集中在12毫秒～16毫秒。

现在安装https是一种受罪，将来还可能会全面收费。过渡期，只能暂时这样。安装https唯一的好处是浏览器不会出现“不安全”的警报，现在浏览器进一步强推，已经计划对http页进行页面拦截。