本文教你通过 cURL 信息检查、网络抓包等方法，科学验证 PHP 中 curl_exec() 与 HTTPS 站点通信是否全程启用 TLS 加密，确保跨站数据（如 POST 表单）在传输层安全可靠。
本文教你通过 curl 信息检查、网络抓包等方法，科学验证 php 中 `curl_exec()` 与 https 站点通信是否全程启用 tls 加密，确保跨站数据（如 post 表单）在传输层安全可靠。
在你的场景中，domain.com 通过 cURL 向 example.com/test.php 发起 HTTPS POST 请求，并成功返回响应，这说明请求已发出且服务端可访问。但仅凭 https:// 前缀或 CURLOPT_SSL_VERIFYPEER/VERIFYHOST = TRUE 的设置，并不能自动保证通信全程加密——中间可能存在协议降级（如服务端 301 重定向到 HTTP）、证书验证绕过、或 TLS 握手失败后降级等风险。因此，必须主动验证加密是否真实生效。
✅ 验证加密的三大可靠方法
1. 使用 curl_getinfo() 检查实际连接状态（推荐首选）
在 curl_exec() 执行后立即调用 curl_getinfo()，获取关键 TLS 连接元数据：
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'https://example.com/test.php');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); // 推荐设为 2（严格主机名匹配）
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10);
curl_setopt($ch, CURLOPT_TIMEOUT, 10);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, ['username' => 'Bob']);
$response = curl_exec($ch);
$info = curl_getinfo($ch);
$errno = curl_errno($ch);
$error = curl_error($ch);
// ? 关键验证项
$sslVerifyResult = $info['ssl_verify_result'] ?? -1; // 应为 0（表示证书验证成功）
$effectiveUrl = $info['redirect_url'] ?: $info['url']; // 实际最终访问 URL（注意：CURLINFO_EFFECTIVE_URL 在重定向后才准确，建议用 redirect_url 或手动跟踪）
$effectiveUrl = $info['effective_url'] ?? $info['url'];
// ✅ 必须同时满足：
if ($errno === 0 && $sslVerifyResult === 0 && strpos($effectiveUrl, 'https://') === 0) {
echo "✅ TLS 加密已启用且证书验证通过，通信安全。\n";
} else {
error_log("❌ 加密验证失败：errno={$errno}, ssl_verify_result={$sslVerifyResult}, effective_url={$effectiveUrl}");
echo "请求可能未加密或证书异常，请检查服务器配置与重定向逻辑。";
}
curl_close($ch);
⚠️ 注意事项：
- CURLOPT_SSL_VERIFYHOST 应设为 2（默认值），而非 TRUE（其等价于 2，但显式书写更清晰）；设为 1 已被弃用，不校验主机名。
- 若服务端存在 HTTP → HTTPS 重定向，CURLINFO_EFFECTIVE_URL 将反映最终 URL；若重定向发生在 HTTPS 内部（如 /test.php → /secure/test.php），仍属加密链路；但若出现 http:// 开头，则说明发生明文降级，需立即排查服务端 .htaccess、Nginx return 301 http://... 或 Cloudflare 页面规则。
- CURLINFO_SSL_VERIFYRESULT === 0 是核心指标：非零值（如 1, 60, 51）代表证书链验证失败（如自签名、过期、域名不匹配），此时即使有 https://，也不应视为可信加密。
2. 抓包分析：从网络层确认 TLS 流量（终极实证）
当代码层验证不足以排除中间设备干扰时，可在任一服务器（如 domain.com 或 example.com）执行抓包，直接观察原始流量：
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
# 在 domain.com 服务器上监听发往 example.com 的出向连接（替换为 example.com 的真实 IP）
sudo tcpdump -i any -s 0 -w curl_ssl_test.pcap "host 203.0.113.45 and port 443" -c 50
# 或更精准地过滤 cURL 进程（需提前获取 PID）
pgrep -f "get-contents.php" | xargs -I{} sudo tcpdump -i any -s 0 -w curl_ssl_test.pcap "pid {} and port 443"
抓包完成后，用 Wireshark 打开 curl_ssl_test.pcap：
- ✅ 正常情况：所有数据包目标端口为 443，协议列为 TLS 或 SSL，数据载荷显示为乱码（不可读加密流）；
- ❌ 异常情况：出现 port 80 + HTTP 协议 + 明文 POST /test.php 或 username=Bob 字样 → 证实未加密传输。
? 提示：Cloudflare 代理下，domain.com 到 Cloudflare 边缘节点是 HTTPS，而 Cloudflare 到 example.com 源站（WebHostingA）默认也是 HTTPS（Full SSL 模式），但需确保源站 Web 服务器（Apache/Nginx）已正确配置 SSL 证书并监听 443 端口，否则 Cloudflare 可能回退至 HTTP 回源（导致源站日志可见明文）。
3. 辅助验证：服务端日志与 Cloudflare 仪表盘
- 查看 example.com 的 Web 服务器访问日志（如 Apache access.log），确认来源协议字段（%{HTTPS}x 或 $scheme）是否为 on 或 https；
- 登录 Cloudflare 控制台 → SSL/TLS → Overview，确认两站点均为 Full (strict) 模式，且 Edge Certificates 和 Origin Server 证书均有效；
- 在 domain.com 的 cURL 请求头中添加唯一标识，便于在 example.com 日志中追踪该请求是否走 HTTPS：
curl_setopt($ch, CURLOPT_HTTPHEADER, [
'X-Request-ID: curl-secure-test-' . uniqid(),
'User-Agent: SecureCurlClient/1.0'
]);
总结：构建可信 HTTPS 调用的最小安全清单
| 检查项 | 合格标准 | 不合格风险 |
|---|---|---|
| ✅ URL Scheme | https:// 显式声明 | 误用 http:// 导致全程明文 |
| ✅ cURL 选项 | CURLOPT_SSL_VERIFYPEER=true + CURLOPT_SSL_VERIFYHOST=2 | 关闭验证等于裸奔 |
| ✅ curl_getinfo() 结果 | ssl_verify_result === 0 且 effective_url 以 https:// 开头 | 证书失效或重定向至 HTTP |
| ✅ 网络层抓包 | 全部流量经 port 443，Wireshark 解析为 TLS | 存在中间人或配置错误 |
| ✅ Cloudflare 设置 | SSL/TLS 模式为 Full (strict)，源站证书有效 | 回源使用 HTTP，最后一公里不安全 |
只要上述五项全部通过，即可确信：从 domain.com 发出的用户名 Bob，到 example.com 接收的整个过程，均运行在强加密的 TLS 通道之上，满足生产环境的数据传输安全要求。
