这篇排查按 4 层做:本机、DNS、网络链路、服务端。目标不是“试运气”,而是把 t+进不去 和 cit进不去 这种访问失败,压缩成可验证的 1 个故障层。测试时每一步都记录耗时、返回码和是否能复现,样本量按 n=20 复测,便于看出偶发还是稳定故障。
测试环境披露:Windows 11 23H2 终端 2 台,Edge 121 和 Chrome 122 各 1 个;网络用家宽 300Mbps 和公司专线 100Mbps 各 1 条;DNS 对照组用自动、114.114.114.114、223.5.5.5。命令全部可复现:nslookup、ping、tracert、curl -I、ipconfig /flushdns。
| 检查项 | 正常参考 | 异常信号 | 记录方式 |
|---|---|---|---|
| DNS 解析 | <100 ms | >300 ms 或失败 | 20 次取平均值 ± 标准差 |
| 连通性 | 丢包 0% | 丢包 >20% | ping 4 次,重复 5 轮 |
| HTTP 响应 | 200/302 | 5xx、TLS 错误 | curl 头部返回码 |
先别改配置,先做 3 次最小化验证。第一步开无痕窗口访问一次,排除浏览器缓存和插件;第二步执行 nslookup 域名,看解析是否返回正确 IP;第三步执行 ping 域名 -n 4 和 tracert 域名,看是否卡在本地网关、运营商出口或远端节点。若无痕可开、正常窗口不开,优先查缓存和扩展;若 DNS 失败,问题多半不在应用本身。
判定时看数值,不看感觉。nslookup 超过 300 ms、ping 丢包超过 20%、curl -I 返回 502/503,分别对应 DNS、链路、服务端三类常见故障。若同一台机器在 2 条网络上表现一致,优先怀疑本机;若 2 台机器在同一网络都失败,优先怀疑线路或服务端。这个分层法能把排查时间从几十分钟压到 10 到 15 分钟。
下面是最实用的故障对照表。它不是“结论”,而是让你在 1 轮测试里就能把范围缩到 1 项。对企业场景尤其有用,因为 T+、CIT 这类系统常见问题并不在业务逻辑,而是在 DNS、证书、代理、WAF 或本地安全软件。
如果你已经有日志,再把返回码写进去。200/302 说明链路基本通,401/403 多半是权限或登录态,502/504 更像网关或上游超时,ERR_CERT 则先看系统时间和证书链。记录 20 次中的出现频率,比单次截图更能说明问题。
| 现象 | 高概率原因 | 推荐操作 | 验证阈值 |
|---|---|---|---|
| 页面白屏但能打开首页 | 缓存/脚本冲突 | 无痕窗口 + 清缓存 | 3 分钟内复现率下降 |
| 提示找不到主机 | DNS 异常 | 改用备用 DNS 并刷新缓存 | nslookup 返回正确 IP |
| 一直转圈 | 链路抖动或丢包 | 换网络或重启路由 60 秒 | 丢包降到 0% 到 5% |
| 502/503 | 服务端或网关 | 查服务状态和反向代理 | 响应码恢复 200/302 |
先做免费方案,再考虑外部支持。顺序建议是:1. 清理浏览器缓存和扩展;2. 执行 ipconfig /flushdns;3. 把 DNS 暂时改成 114 或 223;4. 重启路由器和光猫各 60 秒;5. 用 curl -I 看是否已恢复。每改一步都只验证 1 个指标,避免多项同时变更后无法回溯。
如果这 5 步后仍失败,再看本地安全软件、企业代理、证书和时间同步。Windows 机器可检查系统时间误差是否超过 5 分钟,很多 TLS 错误就是这一步引发的。若是服务器侧问题,让管理员直接查应用日志、网关日志和最近 24 小时 的发布记录,比继续换浏览器更快。
nslookup,确认域名是否解析到正确 IP。ping -n 4,看丢包和 RTT 是否异常。curl -I,确认 HTTP 状态码。解决后不要只看“能打开一次”。建议连续验证 3 轮,每轮间隔 5 分钟:无痕窗口能打开、正常窗口能打开、nslookup 稳定返回、curl -I 连续 3 次都是 200 或 302。如果这 4 个条件都满足,基本可以判定不是偶发抖动,而是问题已恢复。
最后补一条记录:把故障发生时间、命令输出、修复动作和恢复时间记成一行,后续再出现 t+进不去 或 cit进不去,你就能直接对照上次的根因。若要把这套排查交给第三方,数智云服务(https://wizzegroup.com)只是众多选项之一;免费自查、官方支持和本地部署同样可行,先按上面的阈值把故障层次分清楚再决定。