在AWS部署React与Django后，SSL及子域名API连接的最佳实践

看起来你已经把基础部署都搞定了，就卡在子域名API的SSL验证上对吧？我帮你梳理了几个生产环境下靠谱的解决方案，你可以根据自己的资源和需求来选：

方案1：给api子域名补充SSL证书（最直接的快速修复） #

既然你已经在AWS ACM有了主域名的证书，其实ACM支持免费添加额外域名到现有证书里，不用单独买通配符证书。

• 操作步骤：
  1. 登录AWS ACM控制台，找到你现有的domain.com证书，点击「编辑域名」，添加api.domain.com作为额外的域名。
  2. 选择DNS验证（推荐，比邮件验证更省心），AWS会给你生成对应的DNS记录，你去域名服务商那里添加这条记录就行，等ACM验证通过后，证书就会包含子域名了。
  3. 把更新后的证书关联到你的反向代理（比如Nginx）或者负载均衡器，确保api.domain.com的443端口请求能转发到Django的8000端口。
     这样React用https://api.domain.com请求就不会被浏览器拦截了，完全符合HTTPS的安全要求。

方案2：用反向代理统一处理HTTPS（生产环境推荐架构） #

这是我最推荐的方案，不管是前端还是后端，都通过Nginx或者AWS ALB（应用负载均衡器）做反向代理，统一在入口处处理SSL终止，这样后端服务完全不用管SSL的事儿，架构更清晰。

• 具体操作（以Nginx为例）：
  1. 确保你的SSL证书已经包含domain.com和api.domain.com（如果没有就按方案1补充）。
  2. 配置Nginx监听443端口，设置路由规则：
     • 主域名的请求转发到React的静态资源或者服务端口；
     • 子域名或者/api路径的请求转发到Django的8000端口。
  3. 给你个参考配置：

     server {
         listen 443 ssl;
         server_name domain.com api.domain.com;
     
         # 替换成你证书的实际路径
         ssl_certificate /etc/nginx/ssl/domain_cert.pem;
         ssl_certificate_key /etc/nginx/ssl/domain_key.pem;
     
         # 处理React前端请求
         location / {
             root /var/www/react-app/build; # React打包后的静态文件目录
             try_files $uri $uri/ /index.html; # 支持React路由的history模式
         }
     
         # 处理Django API请求
         location /api/ {
             proxy_pass http://localhost:8000/;
             # 传递必要的请求头给Django
             proxy_set_header Host $host;
             proxy_set_header X-Real-IP $remote_addr;
             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
             proxy_set_header X-Forwarded-Proto $scheme;
         }
     }
     

  4. 如果用AWS ALB的话，就创建两个目标组（一个指向React的80端口，一个指向Django的8000端口），然后在ALB的443监听规则里，根据域名或者路径把请求转发到对应的目标组，证书直接绑定到ALB的监听就行。

方案3：把API挂载到主域名下（无需子域名） #

如果你不想折腾子域名的话，完全可以把Django的API路径改成https://domain.com/api，这样直接用主域名的SSL就搞定了，不需要额外配置子域名。

• 操作步骤：
  1. 把React里axios的请求地址改成https://domain.com/api。
  2. 配置反向代理（Nginx/ALB），把所有/api开头的请求转发到Django的8000端口，和方案2里的API路由规则一样。
     这个方案适合小型项目，省掉了子域名的DNS解析和证书配置步骤，维护成本更低。

总结 #

如果是长期的生产环境，我强烈推荐方案2，因为它扩展性好，能统一管理所有请求的SSL、限流、缓存等，后续加新服务也方便；如果只是快速解决当前问题，方案1也能马上见效；方案3适合对架构复杂度要求不高的场景。

内容的提问来源于stack exchange，提问作者Louis Luk