ssl_cert_file 是启用 tls 加密的必要条件，未设置则 ssl/tls 握手必然失败；必须为绝对路径、pem 格式完整证书链（fullchain.pem），且需与无密码私钥配对，并在创建 server 时指定 swoole_ssl 标志。
ssl_cert_file 是启用 TLS 加密的开关，不是“可选配置”
只要没设 ssl_cert_file，哪怕 enable_ssl 或 open_ssl 设为 true，Swoole 也不会真正启动 SSL/TLS 握手——连接会直接拒绝或静默失败，不会报错提示你证书缺失。它不像 Nginx 那样能 fallback 到 HTTP，Swoole 的 SSL 模式是硬性依赖证书路径存在的。
常见错误现象：SSL handshake failed、客户端 connect 后立即断开、curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number，基本都源于此。
-
ssl_cert_file必须指向一个**有效 PEM 格式证书链文件**（含域名证书 + 中间 CA，即 fullchain.pem） -
ssl_key_file必须是对应私钥，且不能有密码保护（Swoole 不支持读取带 passphrase 的 key） - 路径必须对 worker 进程可读；若用相对路径，以 PHP CLI 启动目录为准，不是项目根目录
- 证书与私钥内容不匹配时，Swoole 启动不报错，但首次握手必失败
普通 TCP/HTTP 连接根本不会触发 ssl_cert_file 解析
如果你用的是 SWOOLE_SOCK_TCP 或未带 SWOOLE_SSL 标志创建 Swoole\Server，那无论配置里有没有写 ssl_cert_file，它都会被完全忽略——Swoole 内核压根不进入 TLS 初始化流程。
典型误用场景：
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- WebSocket Server 开启了
open_websocket_protocol却忘了加SWOOLE_SSL标志，导致 wss:// 连接 400 或直接 timeout - HTTP Server 配置了
ssl_cert_file，但new Swoole\Http\Server第四个参数漏掉SWOOLE_SSL，结果还是走明文 HTTP - 在 reload 时只改了证书文件内容，但没重启进程（Swoole 不支持运行时热换证书）
ssl_cert_file 路径内容决定 TLS 兼容性底线
证书链是否完整、私钥是否匹配、是否使用 SHA-2 签名、是否包含 SAN（Subject Alternative Name），这些都直接影响客户端能否完成握手。浏览器、iOS App、curl 默认已禁用 TLS 1.0/1.1，若你的证书由过期的 CA 签发或缺少中间链，Swoole 就会返回 SSL alert: protocol version 或 unknown ca。
验证方式很简单：
- 用
openssl s_client -connect yourdomain.com:9501 -servername yourdomain.com直连 Swoole 端口看输出 - 检查返回中是否有
Verify return code: 0 (ok)，否则就是证书链或域名不匹配 - 注意：Swoole 不支持 ALPN 协商 HTTP/2，若需 h2，必须确保客户端明确发起
h2协议协商（如 curl -k --http2 https://...）
别把 ssl_cert_file 和 PHP stream context 混用
你在 file_get_contents() 或 cURL 里配的 cafile、verify_peer 是客户端行为，和 Swoole Server 的 ssl_cert_file 完全无关。后者只作用于当前 Swoole 进程监听的加密入口，不参与任何出站请求。
容易被忽略的一点：Swoole 的 SSL 是单向认证（只验服务器），不提供客户端证书双向认证能力（即 no ssl_ca_file 或 verify_peer 配置项）。如需 mTLS，得自己在 on('receive') 里解析 TLS 扩展字段，或改用 OpenSSL 手动封装。
