网站能打开，连通性检测却失败？从 CORS、403 到超时的排查顺序

你已经在浏览器里打开了网站，另一边的检测工具却亮起红灯。这时，最容易出现两种相反的判断：要么觉得自己的 IP 被封了，要么认定检测工具完全没用。

先不急着选边。直接打开首页、由网页脚本读取一个接口、从远程服务器发起请求，是三种不同的测试。只有目标、请求方式、访问出口和成功标准足够一致，结果才适合直接比较。

排查这类问题的目的，不是想办法把卡片刷成绿色，而是确定失败发生在哪一步，以及它会不会影响你真正要做的事情。

先问检测工具：你测的是哪一段？

“连通”不是一个覆盖所有功能的状态。一次访问至少可能经过域名解析、网络连接、安全连接和应用处理等环节，而账号权限又是另一层判断。

连一个图标、静态资源或状态接口成功，只能证明那项检测目标在当时有响应。它不能替代对登录、上传、支付或其他业务功能的验证。

同样，Ping 没有响应，也不能单独证明网站不可用。ICMP 与网页访问使用的协议不同，网络可能不回应前者，却仍允许正常的 HTTPS 连接。

第一类：网页能开，检测脚本读不到结果

这类问题需要优先考虑跨源限制。

假设检测页面运行在 A 站，它的脚本要读取 B 站的响应。浏览器会检查 B 站是否允许这个来源读取数据；这与用户直接在地址栏打开 B 站，不是同一个权限问题。

MDN 的 CORS 指南说明，跨源请求受浏览器安全机制约束。请求可能已到达目标，但响应不能提供给脚本；也可能在预检阶段就没有获得继续请求的许可。

更棘手的是，脚本拿到的错误往往不够具体。它不一定能区分跨源限制、连接问题和其他失败原因。若检测工具把这些情况全部显示为“无法访问”，就容易把“无法验证”误写成“确定不可达”。

普通用户可以核对直接访问是否稳定、页面是否正常运行，并保留检测时的错误信息。开发者则应查看浏览器控制台和网络记录，确认是否存在 CORS 或预检错误，而不是仅凭一个通用异常给 IP 下结论。

不要为了验证连接而关闭浏览器的安全保护。这样得到的环境已经偏离正常用户环境，也不能修复目标服务的跨源策略。

第二类：请求方法、路径或登录状态不同

有些检测程序为了减少流量，会使用 HEAD 请求。按照 MDN 对 HEAD 的说明，这种方法用于获取相关响应头，不返回响应正文。

但具体网站可能对 HEAD、GET 和业务接口采用不同规则。例如，某条路径未允许 HEAD，而用户用浏览器发出的 GET 可以正常取得页面。此时，要检查的是请求方法与目标路径，不能把单一路径的失败扩大为整个网站不可用。

登录状态也会造成差异。你直接打开网站时，浏览器可能已经保存了有效会话；检测脚本不一定拥有同样的 Cookie、访问令牌或其他上下文。反过来，首页返回正常，也不代表登录后的某项业务已经通过测试。

对这类问题，建议先写出明确的成功标准：是能打开首页，能登录自己的账号，还是能完成一次正常操作？标准明确后，再选择对应的验证方式。

第三类：收到了响应，但它不是你期待的响应

403：请求被拒绝，不等于已经证明 IP 被永久封禁

Cloudflare 对 403 的说明列出了权限和安全规则等相关原因。网站源站、CDN 或安全策略都可能参与请求处理。

有些情况下，错误页面会提供请求标识、规则提示或可联系的支持渠道。保留这些信息，比只告诉客服“我的 IP 不行”更有助于定位。

不过，不要把错误页中的某个品牌标志直接当成全部责任归属。最终需要结合该请求经过的服务和网站配置，才能判断由谁处理。

429：先减少请求，不要把刷新当作排查

429 通常表示请求频率受到限制。限制对象可能是 IP，也可能是账号、凭据、Cookie 或特定资源，并不是所有服务都按同一种方式计数。

RFC 6585没有规定服务器必须如何识别请求者；MDN 的 429 文档也说明了不同的限流方式，以及可能返回的 Retry-After 等待提示。

看到限流时，应停止连续刷新和批量重试，遵守服务给出的等待要求。用更多请求去验证一个限流结果，反而可能让排查持续受到限流影响。

超时：先看测试阈值与失败阶段

超时只说明检测没有在设定时间内完成。失败可能发生在解析、连接、安全协商或等待响应阶段，也可能与浏览器排队、设备负载或并发检测有关。

“检测耗时”也不必然等于网络往返延迟。一个 HTTP 检测结果可能包含服务处理与资源传输时间，不能直接拿它与 Ping 数字进行比较。

短暂超时值得在正常间隔后复测；持续超时则需要保留失败阶段。不要只凭一次超过阈值，就认定该地址长期不可用。

第四类：两个测试根本没有从同一个出口发出

浏览器代理、系统代理和 VPN 可能覆盖不同的应用与协议。设备同时具有 IPv4 和 IPv6 时，两种请求也可能走不同路径。

还有一种容易忽略的情况：检测工具使用远程服务器请求目标。它反映的是那个测试位置的可达性，不是你正在使用的公网 IP 的访问能力。

如果你的问题是“我的 IP 能否访问这个应用”，核心证据应该来自当前设备与当前网络的实际访问。远程检查可以帮助确认服务端是否普遍异常，却不能替代本地出口验证。

因此，比较结果时至少应核对测试来源、地址族、代理状态和目标地址。只写“都是测同一个网站”，还不足以说明测试条件一致。

一次只改变一个条件，定位会快得多

先通过 IP 查询记录当前公网地址，再用场景检测与正常访问作对照。接下来，按实际症状逐项检查。

1. 同一网络、同一浏览器下，确认目标页面或功能是否稳定可用。

2. 查看检测目标和返回原因，区分跨源限制、状态码、解析失败与超时。

3. 用临时的干净浏览器配置进行对照，记录扩展、会话和权限的差异，不急着清空原有环境。

4. 核对 IPv4、IPv6 和代理路径；如果改用另一网络，只把它作为对照证据，不立即推导为原 IP 被封。

5. 必要时补充 DNS 记录查询或 HTTP / TLS 检查，同时记录这些工具采用的测试位置，避免混淆观测来源。

换网络会同时改变地址、解析路径和部分网络策略。“换了就好”能够缩小问题范围，却不能单独指出究竟是哪一项发生了作用。

涉及证书错误时，也不要通过忽略证书警告来宣布问题解决。应核实系统时间、证书链、目标域名及获授权的网络配置；企业设备由管理员确认相关策略。

向支持人员提供什么，才容易得到有效答复？

可以把问题描述成一条可复现的记录：在什么时间、哪种网络和浏览器中，访问哪个公开路径、执行什么正常操作，得到什么结果；检测工具的目标、方法与错误是什么。

如果有请求标识或响应状态码，一并提供。公网 IP 只在排查确有需要时，通过可信的支持渠道交付。账号密码、Cookie、Authorization 请求头和带访问令牌的完整网址，不应贴在公共工单或截图里。

一个有用的结论应当足够具体，例如“首页可以打开，但跨源脚本无法读取结果”，或者“当前出口的某项请求被限流”。它比“网络不行”更接近解决办法，也比一张全绿的检测页面更能说明实际可用性。

分层故障的两个对照案例：从 DNS 到 TLS 的不同失败位置

假设同一个域名在一个环境中 DNS 解析成功，但 TCP 连接失败。解析得到 A 记录或 AAAA 记录，只说明当时返回了记录，并不代表对应地址一定可达。失败可能发生在本地防火墙、运营商策略、目标端口关闭或路径中的设备。此时若直接断言 IP 被封，就跳过了中间证据。更准确的说法是“从当前网络到目标地址的 TCP 端口连接未建立”。

另一个示意案例是 TLS 握手完成后 HTTP 返回 403，说明本次连接已进入应用层处理，但还要看客户端是否启用了证书校验。只有校验开启且成功，才能说证书信任和主机名检查通过；跳过验证的测试没有这项证明。403 通常表示该请求被拒绝，可能涉及路径、身份、权限或安全策略，不能单独证明账号冻结。

这两个案例的差别在于失败层次不同。TCP 失败发生在传输连接阶段，TLS 已过而 HTTP 失败发生在应用处理阶段。把层次写清楚，才能避免把“连接不可达”和“请求被拒绝”混为一谈。例如远程检测节点显示 TCP 失败，只代表那个节点的出口无法建立连接，不能直接推出你的本机也失败。反之亦然。

先保留原始错误：超时意味着规定时间内没有完成相应阶段，连接重置意味着连接被主动终止，但都可能来自目标端、路径设备或客户端环境，不能仅凭错误词定位到防火墙。若已经收到 HTTP 403，则保留请求方法、路径、时间和请求标识，并请服务方核对规则。只有明确失败阶段，后续对照才有针对性。

分层判断也影响后续动作。TCP 失败时，换网络、换地址族或检查代理都可能有意义；TLS 成功后的 403，应减少无效重试，转而去核对请求方法与路径，或确认是否触发安全策略。用单次结果概括全站或全账号状态，会高估证据范围。

写一份可供复现的工单记录：时间、目标、观察点与阶段

有效工单不是一张红色错误截图，而是一条能从观察点复现的记录。建议包含发生时间与时区、访问的目标 URL、使用的浏览器或客户端、设备网络类型，以及检测工具执行的位置。观察点尤其重要：是浏览器本机、远程检测节点，还是从服务器主动请求？不同观察点的失败含义不同。

还要写明失败阶段。如果可能，区分 DNS、TCP、TLS、HTTP 和登录后功能。原始错误应保留文本或状态码，例如连接超时、403 页面中的请求 ID、证书错误代码。敏感信息必须脱敏：不要把密码、Cookie、Authorization 头或带访问令牌的完整网址贴进工单。公网 IP 只应在确有需要时通过可信渠道提供。

不要宣称“所有地区都超时”或“全国无法访问”。你只知道自己测试的观察点。可以写“从当前网络从某时间起连续三次出现 TCP 超时”，这比“全网不通”更可信。远程检测结果可以作为旁证，但必须标注其实测位置和测试时间。

若要引用 RDAP、ASN 或 BGP 等网络证据，可参考IP 证据分层 思路：先用 RDAP 确认地址归属，再用 BGP 或路由数据解释路径变化。但归属不等于恶意，ASN 变化也不等于故障。证据要能支持结论，而不是用来制造恐慌。

对于涉及 IP 黑名单或验证码现象的排查，IP 黑名单与验证码排查 提供了更具体的方向。工单里应说明遇到验证码还是明确拒绝，是否与登录状态相关。验证码可能只是频率控制或风控提示，不等于账号冻结。

最后，不要把某个工具的一次超时阈值当成全平台通用标准。不同检测产品的超时、重试和并发策略不同，阈值只适用于该工具当时的测试。因此工单要写清使用的工具及配置。能复现的记录，才会让支持人员有机会定位阶段，而不是从结论反推问题。