worker启动失败或tls中断主因是证书权限过高：私钥需chmod 600、证书需chmod 644，且属主须为运行用户（如www-data），否则openssl拒绝加载并报ssl_ctx_use_privatekey_file failed。
直接改权限，别让 Worker 因读不了证书而启动失败或 TLS 握手中断。
确认当前权限是否越界
私钥文件（.key）权限高于 600、证书文件（.crt 或 .pem）高于 644，就属于“过高”。Nginx、Workerman 或其他基于 OpenSSL 的服务在启动时若发现私钥可被组或其他用户读取，会拒绝加载并报错（如 SSL_CTX_use_PrivateKey_file failed），尤其在启用 ssl_verify_client on 或严格模式时更敏感。
- 运行
ls -l /path/to/your.key查看实际权限，常见危险值：644、664、755、777 - 若属主不是运行 Worker 的用户（如 www-data、nginx、或自定义的 worker 用户），还需同步修正属主
重设标准权限与属主
权限不是越严越好，而是要满足服务进程可读、且不违反安全基线。Worker 启动用户必须对私钥有读权限，但不能开放给无关账户。
- 私钥文件执行：
chmod 600 /path/to/your.key - 证书文件执行：
chmod 644 /path/to/your.crt（或 fullchain.pem） - 统一属主（以 www-data 为例）：
chown www-data:www-data /path/to/your.*
验证 Worker 是否能真正加载
改完权限不能只看 ls -l，得让 Worker 实际走一遍 SSL 初始化流程。
- 检查 Worker 启动日志，搜索
SSL、cert、private key相关错误行 - 用
openssl s_client -connect your-domain.com:port -servername your-domain.com测试握手是否成功 - 若使用 Nginx 反代 Worker 的 wss，确保 Nginx 没有因证书路径权限问题提前报错（
nginx -t会提示）
避免权限被自动覆盖
证书由 certbot 自动续期、或通过 CI/CD 部署时，容易重置权限。需固化权限策略：
- certbot 续期后加钩子：
--deploy-hook "chmod 600 /etc/letsencrypt/live/example.com/privkey.pem && chmod 644 /etc/letsencrypt/live/example.com/fullchain.pem" - Docker 中挂载证书时，用
chmod命令或USER指令确保容器内进程有读权 - Ansible 等配置管理工具中，显式声明
mode: '0600'和owner
