核心内容摘要
久久人：定格时光，镌刻深情，让爱与记忆“久久”流传
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 理解“Connection refused”的真正含义当终端报出Connection refused它传递的不是模糊的“失败”而是一个非常明确的技术信号TCP三次握手的第二次SYN-ACK包未被响应目标端口上没有进程在监听。
换句话说——你的请求确实发到了目标IP和端口但那个端口上没有服务在等待接收它或者有服务在监听但被防火墙/安全组/网络策略主动拦截并返回RST重置包。
这与timeout超时、no route to host路由不可达、network is unreachable网络不可达有本质区别。
后者是“找不到路”而Connection refused是“门开着但里面没人应答”。
因此排查方向必须精准锁定在谁该监听这个端口它真的在监听吗它监听的是哪个IP有没有被拦在外面
2 Open-AutoGLM中的三段式连接链路Open-AutoGLM的运行依赖三条独立但协同的网络通道任一环节中断都会导致“连接被拒”。
我们先理清它们各自的职责和监听点链路数据流向关键监听端口负责组件常见拒绝点ADB控制链路本地电脑 ↔ 安卓设备5037ADB Server、5555ADB over TCPadb server电脑、adbd手机手机未启用USB调试WiFi连接未执行adb tcpip防火墙屏蔽5555端口模型服务链路Open-AutoGLM主程序 ↔ vLLM推理服务8000默认、8800等自定义端口vllm.entrypoints.openai.api_server本地或云服务器vLLM未启动启动时绑定
127.
0.
1而非
0.
0.
0云服务器安全组未放行端口远程API链路Open-AutoGLM主程序 ↔ 第三方云服务如z.ai443HTTPS云服务商后端API密钥错误请求域名拼写错误网络DNS解析失败关键提醒很多人把所有问题都归咎于“ADB连不上”却忽略了--base-url指向的模型服务才是真正的第一道关卡。
请务必先确认模型服务可用再排查ADB。
模型服务链路排查先确保“大脑”在线
1 本地vLLM服务检查监听地址与端口如果你在本地电脑上运行vLLM例如通过python3 -m vllm.entrypoints.openai.api_server --port 8000这是最容易出错的第一环。
快速验证命令Windows/macOS/Linux通用#
查看vLLM是否真正在运行检查进程 ps aux | grep vllm.entrypoints | grep -v grep #
检查8000端口是否被监听且绑定在
0.
0.
0而非
127.
0.
1 netstat -tuln | grep :8000 # 正确输出应包含tcp6 0 0 *:8000 *:* LISTEN # 错误输出示例tcp6 0 0
127.
0.
1:8000 *:* LISTEN → 只监听本地回环外部无法访问 #
本地curl测试必须成功 curl -X GET http://localhost:8000/v1/models -H Content-Type: application/json # 成功返回应为JSON格式的模型列表 修复方案问题netstat显示监听
127.
0.
1:8000修复启动vLLM时显式指定--host
0.
0.
0python3 -m vllm.entrypoints.openai.api_server \ --host
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 云服务器vLLM服务如Compshare镜像安全组是最大陷阱当你在Compshare等云平台部署vLLM镜像后--base-url需填写公网IP端口如http://
123.
56.
7
90:8800/v1。
此时90%的“连接被拒”源于云平台安全组未放行端口。
两步验证法在云服务器内部验证SSH登录后执行curl -X GET http://
127.
0.
1:8800/v1/models # 成功 → 服务本身正常 # 失败 → 检查vLLM是否启动、端口是否冲突从本地电脑验证关键telnet
123.
56.
7
90 8800 # 显示Connected to... → 网络可达端口开放 # 显示Connection refused → 安全组未放行No route to host → IP错误或实例未运行 Compshare平台操作指南以UCloud为例登录 Compshare控制台进入你的实例详情页 →“安全组”标签页点击“配置规则” → 添加入方向规则协议类型TCP端口范围8800或你实际使用的端口授权对象
0.
0.
0/0测试用或你的本地公网IP生产推荐注意修改安全组后无需重启实例规则即时生效。
3 第三方云服务z.ai / Novita AI检查URL与认证若使用z.ai等托管服务--base-url格式为https://api.z.ai/api/paas/v4此时“连接被拒”多因URL拼写错误或网络策略。
三秒自查清单URL末尾不要加/v1z.ai用/v4Novita用/v1ModelScope用/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控制台重新生成。
ADB控制链路排查让“手脚”听指挥
1 USB直连绕过WiFi回归最稳定路径当WiFi连接反复失败时请立即切换到USB线——这是最可靠的调试基线。
USB连接黄金四步验证物理层换一根支持数据传输的USB线能传文件的线才合格设备层手机设置 → 开发者选项 →USB调试和USB调试安全设置均开启授权层首次连接时手机屏幕弹出“允许USB调试吗” → 勾选“始终允许”系统层电脑执行adb kill-server adb start-server adb devices # 正确输出List of devices attached → XXXXXXXX device # 错误输出unauthorized → 重做第3步no permissions → 重插USB或重启adb 修复USB常见顽疾问题adb devices显示?????????? no permissionsLinux/macOS修复创建udev规则Linux或安装Android File TransfermacOS# Linux临时修复需sudo sudo chmod arwx /dev/bus/usb/*问题Windows提示“ADB interface driver not installed”修复下载 Google USB Driver在设备管理器中手动更新驱动。
2 WiFi远程连接两套方案一次配对ADB over WiFi有两种技术路径适配不同Android版本方案适用Android版本关键命令最易错点原生无线调试Android 11adb connect
192.
x.x:5555设备未开启“无线调试”或IP地址抄错TCP/IP模式Android
0全兼容adb tcpip 5555→ 断开USB →adb connect
192.
x.x:5555忘记执行adb tcpip 5555直接connect必失败一次配对成功流程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.
100:5555 # 输出connected to
192.
168.
100:5555 # Step 6: 验证 adb devices # 输出
192.
168.
100:5555 device提示如果adb connect后adb devices仍显示offline执行adb disconnect再重连。
Open-AutoGLM主程序链路参数与环境的终极校验
1--device-id与--base-url的精确匹配这是用户输入错误率最高的环节。
请严格对照以下表格检查参数本地USB连接WiFi远程连接云服务调用--device-id留空自动选择或填adb devices第一行ID如ZY22345678必填格式为
192.
168.
100:5555同WiFi远程--base-urlhttp://localhost:8000/v1本地vLLMhttp://localhost:8000/v1若vLLM也在本地https://api.z.ai/api/paas/v4第三方终极验证命令替换为你的真实值# 本地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.
100:5555 \ --base-url http://localhost:8000/v1 \ --model autoglm-phone-9b-multilingual \ 打开设置 # 云vLLM WiFi连接Compshare实例 python main.py \ --device-id
192.
168.
100:5555 \ --base-url http://
123.
56.
7
90:8800/v1 \ --model autoglm-phone-9b-multilingual \ 打开设置
2 Python环境与编码中文乱码引发的“假拒绝”在Windows上若指令含中文如“打开小红书搜美食”CMD/PowerShell默认GBK编码可能导致vLLM服务收到乱码返回空响应被误判为“连接被拒”。
一键修复PowerShell# 在运行main.py前强制设置UTF-8 $env:PYTHONIOENCODINGutf-8 python main.py --device-id ... --base-url ... 打开小红书搜美食通用修复所有系统在main.py文件开头添加import os os.environ[PYTHONIOENCODING] utf-
故障树速查表5分钟定位问题根源当你再次看到Connection refused请按此顺序执行每步耗时不超过1分钟步骤操作预期结果问题定位① 测模型服务curl -X GET [你的--base-url]/v1/models返回JSON模型列表模型服务未启动/端口错误/防火墙拦截② 测ADB连接adb devices显示device状态ADB未授权/USB线故障/开发者选项未开③ 测网络通路telnet [base-url的IP] [端口]显示Connected云安全组未放行/本地网络限制④ 测参数拼写检查--base-url末尾是否有/v
协议是否为httpsURL与文档完全一致拼写错误最常见⑤ 测中文编码在命令前加PYTHONIOENCODINGutf-8中文指令正常发送Windows编码问题完成以上五步95%的“连接被拒”问题将水落石出。
无需猜测每个答案都由一行命令给出。
6.
总结连接的本质是信任链的建立Open-AutoGLM不是一个单体应用而是一条由设备信任ADB授权→ 网络信任端口开放→ 服务信任API可用→ 编码信任UTF-8构成的信任链。
任何一个环节的信任缺失都会表现为冷冰冰的Connection refused。
本文没有提供万能解药而是给你一套可复用的“网络听诊器”用curl听服务心跳用adb devices看设备脉搏用telnet测网络血管。
下次再遇连接问题请记住——不要重启先诊断不要百度先执行。
现在拿起你的终端从第一步curl开始亲手把这条信任链一节节接通。