DNS、TCP、TLS、HTTP 分别在做什么？
它们负责不同阶段，应按最早失败处定位。以常见的 HTTPS 经 TCP 请求为例，先解析目标名称，再连接地址与端口，随后完成 TLS，最后发送 HTTP 请求并等待响应。
| 阶段 | 解决的问题 | 常见线索 |
|---|---|---|
| DNS | 域名如何得到目标地址。 | 无法解析、NXDOMAIN、SERVFAIL、解析器超时。 |
| TCP | 能否与指定地址和端口建立连接。 | 连接被拒绝、连接超时、连接被重置。 |
| TLS | 如何校验身份并建立加密通信。 | 证书校验失败、协议或握手错误。 |
| HTTP | 服务如何处理这次请求。 | 200、跳转、401、403、404、5xx 等状态。 |
这张表适用于本页强制 HTTP/1.1 的示例；HTTP/3 使用 QUIC，传输流程不同。使用代理时，还会增加本机入口、远端代理及代理侧解析，浏览器与命令行也可能采用不同 DNS。先弄清实际路径，才能正确解释“在哪一层失败”。
开始排查前，应该先记录什么？
先保留现场，避免一次改变多个变量。记录完整目标域名、时间、应用与版本、网络、代理模式以及原始错误；涉及账户或订阅时只保留必要信息，不公开凭据和访问令牌。
- 确认是单个域名异常还是多个无关网站都异常，是单个应用还是所有应用。
- 确认客户端是否运行、实际 HTTP/SOCKS 端口与模式是什么，有没有重复实例。
- 固定同一目标和同一请求方式；更换网络或关闭代理对照时，注明已经换了路径。
- 每次只调整一个已定位的设置，修改前保留原值，修改后复测同一问题。
如果只有浏览器失败而 curl 正常，继续检查浏览器的加密 DNS、扩展、代理设置与认证状态。它只能说明两次请求表现不同，不能直接断言某一方“测错了”。系统代理与 TUN 的接管方式可见 系统代理与 TUN 问答。
如何确认问题是不是 DNS 解析失败？
先看指定解析器有没有回答，再区分名称不存在与查询失败。已经安装 doggo 时，可用下面两次短查询检查文档示例域名：
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 访问失败当作原域名的证据。
连接超时、被拒绝和被重置有什么不同？
超时是没有在期限内完成，被拒绝是收到拒绝连接的线索，重置是连接被主动中止的线索。它们指向的范围不同，但单凭错误文字不能确认是哪台设备造成的。
下面让这次命令不使用 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，还算网络不通吗？
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 失败。
Ping 能通，为什么 HTTPS 仍失败？
Ping 使用的探测与 HTTPS 的端口、TLS 和应用处理不同。ICMP 回复正常只说明对应探测有回应，还需要检查实际 HTTPS 流程。
收到 403 后，把 DNS 换掉能保证解决吗？
不能保证。403 是某个 HTTP 响应者拒绝请求，通常应查看权限、请求内容和网站或中间服务策略，先确认拒绝来源和原因。
用 IP 打开 HTTPS 为什么容易出现证书错误？
证书与网站通常按域名识别，改成 IP 可能改变主机名校验、SNI 和路由。它不是与原域名访问完全等价的对照方法。
系统代理关闭后测试正常，能证明代理服务故障吗？
不能单独证明。关闭代理改变了路径与可能的解析方式，故障还可能在本机入口、协议选择或应用设置中，需要逐段复核。
为什么 PowerShell 示例建议使用 curl.exe？
部分 Windows PowerShell 环境把 curl 定义为其他命令的别名。curl.exe 明确调用真正的 curl，方便使用本文的命令参数与退出码解释。
官方来源与核对
本文依据以下标准与官方资料整理，资料核对日期为 2026.10.02。概念说明与具体软件实现有区别，实际设置仍需对照对应版本文档。