Ollama远程访问时如何配置CORS策略？

Question

在使用 Ollama 通过 API 进行远程访问时，前端应用常遇到浏览器报错“CORS policy blocked the request”，提示跨域请求被拒绝。这是由于 Ollama 默认未启用 CORS 策略，导致从非本地域名（如 http://localhost:3000）发起的 HTTP 请求无法通过安全校验。尽管可通过反向代理（如 Nginx）绕过该问题，但直接配置 Ollama 服务端允许特定源、方法和头部的跨域请求更为高效。如何在不依赖额外网关的前提下，正确设置 Ollama 的 CORS 策略以支持安全的远程调用？

Answer 1

1. 问题背景与 CORS 基础机制解析

在现代 Web 开发中，前端应用常通过浏览器调用后端服务的 RESTful API。当使用 Ollama 提供本地或远程模型推理服务时，默认监听地址为 http://127.0.0.1:11434。若前端运行于 http://localhost:3000，则构成跨源请求（Cross-Origin），触发浏览器的同源策略（Same-Origin Policy）限制。

CORS（Cross-Origin Resource Sharing）是 W3C 标准，允许服务器声明哪些外部源可以访问其资源。Ollama 默认未配置 CORS 头部，导致响应中缺失 Access-Control-Allow-Origin 等关键字段，从而被浏览器拦截。

典型错误信息如下：

CORS policy blocked the request: 
No 'Access-Control-Allow-Origin' header present on the requested resource.

2. 分析流程：从请求链路到安全校验

1. 前端发起 fetch 请求至 Ollama API 端点（如 /api/generate）
2. 浏览器检测请求源（Origin）与目标服务不同域，触发预检（Preflight）请求（OPTIONS 方法）
3. <3>服务器若未正确响应 OPTIONS 请求并返回允许的源、方法和头部，则预检失败</3>
4. 主请求被浏览器阻止，控制台报错“CORS policy”
5. 即使主请求到达 Ollama，缺少响应头仍会导致结果无法被前端读取

阶段	HTTP 方法	关键头部	预期行为
预检请求	OPTIONS	Origin, Access-Control-Request-Method	返回 200 并携带允许的策略
主请求	POST/GET	Content-Type, Authorization	响应包含 Access-Control-Allow-Origin
响应处理	-	Access-Control-Allow-Credentials	前端可读取响应体

3. Ollama 的服务架构与扩展能力

Ollama 基于 Go 编写，其内置 HTTP 服务使用标准 net/http 包，但未默认集成第三方中间件（如 gorilla/handlers 或 chi/middleware）。这意味着原生不支持动态 CORS 配置，需通过启动参数或环境变量干预，或修改源码注入中间件。

目前官方未提供 CLI 参数直接设置 CORS 策略，因此必须采用以下路径之一实现：

• 编译自定义版本并嵌入 CORS 中间件
• 利用 Ollama 支持的 OLLAMA_ORIGINS 环境变量（v0.1.30+ 版本引入）
• 通过系统级代理注入响应头（非推荐）

4. 解决方案一：环境变量配置（推荐方式）

自 Ollama v0.1.30 起，支持通过环境变量 OLLAMA_ORIGINS 定义允许的跨域源。这是最轻量且无需额外组件的方法。

# Linux/macOS
export OLLAMA_ORIGINS="http://localhost:3000,https://yourapp.com"
ollama serve

# Windows (PowerShell)
$env:OLLAMA_ORIGINS="http://localhost:3000,https://ai.example.com"
ollama serve

该变量接受逗号分隔的 Origin 列表，支持通配符 *，但出于安全考虑应避免生产环境使用。

5. 解决方案二：源码级定制 CORS 中间件

对于需要精细控制 CORS 行为（如凭证支持、自定义头部、缓存时间）的高级用户，建议 fork Ollama 源码并添加中间层。

示例代码片段（main.go 中注入 middleware）：

func corsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        origin := r.Header.Get("Origin")
        allowedOrigins := []string{"http://localhost:3000", "https://yourdomain.com"}

        for _, o := range allowedOrigins {
            if o == origin {
                w.Header().Set("Access-Control-Allow-Origin", o)
                break
            }
        }

        if r.Method == "OPTIONS" {
            w.Header().Set("Access-Control-Allow-Methods", "POST, GET, OPTIONS")
            w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
            w.Header().Set("Access-Control-Max-Age", "86400")
            w.WriteHeader(http.StatusOK)
            return
        }

        next.ServeHTTP(w, r)
    })
}

6. 架构对比与决策矩阵

graph TD A[前端请求] --> B{是否同源?} B -- 是 --> C[直接通信] B -- 否 --> D[发送 OPTIONS 预检] D --> E[Ollama 是否响应 Allow-Origin?] E -- 否 --> F[浏览器阻断] E -- 是 --> G[执行主请求] G --> H[返回带 CORS 头的响应] H --> I[前端成功接收数据]

方案	维护成本	安全性	灵活性	适用场景
环境变量 OLLAMA_ORIGINS	低	中	中	开发/测试环境
反向代理（Nginx）	中	高	高	生产部署
源码嵌入中间件	高	高	极高	私有化部署需求
浏览器禁用 CORS（仅调试）	低	无	低	临时测试

7. 安全实践与最佳建议

在启用 CORS 时，应遵循最小权限原则：

• 避免使用 * 作为 Access-Control-Allow-Origin 的值，尤其在涉及凭据（cookies、Authorization）时
• 明确列出受信任的前端域名
• 设置合理的 Access-Control-Max-Age 减少预检频率
• 监控异常 Origin 请求，防范潜在钓鱼攻击
• 结合 TLS 加密确保传输安全
• 定期审计允许的源列表
• 在生产环境中配合 CSP（内容安全策略）增强防护
• 对敏感接口增加 Token 验证机制
• 日志记录所有跨域请求来源
• 使用自动化脚本验证 CORS 配置有效性