节点全部超时怎么办，先保留网络与设备对照

先换网络和设备试什么？

一句话结论先比较不同网络，例如 Wi-Fi 与移动数据或另一 Wi-Fi；再用另一设备对照同份适配订阅。随后手动更新列表，检查系统时间，并在关闭代理时确认国内网页能否正常访问。

这组动作分别看网络差异、设备差异、配置变化、握手时间与本地是否断网。没有固定的分辨概率，也不保证完成某几步就定位到单个原因。

按连接层面进一步保留错误信息

每种结果说明什么？

商家页面写节点正常，与自己设备能否到达仍是不同观察。不能从面板状态替本地链路作保证，也不能由本地全红认定所有服务器都停止工作。

把入口请求与节点连接分开看

只有 Wi-Fi 连不上是怎么回事？

一句话结论DNS 无法解析节点域名只是其中一项。Wi-Fi 下 IPv6 优先而节点仅支持 IPv4、路由器安全或过滤功能、运营商端口或协议差异、公司学校酒店出网规则，以及 MTU 影响，都是需要区分的候选。

这些条件可能出现相近现象，不由比较结果直接选定一个原因。MTU 所涉握手包问题还可能表现为刚连接就断开，也不能仅凭这种现象直接调整参数。

接下来怎样逐项检查网络设置？

一句话结论已有网络对照之后，再按下列顺序查看具体条件。每次只改对应项目，记下重连后的结果，避免同时改动后无法辨认变化来自哪里。

1. 换到另一处 Wi-Fi，例如另一家庭或公司的网络。若在那里恢复，排查重点转向原来的路由器或宽带环境，而不是立即认定商家节点失效。
2. 在手机的 Wi-Fi 设置中关闭私有地址或随机 MAC，重新连接后比较。
3. 将路由器或客户端中的 IPv6 关闭，再检查同一连接。
4. 关闭路由器内的安全防护及 DNS 过滤功能，保留前后结果。
5. 再处理 DNS 设置，但先按下文确认节点域名是否确实解析失败。

某项改动后恢复，可以把线索对应到该项继续查。只改过 DNS 却没有恢复，并不表示其他环节已经排除，更不能由此直接确定责任在商家。

状态显示正常，为什么设备仍然超时？

一句话结论固定监测点与自己的设备，走到目标的路径不同。节点监测的一条请求能收到响应，不代表设备、本地网络、DNS 和运营商这些环节都已经检查。

因此，监测点收到节点响应与自己这端无法完成握手，可以同时出现。反过来，监测点所在路径失败，也不能单独证明自己的路径同样失败。

还要区分检查对象：节点响应与入口首页可达性不是一项结果。站内入口记录回答的是页面访问，不用它证明节点服务正常。

域名解析则是另一种差别。若 CNAME 指向不存在的目标，只检查服务器 IP 响应的页面仍可能正常，客户端却无法通过域名取得地址。用 nslookup 节点域名 查看；出现 NXDOMAIN 或没有解析地址时，继续按 DNS 部分区分本地配置与商家域名记录。若源头记录错误，修复需要由商家完成。

基础检查完成后，还有哪些项目要核对？

一句话结论网络、系统时间与重新导入都已比较过，下一轮把注意力放到订阅内容、协议和客户端。按顺序保留结果，不用重复同一种操作覆盖不同环节。

1. 打开订阅详情，核对取得的列表是否符合所购内容。明显缺项或仅有测试内容时，查看是否到期、地址被重置或复制不完整，再从商家后台取得完整地址。
2. 检查长地址的末尾。中文输入法下复制时可能漏字，粘贴后逐项对照结尾，不只看前缀是否相同。
3. 比较不同协议：例如 Hysteria2 项都失败时，再试 Trojan 或 VLESS。协议对丢包和 QoS 的敏感情况可能不同，反复检查同一种协议并没有覆盖另一类条件。
4. 完全退出其他代理程序，并停用浏览器内的代理扩展，避免多层代理互相影响。
5. 在系统代理与 TUN 之间切换作对照。出现 系统代理开启失败，已断开连接 时，流量可能没有进入代理，不能把它等同节点握手失败。
6. 用另一款不同的客户端读取同一份适配订阅。若结果改变，继续检查原应用的配置或版本，把应用差异与商家侧问题分开。

对照完整地址与 Clash 导入操作

换了 DNS 怎么确认有没有用？

一句话结论DNS 调整针对域名到地址的解析，不处理全部握手问题。Windows 可运行 nslookup 节点域名；macOS 可运行 dig 节点域名，先看实际返回，而不是只凭超时猜原因。

系统 DNS 之外还有客户端内部配置。Clash 的 dns: 若指定了其他服务器，应用可能仍按该配置请求，而不是使用刚改过的系统项；需要改的是实际生效的那一处。

另查 proxy-server-nameserver：旧配置若继承了失效地址，节点域名可能始终无法解析，界面却不一定另报配置错误。要确认其中地址是否仍有效，不能只检查系统设置。

多个公共 DNS 都给出 NXDOMAIN 时，还需查看是否为商家域名源头记录错误。若目标本就不存在，继续切换本地 DNS 不能替商家修好记录，应等待其处理。

Verge 要看哪些设置？

一句话结论Clash Verge 要把内核、覆写、DNS 与服务模式分别检查。列表能显示，不表示这些层面的设置都已正确生效。

• 核对当前内核；改过内核或开启过覆写时，关闭覆写后比较。脚本有误可能影响全部节点，界面也可能没有对应报错。
• 查看配置中的 dns:，确认它是否覆盖了系统所改的 DNS。
• 单独确认 proxy-server-nameserver 内的地址，避免沿用旧配置里的失效项。
• 检查延迟探测所用的 URL。目标地址不可达或曾被修改时，列表可能全部报超时；换一个检查目标后再看结果，不能仅凭原探测认定节点失效。
• 核对 Service 与 TUN 是否实际启动。Windows 服务未启动时，需要先处理这一层，不能只重复选择节点。

小火箭还要排除哪些 iOS 条件？

一句话结论Shadowrocket 的导入方式与系统配置都可能参与结果。相同订阅在电脑正常、小火箭却失败时，先把以下项目逐项看完，不先改成订阅已经坏了。

• 扫码提示异常时，改用「从 URL 下载配置」导入，避免二维码压缩后的解析差异。
• 在设置进入 Wi-Fi，打开当前网络的详情，关闭「私人 WLAN 地址」后重新连接。
• 排查期间关闭低数据模式与低电量模式，比较后台连接是否受到影响。
• 查看系统中的 VPN 描述文件；存在多份时删除不再使用的配置，排除冲突。

这些检查覆盖导入、网络属性、后台及 VPN 配置，不用某一个开关的状态替其他项目作答。完成后再对照电脑与手机的结果。

v2rayN 先看日志还是超时？

一句话结论先读日志中的具体失败提示，再对照界面。单独的 timeout 不能涵盖代理写入、核心协议与分流文件的差别。

• 系统代理启用失败时，先核对 Windows 的代理设置是否成功写入；可用管理员身份运行，或改 TUN 进行比较。此时不能仅从该错误判断节点通不通。
• 查看核心版本及协议支持范围。核心过旧而不识别节点协议时，同类节点可能一起失败；Xray 核心与 Hysteria2 等相关协议条件需分别确认。
• 核对探测目标是否可达，避免与 Clash 类似地把目标地址失败当成全部节点失败。
• 使用 PAC 时检查 pac.txt。文件损坏可能使分流异常，可切换全局模式比较，区分该文件与节点连接。

NekoBox 的设置怎么检查？

一句话结论NekoBox 需要对应内核，下载未完成时可能影响全部节点。先确认应用运行条件，再看连接交给了哪些程序，不能只重复导入。

• 到设置重新下载对应内核，核对是否完整。
• Android 上先用 VPN 模式作比较，避免把系统代理模式的范围直接当成相同结果。
• 将 NekoBox 加入电池优化白名单，排除后台被结束后反复断开的情况。
• 开启分应用代理时，确认用来验证的应用在代理名单中；应用未被纳入，不能据此断言所有节点都不通。

什么情况才怀疑商家出问题？

一句话结论单项结果不足以作判断，需要同时核对下面这些条件。它们分别覆盖应用、网络、订阅交付与服务消息，不能只留其中一两项。

1. 多款客户端都出现同样超时，换应用后仍未恢复。
2. Wi-Fi、移动数据及另一 Wi-Fi 等不同环境都有相同问题。
3. 订阅能正常刷新，取得的列表内容也符合预期。
4. 商家有服务异常公告，或节点域名出现无法解析等服务侧异常线索。

这些条件一起出现，才有更多依据集中检查商家侧；不把任意单项直接当成停运结论。若异常持续多日，商家又没有明确说明，再考虑是否需要替换服务。

结合公告与失联变化继续核对

停止运营的相关记录另见 查看风险名单及原始来源，仍需连同记录时间和来源程度阅读。不能因本地暂时失败就直接套用风险标签。

需要重新比较时，排序和线路各看哪里？

按推荐清单继续查候选 中的位置由编辑安排，推荐位含合作关系，不代表性能或费用高低。希望只按公开起点比较，可在同页看 不受推荐位置影响的费用表；部分推广成交可能使本站获得佣金。

重视连接连续性时，还需区分内网与公网路径，继续读 把 IPLC、IEPL 与中转直连分别理解。路径资料用于核对需求，不能只凭名称保证当前连接没有故障。

不是全部超时还能查什么？

能够连接但晚间变慢，可转到 按时段核对卡顿原因。导入环节失败则按前面的客户端步骤检查，不与已经取得节点后的握手问题混在一起。

其他症状可用 逐项查看常见故障检查；要读入口当日记录，可用 确认入口访问结果和采集时间。入口响应与节点连接仍是不同检查范围。