在 linux 中管理 nginx https 强制跳转，最优雅的做法是利用 $scheme 变量判断协议，并通过 return 301 指令将 http 请求重定向到对应的 https url。具体做法是在监听 80 端口的 server 块中配置重定向规则，而在监听 443 端口且启用 ssl 的 server 块中处理实际业务逻辑。这样做能确保所有明文流量都被安全地加密传输，同时保持配置的清晰和可维护性。
Nginx 如何根据协议类型区分处理 HTTP 与 HTTPS 请求
通过检查 $scheme 变量的值，Nginx 可以明确区分当前请求是 HTTP 还是 HTTPS。当值为 http 时，执行重定向；当值为 https 时，继续后续的业务处理。这种基于变量的条件判断是构建安全跳转逻辑的核心。
server {
listen 80;
server_name example.com;
# 如果协议是 http，则永久重定向到 https
if ($scheme = http) {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/ssl/certs/example.com.crt;
ssl_certificate_key /etc/ssl/private/example.com.key;
location / {
proxy_pass http://backend_app;
}
}
上述配置展示了完整的分离式结构。第一个 server 块专门负责拦截非加密流量，利用 if 语句检测 $scheme。一旦确认是 HTTP，立即返回 301 状态码，并将客户端引导至 https://$host$request_uri。第二个 server 块则绑定 443 端口并加载 SSL 证书，处理正常的 HTTPS 请求。这种写法避免了在同一个 server 块中混合使用 listen 80 和 listen 443 导致的逻辑混乱，使得每个模块职责单一。
如何确保重定向后的 URL 保留原始路径和查询参数
在构造重定向目标时，必须使用 $host 和 $request_uri 变量来动态拼接新的 URL。$host 提取请求头中的主机名，$request_uri 包含完整的 URI 字符串（含查询参数）。这样无论用户访问的是根目录还是深层链接，重定向后都能准确还原原始路径。
# 假设用户访问：http://example.com/search?q=nginx&lang=zh
# $host 的值为：example.com
# $request_uri 的值为：/search?q=nginx&lang=zh
# 最终重定向地址为：https://example.com/search?q=nginx&lang=zh
if ($scheme = http) {
return 301 https://$host$request_uri;
}
这种动态拼接方式确保了用户体验的一致性。例如，当用户从搜索引擎点击一个带有特定参数的 HTTP 链接时，服务器不会丢失这些参数，而是将其原封不动地附加到 HTTPS URL 之后。测试时可以使用 curl -I http://example.com/path?param=value 命令验证响应头中的 Location 字段是否完整包含了路径和参数。若发现参数丢失，通常是因为错误地使用了 $uri 而非 $request_uri，前者不包含查询字符串。
当 SSL 证书配置错误或连接失败时 Nginx 如何处理 HTTPS 请求
如果在监听 443 端口的 server 块中 SSL 证书路径错误或文件权限不足，Nginx 将无法启动或拒绝处理该域名的 HTTPS 请求。此时，浏览器会显示安全警告或直接连接超时。为了优雅管理这种情况，应确保 ssl_certificate 和 ssl_certificate_key 指向正确的绝对路径，并赋予 Nginx 进程读取权限。此外，可通过 nginx -t 命令在重启前验证配置语法和证书有效性，避免服务中断。
