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

背景介绍

Cobalt是一个开源的媒体下载工具，采用前后端分离架构设计。在实际部署中，很多用户希望将其置于反向代理之后，并添加认证层保护。然而，这种部署方式会遇到跨域资源共享(CORS)问题，导致前端无法正常访问后端API。

核心问题分析

当用户尝试通过反向代理部署Cobalt时，主要面临两个技术挑战：

1. 跨域请求问题：前端页面与API服务位于不同域名或端口时，浏览器会阻止跨域请求
2. 认证传递问题：当添加认证层(如Authelia)后，认证信息无法从前端传递到API服务

解决方案

方案一：同域名部署

最推荐的解决方案是将前后端部署在同一域名下，通过路径区分：

version: '3.7'

services:
  cobalt-api:
    image: ghcr.io/wukko/cobalt:7
    ports:
      - 127.0.0.1:9000:9000/tcp
    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/tcp
    environment:
      - webURL=https://cobalt.example.com/
      - apiURL=https://cobalt.example.com/

对应的Nginx配置示例：

upstream cobalt-api {
    server 127.0.0.1:9000 max_fails=0;
}

upstream cobalt-web {
    server 127.0.0.1:9001 max_fails=0;
}

server {
    listen 80;
    server_name cobalt.example.com;

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

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

方案二：跨域名部署(7.10.3版本后)

从Cobalt 7.10.3版本开始，项目引入了CORS_URL环境变量，专门用于解决跨域问题：

version: '3.7'

services:
  cobalt-api:
    image: ghcr.io/wukko/cobalt:7.10.3
    ports:
      - 127.0.0.1:9000:9000/tcp
    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
    ports:
      - 127.0.0.1:9001:9001/tcp
    environment:
      - webURL=https://cobalt-web.example.com/
      - apiURL=https://cobalt-api.example.com/

认证层集成注意事项

当添加认证层时，需要特别注意：

1. 认证cookie的作用域应设置为父域名(如.example.com)，而非特定子域名
2. 确保认证信息能够从前端传递到API服务
3. 反向代理需要正确转发认证头信息

最佳实践建议

1. 优先考虑同域名部署方案，减少CORS问题
2. 保持Cobalt版本更新，以获取最新的CORS支持
3. 测试环境先行，确保认证流程正常工作
4. 监控反向代理日志，及时发现并解决跨域问题

通过以上方案，用户可以安全、稳定地在反向代理后部署Cobalt服务，同时保持完整的功能性和安全性。