遇到 Shadowrocket 超时问题，很多人第一反应就是换节点。说白了，这样查太慢了。真正麻烦的地方，不是节点一定坏了，而是
DNS、连通性、握手、兼容模式、UDP、规则分流 这些东西会一起搅进来，看起来都像“超时”。这篇就不绕弯子了，直接按日志和排查顺序来。
开始前先确认 3 件事
- 超时不等于节点一定失效，很多时候是 DNS 没解析出来，或者当前网络没把连接走通。
- 别一上来就删订阅、重装软件。先看日志，再决定动 DNS、动设置，还是换节点。
- 同一个节点，Wi-Fi 能用、蜂窝数据超时 很常见，两个环境一定分开测。
如果你已经在 Shadowrocket 日志里看到类似报错，可以直接点下面对应关键词，跳到那一段看解决思路。
第一步先做连通性测试，别只看延迟
很多人平时只看节点列表里的延迟数字，觉得 80ms、90ms 就稳。其实不是。能测出延迟，不等于真正能连通。真正该看的，是它能不能稳定连上、连上后会不会马上超时。
更稳的做法很简单：先把延迟测试方法调成更适合实际连通判断的方式，再跑一轮连通性测试。先确认“能不能通”，再看后面的 DNS、日志和具体报错，这样排查会快很多。
我建议这样查
- 先做一轮连通性测试
- 优先选能稳定通过测试的节点
- 不要只看 ping 数字
- 同机场节点之间也要横向对比
Shadowrocket 超时，一般会卡在这 4 层
- DNS 解析：先把域名变成 IP
- 连接节点：手机先去连代理服务器
- 握手建立：TLS、Trojan、VLESS、Reality 这些继续往下谈
- 访问目标网站：最后把网页或 App 内容拉回来
你只要把这一层想明白，很多日志就不难看了。看到不同报错，不是马上换机场，而是先判断它到底卡在“解析”、“连接”，还是“握手”。
报错一：dns resolve failed
这个报错最常见。翻成人话就是：域名没解析出来。不是一定网站挂了，也不是一定节点坏了，而是 Shadowrocket 在规定时间里没有拿到目标域名对应的 IP。
常见表现
- 节点显示已连接，但网页一直转圈
- 有些 App 能开，有些死活打不开
- Wi-Fi 正常，切到流量就容易抽风
- 换了几个节点，问题还是差不多
常见原因
- DNS 服务器本身不通，或者响应特别慢
- 本地 DNS、远程 DNS、系统 DNS 混着用，把路径绕乱了
- 节点域名自己都没解析出来，还没连上机场就先卡住
- 蜂窝网络下 DNS 表现明显比 Wi-Fi 差
先查什么
- 先看 DNS 相关日志
- 把 DNS 配置简化，别一口气堆太多套
- 必要时再考虑远程解析或代理解析
- 再换同机场其他节点，排除单个入口异常
看到
dns resolve failed，先把 DNS 这层查清楚，往往比盲目换节点有效得多。报错二：context deadline exceeded
这个报错最容易把人看懵。它本身不是在告诉你“哪项配置错了”，它的意思更像是：某一步在限定时间内没完成。
怎么判断
别只盯这一句，要看它前面的完整上下文：
- dns resolve failed: context deadline exceeded → 基本就是 DNS 解析超时
- connect error: context deadline exceeded → 更像是连节点这一跳超时
这种情况怎么查
先别急着动配置。先分清到底是 DNS 卡住了，还是 connect 那一步没过去。只要层级分清，后面就不会乱。
报错三：connect error
看到这个，很多人直接就说“节点死了”。有时候确实是。可很多时候不是死，而是手机到节点这一跳没有走通。
常见原因
- 节点 IP 或端口写错了
- 服务端没起来，或者端口没监听
- 当前网络把某个端口或协议拦了
- 晚高峰入口拥堵，连不上或很慢
先查什么
- 先换同机场不同地区节点
- 再换同机场不同协议节点
- 看连接相关日志，确认到底卡在哪
- Wi-Fi 和蜂窝数据分开测
延迟低，只能说明“看起来不错”。真正要紧的是它能不能稳定连通，连通后会不会马上抽风。
报错四：TCP handshake timeout
这个比普通 connect error 更明确一点。意思就是：TCP 连接握手阶段没完成。简单理解，就是手机已经去敲门了，但对面一直没正常回应。
常见原因
- 当前网络丢包高，质量一般
- 节点入口晚高峰被挤爆
- 运营商到这条线路绕路严重
- 机房状态不稳，握手阶段就开始拖
先查什么
- 换节点地区
- 换协议类型
- 换网络环境测试
- 观察是不是晚上固定时间集中出现
报错五：TLS handshake 相关错误
这类问题一般不是完全连不上，而是 TCP 已经过去了，但 TLS 或协议握手没谈拢，或者谈得太慢。
常见原因
- 客户端和服务端参数没对上
- 线路不稳，握手阶段丢包
- 当前网络对某个协议兼容一般，白天能用，晚上抽风
先查什么
- 换同机场其他协议
- 继续看连接相关日志
- 确认是不是只有某一种协议容易出问题
Wi-Fi 能用、流量超时，重点别放错
这种情况特别常见。在家正常，出门一开数据就开始超时。很多人还在那里死调节点，方向一下就偏了。
先查什么
- Wi-Fi 和蜂窝数据分开测试，不要混着看
- 如果只在流量下容易抽，优先看兼容模式和接管方式
- 如果某些协议、语音、视频场景不稳，再看 UDP 相关设置
- 如果只是部分 App 出问题，再看规则分流和按需连接逻辑
没明显报错，但一直转圈怎么办
这种最烦。日志不够直白，用户体验却最差。表面上看像“都没报错”，实际上问题通常还是落在几块：DNS、规则、目标站点、当前网络。
最常见的几种情况
- 规则分流错了：该代理的走了直连，该直连的又进了代理
- DNS 路径乱了：解析出来了，但出口不对
- 目标网站自己慢：别什么都怪节点，有时就是网站或 CDN 抽风
这种情况怎么查
- 先换几个不同网站测试，不要只盯一个目标
- 再回头看规则和 DNS
- 最后再判断是不是节点质量问题
一张表，直接对照看
| 日志报错 | 大概率问题 | 先查哪边 |
|---|---|---|
| dns resolve failed | DNS 解析失败或过慢 | DNS 设置、DNS 日志、解析路径 |
| context deadline exceeded | 某一步在限定时间内没完成 | 先看前后文，判断是 DNS 还是 connect |
| connect error | 到节点这一跳没走通 | 连通性测试、连接日志、网络环境、节点入口 |
| TCP handshake timeout | TCP 握手没完成 | 换地区、换协议、换网络、看高峰期表现 |
| TLS handshake | TLS 或协议握手异常 | 换协议、看日志、排查参数和线路稳定性 |
| Wi-Fi 能用，流量超时 | 网络环境或系统接管方式问题 | 兼容模式、UDP、按需连接、权限相关设置 |
| 没明显报错但一直转圈 | 规则、DNS、目标站、链路异常 | 先换网站测试，再看规则和 DNS |
常见问题
Q1：Shadowrocket 连上了，但还是超时，是不是节点不行？
不一定。很多时候只是 DNS 没解析对，或者当前网络没有把连接真正走通。先做连通性测试，再翻日志，比上来就删订阅靠谱得多。
Q2：为什么有时候只在流量下超时？
这类情况很常见。重点往兼容模式、UDP、按需连接这些方向去看，别把 Wi-Fi 和蜂窝数据混在一起排查。
Q3：晚高峰一到就开始超时，怎么处理？
说白了，多半还是线路质量不够。白天能用不代表晚上稳。碰到这种，优先换更稳的入口和协议，比一直死守一个便宜节点更省时间。