常见问题与故障排除

绝大多数连接问题,其实是四种表象相似但成因完全不同的故障。先判断自己属于哪一种, 再去改设置 —— 否则改的多半是本来就没问题的地方。

先判断:到底是哪一种故障?

按顺序往下走,每一步都会排除掉一部分可能。

1. 客户端显示已连接了吗? 如果始终连不上,问题在建立隧道这一环 —— 见连不上。

2. 隧道起来了,但有任何东西能打开吗? 如果所有网站都打不开、客户端却显示已连接,这几乎总是域名解析的问题,而不是节点 —— 见连上了但什么都打不开。

3. 有的能用有的不能,或者用着用着就不行了? 这种"时好时坏"指向节点选择,而不是隧道挂了 —— 见时好时坏。

4. 都能打开,只是慢? 见速度慢。

先确认流量真的走了隧道

"已连接"只说明隧道建起来了,不等于你的流量正在走它。直接验证一下:

1. 隧道关闭状态下,打开任意一个能显示你公网 IP 的页面,记下地址。
2. 连接,然后刷新那个页面。
3. 地址应该变化。如果没变,说明你的流量绕过了隧道。

流量绕过正在运行的隧道,常见原因有:

• 当前网络自己配了代理。 Wi-Fi 或系统上设置的代理,会对遵守该设置的应用生效, 把它们的流量送到隧道之外。断定"隧道坏了"之前,先检查当前网络的代理设置。
• 分应用规则把你用来测试的那个应用排除在外了(在提供该功能的平台上)。
• 某条分流规则把这个目标判给了直连 —— 见高级配置。

连不上

客户端始终到不了"已连接"状态。

1. 先确认配置还有效。 刷新一次订阅 —— 过期或被吊销的配置,会留下一批已经无法通过认证的条目。
2. 检查是不是还有别的 VPN。 大多数系统同时只允许一个 VPN 配置生效。 先关掉其它 VPN 或过滤类应用再试。
3. 确认系统权限。 首次连接需要批准系统的 VPN 请求。如果之前拒绝过, 客户端可能只是失败而没有明确提示 —— 去系统的 VPN 设置里重新授权。
4. 换个网络试试。 有些网络会封锁配置所用的传输方式。 从 Wi-Fi 切到移动数据(或反过来),就能把"这个节点挂了"和"这个网络封了它"区分开。
5. 手动指定某一个节点,不要用自动分组 —— 这样结果指向的是一个确定的节点, 而不是分组当时恰好挑中的那个。

如果出现端口被占用的错误,说明有别的程序占着客户端要用的端口。 请在设置里改客户端的本地端口,而不是去关掉那个程序。

连上了但什么都打不开

隧道显示已连接,却一个网页都开不了。当所有东西同时失效时,先怀疑 DNS —— 解析失败意味着根本没有目标被访问到,表现出来和隧道死掉一模一样。

1. 直接用 IP 地址访问试试。 如果数字地址能通、域名不行,那隧道是好的,问题在 DNS。
2. 查看配置为代理流量指定的解析器是哪一个,以及它在当前网络下是否可达。
3. 每改一次都要重新验证。 DNS 结果会被缓存,一个失败的缓存结果可能比修复本身活得更久。 请重新连接,并在新的浏览器窗口里重试。

然后再查分流:如果某条兜底规则把流量导向了不可达的出口,那么所有目标都会失败。 可以恢复一份已知可用的配置来确认。

时好时坏

有的连接成功、有的失败,看不出规律;或者用了一阵子之后就不行了。这通常不是隧道坏了。 绝大多数情况是下面两个原因之一:

分组正把流量派给连不通的节点。 配置里可能含有从你的网络根本到不了的条目。 不按健康状况排序的选择策略,照样会把连接平均分给每一个成员, 于是一部分连接就落到了死节点上。把分组换成按健康状况排序的策略, 或者手动选定一个确定可用的节点,马上就能看出是不是这个原因。 详见节点选择。

健康数据过期了。 延迟测量是按间隔刷新的,而且隧道空闲时可能停止刷新。 长时间闲置之后,选择依据的可能是很早以前测的数据 —— 当时最快的那个节点,现在也许已经挂了。 所以在断定某个节点不好之前,先重新测一次延迟。

如果是连续用几个小时后才变差,请记下大约多久出现、以及重连能否恢复 —— 这个区别在反馈问题时很有价值。

速度慢

1. 先测基准。 关掉隧道测同一个下载。如果关掉也一样慢,那客户端里怎么改都没用。
2. 不要把延迟当速度看。 节点旁边的数字是往返时间,不是带宽。 一个节点完全可能很快回应一个很小的测试请求,实际传输却很慢。请直接测你真正关心的那种传输。
3. 换不同地区、不同协议类型的节点试。 在同一个网络下,不同传输方式的吞吐可能差很多。
4. 用大文件下载来测,不要用打开网页来测。 网页加载主要受往返次数影响,反映不出带宽上限。
5. 确认瓶颈是不是链路本身。 在计费或漫游的移动网络上,上限可能远低于节点能提供的速度。

手机上的耗电与后台行为

隧道意味着有一个进程一直在运行,这会耗电。如果每次息屏后连接就断, 多半是系统把应用挂起了:请到系统的电池优化设置里为它放行。 如果客户端提供了"连接中"的常驻通知,保持开启也有助于系统让它活着。

收集诊断信息

如果你的版本提供日志查看或导出,请抓取覆盖故障发生时段的日志 —— 先复现问题,再导出,这样关键的那几行才会被包含进去。

求助前值得先记录下来的信息:

• 应用版本和操作系统版本;
• 客户端显示了什么(状态或报错的原文);
• 关掉隧道时,同一个目标是否正常;
• 换一个网络是否表现不同;
• 重连、或恢复到之前的配置,能否解决。

获取帮助

请通过支持页面联系我们,或发邮件至 service@allianceinterstellar.com。 附上上面列出的信息,并把凭证部分脱敏。

如果是节点或订阅本身的问题 —— 套餐到期、流量用尽、节点下线 —— 请联系签发该配置的服务商。 客户端无法修复一个本身就没在提供服务的节点。