webman本身不处理ssl握手，也不能直接配置证书；所有tls加解密必须由nginx等前置服务器完成，webman仅监听明文端口（如8787），通过http协议接收nginx转发的已解密请求。
Webman 本身不处理 SSL 握手，也不能直接“配置证书”——你看到的任何 ssl_certificate 配置项，都属于 Nginx 或 Apache，不是 Webman 的。
Webman 启动时根本不会读取 .pem 或 .key 文件
Webman 是一个常驻内存的 PHP HTTP 服务，它默认监听明文端口（如 0.0.0.0:8787），所有 TLS 加解密必须由前置 Web 服务器完成。即使你在 start.php 里写死 $worker->transport = 'ssl'，也只适用于 Workerman 原生模式（非 Webman 标准部署），且要求：
- PHP 已启用
openssl扩展 - Workerman 版本 ≥ 3.3.7
- 证书路径为绝对路径，且 Webman 进程有读取权限（
www-data或www用户） - 防火墙放行 443 端口（若直接监听 443）
但这种写法在宝塔、Docker、多域名场景下极易出错，不推荐用于生产环境。
Nginx 反向代理是 Webman 开启 HTTPS 的标准路径
绝大多数 Webman 项目都是通过 Nginx 接收 HTTPS 请求、解密后以 HTTP 协议转发给 Webman。关键点在于 Nginx 的每个 server 块必须独立且精准匹配：
-
listen 443 ssl http2;—— 缺少ssl关键字，Nginx 就当 HTTP 处理 -
server_name example.com;—— 必须与证书的 CN 或 SAN 完全一致（www.example.com和example.com视为两个域名） -
ssl_certificate /www/server/panel/vhost/cert/example.com/fullchain.pem;—— 路径必须是绝对路径，不能用相对路径或变量 -
ssl_certificate_key /www/server/panel/vhost/cert/example.com/privkey.pem;—— 私钥文件不能被 Windows 标记为“来自其他计算机”（右键 → 属性 → 解除锁定）
常见错误：把多个 server_name 塞进同一个 server 块，指望 Nginx 自动选证书——它不会。
宝塔面板中配置 HTTPS 的实操要点
在宝塔中部署 Webman + HTTPS，不是点几下“SSL”开关就完事。以下是必须手动核对的环节：
- 站点根目录必须指向 Webman 的
public/目录，不是项目根目录（否则路由和静态资源会 404） - 反向代理的目标 URL 必须是
http://127.0.0.1:8787（或你实际监听的端口），协议必须是http，不能写https - 代理配置里必须加这三行，否则
$request->secure()和$request->host()会失真：proxy_set_header X-Forwarded-Proto $scheme;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $remote_addr; - SSL 页面点“强制 HTTPS”后，要确认 Nginx 配置里是否自动生成了
error_page 497 https://$host$request_uri;—— 这是把 HTTP 请求 301 重定向到 HTTPS 的关键
浏览器报 NET::ERR_CERT_COMMON_NAME_INVALID 怎么办
这个错误 100% 是 Nginx 配置问题，和 Webman 无关。检查顺序如下：
- 用
nginx -t检查语法，再nginx -s reload生效 - 确认当前请求的域名是否精确匹配
server_name（大小写、www 前缀、尾部点号都要一致） - 用
openssl x509 -in /path/to/cert.pem -text -noout | grep -A1 "Subject Alternative Name"查看证书 SAN 是否包含该域名 - 清空浏览器 DNS 缓存（
chrome://net-internals/#dns）和 SSL 状态（chrome://net-internals/#sockets）
证书本身没问题，只是没被正确加载到对应域名的 server 块里——这是最常被忽略的细节。
