wait_for模块无法检测HTTP状态码，仅验证TCP连接是否建立；应改用uri模块配合until循环轮询健康端点，严格校验状态码200及响应内容。

直接用 wait_for 模块无法检测 HTTP 状态码——它只管端口通不通，不关心服务是否真正返回 200。要实现对后端 API 响应状态码的持续循环监测，得换用更贴合语义的方案：用 uri 模块 + until 循环。

为什么 wait_for 不适合监测 API 状态码

wait_for 的 state=started 仅验证 TCP 连接能否建立，比如 Nginx 进程起来了、端口监听了，但配置错误导致所有请求 502；或 Spring Boot 应用刚启动，/actuator/health 还没就绪，wait_for 就已“成功”退出，后续任务大概率失败。

推荐做法：用 uri 模块轮询健康端点

确保你的后端提供一个轻量、快速响应的健康检查接口（如 /healthz、/actuator/health 或 /ping），返回明确的状态标识（如 HTTP 200 + 响应体含 "status":"UP" 或纯文本 OK）。

• 使用 uri 模块发起 GET 请求，设置 status_code: 200 和合理超时（timeout: 10）
• 通过 until 和 retries 实现带条件的重试逻辑，比 wait_for 的固定 timeout 更可控
• 用 register 捕获响应，再在 until 条件中校验 status 和 content

示例任务：

Linux Ai Server

Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。

下载

- name: Wait for backend API to be ready and return 200
  uri:
    url: "http://localhost:8080/healthz"
    method: GET
    timeout: 10
    status_code: 200
  register: api_health
  until: >-
    api_health.status == 200 and
    ("OK" in api_health.content | string or "UP" in api_health.content | string)
  retries: 12
  delay: 5

这段代码最多等待 60 秒（12 × 5 秒），每次失败后等 5 秒再试，且严格要求响应状态为 200、内容含预期字符串。

增强健壮性的实操建议

• 若服务部署在远程主机，注意 url 中的 localhost 要替换为实际监听地址（如 {{ ansible_host }} 或服务绑定 IP），避免因网络栈差异导致本地 loopback 不通
• 加 validate_certs: no（仅限测试环境）绕过 HTTPS 证书校验，避免 TLS 握手失败中断等待
• 对敏感接口，可配合 headers 传入认证 token，例如 {"Authorization": "Bearer {{ api_token }}"}
• 如果健康端点本身不稳定（偶发 5xx），可在 until 条件中放宽判断，比如允许连续 2 次成功再退出循环

特殊情况补充：需要先等端口再等状态码？

极少数场景（如容器冷启动慢、服务进程未完全绑定端口），可分两步走：

• 先用 wait_for 等端口可连（state: started，timeout: 30）
• 再用上述 uri + until 等真实业务就绪

这样既避免空等，又防止在端口都未打开时就发起 HTTP 请求报错。