Ansible批量配置网络时超时本质是SSH连接中断或响应迟缓，需分层排查：先验基础连通性（ping/nc/ssh测试），再调大ansible_ssh_timeout等参数，接着确保网络任务含等待机制、备份回滚及拆分执行，最后用-vvv和日志定位具体断点。

Ansible 批量配置变更时出现网络超时，本质是 SSH 连接在执行过程中中断或响应迟缓，常见于网络配置类任务（如改 IP、重启网卡、切换 DNS）——一旦配置错误或服务重启不稳，控制机就收不到目标主机响应，直接报 UNREACHABLE 或 Timeout。排查不能只看报错，要分层定位：先确认基础连通性是否被破坏，再检查 Ansible 本身的行为逻辑，最后回溯配置变更的影响点。

确认目标主机是否真的失联

别急着重跑 playbook，先手动验证底层可达性：

• 用 ping -c 3 目标IP 测试 ICMP 是否通（注意：部分服务器禁 ping，不能单凭这个下结论）
• 用 nc -zv 目标IP 22 或 ssh -o ConnectTimeout=5 user@目标IP exit 直接测 SSH 端口和登录能力
• 如果 SSH 失败但 ping 通，说明网络层没问题，问题出在 SSH 服务、认证或防火墙；如果两者都失败，大概率是 IP/子网/网关配置已变更且有误

检查 Ansible 的连接参数是否合理

默认 SSH 超时太短（通常 10 秒），尤其在网络配置重启期间，服务恢复可能需要更长时间：

Linux Ai Server

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

下载

• 在 playbook 中为高风险任务显式设置连接参数：
  vars:
  ansible_ssh_timeout: 30
  ansible_ssh_connect_timeout: 30
• 或全局配置 /etc/ansible/ansible.cfg：
  [defaults]
timeout = 30
[ssh_connection]
ssh_args = -o ConnectTimeout=30 -o ConnectionAttempts=3
• 避免在任务中使用 async + poll: 0 后不做状态轮询，这类异步操作容易掩盖真实超时原因

聚焦网络变更任务本身的执行顺序与容错

很多超时其实源于“边改边连”的逻辑冲突，比如刚写完新 IP 就立刻重启网卡，还没来得及绑定新地址，SSH 就断了：

• 确保网络配置任务后有明确的等待机制，例如：
  - name: 重启 systemd-networkd 并等待生效
  systemd:
    name: systemd-networkd
    state: restarted
  register: net_restart_result
- name: 等待网络接口重新上线
  shell: ip link show eth0 | grep "state UP"
  until: net_restart_result is succeeded
  retries: 6
  delay: 5
• 关键步骤前加备份和回滚钩子，比如用 copy 模块备份原 /etc/netplan/*.yaml，并在 block/rescue 中定义失败时还原配置并重启服务
• 禁止把主机名修改和网络配置放在同一个 task 里——改主机名不影响连接，但改网络极可能中断，必须拆成两个独立 play，并用 serial: 1 逐台执行

启用详细日志与连接调试

Ansible 默认输出较简略，需主动开启调试信息才能看清卡在哪一步：

• 加 -vvv 参数运行：ansible-playbook site.yml -i inventory -vvv，会显示每条 SSH 命令、传输文件路径、模块调用细节
• 在任务中临时加一个 debug 步骤，确认执行到哪一行才中断：
  - name: DEBUG - before network change
  debug:
    msg: "About to apply new netplan config"
• 检查目标主机的 /var/log/auth.log 或 journalctl -u ssh，看是否有大量连接拒绝、密钥校验失败或 PAM 限制记录