manus 1.6 max 多步任务卡死大概率由网络异常引发，需先验证dns解析与防火墙连通性，再通过直连测试、调试日志和模型url手动验证定位卡点，最后检查出口ip是否被限频。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Manus 1.6 Max 在执行多步任务时突然卡死，界面无响应、日志停在 model_client.invoke() 或 /v1/chat/completions 请求后无返回，大概率是网络异常引发的底层连接挂起或模型服务不可达，而非单纯配置错误。
确认是否真卡死，还是假性冻结
打开终端，执行 curl -m 5 -I https://your-manus-domain.com/health。若 5 秒内无任何输出（非 200/503，而是直接卡住），说明请求根本未发出——问题不在 Manus 逻辑层，而在系统出向链路。
运行 nslookup your-manus-domain.com。如果返回 NXDOMAIN 或超时，证明 DNS 解析失败，所有后续请求都会阻塞在此；此时检查 /etc/resolv.conf 是否指向了内网 DNS 且该 DNS 未同步公网记录。
若 DNS 正常但 curl 仍无响应，执行 telnet your-manus-domain.com 443。连接拒绝（Connection refused）说明上游服务未监听；连接超时（No route to host）则极可能是云主机安全组或本地防火墙拦截了 outbound 443 流量。
绕过网关直连Manus进程端口
方法一：查清Manus实际监听端口
进入 Manus 部署目录，打开 config.yaml 或 .env 文件，找到 server.port 字段值（默认常为 8000 或 9000）。
使用AIsa生成图像与视频。仅需一个API密钥即可调用Gemini 3 Pro Image（图像）和Qwen Wan 2.6（视频）。
方法二：用 curl 直连该端口
执行 curl -v http://127.0.0.1:8000/health（将 8000 替换为实际端口）。若返回 200，说明 Manus 进程本身健康；若仍超时，则问题在进程内部——比如它正卡在调用下游模型 API 的 asyncio.wait_for() 中，而该模型地址因 DNS 或证书失效无法建立 TLS 握手。
【关键前提】必须确保 curl 直连时使用的是 HTTP（非 HTTPS），否则会因缺少证书验证失败，误判为服务异常。
定位模型服务调用环节的网络断点
第一步：启用 Manus 内置调试日志
在启动命令中加入环境变量 LOG_LEVEL=DEBUG，例如：LOG_LEVEL=DEBUG python app.py。重启后观察 logs/debug.log 中是否出现类似 “Calling Qwen endpoint https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation” 的日志行。
第二步：手动测试该模型 URL 可达性
复制日志中的完整模型请求 URL，在终端执行 curl -v --connect-timeout 10 -H "Authorization: Bearer YOUR_API_KEY" -H "Content-Type: application/json" -d '{"model":"qwen-max","input":{"messages":[{"role":"user","content":"test"}]}}' https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation。若卡在 * Connected to dashscope.aliyuncs.com (203.107.12.15) port 443 (#0)，说明 DNS 和路由正常，但目标服务器 TLS 握手失败或限频；若卡在 Resolving host…，则是 DNS 缓存污染或 resolv.conf 配置错误。
第三步：检查出口 IP 是否被模型服务商临时封禁
访问 https://api.ipify.org，获取当前出口 IP；再前往对应模型平台（如 DashScope 控制台 → API 调用配额 → IP 黑名单）确认该 IP 是否在 block 列表中。部分服务商对高频失败请求自动触发 1 小时限频，不报错只静默丢包。
