我正在自行托管 Nextcloud 实例。我多年来一直在更新它，并且一直对它非常满意。我不使用 docker，而是在 Debian 11 Bullseye 系统上托管裸机。对于 SSL，我使用 Let's Encrypt，Web 服务器是 NGINX。硬件相当不错，16 GB RAM、Xeon 双核、SSD。
我发现，第一次连接尝试总是非常慢。之后，情况会好转。但等待几分钟后，速度又变慢了。
我可以用 curl 重现这种行为
$ curl -v https://cloud.example.org
* Trying 2001:....:443...
* Trying 192.168.170.11:443...
* Connected to cloud.example.org (192.168.170.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=cloud.example.org
* start date: Nov 26 16:41:45 2022 GMT
* expire date: Feb 24 16:41:44 2023 GMT
* subjectAltName: host "cloud.example.org" matched cert's "cloud.example.org"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x55f65608ee80)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: cloud.example.org
> user-agent: curl/7.81.0
> accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
LONG WAITING TIME HERE (40+ seconds)
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 302
< server: nginx
< date: Mon, 09 Jan 2023 15:02:09 GMT
< content-type: text/html; charset=UTF-8
< location: https://cloud.example.org/login
< expires: Thu, 19 Nov 1981 08:52:00 GMT
< cache-control: no-store, no-cache, must-revalidate
< pragma: no-cache
< set-cookie: oc_sessionPassphrase=xxxx; path=/; secure; HttpOnly; SameSite=Lax
< set-cookie: oca19nuvojkz=0a58ikqc0mvt2cchvemee08vd5; path=/; secure; HttpOnly; SameSite=Lax
< content-security-policy: default-src 'self'; script-src 'self' 'nonce-d0dqRGNyd3ZaL1BycTh3SE1tRmw2VnArdnQvU3ZtRTlaeDlrQ0VpYnk4cz06dVYrNkt2bE9Fb0dlenI5Q0F3NVd1ejRjL1l5LytBeGtCRmNKZXcvUHNvZz0='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
< set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< strict-transport-security: max-age=15768000; includeSubDomains; preload;
< referrer-policy: no-referrer
< x-content-type-options: nosniff
< x-download-options: noopen
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: none
< x-xss-protection: 1; mode=block
<
* Connection #0 to host cloud.example.org left intact
因此，如您所见，它在 TLS 握手上等待了好几秒钟。这是什么原因造成的？
我正在运行最新版本的 Nextcloud，24，但这个问题已经存在 4 到 6 个月了。我在 Nextcloud 论坛上没有得到任何回复，但我认为这是 Nginx / TLS 问题。
答案1
我终于在 NGINX 错误日志中找到了原因。有很多关于 ssl 和密码的错误。似乎我对密码的限制太多了，所以客户端需要很长时间进行握手，因为我的大多数服务器密码都没有被客户端接受。
这也可能是由于 NGINX 更新而发生的。
用过的Mozillas SSL 配置生成器更新我的配置。现在速度相当快。