Oracle Tuxedo环境下libcurl完成证书校验后运行停滞问题求助

• 首先对比命令行curl和程序依赖的libcurl版本及TLS后端：
  执行curl -V查看命令行curl使用的TLS栈（AIX环境常见的有系统自带的GSKit、第三方编译的OpenSSL两种），再执行dump -X32_64 -H 你的可执行文件查看编译生成的程序链接的libcurl版本、依赖的TLS库是否和命令行curl一致，TLS栈不一致是TLS握手阶段卡住的高发原因。
• 修正代码中的错误配置：
  你代码中CURLOPT_SSL_VERIFYHOST参数使用了已废弃的1L值，符合规范的严格主机名校验值为2L，部分旧版libcurl遇到废弃值会触发TLS握手逻辑异常。同时建议补充超时配置，避免程序无限卡住：

  // 修正SSL校验参数
  curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 2L);
  // 新增超时配置
  curl_easy_setopt(curl, CURLOPT_TIMEOUT, 10L); // 总请求超时10秒
  curl_easy_setopt(curl, CURLOPT_CONNECTTIMEOUT, 5L); // 连接超时5秒
  

• 排查Tuxedo环境的信号限制：
  Oracle Tuxedo的服务进程默认会屏蔽大量系统信号，而OpenSSL等TLS库依赖SIGALRM等信号实现超时逻辑，信号被屏蔽会导致TLS握手阶段卡死。可以在调用libcurl逻辑前临时放开信号屏蔽，执行完成后再恢复原有配置。
• 对比权限和网络规则差异：
  确认命令行curl的执行用户和Tuxedo服务的运行用户是否一致，AIX可能存在针对不同用户的出站TLS包限制、防火墙规则，非root用户可能无法正常发送TLS握手包。
• 开启libcurl详细调试日志：
  代码中新增CURLOPT_VERBOSE和调试回调配置，输出完整的底层执行日志，对比和命令行curl日志的差异，定位具体卡住的环节。

最简便的方案是直接调用系统命令行curl，无需处理libcurl链接兼容、TLS栈适配问题，非常适合Tuxedo这类封闭的企业级运行环境，代码示例：

#include <stdio.h>

int call_rest_api(char *resp_buf, int buf_len) {
    FILE *fp = popen("curl -s -H \"Content-Type: application/json\" -H \"ApiKey: realKey\" --cacert /var/ssl/cert.pem https://ApiUrl.here", "r");
    if (!fp) {
        return -1;
    }
    size_t read_len = fread(resp_buf, 1, buf_len-1, fp);
    resp_buf[read_len] = '\0';
    int ret = pclose(fp);
    return ret == 0 ? 0 : -1;
}

如果对性能要求较高、不想调用外部进程，可以基于AIX自带的GSKit库封装TLS逻辑，自行实现轻量的HTTP/1.1协议栈，不需要引入第三方依赖。

内容的提问来源于stack exchange，提问作者Lookie