一次 HTTPS 请求经过哪些阶段
以 HTTPS 经 TCP 的新连接为例，应用先解析域名，再连接地址与端口，完成 TLS 后发送 HTTP 请求。排查时先找最早失败的阶段。
| 阶段 | 解决的问题 | 常见线索 |
|---|---|---|
| DNS | 域名如何得到目标地址。 | 无法解析、NXDOMAIN、SERVFAIL、解析器超时。 |
| TCP | 能否与指定地址和端口建立连接。 | 连接被拒绝、连接超时、连接被重置。 |
| TLS | 如何校验身份并建立加密通信。 | 证书校验失败、协议或握手错误。 |
| HTTP | 服务如何处理这次请求。 | 200、跳转、401、403、404、5xx 等状态。 |
这张表适用于本页强制 HTTP/1.1 的示例；HTTP/3 使用 QUIC，传输流程不同。使用代理时，还会增加本机入口、远端代理及代理侧解析，浏览器与命令行也可能采用不同 DNS。先弄清实际路径，才能正确解释“在哪一层失败”。
留下目标、路径和原始错误
先保存目标域名、时间、应用和原始错误。记录有没有系统代理、TUN 或其他 VPN，后续换网络、换入口时才能知道比较条件改变了什么。
- 确认是单个域名异常还是多个无关网站都异常，是单个应用还是所有应用。
- 确认客户端是否运行、实际 HTTP/SOCKS 端口与模式是什么，有没有重复实例。
- 固定同一目标和同一请求方式；更换网络或关闭代理对照时，注明已经换了路径。
- 每次只调整一个已定位的设置，修改前保留原值，修改后复测同一问题。
如果只有浏览器失败而 curl 正常，继续检查浏览器的加密 DNS、扩展、代理设置与认证状态。先核对两者实际使用的入口与解析器。系统代理与 TUN 的接管方式可见 系统代理与 TUN。
DNS：区分无记录、失败和超时
先区分名称不存在、没有某种记录、解析器处理失败和查询超时。已安装 doggo 时，可以对同一域名分别查 A 与 AAAA。
doggo example.com A --timeout=5s
doggo example.com AAAA --timeout=5sA 与 AAAA 分别查询 IPv4、IPv6 地址记录，记录回答来自哪个解析器。NXDOMAIN 表示该解析器报告所查询名称不存在；SERVFAIL 表示它无法完成处理；没有 AAAA 答案可能只是该名称没有 IPv6 记录，不能把这些都叫成“断网”。
超时还可能来自解析器地址或传输路径不可达，应按 doggo 指南做指定解析器对照。命令行有答案也不能证明浏览器或代理侧解析相同，可见 DNS 与加密 DNS 解析说明。
直接把 HTTPS URL 换成 IP 可能改变证书主机名、SNI 与网站路由，容易引入新错误。需要固定 IP 做高级对照时仍应保留原域名与正确身份校验，不把普通 IP 访问失败当作原域名的证据。
TCP：超时、拒绝与重置
超时表示等待期限内没有完成，被拒绝表示收到了拒绝连接的线索，重置表示连接被中止。继续结合详细输出，确认错误对应的是本机入口还是目标地址。
下面让这次命令不使用 curl 自身设置或环境变量指定的显式代理，发起一次短请求。--noproxy "*" 不会绕过 TUN、VPN 或透明转发，实际是否直连需结合路由和客户端日志确认。Windows PowerShell 使用 curl.exe，macOS/Linux 使用 curl：
curl --noproxy "*" --http1.1 --verbose --head --connect-timeout 5 --max-time 20 https://example.com--verbose 帮助观察解析、尝试连接、握手与响应。--connect-timeout 限制建立连接阶段，--max-time 限制整个请求；建立连接阶段还可能包括解析与 TLS 等准备，不把五秒超时直接等同于纯 TCP 故障。
本机代理端口被拒绝时，优先检查进程与监听地址；远端端口被拒绝时，检查目标端口、服务及拒绝策略。长时间无回复则考虑路由、过滤或目标状态。命令只解释当时实际经过的路径；代理问题应另外使用客户端实际端口，并结合 TUN/VPN 状态、路由与日志复现相同路径，入口可见 验证命令生成器。
TLS：证书和握手错误
先看报错中的主机名、日期和证书链，再检查 TLS 握手条件。保留证书校验，把时间、身份或信任问题修好。
- 证书主机名不匹配：检查访问的域名、URL 与服务配置，确认没有用 IP 或错误别名替换目标。
- 证书过期或尚未生效：检查本机时间和服务端证书有效期，分清问题发生在哪一端。
- 无法建立可信链：检查系统或工具使用的信任库，以及服务端是否提供正确证书链；受管理网络的代理也可能影响证书。
- 一般握手失败：查看具体错误与客户端版本，可能涉及协议、服务配置、网络中断或其他 TLS 条件。
curl 常见退出码 35 指向 TLS 连接或握手错误，60 指向对端证书验证失败；具体文字比单个数字更利于判断。关闭验证会改变测试前提，应修复对应身份或信任问题。排查时可用 Wireshark观察握手线索，但抓到加密流量不会自动得到明文。
HTTP：按状态码检查服务响应
收到 403 后，已经有 HTTP 响应可供检查。先看响应内容、请求路径和权限，确认拒绝来自网站、CDN 还是代理，再修改相关设置。
401 常涉及目标服务认证，407 涉及代理认证，403 表示响应者拒绝执行。结合响应正文和服务日志查原因，通常不需要反复改 DNS 或本机端口。
HEAD 仅请求响应头，有些网站对它的处理与 GET 不同，可能返回 405 或不同状态。必要时用同一目标的普通浏览器请求对照。HTTP 代理显示的 200 Connection established 是隧道阶段响应，后续还应查看 TLS 与目标响应。
curl 未使用 --fail 时，收到 403 也可能退出 0：它完成了传输，不代表业务成功。判断时同时看 HTTP 状态、命令退出码与错误文本，不能只看终端有没有出现红字。
修复后重试同一个请求
从最早失败的一步修起，修复后用原应用重试同一目标。把修改前后的结果放在一起，能确认改变的是哪个环节。
- 先确认本机入口与实际请求路径，记录目标和时间。
- DNS 无法完成时，核对所用解析器及回答状态；得到地址后再检查连接。
- 连接失败时，结合拒绝、超时与重置的区别，核对端口、监听和路径。
- 进入 TLS 后按证书或握手的具体错误检查，保留正确主机名与校验。
- 已收到 HTTP 响应后，按状态与内容查认证、路径和应用策略。
- 修复后验证原应用；重新执行浏览器、手机或工作流程中原来失败的操作。
需要比较时间时，参考 网络测试指标；计时字段通常是累计时间，失败后的零值不代表很快。把版本、命令、路径、错误与修复后的结果一起保存；若必须分享日志，遮盖 Cookie、Authorization、订阅令牌及个人地址。
常见问题
curl 的退出码 6、7、28 分别说明什么？
6 常指目标名称无法解析，7 常指无法连接目标或代理，28 指操作超时。28 可以发生在多个阶段，需结合详细输出判断，而不是直接归为 TCP 失败。
用 IP 打开 HTTPS 为什么容易出现证书错误？
证书与网站通常按域名识别，改成 IP 可能改变主机名校验、SNI 和路由。它不是与原域名访问完全等价的对照方法。
为什么 PowerShell 示例建议使用 curl.exe？
部分 Windows PowerShell 环境把 curl 定义为其他命令的别名。curl.exe 明确调用真正的 curl，方便使用本文的命令参数与退出码解释。
参考资料
原理和协议定义可查以下标准与官方文档。文中的流程图由 AFQKit 绘制。