GitHub Action内cURL docker compose栈失败 报exit code35 SSL错误

--insecure参数仅会跳过服务端证书的有效性校验（包括自签证书不信任、域名不匹配、证书过期这类场景），不会干预TLS握手的协商流程，所以出现SSL握手错误时加这个参数本来就不会解决问题。

结合GitHub Action环境的特性，这个问题按出现概率从高到低有以下几个诱因：

• 最高概率：访问地址使用错误。0.0.0.0是服务端监听用的特殊地址，代表绑定本机所有网卡接口，本身就不是客户端发起请求时应该使用的目标地址。你本地访问https://0.0.0.0:8001能通，是因为桌面版操作系统默认加了0.0.0.0指向回环网卡的路由规则，属于系统做的兼容处理；但GitHub Action使用的无桌面版Ubuntu runner默认没有这条路由规则，访问0.0.0.0时TCP连接就会出现异常，部分场景下会直接表现为SSL握手失败。把访问地址换成127.0.0.1或者localhost即可解决。
• 次高概率：重试逻辑覆盖不全。你当前curl命令的--retry-connrefused参数只会在「连接被直接拒绝」时触发重试，但服务启动过程中可能已经开始监听端口，但TLS配置还没加载完成，这时候连接不会被拒绝，但SSL握手会直接失败，curl不会触发重试逻辑。加上--retry-all-errors参数，让所有请求错误都触发重试即可覆盖这种场景。
• 概率较低：TLS协议版本不匹配。GitHub Action runner内置的curl版本通常比普通用户本地环境新，新版curl默认禁用了TLS1.0、TLS1.1等老旧协议版本，如果你的服务仅支持老旧TLS版本，握手阶段会直接失败。可以给curl加上-v参数输出完整握手日志，确认是否是协议/加密套件不匹配问题，如果是，添加--tlsv1.2（或你服务支持的对应TLS版本）参数即可。
• 偶发诱因：端口映射未生效/服务启动异常。可以在执行curl前先运行docker compose ps检查容器运行状态，运行ss -tulpn | grep 8001确认宿主机8001端口确实已经被正常监听，排除端口映射配置错误、服务启动崩溃的问题。

- name: Test that the Perseus API stack is up and running with curl
  run: |
    # 前置检查，方便定位问题
    docker compose ps
    ss -tulpn | grep 8001
    # 替换访问地址为127.0.0.1，补全重试参数，增加详细日志输出
    curl -v --retry 10 --retry-all-errors --retry-delay 3 --insecure https://127.0.0.1:8001

内容的提问来源于stack exchange，提问作者Micheal J. Roberts