GitHub Action执行cURL请求时步骤无限运行无法退出如何排查

问题基线 #

• 流水线配置的接口测试cURL步骤执行后持续处于运行状态，无报错输出、不主动退出，导致整个流水线无法完成
• 本地启动相同服务栈，执行同参数cURL命令可正常返回结果，无异常
• 对应步骤原始配置：

- name: Perseus API cURL Test Stack on http
  run: |
    curl --silent --show-error --fail -v -L http://0.0.0.0:8001/

可落地排查方向 #

• 优先确认服务启动逻辑是否阻塞步骤：如果服务是在同一个run步骤内启动，检查是否把服务进程放到了后台运行。前台启动服务会让步骤一直卡在服务运行状态，根本不会执行后续的cURL命令。如果是用docker/docker-compose启动服务，必须加-d参数让容器后台运行，不要前台挂着。
• 修正监听地址访问逻辑：0.0.0.0是服务端绑定所有网卡的监听地址，不是客户端访问的推荐地址，把cURL里的请求地址换成http://127.0.0.1:8001/测试。部分服务在Action环境下默认只绑定ipv6地址或者容器内部网卡，会导致ipv4的0.0.0.0请求进入半连接状态，既不失败也不返回响应。
• 给cURL增加强制超时参数，避免无限等待：原有cURL参数没有配置任何超时阈值，遇到半连接、服务无响应的场景会永久挂起。修改命令补充连接超时、总超时参数，异常场景下会主动退出并抛出明确错误：

  curl --silent --show-error --fail -v -L \
    --connect-timeout 10 \
    --max-time 30 \
    http://127.0.0.1:8001/
  

  执行后如果报连接超时，说明端口未正常监听/地址不通；如果报响应超时，说明TCP连接已建立但服务未返回HTTP内容，直接定位到服务端在Action环境的运行异常。
• 补充服务就绪检查逻辑，不要启动服务后立刻发请求：服务启动需要一定初始化时间，刚启动容器/进程就发请求，很容易碰到服务端口已经监听但业务逻辑还没初始化完成的状态，导致请求挂住。不要用固定时长的sleep等待，加轮询逻辑重试直到接口正常响应：

  # 最多等待60秒，每2秒重试一次
  for i in {1..30}; do
    if curl --connect-timeout 2 --max-time 5 http://127.0.0.1:8001/ >/dev/null 2>&1; then
      echo "service is ready"
      break
    fi
    echo "waiting for service start..."
    sleep 2
  done
  # 就绪后再执行正式测试请求
  curl --silent --show-error --fail -v -L --max-time 30 http://127.0.0.1:8001/
  

• 对照verbose日志定位卡顿时点：
  • 如果日志停在* Trying x.x.x.x...阶段无后续：属于网络不通/端口未监听问题，检查端口映射、服务是否正常启动、地址配置是否正确
  • 如果日志停在* Connected to x.x.x.x port 8001 (#0)阶段无后续：TCP连接已建立，问题出在服务端本身，检查服务在Action环境下的启动日志、环境变量配置、依赖组件是否正常连通

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