Ping 不通，但浏览器能打开网站，是可能出现的正常现象；Ping 有回应，网站却无法登录，也并不矛盾。两者检查的不是同一种通信。将“服务器能否回应 Ping”直接等同于“网站是否可用”，容易让排查走错方向。
如果客户反馈的是中国大陆域名访问异常，应先检查实际域名与访问症状，而不是把 Ping 作为总判据。ICMP 和 TCP 是补充定位工具，适合回答具体的地址与端口问题。
1. Ping 检查的是 ICMP 回应
常见的 IPv4 Ping 使用 ICMP Echo 请求与回应，基本格式见 RFC 792。它不是向网站的 80 或 443 端口发起 HTTP 请求，也不会协商 TLS、检查页面内容或登录账户。
回应说明本次 ICMP 探测收到答复；没有回应，只说明这次没有收到可用答复。若 Ping 输入的是域名，工具还会先获得地址，因此报告时应同时记录实际探测的 IP，不能仅保留一个域名和“通／不通”。
2. 为什么网站能打开却不回应 Ping？
服务器、防火墙或网络设备可能不回应 ICMP，或对它限速，却仍允许网站连接。CDN 边缘地址的 ICMP 策略也可能与业务服务不同。因此 ICMP 丢包比例不能直接改写成页面失败率，延迟也不能当作完整网页加载时间。
反过来，一个地址回应 Ping，不表示 HTTPS 服务已启动，也不表示证书、域名路由和业务正常。对“Ping 不通但网站正常”的情况，优先确认 ICMP 策略；没有客户访问故障时，不应单凭这一个现象宣告业务宕机。
询问用户“能不能访问”时，也应明确访问的是哪个网站、完成了什么动作。同地址上的其他服务正常，不能证明目标网站正常；打开了缓存中的页面，也不能替代新的业务请求。把用户实际完成的操作写进记录，比一个模糊的“浏览器可用”更清楚。
3. TCP 检查必须绑定地址和端口
TCP 建连检查的问题是“从这条网络，能否连接这个 IP 的这个端口”。例如 198.51.100.10:443 与同地址的 :80 是两个目标。一个成功不能替代另一个，也不能代表该地址所有服务都可用；这个示例地址仅用于说明。
TCP 成功不代表 TLS 或 HTTP 请求成功。失败则应继续区分拒绝连接、超时及其他错误，再核对监听服务、访问控制和网络。只有端口、检测网络及时间一致，前后结果才有可比性；不要将不同端口的结果混成一个“服务器状态”。
复查之前还要确认这个地址仍属于待检查的服务。如果域名已经切换 CDN 或迁移源站，对旧地址的端口探测可能与当前用户访问无关。不要不断更换 IP 直到出现成功，而应说明每个地址来自哪里、对应哪个部署和观测时间。
4. IP 连通不等于域名服务正常
同一个 IP 可以承载多个域名。HTTP Host 用于区分目标主机资源，见 RFC 9110 第 7.2 节；TLS SNI 在握手中提供服务器名称，见 RFC 6066 第 3 节。单纯建立 IP 与端口连接，没有验证这些域名层面的行为。
直接将 HTTPS URL 改成 IP，还可能访问默认站点或产生名称不匹配。应保持原域名进行相应协议检查，不要关闭证书验证来证明“网站可用”。合法 HTTP 响应不必是 200；TLS 握手成功也不是浏览器证书信任与业务流程全部正常的保证。
5. 为不同问题选择不同检查
| 要回答的问题 | 适合的检查 | 结果边界 |
|---|---|---|
| 域名是否报告 DNS 污染？ | DNS 污染检测 | 不能替代 HTTP、TLS 和业务检查 |
| 域名主要访问维度是否异常？ | GFW 全量 | DNS 污染、HTTP Host、TLS SNI 及汇总 |
| 某 IPv4 地址有无 ICMP 回应？ | ICMP Ping | 不回应不等于业务宕机 |
| 某 IPv4 地址的指定端口能否连接？ | TCP Connect | 不验证域名身份或业务响应 |
单域名中国大陆访问初查可从DNS 污染检测开始，相关入门见DNS 检测指南。若需要批量查看主要域名维度，可直接选择GFW 全量，无需先逐个单测；“全量”不是全部七种检测或完整浏览器测试。
6. 保留 IPv4、端口与网络范围
WeaveBit 公开 API 的 IP 目标目前只接受 IPv4，TCP 使用指定端口。不能把一个 IPv4 检查结果推广到 IPv6，也不能用默认 443 的结果证明另一个业务端口正常。选择检查前，核对目标、方法与参数，详见公开 API 文档。
用户终端可能采用不同地址或网络路径。域名由 CDN 调度到多个地址时，应记录实际访问的地址及时间，而不是拿历史 IP 与新观测强行对比。一个节点的结果也不能代表所有地区和运营商；扩大检查时应明确新增的网络范围。
需要调查 IPv6 用户反馈时，应单独记录地址族，并使用适用的客户端证据和工具。不能因为平台提供 IPv4 IP 检查，就暗示同一个结果已经覆盖双栈终端；同样，新增一个检测节点也不等于复现了用户所在的家庭或企业网络。
7. 一份能交给运维的证据清单
- 记录用户真正失败的动作：主页、登录、接口或资源，以及错误提示、时间和时区；分享时移除个人信息与令牌。
- 列出域名、实际 IP、地址族与端口，注明是否绕过了普通解析或改变了测试配置。
- 保存 DNS 污染或 GFW 全量的分项与节点结果；如补充 ICMP、TCP，分别记录方法，不合并成一个成功率。
- 在相近时间比较受影响网络与对照网络，核对 ICMP 策略、端口监听、CDN 和安全设备日志。
- 调整后先重复原配置，再验证实际业务；保留异常、正常、无法判定及未返回的观测。
8. 按症状处置，不按一个“通”字结案
若只有 ICMP 不响应、TCP 与实际网站访问正常，可以记录为 ICMP 观测限制并确认策略。若 TCP 也失败，核对地址、端口和服务监听；若 TCP 成功但 HTTPS 失败，转向 TLS、证书和域名请求。主站正常但登录失败，则检查登录及其他依赖域名。
端口能连接但 HTTPS 仍失败时，可继续使用TLS、SNI 与连接重置排查指南定位下一层需要的证据。
结案时分别写清网络观测和业务验证：例如端口已恢复连接，但登录仍待用户确认。修改配置之后保留原目标的复查记录，不要仅凭新增网络上的一次成功宣布全体用户恢复。仍有不确定结果时，继续标记影响范围和待办事项。
重置或超时仍不单独证明责任方。按照结果解读文档保留平台判定与原始状态，不把无法判定算作正常或已封锁。理解检测方式的边界之后，才能将网络证据与客户的业务体验放在同一份故障记录中。