Open-AutoGLM连接被拒？网络问题全排查

Open-AutoGLM连接被拒？网络问题全排查

在使用Open-AutoGLM构建手机端AI智能助理时，你是否遇到过这样的场景：一切配置看似正确，adb devices能识别设备，vLLM服务也正常启动，但执行python main.py时却突然弹出报错——“Connection refused”？或者更隐蔽地，指令发出去后毫无响应，日志里只有一行冰冷的Failed to connect to server？这不是模型能力不足，也不是代码写错了，而是网络链路中某个环节悄悄断开了。

本文不讲原理、不堆参数，只聚焦一个最常卡住新手的问题：连接被拒（Connection refused）的完整排查路径。我们将以真实调试视角，从物理层到应用层逐层下探，覆盖USB直连、WiFi远程、云服务调用三类典型场景，给出可立即验证、可快速修复的操作清单。无论你是刚接触ADB的新手，还是已在Compshare平台部署好vLLM镜像的老手，都能在这里找到对应你的那一行命令、那一个开关、那一处配置。

1. 连接被拒的本质：不是“连不上”，而是“被拒绝”

1.1 理解“Connection refused”的真正含义

当终端报出Connection refused，它传递的不是模糊的“失败”，而是一个非常明确的技术信号：TCP三次握手的第二次SYN-ACK包未被响应，目标端口上没有进程在监听。换句话说——

• 你的请求确实发到了目标IP和端口；
• 但那个端口上，没有服务在等待接收它；
• 或者，有服务在监听，但被防火墙/安全组/网络策略主动拦截并返回RST重置包。

这与timeout（超时）、no route to host（路由不可达）、network is unreachable（网络不可达）有本质区别。后者是“找不到路”，而Connection refused是“门开着，但里面没人应答”。

因此，排查方向必须精准锁定在：谁该监听这个端口？它真的在监听吗？它监听的是哪个IP？有没有被拦在外面？

1.2 Open-AutoGLM中的三段式连接链路

Open-AutoGLM的运行依赖三条独立但协同的网络通道，任一环节中断都会导致“连接被拒”。我们先理清它们各自的职责和监听点：

关键提醒：很多人把所有问题都归咎于“ADB连不上”，却忽略了--base-url指向的模型服务才是真正的第一道关卡。请务必先确认模型服务可用，再排查ADB。

2. 模型服务链路排查：先确保“大脑”在线

2.1 本地vLLM服务：检查监听地址与端口

如果你在本地电脑上运行vLLM（例如通过python3 -m vllm.entrypoints.openai.api_server --port 8000），这是最容易出错的第一环。

快速验证命令（Windows/macOS/Linux通用）

# 1. 查看vLLM是否真正在运行（检查进程） ps aux | grep "vllm.entrypoints" | grep -v grep # 2. 检查8000端口是否被监听，且绑定在0.0.0.0（而非127.0.0.1） netstat -tuln | grep :8000 # 正确输出应包含：tcp6 0 0 *:8000 *:* LISTEN # 错误输出示例：tcp6 0 0 127.0.0.1:8000 *:* LISTEN → 只监听本地回环，外部无法访问 # 3. 本地curl测试（必须成功！） curl -X GET http://localhost:8000/v1/models -H "Content-Type: application/json" # 成功返回应为JSON格式的模型列表

🔧 修复方案

• 问题：netstat显示监听127.0.0.1:8000
  修复：启动vLLM时显式指定--host 0.0.0.0

  python3 -m vllm.entrypoints.openai.api_server \ --host 0.0.0.0 \ --port 8000 \ --model zai-org/AutoGLM-Phone-9B-Multilingual \ ...

• 问题：curl返回Connection refused，但ps能看到进程
  修复：vLLM启动卡在模型加载阶段（尤其首次下载）。查看终端最后10行日志：

  tail -10 nohup.out # 如果后台运行 # 若看到"Downloading model..."或CUDA OOM错误，需等待或调整显存

2.2 云服务器vLLM服务（如Compshare镜像）：安全组是最大陷阱

当你在Compshare等云平台部署vLLM镜像后，--base-url需填写公网IP+端口（如http://123.56.78.90:8800/v1）。此时90%的“连接被拒”源于云平台安全组未放行端口。

两步验证法

1. 在云服务器内部验证（SSH登录后执行）：

   curl -X GET http://127.0.0.1:8800/v1/models # 成功 → 服务本身正常 # 失败 → 检查vLLM是否启动、端口是否冲突

2. 从本地电脑验证（关键！）：

   telnet 123.56.78.90 8800 # 显示"Connected to..." → 网络可达，端口开放 # 显示"Connection refused" → 安全组未放行；"No route to host" → IP错误或实例未运行

🔧 Compshare平台操作指南（以UCloud为例）

• 登录 Compshare控制台
• 进入你的实例详情页 →“安全组”标签页
• 点击“配置规则” → 添加入方向规则：
  • 协议类型：TCP
  • 端口范围：8800（或你实际使用的端口）
  • 授权对象：0.0.0.0/0（测试用）或你的本地公网IP（生产推荐）

注意：修改安全组后无需重启实例，规则即时生效。

2.3 第三方云服务（z.ai / Novita AI）：检查URL与认证

若使用z.ai等托管服务，--base-url格式为https://api.z.ai/api/paas/v4，此时“连接被拒”多因URL拼写错误或网络策略。

三秒自查清单

• URL末尾不要加/v1（z.ai用/v4，Novita用/v1，ModelScope用/v1）
• 协议必须是https://，不是http://
• 使用curl -v查看详细握手过程：

curl -v https://api.z.ai/api/paas/v4/models \ -H "Authorization: Bearer sk-xxxxxx" # 观察输出中是否有"Connected to api.z.ai"和"HTTP/2 401"（认证失败）或"HTTP/2 200"（成功）

• 常见错误：复制API Key时多了一个空格，或Key已过期 → 登录z.ai控制台重新生成。

3. ADB控制链路排查：让“手脚”听指挥

3.1 USB直连：绕过WiFi，回归最稳定路径

当WiFi连接反复失败时，请立即切换到USB线——这是最可靠的调试基线。

USB连接黄金四步验证

1. 物理层：换一根支持数据传输的USB线（能传文件的线才合格）
2. 设备层：手机设置 → 开发者选项 →USB调试和USB调试（安全设置）均开启
3. 授权层：首次连接时，手机屏幕弹出“允许USB调试吗？” → 勾选“始终允许”
4. 系统层：电脑执行

   adb kill-server && adb start-server adb devices # 正确输出：List of devices attached → XXXXXXXX device # 错误输出："unauthorized" → 重做第3步；"no permissions" → 重插USB或重启adb

🔧 修复USB常见顽疾

• 问题：adb devices显示?????????? no permissions（Linux/macOS）
  修复：创建udev规则（Linux）或安装Android File Transfer（macOS）

  # Linux临时修复（需sudo） sudo chmod a+rwx /dev/bus/usb/*

• 问题：Windows提示“ADB interface driver not installed”
  修复：下载 Google USB Driver，在设备管理器中手动更新驱动。

3.2 WiFi远程连接：两套方案，一次配对

ADB over WiFi有两种技术路径，适配不同Android版本：

一次配对成功流程（TCP/IP模式）

# Step 1: USB连接手机，确认adb devices可见 adb devices # Step 2: 启用TCP/IP监听（关键！） adb tcpip 5555 # 输出：restarting in TCP mode port: 5555 # Step 3: 断开USB线，连接同一WiFi # Step 4: 查手机IP（设置→WiFi→点击当前网络→IP地址） # Step 5: 连接 adb connect 192.168.1.100:5555 # 输出：connected to 192.168.1.100:5555 # Step 6: 验证 adb devices # 输出：192.168.1.100:5555 device

提示：如果adb connect后adb devices仍显示offline，执行adb disconnect再重连。

4. Open-AutoGLM主程序链路：参数与环境的终极校验

4.1--device-id与--base-url的精确匹配

这是用户输入错误率最高的环节。请严格对照以下表格检查：

终极验证命令（替换为你的真实值）

# 本地vLLM + USB连接 python main.py \ --device-id ZY22345678 \ --base-url http://localhost:8000/v1 \ --model autoglm-phone-9b-multilingual \ "打开设置" # 本地vLLM + WiFi连接 python main.py \ --device-id 192.168.1.100:5555 \ --base-url http://localhost:8000/v1 \ --model autoglm-phone-9b-multilingual \ "打开设置" # 云vLLM + WiFi连接（Compshare实例） python main.py \ --device-id 192.168.1.100:5555 \ --base-url http://123.56.78.90:8800/v1 \ --model autoglm-phone-9b-multilingual \ "打开设置"

4.2 Python环境与编码：中文乱码引发的“假拒绝”

在Windows上，若指令含中文（如“打开小红书搜美食”），CMD/PowerShell默认GBK编码可能导致vLLM服务收到乱码，返回空响应，被误判为“连接被拒”。

一键修复（PowerShell）

# 在运行main.py前，强制设置UTF-8 $env:PYTHONIOENCODING="utf-8" python main.py --device-id ... --base-url ... "打开小红书搜美食"

通用修复（所有系统）

在main.py文件开头添加：

import os os.environ['PYTHONIOENCODING'] = 'utf-8'

5. 故障树速查表：5分钟定位问题根源

当你再次看到Connection refused，请按此顺序执行，每步耗时不超过1分钟：

完成以上五步，95%的“连接被拒”问题将水落石出。无需猜测，每个答案都由一行命令给出。

6. 总结：连接的本质是信任链的建立

Open-AutoGLM不是一个单体应用，而是一条由设备信任（ADB授权）→ 网络信任（端口开放）→ 服务信任（API可用）→ 编码信任（UTF-8）构成的信任链。任何一个环节的信任缺失，都会表现为冷冰冰的Connection refused。

本文没有提供万能解药，而是给你一套可复用的“网络听诊器”：用curl听服务心跳，用adb devices看设备脉搏，用telnet测网络血管。下次再遇连接问题，请记住——不要重启，先诊断；不要百度，先执行。

现在，拿起你的终端，从第一步curl开始，亲手把这条信任链一节节接通。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。