Web 服务请求链路

浏览器访问域名时，DNS、端口、TLS、HTTP 和反向代理依次解决“去哪台机器、连哪个入口、如何安全通信、请求什么资源、由哪个后端处理”。

是什么

一个 Web 请求不是“域名直接找到应用”，而是多个职责明确的层共同完成：

1. URL 描述协议、主机名、可选端口、路径和查询参数。
2. DNS 把主机名解析成 IP 地址或其他 DNS 记录。
3. 传输层连接目标 IP 的指定端口。
4. TLS 在 HTTPS 中认证服务器并建立加密通道。
5. HTTP 表达方法、路径、请求头、请求体和响应。
6. 反向代理接收公网请求，再转发给内网应用。

RFC 9110定义 HTTP 的通用语义；RFC 8446定义 TLS 1.3。

为什么重要

• 能判断故障发生在 DNS、端口、防火墙、证书、代理还是应用层。
• 能避免把数据库、管理端口和应用内部端口直接暴露到公网。
• 能理解为什么“HTTP 跳转到 HTTPS”不能保护第一次已经发出的 HTTP 敏感数据。
• 能正确配置多个子域名共用一台服务器。
• 能区分“域名解析成功”和“服务可以安全访问”是两件事。

工作原理

完整请求路径

URL、DNS 和端口

以 https://api.example.com:8443/v1/models 为例：

部分	值	作用
scheme	https	表示在安全通道中使用 HTTP
host	api.example.com	交给 DNS 解析
port	8443	目标服务入口
path	/v1/models	交给服务器或应用路由

省略端口时，HTTP 通常使用 80，HTTPS 通常使用 443。DNS 主要回答“域名对应什么地址”，不会替普通浏览器 URL 自动选择应用端口；端口来自 URL 默认值或显式端口。SRV 记录能表达服务端口，但常规 Web origin 不依赖它代替 80/443。

HTTP 与 HTTPS

HTTP 是应用层协议，定义请求和响应的语义。HTTPS 不是另一套业务语义，而是 HTTP 运行在 TLS 保护的通道中。

TLS 1.3 提供三项核心性质：

• 认证：客户端确认连接的是证书对应的服务器。
• 机密性：传输内容对链路上的旁观者不可读。
• 完整性：内容被篡改时能够检测出来。

TLS 握手大体完成两件事：

1. 服务器发送证书链，并证明自己持有相应私钥。
2. 双方通过密钥交换建立临时的对称会话密钥。

非对称密码主要用于身份认证和密钥协商；大量业务数据使用更高效的对称加密保护。证书不包含服务器私钥，私钥必须只保存在服务器端。

CA 与证书信任链

浏览器内置受信任的根证书集合。服务器证书通常由中间 CA 签发，中间 CA 再由根 CA 授权。客户端会检查：

• 证书链能否连接到受信任根；
• 访问域名是否包含在证书中；
• 证书是否在有效期内；
• 服务器能否证明持有对应私钥；
• 签名与算法是否满足安全要求。

以 Let’s Encrypt 为例，ACME 客户端先证明自己控制域名，再由 CA 签发证书；Let’s Encrypt 流程和 Caddy 自动 HTTPS 都会自动化申请与续期。

反向代理

反向代理面向客户端代表后端服务，常见职责包括：

• 在 443 端口终止 TLS；
• 按域名和路径路由；
• 转发请求头、客户端地址和原始协议；
• 负载均衡、健康检查、限流或统一认证；
• 隐藏内部应用地址与端口。

最小 Caddy 配置：

api.example.com {
    reverse_proxy 127.0.0.1:12731
}

根据 Caddy reverse_proxy 文档，未显式写 scheme 的上游默认使用 HTTP。若应用与代理在同一受控主机，通过 loopback 通信通常不需要再次加密；跨主机或不可信网络时，应考虑上游 HTTPS 或其他安全通道。

localhost、127.0.0.1 与 0.0.0.0

• localhost 和 127.0.0.1 指当前这台主机自身。
• 服务绑定 127.0.0.1 时，只接受本机连接，适合作为反向代理后的内部端口。
• 服务绑定 0.0.0.0 时，表示监听所有 IPv4 网络接口；它不是客户端应访问的真实目标地址。
• “本机”取决于命令在哪里运行：云服务器上的 localhost 是云服务器，不是你的 Mac。

80 与 443 的安全边界

端口 80 常用于把无敏感内容的 HTTP 请求重定向到 HTTPS，或完成 ACME HTTP 域名控制验证。但客户端若把 token、密码或 API Key 先通过 HTTP 发出，内容在重定向发生前就已暴露。

正确做法是客户端从一开始使用 https://；必要时再配合 HSTS，降低后续降级到 HTTP 的机会。

历史与演进

• 1980 年代：DNS 取代集中式主机表，形成分层命名系统。
• 1990 年代：HTTP/1.x 与 TLS/SSL 奠定 Web 请求和安全传输基础。
• 2015 年后：HTTP/2 通过多路复用改善连接利用率。
• 2022 年：HTTP/3 标准化，在 QUIC 之上提供安全多路复用。
• 现在：ACME 与自动 HTTPS 使证书签发、续期和跳转成为基础设施能力。

常见误解

• “DNS 可以把域名直接解析到应用端口”：普通 A/AAAA 记录只提供地址；Web 端口来自 URL scheme 默认值或显式端口。
• “Caddy 会自动猜到后端端口”：Caddy 能自动管理公网 HTTPS，但后端地址仍需配置。
• “有了 301 跳转，HTTP 请求就是安全的”：首次 HTTP 请求已经在明文通道中发出。
• “证书把私钥发给浏览器验证”：服务器通过签名证明私钥持有权，私钥不会发给浏览器。
• “内网 HTTP 一定不安全”：同机 loopback 与跨公网 HTTP 不是同一威胁模型。
• “开放端口越多越方便”：公网只应开放真正需要的入口。

与相邻概念的区别

概念	解决的问题	不负责什么
DNS	名称如何找到地址	不处理 HTTP 路由和证书
端口	一台主机上的服务入口	不定义业务请求语义
TLS	身份认证、加密、完整性	不决定路径如何处理
HTTP	请求与响应语义	单独使用时不保证加密
反向代理	公网入口到后端的转发与策略	不替代后端业务逻辑
防火墙	允许或拒绝网络流量	不签发证书、不理解业务路由

相关

• SSH 与 Linux 服务器基础
• Wiki 目录