无需在nginx.conf中显式指定域名，将.net重定向到.com

这种场景我处理过好多次了，用Nginx的正则匹配和内置变量就能完美解决，完全满足你用单个nginx.conf搞定所有.net到对应.com重定向的需求，不管是主域名还是多级子域名都能覆盖到。

核心配置（HTTP + HTTPS） #

直接把下面的配置加到你的nginx.conf里就行，位置放在其他server块之前（因为正则匹配的优先级更高，能确保所有.net请求先被捕获）：

# 处理HTTP请求的重定向
server {
    listen 80;
    listen [::]:80;

    # 正则匹配所有以.net结尾的域名，捕获前面的所有内容（包括子域名）
    server_name ~^(.*)\.net$;

    # 301永久重定向到对应的.com域名，保留原协议、路径和参数
    return 301 $scheme://$1.com$request_uri;
}

# 处理HTTPS请求的重定向（如果你的站点启用了HTTPS）
server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name ~^(.*)\.net$;

    # 这里需要配置你的.net域名对应的SSL证书
    # 如果是多级子域名，建议用通配符证书（比如*.yourdomain.net）或者包含所有.net域名的SAN证书
    ssl_certificate /path/to/your/net-wildcard-certificate.pem;
    ssl_certificate_key /path/to/your/net-wildcard-certificate.key;

    return 301 $scheme://$1.com$request_uri;
}

关键细节解释 #

• 正则匹配逻辑：server_name ~^(.*)\.net$里的(.*)会精准捕获.net前面的所有内容——不管是www.whatever、www.sub.whatever还是纯whatever，都能被正确捕获。
• 变量复用：$1就是刚才捕获的内容，直接拼接.com就能得到对应的目标域名；$scheme自动保留原请求的HTTP/HTTPS协议，$request_uri则会完整保留原请求的路径、查询参数，避免重定向后丢失用户的请求内容。
• 状态码选择：用301永久重定向适合生产环境，搜索引擎会更新索引指向新域名；如果只是临时测试，可以换成302临时重定向。

注意事项 #

• SSL证书：如果要处理HTTPS的.net请求，必须配置对应的SSL证书——如果有多个子域名，推荐用通配符证书（比如*.yourdomain.net），这样所有子域名都能覆盖到；要是有跨主域名的.net站点，可能需要用包含所有.net域名的SAN证书。
• 配置验证：修改完配置后，一定要用nginx -t命令检查配置是否合法，确认没问题后再用nginx -s reload重启Nginx生效。
• 匹配优先级：把这个重定向的server块放在其他业务server块前面，确保所有.net请求先被这个规则捕获，不会被其他配置拦截。

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