在 nginx 中实现主域名带 www 与不带 www 的统一，核心做法是在 `server` 块中使用 `if` 指令判断 `$host` 变量，并通过 `return 301` 将请求重定向到标准格式。具体而言，若希望统一为带 www 的域名，需检查 `$host` 是否等于裸域名（如 example.com），若是则返回 301 重定向至 https://www.example.com$request_uri；反之亦然。此方法利用 nginx 内置变量 `$request_uri` 保留原始查询参数和路径，确保 seo 友好且用户体验无缝。
如何配置 server 块以捕获非标准域名请求
要捕获非标准域名请求，需在 `server` 块中设置 `server_name` 并配合 `if` 条件判断。例如，当用户访问 example.com 时，Nginx 会匹配该 server 块，此时通过 `if ($host = 'example.com')` 触发重定向逻辑。关键在于使用 `return 301` 而非 `rewrite`，因为 `return` 更高效且直接终止后续处理，避免不必要的正则表达式开销。同时，必须指定完整的 URL 结构，包括协议、域名和 `$request_uri`，以确保重定向目标准确无误。
server {
listen 80;
server_name example.com;
if ($host = 'example.com') {
return 301 https://www.example.com$request_uri;
}
# 其他配置...
}
上述代码中，`listen 80` 监听 HTTP 端口，`server_name example.com` 明确指定裸域名。当请求到达时，`if` 语句检查 `$host` 是否为 example.com，若是则执行 `return 301`，将请求永久重定向至 https://www.example.com 并附加原始 URI。预期结果是：所有对 example.com 的请求均被重定向至 www 版本，且查询参数（如 ?id=123）得以保留。若需统一为不带 www 的格式，只需交换判断条件和重定向目标即可。
为何推荐使用 return 而非 rewrite 进行重定向
推荐使用 `return` 而非 `rewrite` 进行重定向，主要因为 `return` 是 Nginx 原生指令，执行效率更高且语义更清晰。`rewrite` 基于正则表达式引擎，涉及模式匹配和替换，可能引入额外性能开销和复杂性。例如，使用 `rewrite ^(.*)$ https://www.example.com permanent;` 虽能实现类似效果，但需确保正则表达式正确捕获所有路径，而 `return` 直接构造完整 URL，无需担心正则陷阱。此外，`return` 支持状态码直接指定（如 301），而 `rewrite` 需依赖 `permanent` 或 `redirect` 标志，易混淆。
# 不推荐的 rewrite 写法
server {
listen 80;
server_name example.com;
rewrite ^(.*)$ https://www.example.com$1 permanent;
}
# 推荐的 return 写法
server {
listen 80;
server_name example.com;
if ($host = 'example.com') {
return 301 https://www.example.com$request_uri;
}
}
对比两段代码，`rewrite` 版本使用正则 `^(.*)$` 捕获整个 URI 并拼接到目标 URL，但正则引擎需逐字符匹配，增加 CPU 负担。而 `return` 版本直接引用 `$request_uri` 变量，由 Nginx 内部高效处理，无正则解析步骤。实际测试中，`return` 的重定向延迟更低，尤其在高并发场景下优势明显。因此，除非有特殊需求（如复杂条件分支），否则应优先选用 `return` 实现简单重定向。
如何处理 HTTPS 证书与重定向的兼容性
在处理 HTTPS 证书与重定向的兼容性时，需确保重定向目标域名的 SSL 证书有效且配置正确。例如，若统一为 www.example.com，则必须为该域名部署有效的 SSL 证书，否则浏览器会拒绝连接。建议在 `server` 块中同时监听 443 端口并启用 SSL，同时保留 HTTP 到 HTTPS 的重定向逻辑。此外，需注意 HSTS（HTTP Strict Transport Security）头部的设置，以避免中间人攻击。若未正确配置证书，重定向可能导致循环或安全警告，影响用户体验。
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
# 其他 SSL 配置...
}
server {
listen 80;
server_name example.com www.example.com;
if ($host = 'example.com') {
return 301 https://www.example.com$request_uri;
}
if ($host = 'www.example.com' && $scheme = 'http') {
return 301 https://www.example.com$request_uri;
}
}
上述代码展示了完整方案：第一个 `server` 块处理 HTTPS 流量，绑定 www.example.com 并加载证书；第二个 `server` 块处理 HTTP 流量，统一两个域名的重定向逻辑。当用户访问 http://example.com 时，触发第一个 `if` 重定向至 https://www.example.com；若访问 http://www.example.com，则触发第二个 `if` 重定向至 HTTPS 版本。预期结果是：所有 HTTP 请求均被重定向至安全的 HTTPS www 版本，且证书验证通过。若证书缺失或过期，Nginx 仍会尝试重定向，但浏览器会显示安全错误，因此务必确保证书链完整且有效期覆盖当前时间。
