php 7.4 中用 curl_multi 批量请求 https 时，必须对每个 curl 句柄单独设置 curlopt_ssl_verifypeer => false 和 curlopt_ssl_verifyhost => 0 才能跳过证书校验，二者缺一不可；此举放弃传输层安全，易受中间人攻击，仅限测试环境临时使用，生产环境须通过配置可信 ca 证书（如 curlopt_cainfo）等方式真正解决校验问题。
PHP 7.4 中用 curl_multi 批量请求 HTTPS 域名时，若遇到证书校验失败（如自签名、域名不匹配、CA 不可信等），有人会直接跳过验证。这能快速让请求跑通，但必须清楚——这不是“调试开关”，而是主动放弃传输层安全防护。
跳过校验的具体操作方式
对每个 cURL 句柄单独设置，不能只设一次或复用句柄：
-
CURLOPT_SSL_VERIFYPEER => false：关闭证书链信任校验，即不检查服务器证书是否由可信 CA 签发 -
CURLOPT_SSL_VERIFYHOST => 0（注意是整数 0，不是false）：关闭主机名匹配校验，避免因证书 SAN 字段不含目标域名而失败 - 二者必须同时设置，缺一不可；仅关一个仍可能报错或连接中断
示例片段：
CurlShip Directory Submission
下载
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
$mh = curl_multi_init();
foreach ($urls as $url) {
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_multi_add_handle($mh, $ch);
}
// 后续执行 multi 执行逻辑...
跳过校验带来的真实风险
一旦禁用这两项验证，整个 HTTPS 连接退化为“加密但不可信”的状态：
- 中间人攻击（MitM）完全可行：攻击者可在网络路径中伪造服务器响应，你无法识别
- 证书过期、吊销、签发错误等本该阻断的风险全部被忽略
- 内网环境看似安全，但若存在恶意设备（如被入侵的路由器、ARP 欺骗节点），风险依然存在
- 不符合 PCI DSS、等保2.0、GDPR 等合规要求，生产环境上线即被否决
更稳妥的替代方案
跳过 ≠ 解决。真正可靠的做法是让校验通过：
- 使用合法可信任的证书（如 Let’s Encrypt），并确保服务端正确配置完整证书链
- 若调用内网 HTTPS 服务，把其自签名 CA 证书导出为 PEM 文件，通过
CURLOPT_CAINFO指定路径 - 确认系统 OpenSSL 版本和 CA 证书库是否过旧（如 CentOS 7 默认 CA 包陈旧），可更新
ca-certificates包 - 对
curl_multi中每个 handle 单独指定CURLOPT_CAINFO或CURLOPT_CAPATH，不依赖全局配置
为什么不能靠 ini_set 或全局配置绕过？
像 ini_set('openssl.cafile', '') 或修改 php.ini 中的 openssl.cafile 并不能跳过校验：
- 它只是改变 CA 证书查找路径，空值会让 OpenSSL 回退到系统默认路径（如 /etc/ssl/certs），效果不可控
- cURL 的证书验证逻辑独立于 PHP 流上下文，
stream_context_create的 ssl 选项对curl_multi完全无效 - 试图用
CURLOPT_SSLVERSION强制降级 TLS 版本也无法绕过证书验证，只会叠加协议错误
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
