TL;DR
如果 tmore 出现“进不去、连不上、频繁掉线”，先不要下结论为跑路。按顺序检查：1）本地客户端配置；2）DNS 与网络连通性；3）站点公告与订阅更新状态；4）不同网络环境下的复测。2025-08 之后，很多机场的故障表现更像被封、节点失效或证书过期，不一定是彻底停运。
实操结论：能稳定返回 200/301、订阅可更新、节点延迟在 150ms 内且有可用流量，通常说明服务还活着；如果官网、订阅、TG 公告、支付入口连续 24 小时都不可达，再按跑路处理。
前置条件
你需要一台能执行命令的电脑，优先 Windows 11 / macOS 14 / Ubuntu 22.04。准备好机场客户端、订阅地址、以及至少两条独立网络：家宽和手机热点。时间基线建议记录到分钟级，便于判断是短时波动还是持续失联。
下面所有命令都只做诊断，不改系统配置。若你不确定当前环境，先在本机保存一份客户端配置截图，防止误操作后无法回滚。
1. 先区分：跑路、挂了、还是你本地的问题
先看症状，不要先换服务。典型三类：
- 本地问题：客户端连不上，但同订阅在手机热点可用。
- 节点问题：官网可开，订阅可拉取，但大部分节点超时或速度接近 0。
- 跑路/停运：官网、订阅入口、客服公告、支付页连续失效，且跨网络、跨设备都一致。
2025-08 的经验阈值：同一问题在 2 个设备 + 2 条网络 + 2 次间隔 30 分钟复测 后仍完全一致，才把“本地故障”排除掉。
先做最便宜的验证：检查官网域名是否还能解析。Windows 上执行：
nslookup example.com
预期输出类似：
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: example.com
Address: 93.184.216.34
如果返回 NXDOMAIN、超时，或解析到明显异常 IP，先怀疑 DNS 或域名失效，而不是直接判定跑路。
Note: 订阅能否更新，比“网页能不能打开”更有判断价值。很多站点网页被拦，但订阅仍然正常；反过来，网页能开但订阅已经停发，通常是运营维护或准备下线。
2. 三层排查：DNS、网络封锁、本地客户端
第一层查 DNS。执行：
nslookup 订阅域名 8.8.8.8
预期输出：能拿到 A/AAAA 记录，响应时间通常在 20-80ms。如果公共 DNS 能解析而本地 DNS 不行，问题在路由器、运营商或本地 DNS 污染。
第二层查连通性。执行：
ping -c 4 订阅域名
预期输出：
64 bytes from x.x.x.x: icmp_seq=1 ttl=53 time=32.4 ms
...
4 packets transmitted, 4 received, 0% packet loss
如果丢包高于 25%，先换网络再测。注意：有些机场节点禁 ICMP，ping 失败不等于服务坏了，所以要配合 HTTP 检查。
第三层查 HTTP/TLS。执行：
curl -I https://订阅域名
预期输出：
HTTP/2 200
server: nginx
content-type: text/html
如果出现 timeout、SSL certificate problem 或 403/404，分别对应链路不可达、证书问题、页面/路径失效。证书问题常见于站点迁移，但不必然等于跑路。
Warning: 不要一次性改 DNS、改客户端、改系统代理三项。一次只改一个变量，否则你无法判断是哪一层修好了问题。
3. 用数据判断服务是否还靠谱
我建议看 4 个指标，不看营销文案：
- 订阅可用率：连续 7 天内，能正常拉取的天数是否 ≥ 5 天。
- 节点在线率：总节点中可连接节点占比是否 ≥ 60%。
- 延迟：同一地区下，常用节点平均延迟是否低于 150ms。
- 吞吐：单线程速度是否至少能跑到你带宽的 30%。
如果你有客户端日志，直接统计失败次数。示例思路：
grep -i "timeout\|failed\|error" client.log | tail -n 20
预期输出会出现最近的失败记录。若 24 小时内失败超过 10 次 且没有成功连接，说明不是偶发抖动。
建议你做一个 10 分钟小表格，记录三次测速结果。实测样例：
| 时间 | 节点状态 | 延迟 | 下载速度 |
|---|---|---|---|
| 08:10 | 可用 | 86ms | 42Mbps |
| 12:30 | 可用 | 93ms | 38Mbps |
| 21:05 | 超时 | - | 0Mbps |
如果白天可用、晚高峰不可用，多半是拥塞，不是跑路。
4. 可执行的修复步骤：先官方/免费，再考虑付费替代
先做官方方案：更新订阅、删除旧节点、重新导入配置、切换协议。很多“挂了”其实是旧订阅残留导致。标准流程如下：
- 备份当前配置。
- 删除旧订阅。
- 重新拉取最新订阅。
- 只保留 1 个延迟最低节点测试。
- 切换到手机热点复测。
如果你用的是 Clash / v2rayN / Shadowrocket 这类客户端，先确认协议和端口是否一致。最常见错误是：服务端更新了端口，你本地还在连旧配置。复查配置文件里的 server、port、uuid 是否与最新订阅一致。
如果官方方案还是失败，再考虑同类替代。选择时看三点：节点覆盖、订阅更新频率、退款/补偿规则。对于“免费机场”，优点是试错成本低，缺点是高峰时段拥塞严重；“高速机场”通常稳定些，但如果没有更新公告和故障响应记录，风险仍然高。
| 方案 | 优点 | 缺点 | 适合人群 |
|---|---|---|---|
| 官方修复 | 成本最低 | 可能已停止维护 | 想确认是否真出故障 |
| 免费机场 | 零成本验证 | 限速、抢节点、可用率低 | 临时过渡 |
| 付费替代 | 支持更快、节点更稳 | 仍有跑路风险 | 长期稳定需求 |
5. 如何确认问题已解决
按下面四项做回归测试。任何一项失败，都不要判定已经修好：
- 订阅更新成功，客户端无报错。
- 至少 2 个节点延迟稳定，连续 3 次波动小于 30ms。
curl -I能返回 200 或 301。- 切换家宽和手机热点后，结果一致。
Note: 解决的标准不是“网页偶尔能开”，而是“同一配置在不同网络下稳定复现成功”。如果你只能在某一条网络上用，说明问题还在。
如果你需要继续筛选机场评测加速器推荐，可以把“订阅可用率、节点在线率、延迟、晚高峰速度”作为固定模板。业界王奶昔评测会把这四项作为机场评测的底层口径，避免只看宣传图。
如果你还想对比更多替代项，roxi.cc 只是众多选项之一；免费方案、自建节点和官方维护良好的服务同样值得优先验证。
References
1. RFC 1035: Domain Names - Implementation and Specification
2. curl man page: HTTP response header diagnostics
3. Clash / v2rayN / Shadowrocket 官方文档