你已经在api.MYDOMAIN.com上配置了CORS来支持SwaggerUI的跨域请求，还提供了OPTIONS预请求的响应结果，我来帮你拆解下这个配置的有效性：

你的请求与响应详情 #

执行的curl命令：

curl -i -X OPTIONS http://api.MYDOMAIN.com/v1/data/extraction

返回的响应内容：

HTTP/1.1 204 No Content
Server: nginx/1.10.3 (Ubuntu)
Date: Wed, 18 Apr 2018 20:45:52 GMT
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Header...

配置项逐一分析 #

• Access-Control-Allow-Origin: *：这个设置允许所有域名发起跨域请求，对于SwaggerUI的基础访问需求是能满足的，但这里有个关键冲突：你同时开启了Access-Control-Allow-Credentials: true。根据CORS规范，当允许客户端携带凭据（比如Cookie、HTTP认证信息）时，Access-Control-Allow-Origin不能设为通配符*，必须指定具体的源（比如SwaggerUI所在的域名，例如http://swagger.yourdomain.com）。如果你的SwaggerUI不需要带凭据访问API，这个冲突不会影响使用，但最好去掉Access-Control-Allow-Credentials来消除这个不符合规范的配置；如果需要带凭据，必须把Origin改成具体域名。
• Access-Control-Allow-Credentials: true：如果你的API需要客户端传递登录态Cookie之类的凭据，这个配置是必要的，但必须配合具体的Origin使用，否则浏览器会拒绝处理响应。如果不需要凭据访问，建议移除这个配置项。
• Access-Control-Allow-Methods: GET, POST, OPTIONS：这个配置覆盖了SwaggerUI常用的请求方法，OPTIONS是预请求必须的方法，GET和POST也是API常见的请求方式，这部分是没问题的。
• Access-Control-Allow-Headers：你的响应里这个字段被截断了，要确保它包含SwaggerUI会发送的所有自定义请求头（比如Content-Type、Authorization等）。如果SwaggerUI只发送标准HTTP头，那这部分没问题；但如果有自定义头，必须在这个字段里明确列出，否则预请求会失败，后续的实际请求也无法发送。

总结与调整建议 #

• 如果SwaggerUI不需要携带凭据访问API：可以保留Access-Control-Allow-Origin: *，但建议移除Access-Control-Allow-Credentials: true，消除规范冲突，同时确认Access-Control-Allow-Headers包含所有需要的请求头。
• 如果需要携带凭据访问：把Access-Control-Allow-Origin修改为SwaggerUI所在的具体域名，保留Access-Control-Allow-Credentials: true，并确保Access-Control-Allow-Headers覆盖所有必要的请求头。

内容的提问来源于stack exchange，提问作者Daniel Protopopov