AWS SDK JS项目中Swagger UI跨域访问问题的分析与解决

问题背景

在AWS EC2实例上部署NestJS后端服务时，开发人员经常遇到一个典型问题：通过Swagger UI测试接口时出现CORS跨域错误。具体表现为Swagger页面可以正常打开，但实际发起API请求时控制台报错"Failed to fetch"，并提示可能的原因包括CORS限制、网络故障或URL协议问题。

核心问题分析

这种现象的本质在于浏览器安全策略的限制。当Swagger UI通过EC2的公网IP访问，而API请求却指向localhost时，就构成了典型的跨域场景。浏览器出于安全考虑会阻止这类请求，即使服务在服务器本地可以正常通过curl测试。

关键配置要点

1. 服务端配置：

   • 确保NestJS应用正确配置CORS中间件
   • 在生产环境中应明确设置允许的源(origin)
   • 示例配置：

     app.enableCors({
       origin: ['http://your-ec2-public-ip'],
       methods: 'GET,HEAD,PUT,PATCH,POST,DELETE',
     });
     

2. Swagger配置：

   • 检查Swagger文档的服务器配置
   • 确保文档中定义的basePath与实际访问地址一致
   • 示例配置：

     const options = new DocumentBuilder()
       .setTitle('API文档')
       .addServer('http://your-ec2-public-ip:3033')
       .build();
     

3. AWS安全组设置：

   • 确认EC2实例的安全组已开放相关端口(如3033)
   • 检查网络ACL规则是否允许入站流量

典型解决方案

1. 统一访问地址：

   • 确保前端页面和后端API使用相同的主机名和协议
   • 避免混合使用localhost和公网IP

2. Nginx反向代理：

   • 推荐使用Nginx作为反向代理统一入口
   • 配置示例：

     server {
         listen 80;
         server_name your-domain.com;
         
         location /api {
             proxy_pass http://localhost:3033;
         }
     }
     

3. 开发环境特殊处理：

   • 开发时可临时启用宽松的CORS设置
   • 但生产环境必须严格限制允许的源

最佳实践建议

1. 始终在开发初期就考虑跨域问题
2. 区分开发和生产环境的CORS配置
3. 使用环境变量管理API基础地址
4. 定期检查安全组和网络ACL设置
5. 考虑使用API网关统一管理API端点

总结

AWS EC2上部署的API服务遇到Swagger跨域问题时，需要从服务端CORS配置、Swagger文档设置和AWS网络配置三个维度进行排查。通过统一访问入口、合理配置反向代理和严格的安全策略，可以有效解决这类跨域问题，同时保证系统的安全性。对于Node.js后端服务，特别要注意NestJS的CORS中间件配置细节，避免因配置不当导致的生产环境安全隐患。