配置CORS解决前端调用DDColor服务时的400 Bad Request问题
在AI图像修复应用日益普及的今天，越来越多开发者尝试将深度学习模型集成到Web前端中，为用户提供直观、便捷的老照片上色体验。然而，即便模型推理功能正常，用户点击“开始修复”后却常常遭遇请求失败——浏览器控制台显示400 Bad Request或模糊提示“被CORS策略阻止”。这类问题极少源于模型本身，而是前后端分离架构下常见的跨域配置疏漏所致。
以热门AI工作流平台ComfyUI中的DDColor黑白上色模型为例，其本地部署的服务默认监听8188端口，而前端开发服务器通常运行在3000端口。这种典型的“不同源”场景触发了浏览器的安全机制，导致请求在到达服务器前就被拦截。更令人困惑的是，部分情况下后端日志并无明显错误，网络面板却显示状态码为400，实则是因为未正确响应预检请求（OPTIONS），致使主请求根本无法发出。
要彻底解决这一问题，必须深入理解CORS（跨域资源共享）机制，并针对性地配置通信链路。
CORS是W3C制定的标准安全策略，用于允许一个域下的网页脚本安全地请求另一个域上的资源。浏览器默认遵循“同源策略”，即只有协议、域名和端口完全一致才被视为同一源。一旦发起跨域请求，尤其是带有自定义头部或非简单方法（如POST带JSON体）的请求，浏览器会自动先发送一个OPTIONS方法的预检请求，询问目标服务器是否允许此次操作。
服务器必须在响应头中明确授权，关键字段包括：
Access-Control-Allow-Origin：指定允许访问的源，例如http://localhost:3000Access-Control-Allow-Methods：声明支持的HTTP方法，如GET, POST, OPTIONSAccess-Control-Allow-Headers：列出可接受的请求头，如Content-Type, AuthorizationAccess-Control-Allow-Credentials：若需携带Cookie等凭证，则必须设为true且不能使用通配符*
如果缺少这些响应头，或者OPTIONS请求返回了非200/204状态码，浏览器就会中断后续请求，前端捕获到的往往是误导性的400 Bad Request，而非清晰的CORS错误信息。
相比早期通过JSONP绕过限制的方式，CORS不仅支持所有HTTP方法，还能进行细粒度权限控制和完整的错误处理，已成为现代Web开发的事实标准。
对于基于Node.js的后端服务，可通过Express框架快速启用CORS支持：
const express = require('express'); const cors = require('cors'); const app = express(); const corsOptions = { origin: 'http://localhost:3000', methods: ['GET', 'POST', 'OPTIONS'], allowedHeaders: ['Content-Type', 'Authorization'], credentials: true }; app.use(cors(corsOptions)); app.post('/api/ddcolor/process', (req, res) => { res.json({ status: 'success', resultUrl: '/results/colorized.jpg' }); }); app.listen(5000);这段代码确保来自前端的请求能被合法放行。但值得注意的是，在生产环境中直接暴露API端点并非最佳实践。更推荐的做法是使用Nginx作为反向代理统一入口，既提升安全性，也便于集中管理CORS策略：
server { listen 80; server_name your-domain.com; location /api/ { add_header 'Access-Control-Allow-Origin' 'https://your-frontend.com'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization'; add_header 'Access-Control-Allow-Credentials' 'true'; if ($request_method = 'OPTIONS') { return 204; } proxy_pass http://127.0.0.1:8188; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }该配置将所有/api/开头的请求代理至ComfyUI服务，并注入必要的CORS头。特别注意对OPTIONS请求的单独处理，返回204 No Content可避免因未实现该方法而导致预检失败。
DDColor作为专精于黑白图像智能上色的模型，在人物肤色还原与建筑纹理增强方面表现突出。它通常以内置节点的形式集成在ComfyUI中，形成可视化的工作流管道。其核心原理基于编码器-解码器结构，结合注意力机制与Lab色彩空间映射，从灰度图中推断出符合人类视觉偏好的自然色彩分布。
实际使用中，用户上传图像后，前端会构造一个包含工作流节点配置的JSON对象，并通过POST请求提交至ComfyUI的/api/prompt接口。示例如下：
{ "class_type": "LoadImage", "inputs": { "image": "black_and_white_photo.jpg" } }, { "class_type": "DDColor-ddcolorize", "inputs": { "model": "ddcolor_artistic.pth", "size": 680, "input_image": ["LoadImage", 0] } }其中size参数建议根据图像类型调整：人物照推荐460–680px以平衡清晰度与性能；建筑类则可提升至960–1280px保留更多细节。模型经过专项数据集训练，在特定领域显著优于通用着色方案，实现了秒级自动化处理的同时保持高质量输出。
当整个系统部署完成后，典型调用流程如下：
- 用户在React/Vue前端页面上传黑白图片；
- 前端组装请求体并调用API；
- 浏览器检测跨域，发起
OPTIONS预检； - Nginx代理层响应CORS头并转发主请求；
- ComfyUI接收指令，加载DDColor模型执行推理；
- 几秒内生成彩色图像，返回结果路径；
- 前端展示修复后的照片。
若中间任一环节缺失CORS配置，流程将在第3步中断。常见现象是控制台报错：
Access to fetch at 'http://localhost:8188/api/prompt' from origin 'http://localhost:3000' has been blocked by CORS policy.此时有两种快捷解决方案：
其一，启动ComfyUI时启用内置CORS标志：
python main.py --listen 0.0.0.0 --port 8188 --enable-cors-header此命令会在所有响应中添加Access-Control-Allow-Origin: *，适合开发调试阶段快速验证功能。
其二，采用反向代理彻底规避跨域：
通过Nginx将前端静态资源与后端API聚合在同一域名下，例如：
location /comfyui/ { proxy_pass http://127.0.0.1:8188/; }前端通过/comfyui/api/prompt访问服务，由于共享同源，不再触发跨域检查，是最稳定可靠的生产部署方式。
在配置过程中还需注意几个工程细节：
- 禁止滥用通配符：生产环境不应设置
Access-Control-Allow-Origin: *，应明确指定可信前端域名； - 凭据请求需精确匹配Origin：若前端携带认证Token或Cookie，响应头中的
Origin必须具体，不可为*； - 缓存预检结果：可通过
Access-Control-Max-Age设置缓存时间（如3600秒），减少重复OPTIONS请求带来的延迟； - 区分环境策略：开发阶段可放宽限制，生产环境应遵循最小权限原则，仅开放必要接口。
掌握CORS的配置逻辑，不仅是解决400 Bad Request的钥匙，更是打通AI模型与前端应用之间“最后一公里”的关键能力。本文所述方法虽以DDColor为例，但其原理适用于所有基于ComfyUI或其他FastAPI/Flask构建的AI服务集成场景。通过合理的网关设计与安全策略配置，开发者能够将强大的算法能力无缝转化为稳定可用的产品功能，真正实现“智能即服务”的落地愿景。
