节点超时或无法连接是使用 Clash 及其衍生内核（Clash Meta、mihomo）过程中最常见的问题类型，但表现相同的故障背后往往对应完全不同的原因：可能是订阅本身已失效，可能是节点服务端出现波动，也可能是本地网络配置冲突。逐一猜测容易浪费时间，按固定顺序从外部到内部依次排除，才能快速定位问题所在。本文给出的排查顺序遵循一个原则：先确认数据来源是否正常，再确认软件是否正常工作，最后确认系统环境是否放行了代理流量。
排查前的基本判断
在进入具体步骤之前，先明确故障范围。打开客户端，观察连接失败的提示信息和影响范围，能帮助缩小排查方向：
- 全部节点都无法连接：更可能是订阅、系统代理或防火墙这类全局性问题。
- 只有个别节点无法连接，其余正常：更可能是节点服务端本身的问题，或者延迟测试结果本就异常。
- 之前能用，突然全部失效：优先检查订阅是否过期或流量是否用尽，其次检查本机是否有新安装的软件占用了端口。
- 换了新设备或新系统后无法连接：优先检查系统代理和防火墙设置，这是新环境最容易缺失的配置。
做完这个初步判断后，再按下面五个步骤逐层排查，通常能在第二到第四步之间就能定位到具体原因。
第一步：检查订阅是否有效
订阅失效是节点全部超时最常见的原因，但很容易被忽略，因为客户端界面上节点列表可能仍然显示着，只是背后对应的服务已经停止响应。检查订阅有效性可以从以下几个角度入手：
- 查看订阅到期时间和剩余流量：多数订阅服务商会在链接或面板中提供到期日期与流量余量信息，客户端的订阅管理页通常会展示这两项数据，确认是否已经到期或流量已用尽。
- 手动更新订阅：在客户端的订阅列表中执行一次手动更新（通常是一个刷新图标或“更新订阅”按钮），如果更新失败并提示网络错误或链接无效，说明订阅地址本身出现了问题。
- 检查更新时间戳是否异常：如果自动更新长期停留在很久之前的时间，说明定时更新可能因为网络问题一直失败，节点列表实际上是过时的缓存数据。
- 确认订阅链接未被截断：手动导入订阅链接时，复制粘贴过程中链接末尾的参数容易被遗漏，导致链接指向的内容不完整。重新完整复制一次链接是排除这种可能的最简单方法。
注意：如果订阅更新成功但节点数量和之前完全一致，也不代表订阅一定有效，服务商停止维护后节点列表可能长期不再变化，此时需要结合第二步的延迟测试进一步确认。
第二步：测试节点延迟
订阅确认有效后，下一步是判断具体是哪些节点出现问题。Clash 客户端通常在节点列表旁提供延迟测试功能，点击后会对每个节点发起一次网络探测并显示往返时间（毫秒数）。观察测试结果时注意区分以下几种情况：
- 显示具体毫秒数（如 80ms）：说明该节点当前可以连通，超时问题不在这个节点上，应该继续排查系统层面的原因。
- 显示超时或无响应：说明节点服务端当前不可用，可能是服务器维护、线路波动或该节点被大规模限制，尝试切换到同一分组下的其他节点。
- 所有节点均显示超时：延迟测试本身依赖网络连接完成，如果连测试请求都无法发出，问题往往出在本机网络环境，而不是节点服务端，应该转向后面的端口、系统代理和防火墙排查。
延迟测试的 URL 通常可以在设置中自定义，如果默认测试地址本身在当前网络环境下不可达（例如默认使用了某个特定站点），会导致测试结果整体异常，可以尝试更换一个测试地址后重新测试，排除测试链路本身的问题。
如果某个节点长期高延迟或频繁超时，而其它同一订阅下的节点表现正常，通常是该节点线路质量问题，直接切换节点是最直接的解决方式，不需要在这一个节点上反复排查。
第三步：检查端口占用
如果延迟测试也无法完成，接下来检查 Clash 使用的本地端口是否被其他程序占用。Clash 内核启动时会监听一组本地端口用于接收代理请求，常见的包括 HTTP 代理端口、SOCKS5 代理端口和混合端口（mixed-port），如果这些端口已经被其他程序占用，内核可能无法正常启动监听，导致所有流量都无法转发。
排查端口占用可以按以下方式操作：
- 打开客户端的日志面板，查看内核启动时是否有类似“端口已被占用”“bind: address already in use”之类的报错信息。
- 在系统命令行中查询端口占用情况。Windows 下可以使用命令行工具查看指定端口对应的进程：
netstat -ano | findstr 7890macOS 与 Linux 下可以使用：
lsof -i :7890- 如果发现有其他程序占用了 Clash 需要使用的端口，可以关闭该程序，或在客户端设置中修改 Clash 使用的端口号，避开冲突。
- 修改端口号后需要重启内核使配置生效，并检查系统代理设置中记录的端口号是否也同步更新，两者不一致会导致系统代理指向一个已经无人监听的端口。
说明：同时运行两个 Clash 客户端，或者上一次进程未完全退出就重新启动，是端口冲突最常见的诱因，重启系统或彻底结束相关进程通常可以解决。
第四步：确认系统代理状态
端口正常监听之后，如果浏览器等应用依然无法通过代理访问网络，需要确认系统代理是否真正生效。系统代理决定了哪些应用会把流量交给 Clash 处理，如果这一层配置出错，即便节点和端口都正常，流量也不会经过 Clash。
- 检查客户端内的系统代理开关：确认客户端设置中“设置为系统代理”或类似选项已经开启，部分客户端在重启后不会自动恢复该开关状态，需要手动重新开启。
- 检查操作系统的代理设置：在系统网络设置中查看代理地址和端口是否与客户端当前使用的端口一致，尤其是在手动修改过端口号之后，系统层的代理设置有时不会自动同步。
- 区分系统代理与 TUN 模式：系统代理只对遵循系统代理设置的应用生效，命令行工具、部分游戏或后台服务可能不读取系统代理配置，这类场景下即便系统代理已经开启，这些应用依然会显示无法连接，需要改用 TUN 模式接管全部流量，而不是继续在系统代理层面排查。
- 浏览器或应用自身的代理设置：某些浏览器有独立于系统代理的网络设置项，如果浏览器配置了“不使用系统代理”，即便系统代理正常工作，该浏览器依然无法通过 Clash 访问网络。
确认这一层没有问题的一个简单方法是打开客户端的连接日志或流量面板，观察是否有实时的连接记录产生。如果发起浏览请求后面板上完全没有新连接出现，基本可以确定流量没有进入 Clash，问题出在系统代理配置这一层。
第五步：排查防火墙拦截
如果系统代理配置确认无误，流量已经进入 Clash 但仍然报告超时，最后需要检查是否有防火墙或安全软件拦截了 Clash 的网络访问。这一步在新安装的系统、企业管理的电脑或者刚更新过安全软件版本后尤其常见。
- 检查系统自带防火墙：确认 Clash 主程序及其内核进程被允许通过防火墙的入站与出站规则，如果是首次运行被拦截，操作系统通常会弹出授权提示，需要选择允许而不是拒绝。
- 检查第三方安全软件：部分安全软件会将代理类工具识别为风险程序并静默拦截其网络请求，而不会弹出明显提示，此时需要在安全软件的日志或白名单设置中手动添加 Clash 的可执行文件。
- 检查路由器或网关层面的限制：一些家庭路由器或公司网络在网关层做了端口限制或协议识别，如果本机所有排查步骤都正常但依然无法连接，可以尝试更换网络环境（如手机热点）进行对比测试，缩小问题范围。
- 确认节点使用的传输协议未被针对性限制：部分网络环境会对特定协议特征进行识别和干扰，如果同一订阅下某些协议类型的节点普遍超时、另一些协议类型的节点表现正常，说明网络环境对特定协议做了限制，应优先选择表现正常的协议类型的节点。
注意：关闭防火墙进行测试仅用于临时排查问题原因，确认拦截来源后应恢复防火墙并添加针对性的允许规则，而不是长期关闭系统防护。
仍无法解决时的补充检查
如果按以上五步排查后问题依然存在，可以补充以下几项检查，覆盖一些相对少见但确实会导致连接失败的情况：
- 配置文件中的规则冲突：如果自定义了规则集，检查是否存在规则将本应代理的流量错误地划分到了直连分组，或者代理组的策略选择器配置有误，导致实际选中的节点和界面显示不一致。
- DNS 解析异常：即便代理连接正常，如果 DNS 解析出现问题，浏览器也会报告无法访问，可以在配置中检查 DNS 设置项，或切换为 fake-ip 模式排查是否为 DNS 解析导致的连接失败假象。
- 内核版本与配置格式不匹配：更新客户端或内核版本后，旧的配置文件字段可能已经变更或废弃，查看日志中是否有配置解析相关的警告或报错。
- 系统时间不准确：部分节点的加密协议对系统时间偏差比较敏感，系统时间与实际时间相差较大时可能导致握手失败，表现为连接超时，检查并校准系统时间可以排除这一类问题。
把这五个步骤和补充检查按顺序走一遍，绝大多数节点超时问题都能在其中一步找到明确原因。养成先看日志、再逐层排查的习惯，比反复重启软件或更换节点更能稳定地解决问题。