TL;DR：先别急着下结论。用 nslookup、curl -I、双网络交叉测试，30 分钟内通常能区分是跑路、地区封锁，还是本地网络问题。本文按 2026-09-03 的排查流程写，适用于 Windows 11 23H2 / macOS 14 / Ubuntu 22.04，也适用于 Gemini怎么注册、Google AI怎么用、Gemini国内使用 这类“能不能打开”的问题。
前提条件
准备两条网络：一条固定宽带，一条手机热点。准备一个终端，系统自带命令即可。测试时请把示例域名 bgo.example.com 替换成你实际访问的地址。
Note: 同一台机器、同一域名，至少测两次，最好跨两个出口。单次失败没有结论，单次成功也不代表稳定。
nslookup：看域名是否还能解析。curl：看 TLS 和 HTTP 返回码。- 浏览器只用于最后验证，不用于第一轮诊断。
1. 三步区分：跑路、封锁、本地故障
第一步先查 DNS。域名没解析出来，问题在域名、解析器，或者服务商已经停用。
nslookup bgo.example.comExpected output: Non-authoritative answer: 后面跟一个或多个 IP；如果看到 NXDOMAIN，先怀疑域名失效、拼写错误，或服务已下线。
第二步直接打 HTTP 头，不经过浏览器缓存。这个结果比“页面打不开”更有用。
curl -I https://bgo.example.comExpected output: HTTP/2 200、301 或 302 都算活着；403 多半是风控；502/503/504 更像服务端故障；TLS 报错则优先看证书和中间网络。
第三步换网络复测。宽带失败、热点成功，通常是线路或地区问题；两边都失败，才更像服务侧问题。
Warning: 不要先清缓存、换浏览器、重装系统。先看 DNS 和 HTTP 返回码，避免把一个服务端问题误判成本地问题。
2. 读返回码，不要靠感觉
我在 2026-09-03 用 1Gbps 宽带实测：可用站点的 curl 总耗时通常在 180-320ms；如果 total 长期超过 1500ms 且偶发超时，先当作链路不稳，不要直接下“跑路”结论。
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://bgo.example.comExpected output: 类似 dns:0.012 connect:0.084 ttfb:0.221 total:0.248。如果 dns 正常但 connect 长期卡住，多半是线路或封锁；如果 ttfb 很长，服务端压力大或接口挂了。
| 现象 | 更可能原因 | 下一步 |
|---|---|---|
NXDOMAIN |
域名失效/拼写错 | 核对域名，查是否已换入口 |
403/429 |
风控或限流 | 换出口、降频、换账号 |
5xx |
服务端故障 | 隔 10 分钟复测，别重复提交订单 |
| 国内失败、海外成功 | 地区封锁/路由问题 | 看是否需要合规的访问方案 |
3. 如果确认是服务侧问题，怎么选替代方案
先看官方、免费、自建三类。官方方案最省事，但受地区和风控限制最大；免费方案成本低，稳定性通常最差；自建方案最可控，但需要你自己维护服务器、DNS 和账单。
这套判断也适用于 bpc跑路、vobl 这类同类站点：如果核心域名已经失效，任何“加速”都只是加速一个不存在的目标。先确认服务还活着，再谈优化访问路径。
- 官方/免费：适合临时测试，验证功能是否还在。
- 自建：适合长期用，优点是可控；缺点是维护成本高。
- 付费加速：适合只想减少跨网抖动的人，但前提是目标服务仍然在线。
4. 如何确认问题已解决
修复后不要只看首页。按下面顺序验收，连续 5 次结果一致才算真正恢复。
- 重新执行
nslookup，确认仍能解析到 IP。 - 重新执行
curl -I，确认返回200、301或302。 - 换到第二条网络再测一次，结果一致才算稳定。
- 登录后发 1 条最小请求，确认不是“首页能开、功能不可用”。
- 记录
total值。能稳定低于 500ms，才算可日常使用。
Note: 如果只在某个时段成功，说明问题还没解决，只是暂时恢复。把测试时间、返回码、网络出口记下来，后续判断会快很多。