前几天我在处理公司网站时遇到了一个问题：同一个网站，我的电脑和手机都能打开，另一台电脑却打不开，而且三台设备连的还是同一个 Wi-Fi。

我一开始觉得，既然大家连的是同一个 Wi-Fi，那访问结果应该也是一样的。后来继续检查才发现，我把“网络相同”和“访问过程相同”当成了一回事。实际上，每台设备的 DNS、浏览器缓存、代理、HTTPS 设置和安全软件都可能不一样。

这次问题最后还牵扯出了 HTTP、HTTPS、80 和 443 端口，以及安全证书。以前我知道 HTTPS 更安全，但并没有真正理解它们是怎么连在一起的。

先说这次网站为什么有的设备能打开

当时的网站可以通过 HTTP 访问，但是 HTTPS 没有正确配置。能打开网站的设备访问的是 http://www.lszyfwh.com，另一台电脑可能因为浏览器设置、以前留下的跳转记录，或者 HSTS，自动尝试访问了 https://www.lszyfwh.com。

这两个地址看起来只是多了一个字母，但实际连接的入口并不一样：

  1. HTTP 通常使用 80 端口。
  1. HTTPS 通常使用 443 端口。

如果服务器只开了 80 端口，那么 HTTP 可以访问，不代表 HTTPS 也可以访问。浏览器连接 443 端口时，可能会直接显示连接被拒绝。

这也是我这次学到的第一个判断方法：不要只说网站“能打开”或者“打不开”，而要先看访问的是 HTTP 还是 HTTPS，以及浏览器显示的具体错误。

HTTP 是什么

HTTP 是浏览器和服务器之间交换信息的一套规则。浏览器向服务器发送请求，服务器处理以后再返回响应。

比如我们打开一个文章页面时，浏览器会告诉服务器自己想访问哪个地址。服务器找到对应内容以后，会返回状态码、网页内容和其他信息。

HTTP 负责的是双方怎样交流，但普通 HTTP 本身没有保护通信内容。如果数据在传输过程中被别人截获，对方可能看到里面的内容，也可能对内容进行修改。

所以像密码、Cookie、登录状态和表单数据，都不适合直接通过普通 HTTP 传输。

HTTPS 和 HTTP 到底是什么关系

以前我会把 HTTP 和 HTTPS 当成两套不同的东西。后来才理解，HTTPS 并不是把 HTTP 完全换掉，而是先通过 TLS 建立一条安全连接，再在这条连接里传输 HTTP 请求和响应。

一个比较简单的访问过程是：

  1. 浏览器连接服务器的 443 端口。
  1. 浏览器和服务器进行 TLS 握手。
  1. 浏览器检查服务器提供的安全证书。
  1. 双方协商后续通信使用的密钥。
  1. 安全连接建立完成，再开始传输 HTTP 数据。

TLS 主要保护三件事：

  1. 机密性：让其他人即使截获数据，也很难直接读懂内容。
  1. 完整性：如果传输内容被修改，通信双方可以发现。
  1. 身份验证：确认当前连接的服务器确实有权代表这个域名。

我之前还有一个理解不准确的地方，以为安全证书本身就是用来加密整个网页的。实际上，大量网页数据一般由 TLS 握手时协商出来的会话密钥进行加密。证书更重要的作用，是证明域名身份，并把域名和公钥联系起来。

HTTPS 安全证书是什么

大家平时常说的“SSL 证书”，现在更准确地说应该是 TLS 证书。证书中通常会记录域名、公钥、颁发机构、有效期和签名等信息。

浏览器访问 HTTPS 网站时，会检查下面这些内容：

  1. 证书中的域名和当前访问的域名是否一致。
  1. 证书是否还在有效期内。
  1. 证书是不是由浏览器或系统信任的机构签发。
  1. 中间证书是否完整，能不能一直验证到受信任的根证书。
  1. 服务器是否持有与证书公钥对应的私钥。

不过，浏览器显示连接安全，只能说明当前连接经过了加密，并且证书验证通过，不代表这个网站上的所有内容都一定可信。钓鱼网站也可以给自己的域名申请正常证书，所以访问网站时还是要看清楚域名。

我当时还把两种“证书”弄混了

公司网站的服务商后台里有一个“域名证书”入口。我当时看到这个名字，就以为它是 HTTPS 使用的安全证书。

点进去以后才发现，它其实只是域名注册证明，上面记录的是域名注册单位、注册时间和到期时间。它可以证明域名登记信息，但不能用来启用 HTTPS。

真正的 HTTPS 证书需要部署到 Web 服务器上，并且和域名、私钥以及 443 端口绑定。只在后台下载一份证书文件，并不会让网站自动支持 HTTPS。

这两种证书的区别可以简单记成：

  1. 域名注册证明：说明这个域名登记给了谁。
  1. TLS 安全证书：在访问网站时证明服务器身份，并参与建立安全连接。

网站要怎样支持 HTTPS

把整个过程整理以后，我现在理解的 HTTPS 配置步骤大概是：

  1. 准备好域名和能够运行网站的服务器。
  1. 向证书颁发机构申请证书。
  1. 通过 DNS 记录或指定的 HTTP 文件，证明自己可以控制这个域名。
  1. 生成私钥和 CSR，并提交证书申请。
  1. 取得网站证书和中间证书链。
  1. 在 IIS、Nginx、Apache 或托管平台中安装证书。
  1. 为正确的域名绑定 443 端口和证书。
  1. 确认 HTTPS 可以正常访问后，再把 HTTP 跳转到 HTTPS。

这里比较容易忽略的是私钥。证书里的公钥可以公开，但私钥必须保存在服务器上，不能随便发送，也不能上传到公开代码仓库。如果只有证书文件却没有对应的私钥，服务器也无法正确完成身份验证。

为什么同一个 Wi-Fi 还是会出现不同结果

这次问题让我重新理解了设备访问网站的过程。设备连接 Wi-Fi 只是第一步，后面还要经过浏览器、本机缓存、DNS、代理、服务器端口、TLS 和网站程序。

即使使用同一个 Wi-Fi，不同设备之间也可能存在这些差别：

  1. 使用了不同的 DNS 或安全 DNS。
  1. 浏览器保存了不同的缓存和跳转记录。
  1. 某台设备开启了“始终使用 HTTPS”。
  1. 某台电脑使用了代理或 VPN。
  1. 安全软件拦截了连接。
  1. 系统时间不正确，导致证书有效期检查失败。
  1. 浏览器曾经记录过这个域名的 HSTS 设置。

HSTS 的作用是告诉浏览器，以后访问这个域名时只能使用 HTTPS。它可以防止连接从 HTTPS 降级到不安全的 HTTP，但如果服务器后来没有正确配置 HTTPS，某些保存过 HSTS 记录的设备就可能打不开网站，而没有这条记录的设备还可以通过 HTTP 访问。

以后再遇到类似问题，我会怎么检查

以前遇到“网站打不开”，我一般会先刷新网页，或者怀疑是不是网络不好。现在我觉得更有效的方法是按顺序确定问题发生在哪一层。

  1. 记录完整错误信息。先看是域名解析失败、连接超时、连接被拒绝，还是证书错误。
  1. 分别测试 HTTP 和 HTTPS。手动输入完整地址，并观察浏览器有没有自动把 HTTP 改成 HTTPS。
  1. 检查 DNS。使用 nslookup 域名，对比不同设备解析出来的 IP 地址。
  1. 检查端口。HTTP 主要看 80，HTTPS 主要看 443。
  1. 检查本机设置。用无痕窗口测试，再检查代理、VPN、安全软件、浏览器设置和系统时间。
  1. 检查服务器和证书。确认域名绑定、证书有效期、证书链、私钥和 HTTPS 端口配置。

根据错误现象，也可以先做一个大概判断：

  1. HTTP 能开，HTTPS 显示连接被拒绝：可能是 443 端口或 HTTPS 服务没有启用。
  1. HTTP 能开，HTTPS 显示证书警告：说明 443 已经有响应，但证书配置存在问题。
  1. HTTP 自动跳到 HTTPS 后失败：需要先修复 HTTPS，同时检查浏览器缓存和 HSTS。
  1. 只有一台设备打不开：优先检查这台设备本身的 DNS、代理、缓存和浏览器设置。
  1. 所有设备都打不开：优先检查域名解析、服务器状态、防火墙和端口。

这次学习以后，我真正理解了什么

以前我知道域名要解析到服务器，也知道 HTTPS 需要证书，但这些知识点在我脑子里是分开的。真正遇到网站故障以后，我才把它们连成了一条完整的访问过程。

域名负责让人找到地址，DNS 负责把域名解析成 IP，端口负责找到服务器上的具体服务，HTTP 规定浏览器和服务器怎样交流，TLS 负责保护通信，安全证书则帮助浏览器确认服务器身份。

这次排查对我来说比较有价值的地方，不只是解决了某一台电脑打不开的问题，而是让我知道以后面对网络问题时，应该先分清楚每一层分别负责什么，再根据错误逐层排除，而不是把 DNS、服务器、HTTPS 和证书混在一起猜。

参考资料