域名能解析出 IP，但中国大陆用户打开 HTTPS 仍遇到连接重置、握手失败或证书警告，这些现象并不矛盾。DNS 只是访问链路的一环，后续连接、TLS 协商和应用请求仍可能失败。
排查的目标不是立即给网站贴上“被封锁”的标签，而是先确认失败在哪一层，再用相同域名、端口和网络复查。主站、登录和 API 可能分别使用不同域名，应从用户实际失败的地址出发。
1. 先确认“DNS 正常”指的是什么
普通 DNS 查询成功，只说明这次查询获得了回答；它不等于专门的 DNS 污染检测没有报告异常。即便没有报告污染，也不能推出 HTTPS 一定能用。应记录域名、查询或检测时间，以及结果来自用户网络还是检测节点。
需要初查单个域名时，可使用免费 DNS 污染检测；已经有结果时，不必重复初查，而应保留它并继续定位连接问题。基础概念和结果之后的行动见DNS 污染检测入门。
工单中的“DNS 正常”应改成可核对的描述：用了什么检查、何时获得什么结果。如果这句话仅来自另一台机器的解析查询，不能用它排除受影响用户的 DNS 问题。把两份观测分别记录，避免在交接时丢失网络和时间差异。
2. HTTP Host 与 TLS SNI 在不同阶段使用域名
一台服务器或一个 CDN 地址可以承载多个网站。HTTP 的 Host 提供请求目标的主机名及端口信息，帮助服务端区分资源；这是 RFC 9110 第 7.2 节描述的应用层信息。
TLS SNI 则在握手阶段传递客户端要连接的服务器名称，服务端可以据此选择相应配置或证书，见 RFC 6066 第 3 节。正常的 HTTPS 访问先协商 TLS，再发送 HTTP 请求，因此 HTTP Host 与 TLS SNI 相关，但不是同一次检查。HTTP 能响应，不保证 TLS 可以完成。
3. 直接访问 IP 不能复现同一个虚拟主机
把 https://example.com/ 改成 https://198.51.100.10/，不只是跳过了 DNS，也改变了请求的名称。服务端可能选择默认网站或另一张证书；因此“IP 可以打开，域名打不开”不自动证明是域名过滤，“IP 打不开”也不能否定域名服务。
若运维人员要比较某个固定地址，应在有权限的客户端工具中保留原 URL 主机名、相同端口和 TLS 名称，仅改变连接地址，并记录这个差别。示例 IP 仅用于说明。不要通过忽略证书错误来把失败变成成功，也不要把默认站点的响应当成目标网站的响应。
4. 把握手、证书与页面业务分开
| 观察到的现象 | 能够说明 | 仍需检查 |
|---|---|---|
| TCP 连接成功 | 该地址与端口建立了连接 | TLS、域名身份与 HTTP 请求 |
| TLS 握手成功 | 本次 TLS 协商完成 | 浏览器证书信任、名称与业务请求 |
| 收到合法 HTTP 响应 | 对方返回了 HTTP 响应 | 状态码含义、内容及必要跳转 |
| 首页可以显示 | 这次首页访问完成 | 登录、API、资源与其他依赖域名 |
浏览器证书警告可能涉及有效期、主机名匹配、信任链或终端时间。WeaveBit 的 TLS 握手结果不是完整证书审计，应结合浏览器的具体错误检查。合法 HTTP 响应也不要求一定是 200：重定向、鉴权失败或服务端错误同样需要按业务语义处理。
证书类故障与连接类故障应分开处理：先保存浏览器提示，再由网站负责人检查目标域名实际使用的证书与部署配置。不要要求用户关闭安全检查或提交账户密码来证明能否连接；一个连接问题不需要靠完成真实支付等敏感操作验证。
5. reset 与 timeout 不是根因名称
连接重置说明连接被中断，但单独这一现象不能确认是谁发起、为何发生。源站关闭连接、CDN 或访问控制策略、链路问题都值得核查。超时表示在等待窗口内未完成，不应直接改写成“已封锁”。TLS Alert、EOF 和握手错误也要保留原始类型。
先标记失败阶段：TCP 建连、TLS 协商，还是握手后的 HTTP 请求。再核对故障时段的源站、CDN 和安全日志，并比较受影响网络与对照网络。没有对应日志也不一定证明请求未到达；日志覆盖范围与保留时间本身需要确认。
同时记录是偶发失败还是连续失败，以及影响哪些用户。如果只保存成功的重试，就会掩盖间歇故障；若只保存一次失败，也难以确认持续影响。将每次复查作为新观测追加，而不是覆盖最初记录，有利于判断配置变化和恢复时间。
6. 用 GFW 全量查看分项，而不只看汇总
当 DNS 初查不能解释 HTTPS 失败时，可以用 GFW 全量检查 DNS 污染、HTTP Host 与 TLS SNI 三个维度及节点汇总。它不是全部七种方法，也不是完整浏览器访问。按客户网络选择节点，并保持目标与端口一致，具体步骤见GFW 全量检测指南。
查看每个节点的分项 status 和判定，不要只复制一个总体标签。TLS_HANDSHAKE_OK 表示握手成功；TLS_HANDSHAKE_RESET 是平台可以分类为异常的观测；超时或其他不足以分类的状态可能是无法判定。正常、明确异常和无法判定的边界见结果解读文档，不能用最后一种代替恢复证明。
7. 按这个顺序收集可复查证据
- 记录失败 URL、时间与时区、浏览器错误文字，以及用户所在地区和运营商；分享前去掉令牌、个人信息和敏感查询参数。
- 确认真正失败的域名与端口，是主站还是登录、API 或资源；区分普通解析结果与 DNS 污染判定。
- 保存同一配置下的节点、HTTP 和 TLS 分项结果，保留无法判定或未返回的项目。
- 在接近的时间比较受影响网络与对照网络，并核对服务端日志、证书和最近的 DNS、CDN、WAF 变更。
- 配置调整后，用原目标、原端口及相关网络复查，再让受影响用户验证实际业务；每次只改变少量因素并记录变化。
8. 将结论写成范围明确的故障记录
比起“DNS 正常，所以网站正常”，更有用的记录是“某时刻、某运营商节点，DNS 未报告污染，TLS 握手重置；用户登录仍失败，等待服务端与网络复查”。这是记录格式示例，不是真实检测报告。
分项结果转为正常后，还应确认浏览器证书与业务操作。协议检测恢复和业务恢复可以发生在不同时间；证据不足时保留待确认。需要了解各检测覆盖范围，可查看检测方式，避免让一个成功项替代整条访问链路。
如果手头只有 Ping 或 IP 端口测试，先读ICMP、TCP 与域名检测的区别，确认这些证据尚未回答哪些 HTTPS 问题。