Shadowrocket 故障排查
连接、订阅与 DNS 检查

01 · 连接尚未建立

开关打不开：先检查授权与接管状态

先区分开关完全没有响应、点击后立即回落、显示连接后又断开三种情况。前两种更接近本机授权或配置问题，第三种还可能涉及网络切换和按需触发。不要在尚未建立系统连接时反复更换服务器密码，因为远端参数未必已经参与这次失败。先记下弹窗原文、发生时刻和开关停留的状态，再检查系统设置中是否出现对应连接记录。

首次授权与已有连接记录

第一次开启时，系统可能要求允许添加 VPN 配置，并要求完成设备身份验证。这一步是本机网络接管授权，不是订阅登录。确认请求来自刚刚主动打开的 Shadowrocket，再完成系统提示；如果取消，返回应用再次开启并重新确认。若设备由学校或单位管理，限制可能来自管理策略，不能通过修改订阅绕过，应向设备管理员确认是否允许添加此类网络配置。

已经授权却仍立即回落时，先停止其他正在接管网络的 VPN 连接，再回到 Shadowrocket 测试。多份配置出现在系统列表中，不代表它们同时生效，也不代表都需要删除。先确认当前活动项及其来源，只处理能明确归属且确实异常的记录。删除系统连接记录之前保留应用内配置，重新建立时仍应从应用主动触发授权，不安装来历不明的描述文件。

检查当前选择，而不是只看列表

在 Home 确认已经选中一条用户自己的有效服务器信息；列表里存在若干名称，并不说明当前选择正确。随后进入 Config，核对实际启用的配置文件。若刚导入文件便出现异常，优先恢复之前能够启动的配置副本，比较新增的策略名称、引用关系和语法，而不是把所有规则一起清空。应用出现解析错误时，保留错误所在行附近内容，注意排除多余标点与不完整的段落。

若开关关闭后又自动开启，检查 On Demand 是否仍在触发。为便于复现，可暂时关闭相关按需条件，再手动开启一次；这只是隔离触发因素，不是要求永久停用。若手动连接稳定，恢复按需设置时逐条核对网络类型和匹配条件，避免把自动重连误判为按钮失灵。系统中其他连接配置的自动连接条件也应一起确认。

重启与重建的使用边界

完成上述检查仍无法启动，可先正常退出应用并重启设备，再在稳定网络下复测。重启能清除部分暂时状态，但不能修正错误的配置语法。若必须重建系统连接记录，先确认订阅、独立服务器条目和当前 Config 均有可恢复副本。不要把删除应用当作第一步，因为本机保存的独立条目可能无法从订阅重新获得，照片中的二维码也未必仍然有效。

记录开关回落时是否伴随网络切换、锁屏或系统提示。若每次都在同一动作后发生，就沿这条触发路径继续检查；若只在某份配置出现，则保留能正常启动的对照文件。判断本章完成的标准是系统连接可以建立并保持，而不是网页一定能打开。开关已稳定但请求仍失败时，进入下一章，避免继续重复授权操作。

02 · 开关已连接

无法上网：拆分基础网络、路由与目标请求

连接状态说明本机接管已经建立，不代表所选服务器能到达目标，也不代表 DNS、规则和目标服务全部正常。先停止连接，用原网络访问一个平时能够直接访问的页面，确认 Wi-Fi 已完成登录、蜂窝数据仍可用。若关闭后也无法访问，先处理路由器、信号或网络认证；此时反复调整代理参数，只会把基础网络问题和客户端问题混在一起。

用三个姿态做有限对照

Global Routing 的配置、代理、直连分别对应 Config、Proxy、Direct。Config 按当前配置规则选择路径；Proxy 用代理路径做整体对照；Direct 用直连路径做对照。测试前记下原模式，用同一个目标、同一网络、同一选中服务器比较。Proxy 并不意味着能够修复服务器故障，Direct 也不是对所有目标都应成功的保证；它们的意义在于缩小失败范围。

若 Proxy 正常而 Config 异常，不应立即长期保留 Proxy 来掩盖规则问题。先在请求记录中找到刚才的目标域名，查看最终策略是否与预期一致。规则引用的策略名必须真实存在，名称相近也不能视作同一项。目标页面还可能依赖登录、图片和接口等多个域名，主文档成功不代表这些依赖请求也走了同一条路径。

区分全部失败与部分失败

只有一个应用异常时，先关闭该应用并重新打开，再观察是否产生新连接记录。部分应用会复用已有连接，因此改完规则后立即刷新，未必已经走新策略。若浏览器正常而单个应用失败，继续检查该应用依赖域名、系统网络权限和服务自身状态。不要仅凭一个应用的错误提示判断整条服务器连接失效，也不要为单个目标把所有请求永久改为同一路径。

在 Wi-Fi 与蜂窝网络之间做一次对照，可以帮助识别局域网或接入网络差异。切换时先停止连接，确认新网络本身可用，再重新连接并请求同一目标。如果只有 Wi-Fi 异常，检查认证页面、路由器 DNS、局域网限制和地址冲突；如果只有蜂窝异常，检查应用蜂窝数据权限及当前信号。对照过程不要同时更新订阅，以免改变所选条目。

让日志对应一次明确动作

开始测试前记录时间，随后只发起一次目标请求，再查看附近记录中的域名、命中规则、最终策略和错误阶段。若日志只有解析失败，先转到 DNS 章节；若已经开始远端握手，再检查协议参数；若收到目标的访问拒绝或登录要求，则说明至少部分传输已经发生，不能再把它描述成完全无法联网。错误文字是定位线索，不是直接替换全部设置的指令。

恢复时先回到原有 Global Routing 姿态，再保留确有必要的修改。若临时关闭了某条规则或自动触发条件，应记录原因，避免测试状态成为日常配置。仍不能定位时，可将已隐藏敏感信息的错误摘要与网络对照结果整理出来，再查分类问答；比起只写“已连接但不能用”，这些信息更能说明故障所在层级。

03 · 远端连接失败

节点超时：分别核对测试方式与协议参数

超时表示一次操作没有在限定时间内完成，但操作可能是延迟测试、建立传输连接、协议握手或访问测试目标。先确认超时来自 Home 的测试结果，还是实际使用时的请求日志。测试目标不可达时，条目可能显示失败，而另一个业务目标仍可访问；反过来，测试有响应也不能证明所有业务请求都正常。因此必须将测试结果与实际目标请求交叉核对。

先查服务器地址和端口

打开所选条目的编辑页，对照用户已有的原始服务器信息检查地址与端口。地址字段不应误带网页路径、前后空格或端口分隔符；端口应与原始配置一致，不根据常见数值猜测。服务器以域名表示时，还要确认域名能够解析；以 IP 表示时则应区分地址族。若域名刚被服务端调整，本地缓存或旧连接可能仍保留原地址，应在重建连接后重新观察。

仅一条超时而其他已有条目正常，更像是该条目的参数或远端状态问题；同一来源的全部条目同时异常，则检查基础网络、订阅是否过期及远端是否变更。可以切换另一条自己已有的条目作对照，但不要把多次连续批量测试当作修复手段。过于频繁的测试本身可能增加负载，也会使日志中混入大量与实际故障无关的请求。

握手字段必须成组核对

协议类型选错时，地址和端口完全正确也可能无法完成握手。Shadowsocks 的加密方式与密码、VMess 和 VLESS 的身份信息、Trojan 的密码，以及传输相关字段都应按原始配置逐项比对。不要把一种协议的字段直接搬到另一种协议。若使用 TLS 或特定传输，还应同时检查服务端名称、路径与相关头字段，不能只保留一个看起来像域名的值。

日志出现证书相关错误时，先检查设备日期与时间，再核对服务端名称是否匹配配置要求，最后确认服务端证书状态。不要为了让提示消失就长期放宽验证条件。若配置依赖 UDP 传输，所处网络是否允许相应流量也会影响结果；某种传输在当前网络失败，不意味着换一个协议名称就能修复，服务端必须实际支持对应配置。

按失败阶段决定下一步

无法解析服务器域名时，处理本地解析链路；能解析但建立连接超时，检查接入网络和远端监听；连接被立即拒绝，优先确认端口与服务状态；已经建立连接却身份验证失败，优先核对凭据。不同实现的日志措辞可能不同，应结合前后记录判断，不把单个英文单词当作唯一依据。若错误只在某个网络出现，应保留网络对照结果。

订阅管理的条目被手动改过之后，下一次更新可能重新写入原字段。确需临时对照时，先复制为独立测试条目并清楚命名，避免以为修改未保存。验证结束后删除不再需要的测试副本，保留来源明确的正式条目。恢复有效连接的标准是预期业务请求成功，且日志走到预期策略，而不是测试数字看起来更小。

04 · 获取与解析分开检查

订阅失败：区分链接获取、内容解析与更新覆盖

订阅更新失败有两条不同路径：客户端没有获取到响应，或已经收到响应但内容无法解析。列表为空也可能只是筛选条件、分组折叠或更新后名称变化。先保留原订阅与可用条目，不要连续删除再添加。记录更新前的分组状态、错误提示和当前网络，再在 Home 手动更新一次，观察问题发生在网络请求阶段还是导入阶段。

确认链接完整且用途正确

从用户自己的配置提供方重新复制订阅链接，检查前后空格、换行和聊天软件附带标点。链接中用于区分访问权限的参数不能缺失，也不能将某个参数后面的内容当作备注删除。网页管理地址、登录页面地址和订阅地址用途不同，能够打开网页并不表示它就是可导入内容。二维码也应确认承载的是订阅地址还是单条服务器信息。

若错误提示指向身份验证、权限或内容不存在，应在原有账户页面确认链接是否仍有效、访问权限是否改变，以及是否需要重新生成。新链接可能使旧链接失效，因此更新前先确认会影响哪些设备。不要把含访问参数的地址粘贴到公开讨论区、在线转换页面或陌生检测工具。向他人说明问题时，仅保留域名、错误类型与参数名称，隐藏参数值。

收到内容不等于收到正确格式

有时请求返回成功，但正文实际是登录页面、访问提示或普通网页。此时网络传输已经完成，问题在内容类型或权限，不应继续修改 DNS 试图让解析成功。若提示格式不支持或某些条目无法识别，先确认提供方给出的内容适用于 Shadowrocket，并区分单条分享信息、服务器列表与 Config 配置文件。不同导入入口有各自用途，不能因为都是文本就互相替换。

更新后只缺少部分条目时，检查这些条目是否使用不同协议或新参数，再与原始说明核对。名称变化也会导致旧策略组仍引用旧名称，表现为列表里有条目但规则选不到。应把订阅内容、分组筛选和 Config 的策略引用分开检查。若用户自行设置了筛选条件，可暂时撤销筛选看完整列表，再逐项恢复，而不是直接判断远端没有返回内容。

检查更新请求本身走哪条路径

订阅地址也是网络请求，其获取路径可能受当前网络和配置影响。若当前选中的服务器已经失效，而更新请求又依赖它，就可能形成无法自我恢复的状态。先确认基础网络可用，再用已知可用的路径尝试获取，并保留原模式。只在明确知道当前路径造成阻塞时做临时切换，不应把所有订阅固定改成某一路径，也不承诺直连或代理一定可取回内容。

手动更新成功后，核对条目是否完整、当前选择是否仍存在，以及配置中的名称引用是否需要调整。自动更新的问题还要检查设备是否当时离线、应用是否有执行机会及系统限制；不要把未触发自动更新与服务器返回空内容混为一谈。频繁缩短更新间隔通常不能修复权限或格式问题，只会重复同样的失败请求。

如果要重建订阅，先保存独立条目与当前 Config，再记录旧分组的用途。新订阅导入后，先用其中一条确认连接，再调整原有策略引用，最后移除重复分组。完整恢复不仅是更新按钮不再报错，还包括预期条目出现、当前选择正确、规则能够引用。基础导入步骤可返回使用教程核对，本章则用于解释每个失败分支。

05 · 请求能够完成

速度慢与断流：先建立可比较的测试条件

速度慢不是单一指标。页面首次打开等待、持续下载速率低、视频缓冲和连接中途断开，可能来自完全不同的阶段。先确定哪种现象最稳定，选一个合法且熟悉的目标，在同一网络和相近时间重复少量测试。不要把不同网站、不同文件大小或不同清晰度的结果直接比较，也不要只凭延迟测试判断持续传输能力。

把等待拆成解析、握手与传输

若第一次打开很慢，随后连续访问正常，优先观察 DNS 与新建连接过程；若页面很快出现但大文件持续传输缓慢，优先观察带宽、拥塞和目标服务限制；若每隔一段时间停顿，再自行恢复，检查网络切换、无线信号与长连接重建。日志能够帮助识别请求是否一直重试，但不能仅凭客户端日志准确推算远端链路上每一段的带宽。

测试时暂停设备上与排查无关的大流量任务，例如云端同步、系统下载和大文件上传。上传占满可用链路时，也可能使普通页面响应变慢。随后让设备保持同一位置，对照另一条自己已有的服务器信息；每次只切换条目，不同时改 DNS、规则和协议参数。若所有条目同时变慢，先检查本地接入网络，而不是一次修改全部服务器。

无线网络与目标服务分别对照

Wi-Fi 信号看起来充足，不代表信道拥塞、路由器负载或上行链路都正常。可在靠近路由器的位置复测，并在条件允许时用蜂窝网络做对照。切换网络后必须重建连接，避免拿旧连接的失败结果评价新网络。如果只有某一局域网慢，再检查路由器或网络管理限制；不要在没有证据时直接重置整台设备的所有网络设置。

单个网站慢，而其他相同类型请求正常，可能涉及目标的内容分发、账户状态或对当前出口的限制。此时先看失败域名实际命中的策略，确认它是否误走了与页面主体不同的路径。某些媒体资源与主页面使用不同域名，规则只能按已知请求特征作决定，不能根据页面外观自动知道哪些资源应该同路。修改规则后应新建连接再验证。

断流、UDP 与包大小问题

文字页面能打开而某些实时业务失败时，要检查该业务是否依赖 UDP，以及当前协议与网络路径是否支持相应流量。不能仅打开一个相关选项就推定服务端已经具备支持条件。若短请求正常、大请求容易停顿，包大小与路径特征也值得检查，但不要照抄陌生数值作为固定答案。任何参数实验都应记录原值，一次改一项，并准备立即恢复。

长连接中断可能与锁屏、无线网络切换、远端超时或系统资源压力有关。记录中断前后的时间和设备动作，观察是否总在相同触发条件下出现。如果每次切换接入点后断开，应先验证重新连接是否恢复；如果静止使用也持续重建，再查看远端握手和目标返回错误。将这些场景统一称为“速度慢”，容易错过真正的触发点。

恢复后保留一组可复现的基线：网络类型、当前条目、Global Routing 姿态、目标类别与观察到的症状。不需要长时间连续测试，更不应为了测试反复消耗大量流量。若速度变化来自外部网络或目标服务，客户端设置未必能够消除；本章的目标是分清责任边界，并找出能够通过配置修正的部分，而不是承诺固定速率或稳定时长。

06 · 解析与匹配

DNS 问题：先查解析结果，再查规则路径

DNS 将域名转换为地址；规则决定请求采用哪种策略，两者有关联但不是同一个步骤。域名无法解析、解析结果不合预期、连接到了错误路径，都会表现为网页打不开。先找同一次失败请求的域名和错误阶段，再判断是没有得到地址，还是得到地址后连接失败。不要仅因为页面恢复过一次，就认定某个 DNS 地址适合所有网络。

避免解析链路依赖自身

检查当前 Config 与 Settings 中实际生效的 DNS 设置，而不是只看刚编辑的文件。如果解析服务本身使用域名，它也需要先有可工作的基础解析路径；如果解析请求必须经过尚未建立的代理，又可能形成启动依赖。排查时先保留原配置，再确认解析服务地址和访问路径能够到达。不要同时叠加多个未知来源的 DNS 片段，导致无法辨认究竟哪项覆盖了哪项。

同一域名可能返回多个 IPv4 或 IPv6 地址，网络对不同地址的可达性也可能不同。只有部分请求失败时，应观察实际使用的地址族，而不是立即全局关闭某种能力。服务器域名的解析与业务目标的解析还应分开看：前者失败会使代理连接根本无法建立，后者失败则可能只影响特定目标。修改后重新建立连接，防止旧缓存掩盖变化。

用最小规则片段理解匹配

下面是用于说明顺序的规则片段，不是可直接覆盖现有文件的完整配置。PROXY 所指策略必须在当前配置中有效。规则从上到下匹配，FINAL 放在末尾作为未命中前面规则时的处理项；将它提前可能使后续规则没有机会生效。域名示例仅用于语法说明，不表示任何实际服务的推荐路径。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

如果请求被 REJECT 命中，先确认是否确为配置预期。域名规则能够拒绝符合条件的请求，但不能理解页面中的所有内容，也不能保证某个资源永久使用相同地址。误拦时应缩小具体规则范围，而不是删除全部规则。关于顺序与能力边界，可进一步阅读REJECT 规则说明，并用日志验证实际命中项。

恢复与缓存验证

改动 DNS 或规则之后，先停止并重新建立连接，再重开测试应用，确认出现的是新请求。应用自身可能缓存地址或复用连接，因此单次刷新结果不足以证明新设置已经参与。不要为了清缓存就先删除应用；优先使用影响范围较小的重连与重开操作。若只在某个局域网失败，还应检查该网络是否有单独的解析要求或内部域名。

验证标准应同时包含解析完成、命中预期规则和目标请求成功。若改动只是把失败从解析阶段转移到了握手阶段，说明问题尚未全部解决，但定位已经前进了一步。保留修改前后的配置差异，撤销没有帮助的尝试，避免长期积累互相覆盖的解析设置。常用关键字含义可在术语表查阅，具体设置入口则见设置说明。

07 · 状态变化后异常

耗电与更新异常：先保留基线，再比较差异

耗电上升与更新后异常都需要一份正常基线。系统电池统计里的占比是相对值，不等于同等使用条件下的实际耗电增量；更新发生在故障之前，也不自动证明更新就是原因。先记录设备使用时长、屏幕状态、网络类型与后台任务，再回看最后正常时的配置、订阅和系统变化。不要同时回滚配置、重建订阅和重设网络，避免丢失判断依据。

分辨正常传输与重复失败

持续上传、视频播放或云端同步都会增加网络活动，流量被 Shadowrocket 接管后，相关活动也可能反映在系统统计中。先在相近使用时长下比较，而不是拿整天的统计与短暂待机直接相减。如果异常主要出现在屏幕关闭期间，检查是否存在不断失败又重试的连接、过于频繁的测试或更新任务，再结合日志判断是否确有重复活动。

临时关闭调试级记录、停止不必要的连续测试，可以帮助排除额外工作负担，但必须先保存与当前故障相关的片段。检查 On Demand 是否在不稳定网络下反复触发重连，并观察设备是否频繁在 Wi-Fi 和蜂窝之间切换。不要为了降低统计占比就永久停止必要功能，应先确认哪一种活动与额外消耗具有稳定关联，再调整对应触发条件。

更新后先查三类变化

第一类是应用或系统更新改变了连接状态，需要重新确认授权或重新建立连接；第二类是订阅内容变化，原来的条目或策略名称已经不存在；第三类是 Config 被更新，规则、DNS 或外部引用与旧文件不同。先确定实际发生了哪种变化，再选择对应章节。若只是某份文件异常，恢复保存过的配置副本，比直接重装更能验证问题是否来自文件差异。

更新前应保存当前 Config、独立服务器条目和必要的分组关系，并确认备份能够读取。订阅链接并不等于完整备份，因为独立条目、手工规则和部分本机设置可能不在其中。更新后先保持原有选择，验证一个常用目标，再恢复自动更新或批量操作。这样发现问题时，变化范围仍然较小，能够逐项比较而不是面对多重覆盖。

重新获取客户端的注意事项

需要重新获取时，iPhone / iPad 在 App Store 核对开发者 Shadow Launch Technology Limited、官方图标与应用 ID 932747118，系统要求以 App Store 页面标注为准。Mac 应先确认 Apple 芯片或 Intel，再选对应包；其他平台通过下载指南使用本站 /dl/ 安装包。重新获取不能保证修复远端连接问题，操作前仍须保留本机数据。

桌面与安卓首次打开可能遇到系统拦截。确认来源后，Mac 可在“隐私与安全性”按系统提示选择“仍要打开”；Windows SmartScreen 可在核对来源后查看“更多信息”，再决定是否“仍要运行”；安卓仅对当前安装所用来源按需允许安装未知应用，完成后可收回权限。Linux 按所选包格式操作，AppImage 需要执行权限。详细边界见安装放行说明，不要忽略来源核对直接放行。

如果重建连接和恢复配置后问题仍在，整理更新前后差异与最小复现步骤。描述应包含故障动作、预期结果、实际结果及出现频率，不包含完整凭据。保留能正常工作的配置副本，逐项重新加入必要设置；一旦某项稳定触发故障，就停止扩大改动范围。这样既能恢复可用基线，也能避免把暂时恢复误认为所有问题已经解决。

08 · 设备与网络场景

iPad 专项：按网络切换、锁屏与局域网检查

iPad 的排查重点不是为它另造一套规则，而是确认与其他设备相比发生了哪些环境变化。同一份订阅在 iPhone 正常、在 iPad 异常，只能说明存在可比较的差异，不能直接证明 iPad 需要不同协议。先确认两台设备使用同一网络、同一条目、同一 Config 和同一 Global Routing 姿态，再比较请求结果，避免把设备差异与配置差异混为一谈。

Wi-Fi、蜂窝与热点切换

只有 Wi-Fi 的 iPad 与具备蜂窝连接的设备，能够进行的对照并不完全相同。使用个人热点测试时，热点本身又是一条不同的接入路径，应将它单独记录。每次切换后先确认系统已经取得可用网络，再重建 Shadowrocket 连接。若网络需要网页认证，应先完成认证；若设备仍显示旧网络名称或连接反复变化，则先解决接入稳定性。

从家庭网络移动到办公网络后，原有长连接可能暂时失效；外观仍显示已连接，也不代表旧连接已经迁移成功。先关闭并重新建立连接，再重复同一目标请求。若重连即恢复，重点记录切换动作和 On Demand 条件；若重连也失败，回到基础网络与服务器可达性检查。不要因为网络切换时出现一次失败，就永久修改所有规则或删除订阅。

锁屏、分屏与应用复用

锁屏后恢复时，应用可能继续使用旧会话，也可能发起新的连接。先观察故障是否仅出现在恢复后的第一批请求，还是所有后续请求都失败。若重开目标应用便恢复，说明应用会话复用值得进一步检查；若所有应用同时失败，再检查系统连接状态。分屏同时运行两个应用时，不能仅凭它们展示相同网页就认定请求路径一致，应分别查看各自依赖的域名。

长时间后台传输是否持续，还取决于目标应用与系统的后台执行条件。Shadowrocket 的连接状态不能代替目标应用获得后台运行机会，因此不要把下载暂停一概归因于规则。测试时先让目标应用保持前台，确认传输正常，再比较锁屏后的变化。设备温度、低电量状态和系统资源压力也应记录，但不宜仅凭相关现象推断某个设置必然有问题。

局域网访问与跨设备配置

连接后无法发现打印机、访问本地管理页面或连接局域网设备时，先停止连接作基础对照，确认目标设备与 iPad 是否确在同一局域网。名称发现与直接访问地址不是同一种请求，发现失败不一定意味着所有本地连接都失败。检查本地网络权限、实际目标地址及命中策略，再针对已有网络结构调整配置，不应直接把所有私有地址段照抄进未知用途的文件。

从其他设备复制配置后，应重新检查策略引用和独立条目是否齐全。相同名称并不能证明内部参数相同，配置文件可用也不能说明本机已完成系统授权。订阅更新可能改变条目名称，旧规则仍引用原名时会出现设备间表现不同。先比较当前生效内容，而不是比较最初导入的文件名；必要时恢复同一份备份再做受控测试。

本章的验证应覆盖三个日常动作：静止使用时请求正常，切换可用网络后能够重新建立连接，锁屏恢复后能够产生新请求。若某一步仍失败，就记录触发点并回到对应章节，而不是继续扩大配置改动。对于仍无法定位的问题，保留已隐藏敏感信息的日志摘要、模式与网络对照；入门操作返回快速上手教程，具体概念查术语表，常见短答查问答。