一、为什么 HTTPS 部署后还要保留 80 端口¶

很多人第一次做 HTTPS 时，会只想着把站点改到 443。
但原笔记在单机 HTTPS 之后，专门又讲了“HTTP 跳转 HTTPS”，这说明真实使用场景里：

• 用户仍可能先访问 http://
• 站点需要自动把用户引导到 https://

否则就会出现：

• 浏览器里输入旧地址
• 结果访问不到或体验割裂

所以，标准做法通常是：

• 80 端口只负责跳转
• 443 端口负责真正提供加密站点

二、return 实现 HTTP 跳 HTTPS 的写法¶

原笔记的第一种方案是：

server {
  listen 80;
  server_name ssl.harbor-local.cn;
  return 301 https://ssl.harbor-local.cn$request_uri;
}

server {
  listen 443 ssl;
  server_name ssl.harbor-local.cn;
  root /app/code/ssl;

  ssl_certificate /etc/nginx/ssl_keys/www.harbor-local.cn.pem;
  ssl_certificate_key /etc/nginx/ssl_keys/www.harbor-local.cn.key;

  error_log /var/log/nginx/ssl-error.log notice;
  access_log /var/log/nginx/ssl-access.log main;

  location / {
    index index.html;
  }
}

这里的关键在于：

• return 301 表示永久跳转
• $request_uri 用来保留用户原始访问的路径和参数

例如用户访问：

http://ssl.harbor-local.cn/index.html

就会被自动引导到：

https://ssl.harbor-local.cn/index.html

三、为什么很多场景更推荐 return¶

从原笔记的配置顺序可以看出，return 被放在前面并不是偶然。
因为对于这种“固定跳到同域名 HTTPS”的需求来说，return 的优点很明显：

• 写法简洁
• 语义直接
• 可读性高

当需求足够简单时，用 return 301 往往比写正则更清晰。

四、rewrite 实现 HTTP 跳 HTTPS 的写法¶

原笔记的第二种方案是：

server {
  listen 80;
  server_name ssl.harbor-local.cn;
  rewrite ^(.*)$ https://ssl.harbor-local.cn$1;
}

server {
  listen 443 ssl;
  server_name ssl.harbor-local.cn;
  root /app/code/ssl;

  ssl_certificate /etc/nginx/ssl_keys/www.harbor-local.cn.pem;
  ssl_certificate_key /etc/nginx/ssl_keys/www.harbor-local.cn.key;

  error_log /var/log/nginx/ssl-error.log notice;
  access_log /var/log/nginx/ssl-access.log main;

  location / {
    index index.html;
  }
}

它的思路是：

• 用正则 ^(.*)$ 捕获整个 URI
• 再把 URI 拼接到新的 https 地址后面

这种写法也能实现跳转，但相对 return 来说会更偏“改写”思维。

五、两种写法最核心的区别是什么¶

结合原笔记的内容，可以把差异简单理解为：

对当前这个“HTTP 统一跳 HTTPS”的需求来说，两者都能用。
但如果只是单纯做站点统一升级：

• 通常优先选 return

如果后续还涉及：

• 多规则匹配
• 路径改写
• 条件分流

那 rewrite 的扩展性会更强。

六、为什么测试前还要清浏览器缓存¶

原笔记在测试时专门提醒：

• 打开浏览器前先清缓存
• 快捷方式是 Ctrl + Shift + Delete

这主要是因为：

• 浏览器会缓存重定向结果
• 尤其是 301 永久跳转，影响更明显

如果不清缓存，很容易误以为配置没生效，实际上是浏览器直接用了旧跳转结果。

七、小结¶

HTTP 跳 HTTPS 是 HTTPS 部署中几乎必不可少的一步。
原笔记给出的两种方式已经覆盖了最常见的做法：

• return 301 https://域名$request_uri
• rewrite ^(.*)$ https://域名$1

从实用角度看：

• 简单跳转优先用 return
• 复杂路径改写再考虑 rewrite

把这一步配置好，HTTPS 站点的访问入口才算真正完整。