从HTTP到HTTPS：原理、证书申请与Nginx配置实战-开发者社区

1. 项目概述：一次不得不做的升级

1.1 核心需求解析

先聊聊这个标题背后最实际的问题：为什么一个写惯了HTTP接口的人，突然要折腾HTTPS？

以我做后端开发这几年的经历来看，需求往往来自三个方面：第一种是项目要上线了，安全评审要求必须上HTTPS；第二种是微信小程序、支付宝小程序这类平台强制要求请求域名必须是HTTPS，否则接口直接调不通；第三种是做爬虫或者对接第三方服务时，对方只提供了HTTPS的接口，你绕不过去。

这三种场景我都踩过，尤其是第二种。记得第一次接小程序项目，本地HTTP接口调试得好好的，一上真机环境直接白屏，控制台报的错一串接一串，全是混合内容拦截的提示。那时候才意识到，HTTP和HTTPS之间差的不是一个字母，而是一整套安全机制的升级。

这个项目内容解决的就是这个问题：从HTTP底层的传输机制讲起，拆解HTTPS在HTTP基础上做了哪些事，再演示一个完整的升级过程，包括证书申请、Nginx配置、代码适配这几个环节，最后附上实际可跑的代码示例。

适合谁看呢？我觉得主要是两类人：一类是刚接触Web开发不久，想知道浏览器地址栏那把锁到底是怎么回事的新手；另一类是后端开发或运维，正在接手一个需要从HTTP切换到HTTPS的项目，想找一个能直接照着做的参考。两种需求，这篇文章都能覆盖一部分。

1.2 从HTTP到HTTPS：到底升级了什么

要搞清楚HTTPS做了什么，得先明白HTTP的问题在哪。

HTTP协议设计之初考虑的是"能不能通"，没怎么考虑"安不安全"。你通过HTTP发送的任何内容，包括登录密码、支付信息、聊天记录，在网络上都是以明文形式传输的。这就相当于把信件直接塞进透明信封里邮寄，沿途任何经手的中转节点都能看到内容，而且还能随意篡改。

更麻烦的是，HTTP没有身份验证机制。你访问一个网站，浏览器并不知道这个网站是不是它声称的那个网站。钓鱼网站正是利用这一点，伪装成银行或支付平台，用户根本分辨不出来。

HTTPS解决的就是这两个问题，在HTTP和TCP之间加了一层SSL/TLS协议，用加密来保证传输内容的保密性和完整性，用数字证书来验证服务器身份。所以HTTPS并不是一个新的应用层协议，它仍然是HTTP，只是传输过程被保护起来了。理解了这一点，后面做升级的时候就不会发怵——你不需要改业务逻辑，只需要在传输层把安全机制加上。

1.3 升级前后对比：一张表看清差异

为了让还没接触过HTTPS的读者有个直观印象，我把两者在做实际项目时表现出的差异整理成一张表：

对比维度	HTTP	HTTPS
传输内容	明文，可被直接抓包查看	密文，抓包只能看到乱码
身份验证	无，任何人都能冒充服务器	依赖CA签发的数字证书验证身份
端口	默认80	默认443
性能	无额外握手开销	多一次TLS握手，首次连接稍慢
成本	无需证书	证书有免费和付费两种选择
市场现状	浏览器大量标记"不安全"	已成为主流网站的默认配置

从这张表能看出来，HTTPS的升级不是一个可选项，而是Web开发的基础环境要求。尤其现在主流的浏览器和平台都在强制推动HTTPS，早做早省心，晚做就会收获一堆奇奇怪怪的兼容问题。

2. 核心原理拆解：SSL/TLS与证书机制

2.1 HTTPS为什么能加密：TLS握手过程

要写代码、配环境，不了解TLS握手的过程会很痛苦，因为很多问题（比如连接超时、证书校验失败）都出在握手的某个环节。

TLS握手的核心目标，是让客户端和服务器在不安全的网络上安全地协商出一个对称加密密钥。为什么不直接用非对称加密传输所有数据？因为非对称加密（如RSA）计算开销远大于对称加密（如AES），对服务器压力太大。所以实际方案是：用非对称加密来安全地传递密钥，再用对称加密来处理实际数据。

一个简化版的TLS握手过程是这样的：

客户端发送ClientHello，包含支持的TLS版本、加密套件列表、随机数。
服务器返回ServerHello，选定加密套件，附带自己的数字证书和随机数。
客户端验证证书有效性（是否过期、是否由受信任的CA签发、域名是否匹配）。
验证通过后，客户端生成预主密钥，用服务器的公钥加密后发送过去。
服务器用私钥解密得到预主密钥，双方各自基于预主密钥和随机数计算出最终的对称密钥。
双方互相发送"Finished"消息确认，之后进入加密通信阶段。

我在实际调试中遇到过一个很典型的现象：第一次访问一个HTTPS网站时明显会慢一拍，之后就好了。这就是握手带来的开销，而且浏览器会有会话复用机制，第二次访问时可以跳过部分握手步骤。如果你发现某个HTTPS接口每次请求都非常慢，可以优先排查是不是每次都在做完整的TLS握手，而没有开启会话缓存。

2.2 数字证书：给服务器发一张"身份证"

证书是整个HTTPS体系里最容易被误解的环节。

很多初学者会问：证书不就是个加密文件吗？装上不就行了？其实证书解决的恰恰是身份可信问题。服务器自己可以生成一份公钥和私钥，但如果客户端每次都接受服务器自报的公钥，中间人攻击依然无法防住——攻击者也可以生成一份自己的公私钥对来冒充服务器。

所以才需要证书颁发机构（CA）的存在。CA对服务器的公钥和域名等信息做签名，生成数字证书。客户端预置了一系列受信任的CA根证书，只要服务器出示的证书链能追溯到受信任的根，就认为服务器身份可信。

这里面有个细节容易翻车：证书不仅要做域名匹配，还有有效期限制。我在项目里就遇到过证书过期导致所有接口报错的情况，线上环境一片哀嚎，排查看半天才发现是证书忘了续期。排查这个问题有个诀窍，可以看浏览器的网络请求，或者使用命令行工具检查证书有效期。

2.3 免费证书与付费证书：怎么选

做实际项目时，证书选择直接影响成本和维护方式，我的建议是：

个人项目或内部系统，用免费证书就够了，比如Let's Encrypt、阿里云/腾讯云的免费单域名证书。
企业项目或对外服务，看预算和业务敏感程度。付费证书通常有更高的兼容性，支持更老的系统和浏览器，还有一些购买附加服务的选择。

一个常见误区是：免费证书"不够安全"。实际上传输加密强度上，免费和付费的差别不大，差异主要在信任覆盖范围和服务上。我给小型项目做过一次免费的证书部署，效果完全够用。

2.4 证书类型速查：单域名、多域名与泛域名

证书还有一个选择维度：覆盖的域名范围。

类型	覆盖范围	适用场景
单域名证书	只保护一个域名	只有一个业务的场景
多域名证书（SAN）	可同时保护多个不相关域名	一个服务器跑多个独立站点
泛域名证书	保护一个域名及其所有子域名	多个子项目共用一套基础设施

每个人的情况不太一样，考虑到项目规模和成本预算，需要选择合适的证书类型。如果项目打算长期扩展子域名，泛域名证书在维护上省心很多，不用每个子域名单独申请一张证书。不过这个证书通常比单域名贵不少，预算不够的话，也可以用免费方案，只是维护成本高一些。

3. 升级实战：从零到HTTPS上线

3.1 环境准备与前置条件

实战操作前，先把环境和工具列清楚。我这次演示用的是最常见的组合：一台Ubuntu服务器、Nginx作为Web服务器、Let's Encrypt作为免费证书来源，后端服务是一个简单的Python HTTP接口。

具体环境版本仅供参考：

服务器：Ubuntu 22.04
Web服务器：Nginx 1.24
证书工具：certbot 2.x
后端代码：Python 3.10 + Flask
域名：example.com（实际请替换成你自己的域名）

一个前提条件必须说清楚：申请Let's Encrypt证书要求你拥有域名的解析权或管理权，而且域名必须已解析到服务器的公网IP上。如果你只是在本地用，可以用自签名证书来模拟整个过程，但浏览器会标记不可信，这个后面会说。

3.2 申请免费证书：certbot一行命令

经典手法是用certbot自动申请并配置证书。我的步骤是：

# 安装certbot及Nginx插件 sudo apt update sudo apt install certbot python3-certbot-nginx # 申请证书并在Nginx中自动配置 sudo certbot --nginx -d example.com -d www.example.com

执行过程中，certbot会询问你是否重定向HTTP到HTTPS，建议选"是"。这里本质上是一次全自动的完成流程：certbot会检查域名解析，向Let's Encrypt提出证书申请，然后自动修改Nginx配置并重载服务。

申请完成后，可以在服务器上检查证书文件位置：

sudo ls /etc/letsencrypt/live/example.com/

里面一般有这个4个文件：

cert.pem：服务器证书
chain.pem：中间证书链
fullchain.pem：证书与链的合并文件
privkey.pem：私钥文件

这里有个安全要点，私钥文件权限必须严格控制，不要让无关用户读取，否则如果有人拿到了私钥，就能解密你这个域名的所有通信内容。

3.3 Nginx配置：从80端口到443端口

证书申请完，Nginx需要做一个配置调整。先看看certbot自动生成的效果：

server { listen 443 ssl; server_name example.com www.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; location / { proxy_pass http://127.0.0.1:5000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } server { listen 80; server_name example.com www.example.com; return 301 https://$host$request_uri; }

这段配置做了几件事：

第一个server块监听443端口，启用SSL，指定证书路径，把请求反向代理到本地的Flask服务。
第二个server块监听80端口，把所有请求301重定向到HTTPS。
几个header头字段也很关键，尤其是X-Forwarded-Proto，主要是让后端能感知到请求是通过HTTPS进来的，这个在做重定向逻辑或生成页面链接时特别重要。

这里面有个我踩过的坑：如果后端通过Nginx的X-Forwarded-Proto判断请求协议，但Nginx那一层没配这个header，后端的回调地址就会生成成HTTP链接，导致登录跳转、支付回调这些场景出现奇怪的问题。记得把这个header加上。

3.4 后端代码适配：生产环境强制HTTPS

前面提到过，切换HTTPS后业务代码大部分不用改，但有一个地方必须处理：后端代码签名或跳转时不能用写死的HTTP地址。

拿我用过的Flask服务举例，如果你在代码里写死了一堆绝对路径，升级后就会出问题。一个常见做法是让Flask跳过代理，或者通过配置来控制协议拼接。下面是通用的思路演示：

from flask import Flask, request, redirect app = Flask(__name__) @app.route('/login') def login(): # 确保回调地址为HTTPS callback_url = request.url_root.replace('http://', 'https://') + 'callback' return redirect(callback_url) @app.route('/callback') def callback(): token = request.args.get('token') if token: return f"登录成功，token: {token}" return "缺少token参数" if __name__ == '__main__': app.run(host='127.0.0.1', port=5000)

有人可能会问：代码里手动替换字符串，是不是太土了？确实土，但这个示例主要想说明一个观念：不要让业务代码依赖固定的外部协议。实际项目中更推荐的做法是使用反向代理来处理协议头，后端只从传递的值中读取Protocol，这样对代码的侵入最小。

3.5 混合内容问题：为什么页面加载还是报HTTPS错误

把服务切到HTTPS后，有个高频问题：浏览器仍然拦截部分内容，控制台提示混合内容（Mixed Content）。

这里需要解释一下。如果页面本身是通过HTTPS加载的，但页面里引用了HTTP的资源（比如图片、脚本、样式、接口请求），浏览器会认为这破坏了加密页面的完整性，于是直接阻止加载。国密浏览器的处理逻辑是这样：图片类静态资源一般会警告，但也有些资源属于完全拦截。

我自己实际排查过的场景：

页面里的广告代码写死了HTTP链接，导致接口数据加载不出来。
数据库里存储的文章内容，图片地址是http://开头。
第三方统计脚本没更新，不支持HTTPS加载。

解决方案大致有几种：批量替换数据库或前端代码里的HTTP资源地址，通过Nginx反向代理HTTP资源做一层映射，或者把静态资源迁移到CDN并用HTTPS访问。最彻底的办法还是把资源统一改成HTTPS，毕竟现在的对象存储和CDN服务基本都支持HTTPS访问。

4. 代码示例详解：Python实现HTTP与HTTPS客户端对比

4.1 用Python请求HTTP与HTTPS接口的差异

写代码时经常需要验证接口是HTTP还是HTTPS，直接写个Python脚本就够了。

import urllib.request import ssl def fetch_http(url): """直接请求HTTP接口""" with urllib.request.urlopen(url) as resp: return resp.status, resp.read().decode('utf-8') def fetch_https_without_verify(url): """请求HTTPS接口但跳过证书校验（仅用于调试）""" ctx = ssl.create_default_context() ctx.check_hostname = False ctx.verify_mode = ssl.CERT_NONE with urllib.request.urlopen(url, context=ctx) as resp: return resp.status, resp.read().decode('utf-8') def fetch_https_with_verify(url): """请求HTTPS接口并校验证书（线上推荐）""" with urllib.request.urlopen(url) as resp: return resp.status, resp.read().decode('utf-8') if __name__ == '__main__': # 实际测试时把域名替换成自己的 print(fetch_http("http://example.com/api/test")) # 下面这句在证书不可信时会抛出ssl.SSLError，用于验证TLS握手 print(fetch_https_with_verify("https://example.com/api/test"))

这个脚本里的三种方式分别代表三种场景。第一种是明文HTTP请求。第二种是跳过证书校验的HTTPS请求，这在某些内网测试或自签名证书场景下会用到，但线上最好不要开，开了等于放弃HTTPS的核心防护。第三种是正常校验证书的HTTPS请求，这是生产环境应该使用的模式。

4.2 用requests库处理HTTPS证书异常

实际项目中我用urllib用得少，更多是用requests库。有一个比较典型的异常处理套路：

import requests import urllib3 # 关闭InsecureRequestWarning警告（仅在明确知道风险时可这么做） urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) def request_with_tls_check(url, token=None, verify=True): headers = {} if token: headers['Authorization'] = f'Bearer {token}' try: resp = requests.get(url, headers=headers, verify=verify, timeout=10) resp.raise_for_status() return resp.json() except requests.exceptions.SSLError as e: print(f"TLS证书校验失败: {e}") if verify: print("可尝试verify=False调试，但线上不要用") except requests.exceptions.Timeout as e: print(f"请求超时: {e}") except requests.exceptions.RequestException as e: print(f"请求异常: {e}") return None

requests库返回SSL相关错误时，主要分两种情况：一种是证书过期或不可信，报CERTIFICATE_VERIFY_FAILED；还有一种是域名与证书不匹配，报HOSTNAME_MISMATCH。排查时先确认证书有效期，再确认证书绑定的域名。

我在给一些老系统对接时遇到过这种问题：对方的证书是自签名或内部CA签发的，没有进入系统的受信任根证书库，导致代码报SSL错误。这种情况下，可以单独把对方的CA证书加入信任列表，也可以只针对这个请求关闭校验。两种做法各有利弊，但个人建议还是把CA证书处理好，比较稳妥。

4.3 代码里常见的4个HTTPS调试手段

代码层面调试HTTPS，有几个实用的手段值得记录一下：

手段	命令/工具	主要用途
查看证书详情	`openssl s_client -connect example.com:443 -servername example.com`	确认证书链、有效期、加密套件
抓包分析	Wireshark + TLS解密配置	查看TLS握手过程
服务器测试	certbot renew --dry-run	验证证书续期流程是否正常
在线检测	SSL Labs等工具	评估站点HTTPS配置的安全等级

把这些工具配合起来使用，基本能解决开发阶段90%的HTTPS疑难杂症。如果连接直接失败，先测试连通性，再继续后面的步骤。还可以用openssl的verify命令来校验证书文件是否是等价的，尤其在做证书轮换时很有用。

5. 常见问题与排查技巧实录

5.1 8个高频报错与对策

整理一下我在实际项目中遇到的高频问题，按出现频率从高到低排列：

1. 证书过期或不可信

表现：浏览器提示SEC_ERROR_EXPIRED_CERTIFICATE等。
解决：登录服务器查看证书有效期，确认过期后更新证书。使用certbot的一般来说可以自动续期，但要确保定时任务存在。
提示：Kubernetes和Docker等多种环境部署时，需要逐一检查容器内的证书挂载情况，避免只更新了宿主机却忘了容器。

2. 域名与证书不匹配

表现：浏览器提示证书不是为该域名签发的。
解决：确认证书绑定的域名是否包含你要访问的域名。泛域名证书保护一级子域名，二级及以下不会覆盖。
提示：访问IP地址更是非常容易触发此类错误。

3. HTTP自动跳转HTTPS失效

表现：访问http://正常，但没有自动跳转。
解决：检查Nginx配置里80端口server块是否有return 301指令，或者配置的替换规则不对。
提示：有些服务（如某些负载均衡器）会在外部做更复杂的跳转逻辑。

4. 混合内容被拦截

表现：页面加载正常，但控制台报Mixed Content错误。
解决：把所有HTTP资源引用改成HTTPS，或改用协议相对URL。
提示：数据库里的历史数据，建议做一次全量替换。

5. TLS握手超时

表现：接口响应极其缓慢，甚至超时。
解决：先检查TLS版本和加密套件是否兼容，再排查服务器的握手缓存设置。
提示：老设备（比如某些旧版Android系统）可能不支持新TLS版本。

6. 后端拿到HTTPS请求但生成的链接是HTTP

表现：页面能打开，但回调、跳转、分享链接都是http://。
解决：检查反向代理是否配置了X-Forwarded-Proto，后端是否读取正确。
提示：这篇博文里的Nginx配置段就是标准写法，可以直接参考。

7. Java/Go等其他语言的证书库缺失

表现：代码运行时报PKIX path building failed或chain certificate error。
解决：把证书链导入到语言的信任库中。
提示：不同语言的信任库不通用，Python、Java、Go要分别处理一下。

8. 证书续期失败

表现：certbot renew报错，或者证书一直没更新。
解决：查看cron或systemd timer是否正常执行，检查80端口是否被占用。
提示：有些云服务器的防火墙规则会拦截HTTP验证请求。

5.2 免费证书续期：自动化配置

Let's Encrypt证书有效期只有90天，手动续期是不现实的。certbot安装时一般会自动配置定时任务，但最好还是自己确认一下：

# 查看systemd timer是否生效 sudo systemctl list-timers | grep certbot # 手动测试续期 sudo certbot renew --dry-run

如果dry-run失败，常见原因是80端口没有被外部访问到，因为证书续期需要验证服务器对域名的控制权。另外，如果用了CDN或全站加速，让证书验证请求绕过了源站，续期也会失败。

我在生产环境会额外写一个每日检查脚本，把证书过期时间不足30天的域名列出来并告警，防止定时任务失效后没有察觉。

5.3 开启TLS相关配置前，先做兼容性评估

有一些优化项（比如TLS 1.3、HTTP/2、OCSP Stapling）确实能改善性能，但如果你的用户群里有很老的客户端或少数特殊场景，先做兼容性评估会比较稳妥。

功能	建议	理由
TLS 1.3	默认开启	主流系统浏览器均支持，官方解释是性能更好
HTTP/2	默认开启	多路复用能显著减少请求队列，不过涉及页面资源较多时需要额外适配
老加密套件	尽量关闭	一些老版本浏览器会受影响，业界已不推荐使用这些较弱套件
OCSP Stapling	可开启	减少客户端向CA查询证书状态的往返，但中继链路较长时不是主要瓶颈

做这类配置调整时，我的经验是先在测试环境用老版本浏览器或操作系统访问一遍，确认关键功能不挂，再逐步灰度上线。

6. 性能影响与优化建议

6.1 HTTPS真的会让网站变慢吗

"HTTPS性能比HTTP差"是很多人的第一印象，但实际上并非绝对。TLS握手确实多消耗一些往返时间，不过这个开销在全局里只占很小比例。很多站点的性能消耗大头其实来自页面本身：资源数量、接口数量、DNS解析、TCP建连、服务端响应时间等。

我做过一个印象深刻的对比：同一套页面，HTTP和HTTPS的首次加载差异大概在一两百毫秒的量级，但HTTP的明文传输在用户侧体验上更让人担心。如果你觉得HTTPS慢，先看整体性能数据，不要直接把锅扣在TLS头上。

真正的优化方向是减少握手次数。比如开启TLS会话缓存和会话票据，让同一个客户端在一段时间内不用重新完整握手。Nginx里的配置大概是这样的：

ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; ssl_session_tickets on;

6.2 启用HTTP/2提升并发效率

H2协议解决了HTTP/1.1的队头阻塞问题，允许同一个连接并行传输多个资源。因为多路复用机制的变化，启用后会有几个连带变化：资源请求的排序不再像以前那么关键，合并文件的传统方案反而可能造成浪费。

不过HTTP/2对服务器有要求，需要配套了合适的TLS配置才能更好发挥。

6.3 证书链合并与部署检查

证书链如果太长，服务器给客户端发证书时要多发送几个中间证书，客户端验证时也需要多几步，这会影响握手速度。手动处理证书文件时，注意确认链文件是否完整，Nginx建议使用fullchain.pem和privkey.pem。

另外在配置完成后，用在线检测工具检查一遍部署状态很有帮助，主要确认证书链是否完整、协议版本是否支持、TLS配置的安全评级。

7. 特殊场景：自签名证书与本地开发

7.1 生成本地自签名证书

本地开发时如果不想折腾域名和公网验证，可以使用自签名证书实现HTTPS模拟。生成命令如下：

openssl req -x509 -newkey rsa:2048 -sha256 -days 365 \ -nodes -keyout example.key -out example.crt \ -subj "/CN=localhost"

但这份证书签发时并不受浏览器信任，浏览器访问时会弹出警告页面，需要手动选择"仍要访问"。这只能用于本地开发调试。

7.2 自签名证书的三个适用场景

本地开发联调：模拟HTTPS环境，验证页面是否存在混合内容问题。
内部系统测试：比如某些局域网工具，大家能接受浏览器的安全提示。
教学演示：需要展示TLS握手或证书校验流程时，自签名证书是了解原理的很好材料。

使用时记得设置好hosts或明确访问IP，注意浏览器对IP地址的证书校验通常更严格。

7.3 mkcert：让本地开发更省心

如果觉得自签名的警告太烦人，可以试试mkcert这个工具。它的原理是创建一份本地根证书，并把根证书加入系统信任区，然后用它签发任意域名的证书。由于根证书被信任，签出来的证书浏览器直接认可，体验和正式证书基本一致。

mkcert安装和使用的流程挺简单，适合经常需要本地跑HTTPS的开发者。

8. 迁移排查清单与实操心得

8.1 迁移HTTPS的10项检查清单

切HTTPS不是改个端口就结束，涉及代码、配置、CDN、第三方服务多个层面。我整理了一份常用的检查清单：

确认证书已安装且未过期。
确认HTTP已301重定向到HTTPS。
确认HSTS响应头已按需配置。
检查页面内所有资源均为HTTPS。
检查数据库内存储的链接。
检查后端回调地址是否从协议头正确推导。
检查反向代理的X-Forwarded-Proto设置。
检查CDN源站协议策略。
检查证书续期任务正常运行。
在移动端和旧版浏览器做兼容性抽查。

8.2 我对HTTPS升级的个人体会

把HTTP升级成HTTPS，看起来好像是改改配置、申请个证书就完事了，但真正落到实际项目里，难点往往不是操作步骤，而是那些影响范围比预期更大的隐含改动。

我在第一次做迁移时，只准备了自己负责的接口升级，结果忘了处理前端打包里的资源链接、安全审查提出的HSTS要求、以及把混合内容警告当噪音忽略的问题，上线后排查了很长时间。后来再遇到这类任务，我的流程会固定下来：先列影响清单，再逐个模块确认，最后一次性做全量回归。

给别人做这个项目的建议时，我常说的一句话是：不要把HTTPS当成一次配置调整，把它当成一次小型架构变更来对待。证书可以几分钟申请完，但整个链路的检查一定不能省。

另外，如果是在云平台上操作，建议先检查平台提供的负载均衡和证书托管服务。很多云厂商支持自动续期，可以让运维工作减少很多。这些托管服务虽然不能覆盖所有定制需求，但能解决大部分常规站点的HTTPS管理问题。

上面这些内容覆盖了从原理到实操、从代码到排查的完整过程，根据自己的项目情况按需选用即可。实际动手时，多注意安全配置和生产环境差异，多测试，基本上都能把HTTP到HTTPS这条升级路走得比想象中更顺利。