# wanyue.online 域名、IP 与 HTTPS 证书原理总结

## 1. 这次实际发生了什么

这次排查里，核心问题不是单一的“证书没装好”，而是下面几个因素叠加：

1. **域名一度解析到了错误的目标 IP**
2. **服务器上存在代理/透明代理，影响了对公网 IP 的判断**
3. **本地访问设备也受代理/Fake-IP DNS 影响**
4. **HTTPS 证书申请用了 DNS TXT 验证**

最终确认：

- 真实业务服务器：`47.98.55.249`
- 域名：`wanyue.online`
- 已安装 Let’s Encrypt 免费证书
- HTTP 会跳转到 HTTPS
- 网站最终恢复正常访问

---

## 2. 正常 IP 访问、域名访问、HTTPS 访问分别是什么

### 2.1 直接用 IP 访问
直接访问：

- `http://47.98.55.249`
- `https://47.98.55.249`

特点：
- 不依赖 DNS
- 用户直接连接某台服务器
- 适合测试网络是否通、Nginx 是否启动
- 但不方便记忆，也不利于正式对外提供服务

### 2.2 用域名访问
例如：

- `http://wanyue.online`
- `https://wanyue.online`

特点：
- 用户先查 DNS
- DNS 返回一个 IP
- 浏览器再连接这个 IP
- 域名可以在不改用户访问习惯的情况下切换后端服务器

### 2.3 HTTPS 访问
HTTPS = `HTTP + TLS/SSL 加密`

特点：
- 浏览器先与服务器完成 TLS 握手
- 验证服务器证书是否合法
- 再进行加密传输
- 能防止中间人窃听和篡改

---

## 3. 三者的关系

```mermaid
flowchart TD
    A[用户输入网址或IP] --> B{输入的是域名还是IP}
    B -->|IP| C[直接连接目标服务器IP]
    B -->|域名| D[查询DNS]
    D --> E[DNS返回目标IP]
    E --> C
    C --> F{HTTP还是HTTPS}
    F -->|HTTP| G[直接传输HTTP请求]
    F -->|HTTPS| H[TLS握手与证书校验]
    H --> I[加密传输HTTP内容]
    G --> J[服务器返回网页]
    I --> J
```

### 一句话理解
- **IP 访问**：直接找机器
- **域名访问**：先查“这台机器在哪”
- **HTTPS**：在“找到机器”之后，再建立“可信 + 加密”的连接

---

## 4. 配置域名服务和配置 HTTPS 证书的区别

这两个步骤经常被混在一起，但本质不同。

### 4.1 配置域名服务（DNS）是在做什么
本质是：

> 把“域名”映射到“服务器 IP”

比如：

- `wanyue.online -> 47.98.55.249`

这一步解决的是：
- 用户输入域名时，浏览器该去连哪台服务器

### 4.2 配置 HTTPS 证书是在做什么
本质是：

> 证明“这台服务器确实有资格代表这个域名”，并建立加密连接

这一步解决的是：
- 浏览器为什么信任这个网站
- 浏览器和服务器之间如何加密通信

### 对比表

| 项目 | 配置域名服务 | 配置 HTTPS 证书 |
|---|---|---|
| 解决的问题 | 域名指向哪台机器 | 这台机器是否可信、通信是否加密 |
| 典型配置位置 | DNS 控制台 | Nginx / Apache / 证书工具 |
| 关键记录/文件 | A/AAAA/CNAME/TXT 等 DNS 记录 | cert.pem / fullchain.pem / privkey.pem |
| 不配置会怎样 | 域名找不到服务器 | 浏览器报不安全或无法建立 TLS |

---

## 5. 标准建站流程图

```mermaid
flowchart TD
    A[准备服务器] --> B[安装网站服务/Nginx]
    B --> C[确认IP访问正常]
    C --> D[购买或准备域名]
    D --> E[配置DNS A记录到服务器公网IP]
    E --> F[等待DNS生效]
    F --> G[访问域名HTTP测试]
    G --> H[申请HTTPS证书]
    H --> I[把证书配置到Nginx]
    I --> J[开启443并重载Nginx]
    J --> K[HTTP跳转HTTPS]
    K --> L[验证浏览器访问与证书有效期]
```

---

## 6. HTTPS 证书有哪些类型

可以从多个维度理解。

### 6.1 按校验强度分类

#### 1）DV 证书（Domain Validation）
域名型证书，只验证：

> 你是否控制这个域名

特点：
- 最常见
- Let’s Encrypt 免费证书属于这一类
- 适合绝大多数网站

#### 2）OV 证书（Organization Validation）
企业型证书，除了域名控制权，还会验证企业/组织信息。

特点：
- 比 DV 审核更严格
- 适合企业官网、政企系统等
- 一般收费

#### 3）EV 证书（Extended Validation）
增强型企业证书，审核最严格。

特点：
- 需要企业资质审核
- 一般收费更高
- 现在浏览器对 EV 的特殊展示已经弱化很多

### 6.2 按域名覆盖范围分类

#### 1）单域名证书
例如：
- 只保护 `wanyue.online`

#### 2）通配符证书
例如：
- `*.wanyue.online`

可保护：
- `a.wanyue.online`
- `www.wanyue.online`
- `api.wanyue.online`

通常**不能直接保护根域名** `wanyue.online`，根域名往往要单独加进来。

#### 3）多域名证书（SAN）
一张证书里可以包含多个域名：
- `wanyue.online`
- `www.wanyue.online`
- `api.example.com`

---

## 7. 为什么有些 HTTPS 证书可以免费申请

### 原理
证书机构（CA）签发证书的本质是：

> 作为一个被浏览器信任的第三方，确认你控制了某个域名，然后给你签发证书

Let’s Encrypt 免费的原因不是“证书没有价值”，而是：
- 它是公益性质推动全网 HTTPS 普及的 CA
- 它只做 DV 证书
- 它把签发、验证、续期全部自动化
- 成本很低，所以可以免费

### 为什么浏览器会信任它
因为 Let’s Encrypt 的根证书/中间证书被主流系统和浏览器预装信任。

所以浏览器会认为：
- 这张证书是受信任 CA 签发的
- 这个域名归当前服务器控制
- 因此该站点可信

---

## 8. 证书申请时，CA 到底在验证什么

不管你用哪种方式，CA 都是在验证同一件事：

> 你是否真的控制 `wanyue.online`

区别只是：
- 用什么方式证明你控制了这个域名

---

## 9. 常见证书验证/签发方式有哪些

### 9.1 HTTP-01 验证
原理：
CA 会要求你在网站根路径下提供一个特定文件，例如：

- `http://wanyue.online/.well-known/acme-challenge/xxxx`

CA 去访问这个 URL：
- 如果能看到正确内容
- 就说明你控制了这个域名指向的网站服务器

#### 流程图
```mermaid
flowchart TD
    A[申请证书] --> B[CA生成challenge token]
    B --> C[客户端把token写到网站目录]
    C --> D[CA访问 http://域名/.well-known/acme-challenge/token]
    D --> E{内容正确吗}
    E -->|是| F[验证通过并签发证书]
    E -->|否| G[验证失败]
```

#### 优点
- 自动化方便
- 常用于普通网站

#### 缺点
- 必须让 CA 能从公网访问到你的 80 端口
- 容易被防火墙、代理、透明代理、错误 DNS 干扰

---

### 9.2 DNS-01 验证
原理：
CA 要求你在 DNS 里添加一条 TXT 记录，例如：

- `_acme-challenge.wanyue.online TXT xxxxxxxxx`

CA 查询这条 TXT：
- 如果值正确
- 就说明你控制这个域名的 DNS

#### 这次你加 TXT 的方式，就是这个原理
我们当时让你添加：
- 主机记录：`_acme-challenge`
- 类型：`TXT`
- 值：某个 challenge token

CA 查询到这条 TXT 后，就确认：

> 你控制了 `wanyue.online` 的 DNS，因此可以签发证书

#### 流程图
```mermaid
flowchart TD
    A[申请证书] --> B[CA生成DNS challenge值]
    B --> C[在DNS平台新增 _acme-challenge TXT记录]
    C --> D[等待DNS生效]
    D --> E[CA查询TXT记录]
    E --> F{TXT值正确吗}
    F -->|是| G[验证通过并签发证书]
    F -->|否| H[验证失败]
```

#### 优点
- 不依赖 80 端口
- 非常适合有代理、WAF、内网穿透、复杂转发的环境
- **通配符证书必须用 DNS-01**

#### 缺点
- 手工加 TXT 时麻烦
- 自动续期需要 DNS API 权限

---

### 9.3 TLS-ALPN-01 验证
原理：
CA 直接连你的 443 端口，在 TLS 握手阶段验证一个特殊标识。

#### 优点
- 不依赖 HTTP 文件路径
- 直接走 TLS

#### 缺点
- 配置更特殊
- 不如 HTTP-01 / DNS-01 常见

---

## 10. 这次为什么 HTTP 验证不顺，DNS 验证能成功

### HTTP-01 遇到的问题
前面排查里，HTTP 验证失败的主要原因是：
- 域名解析目标一度混乱
- 服务器透明代理/出站代理影响判断
- 本地和服务器的网络路径都被代理干扰
- CA 从公网访问 challenge 文件时超时

### DNS-01 为什么更稳
因为 DNS-01 不关心：
- Nginx 是否正常
- 80 端口是否通
- 443 端口是否被代理拦截
- 网站路由是否复杂

它只关心：
- `_acme-challenge` TXT 是否能查到正确值

因此在复杂网络环境里，DNS-01 通常比 HTTP-01 更稳。

---

## 11. 配置 HTTPS 的常见方式

### 方式 A：Certbot + Nginx 插件
常见命令：

```bash
certbot --nginx -d example.com
```

原理：
- 自动申请证书
- 自动改 Nginx 配置
- 自动重载服务

优点：
- 简单
- 适合标准 Nginx 环境

缺点：
- 如果网络复杂、80 端口不可达，就容易失败

---

### 方式 B：Certbot 手动模式
常见命令：

```bash
certbot certonly --manual --preferred-challenges dns -d example.com
```

原理：
- 证书工具给出 challenge
- 你手工完成 TXT 或文件配置
- 再继续签发

优点：
- 灵活
- 适合复杂环境

缺点：
- 手工步骤多
- 不适合长期自动续期

---

### 方式 C：acme.sh + DNS API 自动化
原理：
- acme.sh 调 DNS 服务商 API 自动写 TXT 记录
- CA 验证通过后签发
- 自动安装到 Nginx
- 自动续期

优点：
- 非常适合自动续期
- 对复杂网络最友好

缺点：
- 需要 DNS API 权限（AK/SK 或 RAM 角色）

---

### 方式 D：云平台托管证书 / CDN 托管 HTTPS
原理：
- 证书和 HTTPS 终止放在云产品/CDN/WAF 上
- 回源到源站

优点：
- 对用户操作简单
- 运维压力小

缺点：
- 更依赖平台
- 有些场景下不如自管灵活

---

## 12. 自动续期为什么有时容易，有时不容易

### 容易的情况
- 用 HTTP-01，80 端口稳定可达
- 或者用 DNS-01，并且有 DNS API 权限

### 不容易的情况
- 用手工 DNS TXT 验证
- 没有 DNS API 权限
- 有复杂代理、TUN、透明代理、WAF、边界网络

### 本次情况
本次证书是通过：
- **手工 DNS-01 TXT 验证**

所以：
- 申请成功了
- 但默认**不能无权限自动续期**

要想自动续期，最好改成：
- **AliDNS API 自动写 TXT**

---

## 13. 本次排障的真实链路总结

```mermaid
flowchart TD
    A[用户访问 wanyue.online] --> B[本地DNS/代理可能返回错误结果]
    B --> C[域名曾解析到错误或混乱目标]
    C --> D[HTTP-01验证依赖80端口公网可达]
    D --> E[代理/网络路径导致验证失败]
    E --> F[改用DNS-01 TXT验证]
    F --> G[在阿里云DNS添加 _acme-challenge TXT]
    G --> H[CA查询TXT验证域名控制权]
    H --> I[Let’s Encrypt签发证书]
    I --> J[证书安装到Nginx]
    J --> K[HTTP跳转HTTPS]
    K --> L[网站恢复正常访问]
```

---

## 14. 实操层面的推荐顺序

### 普通网站最推荐
1. 先确认公网 IP
2. 域名 A 记录指向正确服务器
3. 80/443 安全组放行
4. Nginx 先把 HTTP 跑通
5. 优先尝试 `certbot --nginx`
6. 如果 HTTP 验证失败，再切换 DNS-01

### 网络复杂环境最推荐
如果环境里有：
- 代理
- 透明代理
- TUN
- WAF/CDN
- 回源链路复杂

建议直接：
- **DNS-01 + DNS API 自动化**

因为最稳。

---

## 15. 一句话总复盘

### 域名服务的本质
> 告诉用户“这个域名该连哪台服务器”

### HTTPS 证书的本质
> 告诉浏览器“这台服务器确实有资格代表这个域名，并且通信要加密”

### 这次加 TXT 的本质
> 通过 DNS 里的一条 `_acme-challenge` TXT 记录，向 CA 证明“我控制这个域名”

### 为什么能免费
> 因为 Let’s Encrypt 用自动化方式免费签发 DV 证书，推动全网 HTTPS 普及

---

## 16. 后续建议

### 当前可用状态
- 网站已经能访问
- HTTPS 已可用
- 证书有效

### 后续优化方向
1. 给阿里云 ECS 配置 RAM 角色或 AliDNS API 凭据
2. 改成 DNS API 自动续期
3. 固化 Nginx 与证书续期后的 reload 流程
4. 若长期使用代理，需明确区分：
   - 入站网站流量
   - 出站代理流量
   - 本地访问测试流量

---

## 17. 附：判断问题大致属于哪一层

```mermaid
flowchart TD
    A[网站打不开] --> B{nslookup结果正常吗}
    B -->|否| C[先修DNS/本地代理/Fake-IP]
    B -->|是| D{HTTP能打开吗}
    D -->|否| E[查80端口/安全组/Nginx]
    D -->|是| F{HTTPS能打开吗}
    F -->|否| G[查443端口/证书/TLS/代理干扰]
    F -->|是| H[网站基础链路正常]
    G --> I{证书申请失败吗}
    I -->|HTTP-01失败| J[考虑改DNS-01]
    I -->|DNS-01失败| K[检查TXT记录与DNS传播]
```