机场连不上怎么办：订阅失效、节点超时从哪查起

遇到连接失败，先辨认失败发生在订阅获取、配置导入还是核心启动，再检查系统代理与名称解析，随后整理线路测试和日志。订阅更新报错、核心无法启动、测速超时需要分别记录，不能凭其中一个现象就认定订阅失效或服务方故障。

先把订阅获取与配置导入分开看

更新提示停在哪个环节？

界面分别提供获取开始、获取成功、导入失败和内容无效的提示。记录实际出现的文字，先区分获取与导入环节，不把这些状态合并成订阅失效。

是否设置有效并启用了更新？

另有提示用于说明没有有效订阅，或该订阅未启用更新而被跳过。遇到这些提示，应先核对订阅设置；跳过更新本身不能证明服务方停止提供服务。

更新请求是否经过代理？

“更新全部订阅(不通过代理)”和“更新全部订阅(通过代理)”是不同的菜单入口。记录使用的是哪个入口，再描述更新结果，避免遗漏请求所走的路径。

核心启动失败时先找本地报错

配置、核心兼容性与端口都可能有关

官方列出的可能原因包括配置错误、核心不再支持所用配置，以及本地监听端口被其他应用占用。它们是排查方向，不能仅凭启动失败就选定其中一种。

日志应从什么位置收集？

界面操作、设置、测速与检查更新等自身问题的日志在 guiLogs 文件夹；核心问题的日志显示在主界面信息栏，可以复制。反馈时应区分这两类位置。

重现问题前怎样整理记录？

官方要求先清除旧日志，重现问题后提交操作步骤与日志。针对核心启动失败，官方还要求将日志等级设为 Debug，再提交界面显示的日志。

把系统代理、名称解析和线路结果分开核对

重启后系统代理是否仍然开启？

官方说明，客户端接收关机事件后会关闭系统代理，但操作可能来不及完成。因此重启后仍需查看系统代理状态，不能直接沿用关机前的判断。

地址能通而主机名不通说明什么？

ping 用于验证 IP 层连通性。官方文档指出，地址测试成功而主机名测试失败，可能涉及名称解析问题；这里的“可能”不能改写为已经确认 DNS 故障。

路由测试出现星号能否直接定性？

路由跟踪结果中的星号表示该次探测在超时前没有收到回复。记录时应保留这一含义，不能仅凭星号便认定线路中断，更不能据此确定服务方故障。

转向服务方核对前先描述清楚现象

不把本地启动报错写成远端故障

核心无法启动时，官方已经列出配置、兼容性和端口方面的可能原因。提交问题时应保留原始报错与日志，让后续核对围绕实际现象展开。

反馈中保留哪些操作细节？

按官方要求提交可重现的步骤与日志，并注明故障发生在订阅更新、核心启动还是测速期间。不同环节的结果应分别描述，避免用“全部不能用”代替具体过程。

目前还不能确认的几件事

测速全部超时有哪些官方原因？

关于测速全部超时的官方原因清单，官方没有核对到。不能据此补写订阅过期、线路中断等确定结论，应以应用内实际提示和重现后的日志为准。

端口占用是否有专门处理流程？

关于端口占用的专门错误提示与逐步处理办法，官方没有核对到。现有说明只将其列为核心启动失败的可能原因，具体提示应以应用内界面为准。

常见问题

订阅获取成功，就能确认连接恢复了吗？

获取成功对应的是订阅获取环节。界面另有导入失败与内容无效的提示，仍需分别核对后续状态，不能把获取成功当作整个连接过程的结论。

测速时核心启动失败，就是服务方的问题吗？

官方列出的可能原因包含本地配置、核心兼容性和端口占用。应先按要求收集界面日志，再继续核对，不能直接将报错归因于服务方。

开启 TUN 是否必须使用管理员权限？

关于这一要求是否在官方 Wiki 明写，官方没有核对到。界面存在管理员运行入口，但仅凭入口存在，不能推导出所有 TUN 故障都由权限造成。

第三方整理,与文中提到的软件、服务及其开发者无隶属关系。