本质是网络隔离导致容器/vm的localhost指向自身而非宿主机，需将ai服务绑定0.0.0.0并用host.docker.internal（docker）、宿主机局域网ip（vm）或自定义bridge网络访问。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当OpenCode或OpenClaw运行在Docker容器或Windows/Linux虚拟机中，却无法连接宿主机上已正常运行的AI服务（如vLLM监听在http://localhost:8000/v1）时，本质是网络隔离导致的地址不可达——容器/VM看到的localhost指向自身环回接口，而非宿主机的AI服务端口。
确认宿主机AI服务监听地址与端口
在宿主机终端执行 netstat -an | findstr :8000（Windows）或 ss -tuln | grep :8000（Linux/macOS），确认服务实际绑定的是 【0.0.0.0:8000】 而非 127.0.0.1:8000。若只显示127.0.0.1，则vLLM启动参数必须强制指定 --host 0.0.0.0，否则外部设备根本无法建立TCP连接。
这一步漏掉，后续所有代理配置都无效。
Windows虚拟机：启用宿主机网络桥接并开放防火墙
第一步：在Hyper-V或VMware设置中，将虚拟机网络适配器模式从“NAT”改为“桥接模式”。NAT会创建私有子网，虚拟机无法直接访问宿主机的物理网卡IP。
第二步：在宿主机上打开“高级安全Windows防火墙”→“入站规则”→新建规则→选择“端口”→TCP特定本地端口8000→允许连接→勾选“域、专用、公用”→命名为“Allow vLLM 8000”。【跳过此步会导致连接被静默丢弃，无任何错误提示】
第三步：在虚拟机中用宿主机的局域网IP（如192.168.1.100）替代localhost访问，例如 http://192.168.1.100:8000/v1。
使用聊天补全、重试、结构化输出和明确的 User-Agent 标头运行 AIMLAPI LLM 与推理工作流，适用于 Codex 对 AIMLAPI 模型进行脚本化提示/推理调用的场景。
Docker容器：使用host.docker.internal或自定义网络
方法一（推荐，适用于Docker Desktop for Windows/macOS）：直接在容器内用 http://host.docker.internal:8000/v1 访问宿主机服务。该域名由Docker自动解析为宿主机内部IP，无需额外配置。
方法二（Linux Docker或需要精确控制）：启动容器时添加 --network host 参数，使容器共享宿主机网络命名空间。此时容器内 localhost:8000 即指向宿主机服务。【注意：此模式下容器端口直接暴露，禁止用于生产环境】
方法三（多容器协作场景）：创建自定义bridge网络 docker network create ai-net，分别用 --network ai-net 启动vLLM服务容器和OpenCode容器，然后通过容器名（如 http://vllm-service:8000/v1）互相调用。
Linux虚拟机：配置iptables放行并验证路由
在宿主机执行：
① 确保iptables允许来自虚拟机网段的请求：sudo iptables -I INPUT -s 192.168.100.0/24 -p tcp --dport 8000 -j ACCEPT（将192.168.100.0/24替换为你的VM所在子网）；
② 保存规则：sudo iptables-save | sudo tee /etc/iptables/rules.v4；
③ 在虚拟机中执行 curl -v http://宿主机局域网IP:8000/health，返回HTTP 200即通。
若curl卡住，说明防火墙或路由未生效；若返回Connection refused，说明宿主机服务未监听0.0.0.0。
