nginx的return 301必须带$request_uri，否则会截断查询参数导致跳转丢失；$uri不含参数，$host避免多域名绑定错误；私钥权限须为600且属主为nginx用户；http→https重定向必须在独立80端口server块中配置，续期后需手动reload。
HTTPS 不是加个 https:// 前缀就能生效的，必须在服务器层完成证书部署、端口监听、重定向和 TLS 协商。跳过任一环节，浏览器就会显示“不安全”或直接拦截页面。
为什么 Nginx 的 return 301 必须带 $request_uri
常见错误是写成 return 301 https://$host/;，结果所有带参数的 URL（比如 /login?next=/admin）全被截断成根路径，用户登录后跳转丢失。
-
$request_uri保留原始路径 + 查询参数（含#后 fragment 除外） -
$uri只含路径，不含?及之后内容，不能用于重定向 - 用
$host而非$server_name，避免多域名配置时固定死某一个域名 - 务必用
301，302会被浏览器缓存临时跳转，导致 HTTPS 无法稳定生效
Let’s Encrypt 证书路径和权限怎么才算“能用”
证书文件存在 ≠ Nginx 能读取。常见启动失败报错是：SSL_CTX_use_PrivateKey_file("/etc/letsencrypt/live/example.com/privkey.pem") failed (SSL: error:0200100D:system library:fopen:Permission denied)。
- 私钥文件
privkey.pem权限必须是600（仅属主可读写），且属主为运行 Nginx 的用户（通常是www-data或nginx） -
fullchain.pem权限可设为644，但目录/etc/letsencrypt/live/example.com/至少需对 Nginx 用户可执行（755），否则无法进入目录读取文件 - Certbot 默认不会改私钥权限，申请完务必手动执行：
sudo chmod 600 /etc/letsencrypt/live/example.com/privkey.pem - 不要把证书路径写成软链接指向
/etc/letsencrypt/archive/—— Certbot 续期会更新软链接目标，但 Nginx reload 不自动感知，容易卡在旧版本
HTTP 到 HTTPS 的重定向必须在 listen 80 server 块里做
有人试图在 listen 443 ssl 块里用 if ($scheme = http) { return 301 ... }，这是无效的——请求根本到不了这个块，因为 80 端口没监听，连接直接被拒绝。
- 两个独立
server块是硬性要求：一个监听80做强制跳转，一个监听443 ssl做实际服务 - 若使用 CDN（如 Cloudflare），注意关闭其“自动 HTTP 重定向”功能，否则可能和 Nginx 配置叠加，造成循环重定向（301→301→…）
- 本地开发环境（如
localhost）无法申请 Let’s Encrypt 证书，此时可用 mkcert 生成自签名证书，但浏览器会提示不信任，仅用于测试
最易被忽略的一点：证书续期后，Nginx 不会自动重载配置。即使 certbot renew 成功，也必须显式执行 sudo nginx -s reload 或通过 --deploy-hook 触发，否则新证书永远不会生效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
