Continue 插件连接本地 Ollama 11434 端口拒绝访问：从报错根源到生产级高并发落地方案

作者： /

在 AI 辅助编程工具链中，Continue 插件因其对本地模型的灵活支持而备受青睐。然而，当开发者尝试将 Continue 插件连接本地 Ollama 服务时，频繁遭遇 11434 端口拒绝访问 的报错。这并非简单的网络问题，而是涉及 Ollama 服务绑定策略、CORS 跨域限制、网络命名空间隔离以及插件内部请求路径的复合性故障。本文将从业务落地视角出发，深度拆解该错误的根因，并给出可直接用于生产环境的代码级解决方案与高并发扩容指南。

一、业务场景架构：为什么 Continue 插件必须直连 Ollama 11434 端口

💡 推荐阅读：Ollama 无法下载模型 pulls model failed 镜像源配置，手把手保姆级修复教程（实测有效）

在典型的企业内部 AI 辅助开发环境中，架构通常如下：

  • 客户端层：VS Code / JetBrains IDE 中运行的 Continue 插件（TypeScript 编写，基于 Node.js 运行时）。
  • 模型服务层：本地或内网服务器上的 Ollama 服务，默认监听 127.0.0.1:11434。Ollama 的 API 端点包括 /api/generate、/api/chat、/api/embed 等。
  • 业务诉求：Continue 插件通过 HTTP 长连接调用 Ollama 的 /api/chat 接口，实现代码补全、对话式解释、重构建议等能力。由于涉及敏感代码，模型推理必须在本地完成，不能走云端 API。

当 Continue 插件试图访问 http://localhost:11434 或 http://127.0.0.1:11434 时，若 Ollama 服务仅绑定在 IPv4 的 loopback 接口，而插件进程运行在容器、WSL2 或远程开发环境中，就会发生 端口拒绝访问（Connection Refused）。此外，Ollama 从 0.1.30 版本开始默认启用 CORS 限制，若未显式设置 OLLAMA_ORIGINS 环境变量，来自非 localhost 来源的请求会被直接拒绝——即使端口可达，也会返回 403 而非 200。

二、根因定位：从网络层到应用层的四层排查法

💡 延伸阅读：AnythingLLM 本地文档解析失败 PDF 嵌入报错排查：从业务架构到 API 调用的全链路实战

要彻底解决 Continue 插件连接本地 Ollama 11434 端口拒绝访问，必须按以下顺序排查：

2.1 第一层：Ollama 服务是否真正监听 11434

执行 netstat -tlnp | grep 11434 或 lsof -i :11434。若输出显示 127.0.0.1:11434，说明服务正常。若显示 0.0.0.0:11434 或 [::]:11434，则说明已监听所有接口。

# 检查监听状态
ss -tlnp | grep 11434
# 期望输出：LISTEN 0 4096 127.0.0.1:11434 或 0.0.0.0:11434

2.2 第二层：环境变量 OLLAMA_HOST 的绑定策略

默认情况下，Ollama 只绑定 127.0.0.1。若 Continue 插件运行在 WSL2 中，而 Ollama 安装在 Windows 宿主机，则 WSL2 的 localhost 与宿主机不互通。此时必须将 Ollama 绑定到 0.0.0.0：

# 在启动 Ollama 前设置环境变量（Linux/macOS）
export OLLAMA_HOST="0.0.0.0:11434"
# Windows PowerShell
$env:OLLAMA_HOST="0.0.0.0:11434"
# 然后重启 Ollama

2.3 第三层：CORS 跨域配置（关键中的关键）

Continue 插件作为浏览器扩展（VS Code 基于 Electron），其网络请求携带 Origin: vscode-webview://... 头。Ollama 默认只允许来自 localhost 的请求，因此必须显式允许：

# 允许所有来源（开发环境）
export OLLAMA_ORIGINS="*"
# 或指定精确来源（生产推荐）
export OLLAMA_ORIGINS="http://localhost:3000,http://127.0.0.1:3000,app://obsidian.md"

2.4 第四层：代理与防火墙拦截

若开发机配置了系统代理（如 Clash、V2Ray），Node.js 默认会走代理，导致请求被代理服务器拦截。在 Continue 插件配置中强制关闭代理，或在启动 Ollama 时使用 --no-proxy 参数。

三、API/代码调用实战：Python 与 Curl 双版本直连验证

💡 深度技术指南：Open WebUI 连接 Ollama 失败 HTTP 404 解决流程：从报错到修复的保姆级实操手册

在修复上述配置后，我们通过以下代码验证 Continue 插件与 Ollama 的连通性。以下示例均假设 Ollama 已绑定 0.0.0.0:11434 且 CORS 已放开。

3.1 Curl 快速验证（模拟 Continue 插件的请求头）

curl -X POST http://127.0.0.1:11434/api/chat \
  -H "Content-Type: application/json" \
  -H "Origin: vscode-webview://continue" \
  -d '{
    "model": "qwen2.5-coder:7b",
    "messages": [
      {"role": "user", "content": "用Python写一个快速排序"}
    ],
    "stream": false
  }'

若返回 JSON 中包含 "done": true 和 message.content，则说明端口和 CORS 均正常。若返回 403，则需检查 OLLAMA_ORIGINS。

3.2 Python 生产级调用（带超时与重试机制）

以下代码用于企业内部工具链，直接对接 Continue 插件的后端代理服务（即由后端统一调用 Ollama，避免插件直连）。

import requests
import json
from tenacity import retry, stop_after_attempt, wait_exponential

OLLAMA_BASE_URL = "http://localhost:11434"

@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=2, max=10))
def call_ollama_chat(model: str, user_prompt: str, system_prompt: str = None) -> str:
    """
    生产级 Ollama 调用封装：支持重试、超时、流式与全量返回。
    :param model: 模型名称，如 'qwen2.5-coder:7b'
    :param user_prompt: 用户输入
    :param system_prompt: 系统指令，可选
    :return: 模型生成的文本
    """
    payload = {
        "model": model,
        "messages": [],
        "stream": False,
        "options": {
            "temperature": 0.2,
            "num_ctx": 8192  # 上下文窗口
        }
    }
    if system_prompt:
        payload["messages"].append({"role": "system", "content": system_prompt})
    payload["messages"].append({"role": "user", "content": user_prompt})

    try:
        resp = requests.post(
            f"{OLLAMA_BASE_URL}/api/chat",
            json=payload,
            headers={"Origin": "vscode-webview://continue"},  # 模拟 Continue 来源
            timeout=(3.05, 60)  # 连接超时 3 秒，读取超时 60 秒
        )
        resp.raise_for_status()
        data = resp.json()
        if data.get("done"):
            return data["message"]["content"]
        else:
            raise RuntimeError(f"Ollama 返回异常: {data}")
    except requests.exceptions.ConnectionError as e:
        # 这里捕获端口拒绝访问的具体异常
        raise ConnectionError(f"无法连接 Ollama 11434 端口: {e}，请检查 OLLAMA_HOST 绑定") from e
    except requests.exceptions.Timeout as e:
        raise TimeoutError(f"Ollama 响应超时: {e}") from e

# 业务调用示例
if __name__ == "__main__":
    try:
        result = call_ollama_chat(
            model="qwen2.5-coder:7b",
            system_prompt="你是一位资深Python工程师，只输出代码，不解释。",
            user_prompt="实现一个装饰器，用于计算函数执行时间。"
        )
        print("模型输出:\n", result)
    except Exception as e:
        print(f"业务异常: {e}")

3.3 流式调用（用于 Continue 插件实时补全）

Continue 插件需要流式响应以提供逐字输出体验。以下为流式调用的 Python 实现：

import requests
import json

def stream_ollama_chat(model: str, prompt: str):
    payload = {
        "model": model,
        "messages": [{"role": "user", "content": prompt}],
        "stream": True
    }
    with requests.post(
        f"{OLLAMA_BASE_URL}/api/chat",
        json=payload,
        stream=True,
        headers={"Origin": "vscode-webview://continue"}
    ) as resp:
        resp.raise_for_status()
        for line in resp.iter_lines():
            if line:
                chunk = json.loads(line)
                if chunk.get("message", {}).get("content"):
                    yield chunk["message"]["content"]

# 使用示例
for token in stream_ollama_chat("qwen2.5-coder:7b", "解释一下闭包"):
    print(token, end="", flush=True)

四、高并发扩容建议：从单机 Ollama 到多实例负载均衡

当 Continue 插件被团队内 50+ 开发者同时使用时，单机 Ollama 的 11434 端口会成为瓶颈。以下是生产级扩容方案：

4.1 单机多卡并发（NVIDIA GPU）

Ollama 原生支持多 GPU 并行推理。通过设置 OLLAMA_NUM_GPU=999 或指定 --gpu all，让多个 GPU 同时处理请求。但需注意，Ollama 默认对单模型串行处理，需要调整 OLLAMA_NUM_PARALLEL 环境变量：

export OLLAMA_NUM_PARALLEL=4  # 同一模型并发处理4个请求
export OLLAMA_MAX_LOADED_MODELS=2  # 同时加载2个不同模型

4.2 多机水平扩展（反向代理 + 轮询）

部署多台 Ollama 节点，使用 Nginx 或 HAProxy 做 TCP 负载均衡。以下为 Nginx 流式代理配置：

stream {
    upstream ollama_backend {
        least_conn;  # 最少连接数算法
        server 192.168.1.10:11434;
        server 192.168.1.11:11434;
        server 192.168.1.12:11434;
    }
    server {
        listen 11434;
        proxy_pass ollama_backend;
        proxy_connect_timeout 5s;
        proxy_timeout 120s;
    }
}

此时 Continue 插件只需指向 Nginx 所在主机的 11434 端口，即可透明扩展。

4.3 请求排队与削峰（Redis 消息队列）

若模型推理速度跟不上请求洪峰，建议引入 Redis Stream 作为任务队列。将 Continue 插件的请求先写入队列，由独立 worker 进程消费并调用 Ollama。这能有效避免 Ollama 因内存溢出而崩溃。

import redis
import json
import time

r = redis.Redis(host='localhost', port=6379, decode_responses=True)

def enqueue_request(user_id: str, prompt: str):
    task = {"user_id": user_id, "prompt": prompt, "ts": time.time()}
    r.xadd("ollama_tasks", task)

def worker():
    while True:
        items = r.xread({"ollama_tasks": ">"}, count=1, block=5000)
        if items:
            for _, task_id, data in items[0][1]:
                prompt = data["prompt"]
                result = call_ollama_chat("qwen2.5-coder:7b", prompt)
                # 将结果写回 Redis 供前端轮询
                r.set(f"result:{task_id}", result, ex=300)

4.4 监控与告警

必须监控 11434 端口的连接数、请求延迟、GPU 显存占用。推荐使用 Prometheus + Grafana 采集 /api/ps 端点数据，并设置阈值告警。关键指标：ollama_requests_total、ollama_inference_seconds。

五、总结：彻底解决 Continue 插件连接 Ollama 拒绝访问的最终清单

针对 Continue 插件连接本地 Ollama 11434 端口拒绝访问 这一高频问题，总结如下落地步骤：

  1. 修改 Ollama 启动参数：设置 OLLAMA_HOST=0.0.0.0:11434 和 OLLAMA_ORIGINS=*（生产环境限定具体来源）。
  2. 验证连通性：使用 curl -X POST http://127.0.0.1:11434/api/chat 带 Origin 头测试，确认返回 200。
  3. 配置 Continue 插件：在 Continue 配置文件的 models 部分，设置 apiBase 为 http://127.0.0.1:11434，并确保请求头包含 Origin。
  4. 排查代理：在 Node.js 进程或 IDE 设置中关闭系统代理。
  5. 生产环境：采用 Nginx 反向代理 + 多 Ollama 节点 + Redis 队列，确保高并发稳定性。

最后强调：任何网络层面的“拒绝访问”都应当从监听地址、CORS、代理三要素入手。本文提供的 Python 封装代码可直接嵌入你的 CI/CD 或内部工具平台，解决 80% 以上的连接故障。若仍无法解决，请检查操作系统防火墙（如 firewalld 或 ufw）是否放行 11434 端口。

AI排错与深度技术延伸阅读

🎁 DeepSeek-R1 本地量化模型+AI万能提示词资料包免费下载

本文提到的配置文件、报错排查手册及 AI 提效指令库已打包分享至夸克网盘，可极速免费转存：

👉 点击前往夸克网盘免费极速转存

💡 【AI 算力与服务器选型推荐】

本地部署大模型或搭建 AI 接口，推荐搭配高性价比独享云服务器。点击下方链接可领取开发者专属优惠：

👉 点此前往领取云服务器开发者限时优惠券

Post Views: 47
滚动至顶部