Cobalt项目反向代理与CORS问题的解决方案

概述

在使用Cobalt项目搭建自托管服务时，许多开发者会遇到反向代理配置和跨域资源共享(CORS)问题。本文将深入分析这些问题的根源，并提供几种可行的解决方案。

核心问题分析

Cobalt项目由两个主要组件组成：

1. cobalt-api：处理实际下载逻辑的后端服务
2. cobalt-web：提供用户界面的前端服务

当尝试通过反向代理仅暴露前端服务并添加认证层(如Authelia)时，会遇到以下技术挑战：

1. 跨域请求问题：前端尝试直接访问后端API时会被浏览器安全策略阻止
2. 认证传递问题：前端认证无法自动传递到后端服务
3. 服务暴露需求：后端服务必须保持可访问状态

解决方案一：子路径代理模式

推荐使用单一域名下的子路径方式来部署服务：

version: '3.7'

services:
  cobalt-api:
    image: ghcr.io/wukko/cobalt:7
    ports:
      - 127.0.0.1:9000:9000
    environment:
      - cors=0
      - apiURL=https://cobalt.example.com/
      - apiName=cobalt-api

  cobalt-web:
    image: ghcr.io/wukko/cobalt:7
    ports:
      - 127.0.0.1:9001:9001
    environment:
      - webURL=https://cobalt.example.com/
      - apiURL=https://cobalt.example.com/

对应的Nginx配置示例：

upstream cobalt-api {
    server 127.0.0.1:9000;
}

upstream cobalt-web {
    server 127.0.0.1:9001;
}

server {
    server_name cobalt.example.com;

    location / {
        proxy_pass http://cobalt-web;
    }

    location /api {
        proxy_pass http://cobalt-api/api;
    }
}

这种配置的优势：

• 完全避免CORS问题
• 简化认证配置
• 保持单一入口点

解决方案二：多域名配置(7.10.3+版本)

从7.10.3版本开始，项目引入了CORS_URL参数来替代webURL，使得多域名配置成为可能：

version: '3.7'

services:
  cobalt-api:
    image: ghcr.io/wukko/cobalt:7.10.3
    environment:
      - cors=0
      - CORS_URL=https://cobalt-web.example.com
      - apiURL=https://cobalt-api.example.com/
      - apiName=cobalt-api

  cobalt-web:
    image: ghcr.io/wukko/cobalt:7.10.3
    environment:
      - webURL=https://cobalt-web.example.com/
      - apiURL=https://cobalt-api.example.com/

注意事项：

• 认证cookie需要设置为.example.com作用域
• 需要确保认证信息能在子域名间共享

技术原理深入

1. CORS机制：浏览器出于安全考虑会阻止跨域AJAX请求，除非服务器明确允许
2. 认证传递：基于cookie的认证需要作用域设置正确才能跨子域名工作
3. 服务发现：前端需要知道如何定位后端服务，而不会触发安全限制

最佳实践建议

1. 优先使用子路径方案而非多域名方案
2. 保持服务版本更新(7.10.3+)
3. 测试环境先验证配置再部署到生产
4. 监控服务日志以发现潜在问题

通过以上方案，开发者可以构建安全、稳定且易于维护的Cobalt自托管服务。