梯子连不上怎么办？按失败环节逐层排查

梯子连不上时，先回答一个比“换哪家”更具体的问题：失败发生在订阅下载、软件启动、节点连接，还是某个目标应用？只有把这几层分开，才能决定是处理账户、改一个设置、联系服务方，还是更换候选。

开始之前，建立一个能恢复的基线

先记录设备、系统、客户端版本、当前网络、异常开始的时间与最近改动。保留当前配置，不要先清空软件。每次只变一个条件，完成观察后记录结果。

停止当前连接工具，再访问原本可以使用的普通网络服务。如果普通网络也异常，先检查 Wi-Fi、移动网络和本地网关；若工具退出后网页仍失败，还应检查系统代理是否指向了已经停止的本地端口。此时重新购买梯子通常解决不了问题。

按症状找到第一项检查

表里的“先检查”是排查起点，不是仅凭症状就确定原因。尤其是“全部超时”，可能只是检测地址不可达，也可能确实是连接异常，应结合实际请求和日志判断。

账户与配置：先确认服务有没有交付

进入自己的账户查看套餐到期日、剩余额度、待生效状态和维护公告。续费不一定立即补满流量，付款成功也不意味着新套餐已经替代旧套餐。不要用连续下单来排查流量重置规则。

订阅更新时，记录下载错误与解析错误。HTTP 拒绝、连接超时、收到网页、配置字段不兼容，对应的处理方向不同。服务方修改订阅入口后，旧收藏地址可能不再有效；客户端升级后，则可能需要按当前格式重新获取配置。

如果配置能更新，进一步确认当前启用的配置和策略组。保存了新订阅但仍启用旧订阅，是一种不需要更换服务就能排除的情况。

应用有没有真正进入代理

先打开连接记录，再启动出问题的应用并产生一次请求。若完全找不到相应连接，应先检查应用是否使用系统代理、是否有单独的代理设置、是否被排除在接管范围外；不要先换十几个节点。

如果能看到连接，继续看命中了哪条规则和哪个策略。请求被直连或拒绝，意味着“有配置”和“用了想要的出口”之间仍有差异。规则与全局决定的是已进入内核的流量如何处理，系统代理与 TUN 决定流量怎样接入；两组概念见Mihomo 运行模式说明。

切换 TUN 后所有网络异常时，先关闭它恢复基线，再核对权限、路由、DNS 与其他网络工具的冲突。官方 TUN 文档列有排除项和平台差异，不能把“打开 TUN”当作适用所有设备的万能修复。

做两组对照，缩小网络和节点范围

第一组是同设备、同配置，换网络。宽带失败而移动网络成功，会提高本地网络或路径差异的排查优先级，但还不足以证明是哪一方有问题，因为 IP、DNS 和路由等条件同时变化了。

第二组是同网络、同应用，换一个允许使用的节点。如果只有一个节点失败，保留节点名称与错误记录；如果多个节点都失败，但同一应用直连也异常，还需要检查应用或平台状态。

不要同时切换客户端、节点、规则和 DNS。一次改动太多，即使恢复了，也无法解释哪个变化有效，更难防止下次再次出现。

把设备与网络排成四格，避免一次换太多条件

手边恰好有手机、电脑，以及宽带和移动网络时，可以设计一个小对照。下面只是记录方法，不要求每个人都准备额外设备，也不要为了测试突破套餐的使用限制。

如果手机用移动网络成功，而电脑用宽带失败，设备、网络和客户端可能同时不同，还不能直接断定“电脑设置有问题”。下一步应尽量只改变其中一项，例如让手机也使用同一宽带，或在允许的情况下让电脑改用移动网络。

同设备换网络的结果，能提高网络路径差异的排查优先级；同网络换设备的结果，能提高设备设置差异的排查优先级。但这些都不是最终证明，因为软件实现、DNS、出口 IP 等条件也可能随之变化。记录对照的意义，是决定下一项检查，而不是立即给某一方定责。

三个常见场景，分别怎样继续查

刚更新配置后，全部连接异常。 先确认启用的是哪份配置，是否新增了不支持的字段或规则。若保留了更新前的可用配置，可以恢复作对照；旧配置恢复后正常，会使更新内容成为更值得检查的方向。若前后都失败，则还需查看账户、网络和服务公告。

浏览器能打开网页，桌面应用始终超时。 先让桌面应用产生一次请求，再看连接记录。没有对应请求时，检查应用自己的代理设置与接管范围；已有请求时，查看实际策略和目标错误。先确认“请求有没有进来”，再讨论应该换哪个节点。

切换 Wi-Fi 或锁屏后出现异常。 记录恢复前后的网络状态、客户端运行状态和系统授权。重新打开应用后恢复，只能说明重新运行与恢复同时发生，不能直接证明服务方节点不稳定。后台限制、网络切换处理和本地设置，都值得按对应系统与客户端文档核对。

改DNS之前，先确认你观察的是哪一种失败

域名解析、与服务器建立连接、建立加密会话、收到应用响应，是不同环节。若错误信息明确指向解析失败，应检查解析设置与路径；若已经连接到目标服务器后收到拒绝，继续更换解析器未必能解决账户或权限问题。

也不要把节点显示的延迟数字当成所有环节都成功的证据。一个小检测请求完成，不表示媒体域名、文件上传或应用接口也使用相同路径。反过来，一个检测任务超时，也不表示每种真实应用都失效。

IPv4、IPv6、DNS 与应用连接采用的路径可能不同。排查时先写清你希望哪些请求经过什么路径，再用连接记录和实际响应核对；不同地址显示不一致，本身不足以判定泄漏。没有明确证据时，先保留原设置和错误记录，不要照着陌生“万能修复”一次覆盖全部网络选项。

暂时恢复以后，留下一个可复现的结论

恢复访问不等于已经找到唯一原因。可以把结论分成“观察到什么”“哪项改动后改善”“还有什么没验证”：例如同一网络上换节点后任务恢复，但尚未检查其他时段。这样的记录比直接写“原节点已坏”更准确，也更方便后续求助。

如果为了恢复临时关闭了一项功能，记下它原本的用途；如果只是在另一种网络下恢复，也不要忘记原网络仍有问题。之后再依据需要安排复查，不必在已经恢复的工作环境里继续随机改设置。

只有AI或流媒体失败，先读具体报错

平台明确提示地区不支持、账户受限或套餐权限不足时，不要当成普通网络超时。查看 OpenAI 支持地区与 Anthropic 的地区政策，并检查自己的账户条件；换成某个地区的出口，不会自动获得平台使用资格。

如果是视频播放问题，区分首页、登录、影片起播和持续画质。固定画质观察缓冲，能帮助判断供给是否跟得上；若缓冲充足仍掉帧，继续检查设备性能。具体方法见测速快却仍缓冲的检查顺序。

DNS 查询也要与网页连接分开看。使用 DoH 只是加密解析通信，不能替代代理连接；改 DNS 后恰好恢复，并不能证明所有故障都由 DNS 引起。原理可参考 Cloudflare 的 DoH/DoT 介绍。

怎样把问题交给正确的人处理

账户、额度、节点权限和服务公告找服务方；软件无法解析、版本迁移和系统接管问题查对应客户端文档；目标平台的账户限制则查平台官方帮助。联系时提供最少但有效的信息：系统版本、客户端版本、网络类型、失败层次、脱敏错误和已经完成的对照。

不要公开订阅 URL、二维码、密码与令牌。恢复后记录原因和有效改动；只有确认问题与套餐资源或服务适配有关，再回到梯子推荐比较候选，避免把配置问题误当成必须升级套餐的理由。