RAGflowFail to access model(DeepSeek-R1-32B).**ERROR**: [Errno 111] Connection refused
时间: 2025-05-26 14:24:15 浏览: 39
### 解决方案概述
`ConnectionRefusedError: [Errno 111] Connection Refused` 错误表明客户端尝试连接到某个服务时,目标机器主动拒绝了该连接。这通常是由于目标端口未监听、防火墙阻止或服务未运行等原因引起的[^1]。
对于 `DeepSeek-R1-32B` 模型的部署环境,如果遇到此错误,可能的原因包括但不限于以下几点:
1. **Docker 容器中的服务未正常启动**:确保 Docker 中的服务已经正确初始化并绑定到了指定的端口。
2. **端口映射配置不正确**:如果使用了 Docker,默认情况下容器内部的网络与主机隔离,需通过 `-p` 参数显式暴露端口。
3. **防火墙或其他安全策略阻断**:某些环境中可能存在额外的安全设置,例如 SELinux 或 iptables 规则,这些可能会干扰正常的通信。
4. **本地地址冲突**:当多个程序试图占用同一端口号时也可能引发此类问题。
以下是具体的排查和解决方案。
---
### 排查步骤及修复方法
#### 1. 确认服务状态
验证 `ollama` 是否正在运行以及其 API 是否可用:
```bash
docker ps | grep ollama
```
上述命令应返回当前运行中的 Ollama 容器实例及其对应的端口映射信息。如果没有找到任何匹配项,则说明服务尚未启动或者已被停止。
重新拉取镜像并启动服务:
```bash
docker exec -it ollama /bin/bash
ollama pull deepseek-r1:32b
ollama run --port=11434 deepseek-r1:32b
```
注意:此处指定了 `--port=11434` 参数来强制绑定外部可访问的端口[^3]。
#### 2. 检查端口映射
确认宿主机上的实际开放端口是否对应于容器内的预期端口 (默认为 11434),可以执行如下操作查看现有映射关系:
```bash
docker port <container_id>
```
其中 `<container_id>` 是上一步获取到的具体 ID 值。理想状态下会看到类似这样的输出:
```
11434/tcp -> 0.0.0.0:11434
```
如果不是这样,请调整初始创建指令加入必要的参数比如 `-p 11434:11434`.
#### 3. 测试连通性
利用简单的工具检测能否顺利抵达目的地:
```bash
curl http://localhost:11434/api/ping
```
假如收到 HTTP 返回码而非异常中断消息,则证明基础架构层面不存在障碍;反之继续深入分析其他潜在因素如网络安全组设定等[^2].
#### 4. 调整防火墙规则
有时即使完成了前面所有的准备工作仍无法解决问题,那很可能是受到了更高级别的防护机制影响所致。针对 Linux 平台而言,可以通过临时禁用 firewalld 来快速判断是否存在这方面的影响:
```bash
sudo systemctl stop firewalld.service
```
当然长期来看还是建议精细化管理而不是完全关闭它。
另外还需留意是否有启用 AppArmor/SELinux 这样的增强保护措施同样会对进程间交互构成约束作用[^4]:
```bash
getenforce
setenforce Permissive
```
最后重启相关组件使更改生效后再试一次原先的操作流程看效果如何变化。
---
### 总结
综上所述,要彻底消除 `[Errno 111] Connection Refused` 的困扰需要从多方面入手逐一排除可能性直到定位根本原因为止。以上提到的各种技巧均能有效辅助完成这一过程。
---
阅读全文
相关推荐













