开启 HTTPS 详细教程

前提

  1. 服务器
  2. 域名
  3. 备案

域名

购买域名的时候需要注意,不需要买 专业版DNS解析 如果不知道这个东西大概率没有需求!

image-20240905145519033

域名的不同层级

顶级域名(TLD)和二级域名是域名结构中的不同层级。

  1. 顶级域名 (TLD):这是域名的最高层级,通常位于域名的最后部分,比如 .com.org.net.cn 等等。每个域名都必须有一个顶级域名。

  2. 二级域名 (SLD):这是顶级域名前的部分,通常是你注册的名称,用于识别网站或组织。比如在 example.com 中,example 就是二级域名。

  3. 二级域名的子域名(通常称为子域名):是在二级域名前再加一部分,比如 api.example.com 中的 api 就是子域名。

举例来说:

  • 顶级域名com 是顶级域名。
  • 二级域名example.com 是二级域名,其中 example 是二级域名的具体名称,.com 是顶级域名。
  • 子域名api.example.com 中的 apiexample.com 的子域名。

域名 和 SSL 关系

域名是互联网上用于标识网站或服务的唯一地址,比如 example.com。它分为多个层级,常见的有顶级域名(TLD,比如 .com.org)和二级域名(如 www.example.com 中的 www)。二级域名通常用来表示同一域名下的不同子网站或服务。

关于 SSL 证书,每一个二级域名是否需要单独的 SSL 证书取决于你使用的证书类型:

  1. 单域名 SSL 证书:只保护一个特定的域名,比如 example.com,但不能保护二级域名(如 sub.example.com)。

  2. 多域名 SSL 证书(SAN 证书):可以保护多个不同的域名,包括二级域名,但需要你在申请时列出这些域名。

  3. 通配符 SSL 证书:可以保护一个主域名及其所有二级域名,比如 *.example.com,这意味着它同时保护 www.example.comapi.example.com 等等。

如果你有很多二级域名,使用通配符证书可以简化 SSL 证书管理,否则每个二级域名都需要单独的 SSL 证书。

所以我们使用 通配符 SSL 证书 ,如果不用通配符那么就需要单独为 leikooo.com 和 api.leikooo.com 申请两个 SSL 证书,当然流程都是一样的,下面就用 通配符 SSL 做演示!

申请 SSL

我是用的第三方的 SSL 当然腾讯、阿里的 SSL 都是可以的,但是要注意一件事:域名 + 服务器 一定要是同一家的,不然可能会出问题!

OHTTPS

1、

image-20240906171340574

2、

image-20240905152726826

他有一个 365 天的付费证书,但是不需要,选择后面的 90 天的免费证书就行

输入的域名:*.leikooo.com 不要照抄我的,写自己买的域名

3、

image-20240905153442323

4、

比如我的:

主机记录:_acme-challenge.leikooo.com

记录值: _acme-challenge.3ejqm8pg2678gd7n.ohttps.com

image-20240905154713249 image-20240905154039301

域名后台:

  1. 主机记录,只需要写 _acme-challenge (看自己的是什么,这里只是演示)
  2. 记录类型选择 CNAME
  3. 记录值 直接 CV 就行

5、检查是否创建成功

image-20240905154504516

6、等一会~

image-20240905154539380

7、创建成功!

image-20240905154809961

8、转换格式方便后端部署使用

image-20240905155317708 image-20240905155422413

证书格式网站:https://myssl.com/cert_convert.html

image-20240905155854597 image-20240905160034621 image-20240906170535088

9、下载 .key 后缀文件、和 .cer 后缀文件 方便后面原生 Nginx 部署时使用

image-20240906145825556

必要设置

宝塔

1、宝塔安装 Nginx

image-20240906153814080 image-20240906153855695

2、添加前端项目

image-20240906155150856

域名根据自己实际情况填写

3、添加关于后端的项目

image-20240906155100325

4、设置证书和密钥

image-20240906161038215 image-20240906161045353

后端网站也是按照这个流程上传 key 和 cer

5、后端站点设置反向代理,前端站点选中打包上传的目录

前端站点:

image-20240906161321594

后端站点

image-20240906161512514

小插曲,直接访问 接口文档出现下面的情况

image-20240906165028439

解决办法:需要把上面默认目标URL 改成 https

最终效果

比如我的后端项目运行在 9090 端口我就可以这样写

image-20240906165328644 image-20240906165614339

原生 Nginx

1、创建一个文件夹放 key、cer 文件

cmd
复制代码
cd ~ mkdir key

2、把之前下载好的 key 、cer 文件上传到服务器的 /root/key 文件夹,也就是我们上面创建好的文件夹

1)rz 命令

2)WinSCP

3)其他支持上传的工具

image-20240906163852454

3、查看 Nginx 配置文件

nginx
复制代码
nginx -t

如果报错 command not found 就看上面的安装教程,设置一下环境变量就好

image-20240906163413542

4、修改 Nginx 配置文件

text
复制代码
vi /usr/local/nginx/conf/nginx.conf
nginx
复制代码
server { # 把 80 改成 443 ssl listen 443 ssl; server_name www.leikooo.cn leikooo.cn; # ssl 最后的文件名根据实际情况修改 ssl_certificate /usr/key/fullchain.cer; ssl_certificate_key /usr/key/cert.key ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; root /root/project/fronted; location / { index index.html index.htm; try_files $uri $uri/ /index.html; } } # 如果使用 http 转到 https server { listen 80; server_name www.leikooo.cn leikooo.cn; return 301 https://$server_name$request_uri; }
nginx
复制代码
server { listen 443 ssl; server_name api.leikooo.cn; # ssl 和上面的几乎一项 ssl_certificate /usr/key/fullchain.cer; ssl_certificate_key /usr/key/cert.key ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; location / { # 反向代理,根据自己后端实际运行地址端口修改 proxy_pass https://localhost:9090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

前端

前端其实对于 Https 需要代码修改的部分不多,主要就是修改访问后端的地址(修改 baseURL 找不到全局搜索):

text
复制代码
/** * @name request 配置,可以配置错误处理 * 它基于 axios 和 ahooks 的 useRequest 提供了一套统一的网络请求和错误处理方案。 * @doc https://umijs.org/docs/max/request#配置 */ export const request = { baseURL: 'https://api.leikooo.com', withCredentials: true, ...errorConfig, };
image.png

后端

  • 需要格式 JKS
  • 需要文件密码 (上面证书格式转化时候填写的密码)

1、修改配置文件

yml
复制代码
server: ssl: key-store: classpath:_.leikooo.com.jks key-store-type: JKS key-store-password: 密码

_.leikooo.com.jks 这个具体是 jks 文件名称,自己是什么就填写什么就好

2、

需要把 jks 文件,放到 resource 目录下面

text
复制代码
├─java └─resources ├─_.leikooo.com.jks
image-20240906150703646

3、然后打包上传到服务器上,运行就好了!

4、访问线上接口文档,可以发现是 HTTPS 了!

image-20240906151106212
0个评论
点击登录,快来和大家讨论吧~
表情
图片
暂无评论
leikooo
作者分享
DeepSeek Harness 缓存命中率太惊人了,有时候竟然能到 99%,看鱼皮哥的视频竟然还出现过 100% 😱 https://www.bilibili.com/video/BV1VkgK6NEZS
7
ARTS 0809: 反转链表、Shopify 如何用 MySQL 解决超卖与 AI 时代程序员的价值
5
译文:《SwiftUI 七年:平庸的故事》 SwiftUI 在 2019 年高调发布,本应成为苹果全平台成熟、可量产的 UI 未来。七年过去,到了 2026 年,它仍像一场永不结束的 beta:布局难预期、性能不稳、数据流混乱,还几乎没有可靠的向后兼容,开发者被迫写一堆 shim 和 workaround。 作者用苹果官方教程(甚至是有问题的)以及与 UIKit 的对比说明:SwiftUI 用“看起来方便”换掉了精确的工程控制。更深一层,他认为这反映了苹果从 Cocoa、Aqua、Auto Layout 那种不妥协的工艺,转向“够用就行”的企业文化。 SwiftUI 为何存在 苹果并非单纯想提供更好工具,而是不得不应对竞争:React、React Native、Flutter 让“一套代码多端跑”变得诱人;Mac 上原生应用又日渐被网页和 Electron 吃掉。SwiftUI 要同时拴住原生生态、并降低移植到 Mac 的成本。卖点是:响应式数据流、声明式布局、跨平台复用。 数据流 “单一数据源”听起来很美,实际却是 @State、@Binding、ObservedObject,再到 Observation / @Observable 的不断换代。你很难确定视图会更新几次、为何更新;它该忽略的变化会反应,该关心的变化又可能忽略 - - 像个黑盒。 布局系统 基于尺寸协商的布局在 Keynote 里很合理,做浮动视图、自定义侧边栏时却极度不稳定。官方教程里一个很普通的侧边栏,多年仍有问题。布局脆弱到最后往往只能上 GeometryReader - - 一旦用了,声明式优势就没了,还要手算坐标,而且下一版布局规则一变,数学还得重写。 API 稳定与功能对等 代码里满是 if #available。滚动收起键盘要到 iOS 16;工具栏定制很晚才来;网络图片 AsyncImage 要到 iOS 15,缓存相关 API 到 2026 年 7 月仍在 beta。旧 API 常被换掉(如 NavigationView → NavigationStack),开发者要维护多套实现,等于替苹果做 QA。对比 Android 的 Jetpack Compose 可作为依赖打包回退到旧设备,SwiftUI 做不到“写最新 API、稳定回退”。 性能 在真实对比里,即便做了后台解码等优化,SwiftUI 图片网格滚动仍明显不如 UIKit。若展示一堆 JPEG 都得靠顶级芯片撑,架构本身就有问题。 跨平台神话 苹果说的是“学一次、到处用”,不是“写一次、到处跑”。iOS 上学到的布局很少直接适用 Mac;同一套 view 跨平台实现也不一致。结果常变成:学一次、再学一次、某处能用、处处要调。 哲学转向 最大的问题是“够用就行”:覆盖 90% 用例就算成功,用 velocity 掩盖质量下降。作者列举系统与一线应用中的各种瑕疵,认为这不是偶然,而是苹果主动降低质量门槛 - - 所以即使过了七年,他仍不信任 SwiftUI。 结论 对构建稳定、高性能、可维护系统真正重要的部分,SwiftUI 几乎都有问题。它不是“极差”,而是平庸 - - 用假便利换真精度,要么你花时间给框架打补丁,要么把半成品发出去。作者更宁愿继续用“遗留”的 UIKit / AppKit。 最后小总结: 最让人不能接受的不是“SwiftUI 还有 bug”,而是它把“看起来很快”当成了工程上的完成态。声明式、预览、跨平台,每一项都在秀高级感,可真正写进业务后,你面对的是难预测的重绘、脆弱的布局、层层 #available,以及把兼容和排错外包给业务方的现实。七年够长了,若还靠“框架还年轻”解释,那更像是对标准的侮辱。技术选型从来不只是语法偏好,而是你选的是可预期性、可维护成本,以及对用户体验的态度。平庸的“成功”往往比明显失败更危险 ,你说它能上线、能 demo、能交差,但是却在细节里一点点磨损信任。工具可以换代,但对质量的要求不该跟着一起降级。
4
ARTS 0802: 合并有序链表、AI 时代的技术断层与 TCP 200ms 延迟之谜
5
Spring 团队开发者布道师 Josh Long,从 2011 年起每周二坚持写 This Week in Spring https://spring.io/authors/joshlong,大概 15 年半从未间断,到现在大概写了 800 期以上😱 大佬在采访里他说,写博客不是额外负担,而是逼自己整理每周所学的「强制机制」——反正本来就会刷社区动态,写出来既方便自己,也帮到别人。更重要的是 Spring 一直在变:微服务、AI……永远有新东西可聊,停一周就容易掉队。一旦养成习惯,坚持往往比重新开始更容易。 这种级别的大佬都还在用周更逼自己不掉队,我更没理由再拖了。还有之前左耳朵耗子大佬说的 ARTS 打卡,我老实说只撑了两周,真的需要捡起来了,加油✊
10
下载 APP