基于AWS EC2+Route53的Docker+Gunicorn+Nginx+Django：非WWW转WWW方案咨询

嘿，我来帮你捋捋这个裸域名重定向的问题～

一、用Nginx配置实现重定向是否合适？ #

完全合适！这是业内非常常见且直接的做法，尤其在你已经把Nginx作为反向代理部署的架构里，不需要额外新增服务组件，配置成本低、见效快，完全适配你当前的Docker+Django环境。

这种方式的核心优势：

• 复用现有架构，不用动AWS层面的基础配置（只要你已经把域名解析指向了EC2就行）
• 301永久重定向是搜索引擎友好的，能完整传递域名权重
• 配置灵活，还能根据需求保留请求路径、参数，甚至做更细粒度的规则调整

二、有没有更优的解决方案？ #

这得看你的架构长期规划和需求，AWS生态里还有两个更适合大规模或高可用场景的方案：

1. Route53 重定向规则（推荐轻量场景） #

如果不想让EC2额外处理裸域名的请求流量，或者希望把重定向逻辑放在DNS层面统一管理，可以直接在Route53里配置重定向记录：

• 不需要修改Nginx或Docker配置，所有重定向操作在DNS层完成，减少EC2的请求处理压力
• 配置步骤简单：在Route53托管区添加一条A/CNAME类型记录，选择“重定向到另一个域名”，目标设为www.mydomain.com，重定向类型选301永久即可
• 适合裸域名请求量较大，或者未来可能调整后端架构的场景

2. CloudFront 配置重定向（适合带CDN需求的场景） #

如果你的站点已经在用CloudFront做CDN加速，或者计划引入CDN优化性能，可以在CloudFront分发里通过缓存行为或CloudFront Functions实现重定向：

• 结合CDN的缓存能力，进一步提升用户访问速度和站点稳定性
• 可以统一管理所有域名的流量策略，包括HTTPS证书、缓存规则、安全策略等
• 支持更复杂的重定向逻辑，比如根据访问地区、设备类型调整跳转规则

三、适配你Docker架构的Nginx配置示例 #

假设你现有Nginx已经处理www.mydomain.com的请求，只需新增一个server块处理裸域名：

# 处理裸域名重定向
server {
    listen 80;
    server_name mydomain.com;

    # 永久重定向到www域名，保留原请求路径和参数
    return 301 $scheme://www.mydomain.com$request_uri;
}

# 你原有处理www域名的server块
server {
    listen 80;
    server_name www.mydomain.com;

    # 反向代理到Gunicorn的配置（注意对应docker-compose里的服务名）
    location / {
        proxy_pass http://django:8000;
        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;
    }
}

如果已经配置了HTTPS，记得在443端口的server块也添加对应的重定向规则，同时确保docker-compose里的Nginx服务正确映射了80/443端口到EC2主机。

总结 #

• 要是想快速实现需求，Nginx配置是最直接高效的选择，完美适配你当前的架构
• 追求更低EC2负载或AWS生态统一管理，Route53重定向是更优方案
• 若有CDN加速需求，CloudFront重定向能兼顾性能和功能扩展性

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