PHP无法接收HTTPS请求的根本原因是Web服务器未正确终止SSL或未转发解密后的请求，问题出在Nginx/Apache配置（如443监听、证书路径、fastcgi_param HTTPS on）、反向代理时X-Forwarded-Proto处理及证书链完整性。
PHP本身不处理HTTPS协议层，所谓“PHP接收不到HTTPS请求”，实际是Web服务器（如Nginx/Apache）未正确终止SSL或未将解密后的请求转发给PHP。问题根源几乎总在服务器配置，而非PHP代码。
检查Web服务器是否真正启用了HTTPS监听
很多开发者误以为只要域名绑了SSL证书，PHP就能“自动”收到HTTPS请求——其实PHP根本看不到加密流量。必须确认Web服务器在443端口监听并配置了有效的ssl_certificate和ssl_certificate_key。
以Nginx为例，常见遗漏点：
- 只在
http块里写了server，但没加listen 443 ssl - 证书路径写错（比如用相对路径，而Nginx工作目录不是你预期的）
-
ssl_certificate指向的是中间证书拼接文件，但漏了根证书或顺序不对 - 防火墙或云服务商安全组未放行443端口（本地
curl -I https://yoursite.com失败时优先查这个）
验证$_SERVER['HTTPS']是否为'on'或'1'
PHP通过Web服务器设置的环境变量识别HTTPS上下文。$_SERVER['HTTPS']是关键判断依据，但它完全依赖服务器配置是否主动注入。
立即学习“PHP免费学习笔记（深入）”；
Apache需确保SSLEngine on启用，并在虚拟主机中包含：
SetEnvIf X-Forwarded-Proto https HTTPS=on
Nginx则必须在location或fastcgi_param中显式传递：
fastcgi_param HTTPS on;
否则即使访问的是https://地址，$_SERVER['HTTPS']仍为空或不存在——这不是PHP Bug，是Web服务器没告诉它。
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
反向代理场景下HTTPS状态丢失
当Nginx作为反向代理（例如代理到PHP-FPM或另一台HTTP服务），且前端有CDN、WAF或负载均衡器时，原始HTTPS信息会丢失。此时不能依赖$_SERVER['HTTPS']，而要看$_SERVER['HTTP_X_FORWARDED_PROTO']。
安全做法是：仅当$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https'且$_SERVER['HTTP_X_FORWARDED_FOR']可信（比如限定内网IP段）时，才认为是真实HTTPS请求。
常见错误：
- 直接信任任意来源的
X-Forwarded-Proto头（可被恶意构造） - 没配置Nginx的
proxy_set_header X-Forwarded-Proto $scheme; - PHP-FPM池配置中禁用了
env[HTTPS]，导致无法继承
PHP中硬编码HTTP/HTTPS跳转容易出错
用$_SERVER['REQUEST_SCHEME']或$_SERVER['SERVER_PORT'] == 443做跳转判断不可靠：前者在部分CGI/FastCGI环境下为空；后者在反代场景下永远是80（因为PHP看到的是代理连过来的HTTP请求）。
更稳妥的方式是组合判断：
if (!empty($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) === 'on') {
// 原生HTTPS
} elseif (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
// 反代HTTPS（需配合可信IP校验）
} else {
// 强制跳转逻辑放这里
}
注意：$_SERVER['HTTPS']值可能是'on'、'1'或''，不同服务器行为不一致，不要用== true或=== true判断。
最常被忽略的一点：证书链不完整会导致浏览器握手失败，请求根本到不了Web服务器，自然也不会进PHP。用openssl s_client -connect example.com:443 -servername example.com看输出末尾是否有Verify return code: 0 (ok)，否则先修证书再调PHP。
