Wait_For模块卡住或超时的根本原因是默认仅检查TCP连通性，不验证服务真实就绪状态；实操需结合timeout、sleep、uri健康检查及systemd状态轮询等多层验证。
Wait_For 模块为什么总卡住或超时失败
根本原因是 wait_for 默认只检查 TCP 连通性，不验证服务是否真正就绪。比如 Nginx 启动了，端口通了，但配置加载失败、worker 还没起来，wait_for 就认为“好了”，后续任务可能出错；反过来，有些服务（如 PostgreSQL）启动慢、有初始化延迟，wait_for 在超时前反复重试失败，直接报错中断流程。
实操建议：
- 别只靠
port和host，加timeout（默认 300 秒太长，设为 60–120 更可控）和sleep（避免高频探测压垮刚启的服务） - 对 HTTP 服务，优先用
wait_for_connection+ 自定义健康检查（见下一条），wait_for的state=started不适用 HTTP - 注意目标主机时间同步：如果 Ansible 控制节点和被控端时间差太大，
connect_timeout行为会异常
HTTP 服务怎么等它返回 200 再继续
wait_for 本身不支持 HTTP 状态码判断，硬要用会绕弯子（比如配合 uri 模块轮询再 until 循环）。更干净的做法是：用 uri 模块做健康检查，配合 until + retries 实现带状态码的等待逻辑。
实操建议：
- 写一个最小健康端点，比如
/healthz或/ping，返回纯文本OK或 JSON{"status":"up"} - 用
uri调用该端点，检查status == 200且content包含预期字符串 - 设置
retries: 12、delay: 5（即最多等 60 秒），比wait_for的固定超时更灵活
示例片段：
- name: Wait for app to return 200 on /healthz
uri:
url: "http://localhost:8080/healthz"
status_code: 200
timeout: 10
register: health_check
until: health_check.status == 200 and "OK" in health_check.content | string
retries: 12
delay: 5
Wait_For 的 port 检查在 systemd 服务里容易失效
systemd 启动的服务可能启用 ListenStream 延迟绑定，或使用 socket 激活机制（socket unit 先监听，服务进程按需拉起），此时 wait_for 查端口会立刻成功，但实际业务逻辑还没跑起来。
实操建议：
- 禁用 socket 激活：确认服务 unit 文件中没有
Wants=xxx.socket，或临时改用systemctl start xxx.service直接启动 - 用
systemctl is-active --quiet xxx配合command模块轮询，比端口检查更贴近服务真实状态 - 若必须用
wait_for，加上delay: 2和sleep: 1，给 systemd 留出几秒完成 post-start hook
Ansible 2.8+ 应该换用 wait_for_connection？
不是所有场景都适合。 wait_for_connection 只确认 SSH/WinRM 是否可连，和“服务是否就绪”完全无关。它解决的是“机器启动完、网络通了、Ansible 能登录了”这个前置条件，比如云主机刚创建完、需要等系统初始化完毕。
实操建议：
- 用
wait_for_connection替代老式wait_for检测 SSH 端口（port=22），更语义清晰、内置重试逻辑 - 但它不能代替服务级健康检查：Nginx 端口通 ≠ Nginx 已加载配置并 ready 处理请求
- 组合用法常见：先
wait_for_connection确保能连上机器，再用uri或自定义脚本确认服务就绪
最常被忽略的一点：很多人把 wait_for 放在 service 启动任务之后就以为万事大吉，但没考虑服务自身的 readiness 探针是否开启、日志里有没有 silent failure。真要稳，得从服务自身暴露可观测信号开始，而不是只在 Ansible 层拼命加等待。
