所有节点显示 Timeout 的完整排查方法
所有节点同时超时,问题几乎都不在节点本身。本文给出一条从订阅、本地网络、系统时间到客户端配置的完整排查路径,每一步都可以直接执行并验证。
节点超时、订阅失败、连接后无网络、DNS 与 TUN 模式问题的系统排查方法,每一步都是可执行的中文说明。
代理连接出问题时,盲目切换节点往往浪费时间。本栏目把常见故障整理成统一的排查框架:问题现象 → 快速判断 → 常见原因 → 按顺序排查 → 验证结果 → 备用方案。 每篇文章针对一种具体现象,按顺序执行即可定位大多数问题;如果你还不熟悉节点、订阅和客户端的关系,建议先阅读机场是什么。
所有节点同时超时,问题几乎都不在节点本身。本文给出一条从订阅、本地网络、系统时间到客户端配置的完整排查路径,每一步都可以直接执行并验证。
证书错误的常见原因不是"网站真的不安全",而是系统时间偏差、客户端的 MitM/证书抓包功能被误开,或极少数情况下节点本身存在劫持。本文按可能性从高到低给出排查顺序。
DNS 泄漏指域名解析请求绕过代理直接发往本地或运营商 DNS 服务器,即便代理连接本身正常,本地网络也可能看到你访问过哪些域名。本文讲清检测方法与两种常见场景下的修复步骤。
官网打不开不等于服务结束——域名被墙时挂代理或换备用域名即可访问,服务器故障通常等待加看公告,只有官网、节点、公告渠道长期同时失效才需要按风险处置。平时保存备用域名和加入公告频道,是成本最低的预防。
局域网共享代理失败的原因集中在四个环节:其他设备的网关是否正确指向共享设备、DHCP 是否下发了正确网关、路由器防火墙是否放行了转发流量,以及目标设备是否被分流规则划入了直连例外。
联机游戏匹配失败、语音断续,多数情况下不是延迟高,而是节点或协议对 UDP 转发支持不完整。本文讲清 UDP 与 TCP 的差异、如何确认节点支持情况,并给出协议选择与延迟抖动优化建议。
Telegram 客户端直连 IP 而非域名,普通域名规则无法匹配它的流量。在规则集中补齐 Telegram 的 IP 段(GEOIP 规则),或更新规则集、启用增强模式,即可摆脱对全局模式的依赖。
订阅更新失败分四类——链接本身失效、订阅域名被干扰、代理不可用形成的更新死锁、客户端请求特征被服务端限制。按顺序判断类型后,每一类都有对应解法。
Codex 长任务依赖持续数分钟甚至更久的流式连接,任何一次连接重置都会打断任务。断流主要来自节点自动切换、TCP 长连接被中间链路重置与客户端超时设置,三者都有对应解法。
手机可用证明订阅与节点都正常,故障范围收窄到 Windows 本机。按防火墙、系统代理残留、TUN 驱动、浏览器设置、hosts 文件的顺序排查,多数问题出在前两项。
Clash 面板一切正常但网页打不开,说明流量没有真正经过代理。按系统代理开关、DNS、规则模式、浏览器插件、FakeIP 缓存的顺序排查,通常十几分钟内可以定位。
延迟测的是往返时间,速度取决于带宽、丢包与线路拥堵,两者没有必然联系。通过分时段测试、换协议换端口、多线程对照,可以定位速度慢的真实环节。
同一节点「别人能用、自己不能用」,差异必然出在你与节点之间的环节——运营商、本地 DNS、家庭网络、客户端版本或系统时间。本文给出五个方向的对照排查法。
Shadowrocket 连上后没有网络,多数与 iOS 的 VPN 机制有关——描述文件冲突、协议不支持、DNS 配置或网络切换都可能导致。本文按发生频率给出排查顺序。
Wi-Fi 正常而移动数据失效,核心差异在蜂窝网络的 IPv6 优先环境、运营商出口策略和系统对客户端的联网限制。按网络环境、客户端权限、APN 三层排查即可定位。
先确认三件事:订阅是否有效(套餐没过期、流量没用完)、直连网络是否正常(关掉代理能否上网)、客户端时间与系统时间是否准确。这三项排除后,再按文章里的顺序逐步定位。
节点可用性受服务端调整、线路波动和网络环境变化影响,属于常见现象。先更新订阅获取最新节点列表,再切换其他节点测试;如果全部节点失效,参考「所有节点超时」一文排查本地原因。
每篇排查文章底部都有备用方案,通常包括联系服务商工单、更换客户端验证和使用备用服务。建议日常保留至少一个备用连接方案,避免单点故障影响使用。