grpc status 14 错误本质是连接层失败，源于 tls 配置错误导致客户端无法建立连接；需检查 ssl_cert_path、ssl_key_path 绝对路径与权限，确认 pem 格式，mtls 场景下必须配置 ssl_ca_cert_path。
gRPC Status 14 错误本质是连接层失败
不是业务逻辑错误，而是客户端根本没连上服务端。常见现象是 Grpc.Core.RpcException 报出状态码 14，附带消息如 Connect Failed 或 Connection reset by peer。Hyperf 默认用 grpc-php 扩展，它底层依赖 gRPC C-core，对 TLS 配置极其敏感——路径错一个字符、证书链缺一级、甚至文件权限不对，都会直接退回到 Status 14。
检查 ssl_cert_path 和 ssl_key_path 是否可读且路径正确
Hyperf 的 gRPC 客户端配置中，ssl_cert_path 指的是服务端证书（即 PEM 格式的公钥），ssl_key_path 是对应私钥。这两个路径必须：
- 使用绝对路径，例如
/etc/ssl/certs/server.crt，不能用相对路径或./certs/... - PHP 进程用户（如
www-data或hyperf）有读取权限，执行ls -l /path/to/cert.crt确认 - 证书内容必须是 PEM 格式（以
-----BEGIN CERTIFICATE-----开头），不能是 DER 或 PFX - 若服务端用的是自签名证书，
ssl_cert_path必须指向该证书本身，不是 CA 根证书
双向 TLS（mTLS）下必须同时提供 ssl_ca_cert_path
如果服务端启用了客户端证书验证（即 mTLS），Hyperf 客户端必须额外指定 ssl_ca_cert_path，指向签发服务端证书的 CA 根证书（或中间证书链）。漏掉这个字段，连接会在 TLS 握手阶段被服务端拒绝，表现就是 Status 14。
注意：ssl_ca_cert_path 和 ssl_cert_path 不是同一个文件；前者用于验证服务端身份，后者是客户端向服务端出示的身份凭证。
示例配置片段（config/autoload/grpc_client.php）：
'options' => [
'ssl_cert_path' => '/etc/ssl/client.pem',
'ssl_key_path' => '/etc/ssl/client.key',
'ssl_ca_cert_path' => '/etc/ssl/ca-bundle.crt',
],
Hyperf 中禁用证书校验仅限开发环境
生产环境绝不可用。若只是本地调试且服务端用的是自签名开发证书，可在客户端配置中加入 'verify_peer' => false（需确认 grpc-php 版本 ≥ 1.47.0），但必须配合 'ssl_cert_path' 显式设为空或占位值，否则扩展仍会尝试加载并失败。
更稳妥的做法是：用 mkcert 生成本地受信证书，把根证书导入系统信任库，然后在 Hyperf 配置中正常填入 ssl_cert_path 和 ssl_ca_cert_path。Status 14 往往不是“要不要校验”的问题，而是“校验时连文件都打不开”。
