资讯与使用教程

下载安装、配置导入、节点管理和常见问题说明。

REJECT、REJECT-DROP、REJECT-NO-DROP分别返回什么？

在Shadowrocket的配置规则中，REJECT策略通过发送TCPRST包或ICMP端口不可达消息向请求方明确告知连接被拒绝，应用在毫秒级内获知失败信息，访问被阻页面时浏览器会立即显示连接重置或拒绝提示；REJECT-DROP策略则静默丢弃所有数据包，既不返回RST也不发送任何反馈，应用只能依赖自身的超时机制在数十秒后判定连接失败，行为上完全模拟了网络丢包或服务器宕机的场景，具有较强的隐蔽性；REJECT-NO-DROP与前两者在实现层级上不同，它不涉及网络层的数据包操作，仅在代理管道内标记该流量不转发，将请求交还给系统网络栈自行处理，其最终行为因应用实现和系统配置而异，通常表现为普通连接超时。在配置实际使用的拒绝规则时，广告拦截和域名屏蔽应优先选用REJECT以获得最快的连接终止速度和最清晰的用户反馈，如果发现REJECT导致某些应用出现异常的重试或弹窗行为，可替换为REJECT-DROP以静默处理，两者选择的关键在于应用兼容性和用户体验的权衡。REJECT-NO-DROP则通常不作为常规拒绝策略使用，更多出现在规则调试和流量观察的临时场景中。日常配置无需过于纠结三者的细微差别，在配置文件中统一使用REJECT即可满足绝大部分屏蔽需求，只有在遇到具体兼容性问题时才调整至其他变体。REJECT：主动发送拒绝信号，明确告知连接被拒绝REJECT返回TCPRST包终止连接当配置规则中指定REJECT策略时，Shadowrocket在匹配到该规则后会向请求的客户端（即设备上的应用）发送一个TCPRST（Reset）包，这是一个明确的连接终止信号，告诉应用“该连接被主动拒绝，请立即关闭”。应用收到RST包后，会立即停止等待响应并显示连接失败，整个过程干脆利落。对于UDP流量，REJECT通常返回一个ICMP端口不可达消息或直接丢弃数据包，具体行为取决于底层协议栈的实现，但整体逻辑与TCP类似——明确告知请求方拒绝发生。应用层感知REJECT的速度最快由于REJECT通过发送网络层的重置包而非等待超时来终止连接，应用在收到RST后会在毫秒级内得知连接被拒绝，不会进入长时间的等待状态。浏览器在访问被REJECT的域名时会立即显示“无法访问此网站”或“连接已重置”的提示，不会出现加载转圈或等待超时的现象。这种即时反馈对于用户排查规则是否生效提供了清晰的信号，当用户访问某网站瞬间被拒绝加载，即可判断是该域名被配置了REJECT规则。REJECT适用于明确的拒绝场景该策略最常用于广告拦截和恶意域名屏蔽，当配置规则判定某个域名属于广告追踪或恶意软件分发源时，REJECT会以最快的速度切断连接，节省设备流量并提升页面加载速度，因为浏览器不需要等待超时再渲染页面。对于用户明确不希望访问的域名，REJECT能提供清晰的拒绝反馈。REJECT-DROP：静默丢弃数据包，不返回任何响应REJECT-DROP不发送RST，模拟数据包在网络中丢失与REJECT发送明确的拒绝信号不同，REJECT-DROP策略在匹配规则后会将数据包直接丢弃（Drop），既不发送TCPRST包，也不返回ICMP错误消息，完全模拟数据包在网络传输过程中丢失的场景。应用在发送请求后，既没有收到服务器的回应，也没有收到连接拒绝的指示，只能通过自身的超时机制来判断连接失败，通常需要等待数十秒才会显示超时错误。应用层感知REJECT-DROP表现为连接超时由于没有收到任何响应信号，应用在尝试连接被REJECT-DROP的域名时，会持续等待并重试，最终因超时而显示“请求超时”或“无法连接到服务器”的错误。这种体验与访问一个不存在的IP地址或服务器宕机时的表现完全一致，用户无法区分是网络问题还是规则拒绝造成的。从应用的角度看，连接请求如同石沉大海，没有获得任何状态反馈。REJECT-DROP的隐蔽性优势REJECT-DROP的设计初衷在于隐藏拒绝行为的存在，使客户端无法区分是被防火墙规则拒绝还是目标服务器本身不可达。在某些网络环境中，明确返回RST可能被某些应用视为检测到防火墙而触发异常行为，而静默丢弃则让应用认为只是网络故障，从而避免额外的错误处理逻辑。对于希望低调屏蔽某些域名而不引起应用特殊反应的场景，REJECT-DROP相比REJECT更为合适。REJECT-NO-DROP：不丢弃数据包，但禁止其通过代理REJECT-NO-DROP在代理层面拦截而不涉及网络丢包REJECT-NO-DROP的行为逻辑与前两者存在本质区别，该策略不是通过丢弃网络数据包或返回拒绝信号来阻断连接，而是在Shadowrocket的代理处理管道中直接标记该请求“不允许通过代理转发”，但不对数据包本身做任何丢弃或重置操作。这意味着匹配该规则的流量既不会被发送至代理节点，也不会被应用发送RST，而是被交还给系统的网络栈，由设备自身的网络协议栈自行处理——通常表现为连接尝试失败，但失败的具体原因因应用和系统实现而异。REJECT-NO-DROP的应用层感知介于两者之间由于REJECT-NO-DROP不干预网络层的包收发，应用在尝试连接被该策略拦截的域名时，可能会经历一个标准连接超时周期，但具体等待时间取决于应用的超时设置和系统网络栈的行为。与REJECT-DROP的静默丢弃不同，REJECT-NO-DROP让流量走完了代理管道内的所有处理逻辑但最终被标记为“不转发”，应用的体验更接近“代理配置错误无法连接”而非“网络不通”。REJECT-NO-DROP适用于特定规则调试场景该策略在实际使用中的场景相对较少，主要出现在用户需要测试分流规则是否生效而不希望实际阻断连接的调试过程中。当用户不确定某个域名是否应该走代理，希望临时观察匹配行为而不真正中断连接时，可临时将策略设为REJECT-NO-DROP，通过日志查看匹配情况而不影响实际网络行为。在常规使用配置中，用户更倾向于使用REJECT或REJECT-DROP来获得明确的拒绝效果。三种策略在网络层的本质区别总结REJECT：积极拒绝，发送RST终止连接从网络协议栈的视角看，REJECT是唯一在传输层主动发送拒绝信号的策略，它在TCP层面通过RST包明确告诉请求方“该连接被拒绝”，请求方不需要等待任何超时即可知道连接失败。UDP层面则因协议无连接特性，通常表现为返回ICMP端口不可达消息或直接丢弃，但总体行为是积极响应的。这种策略最符合常规防火墙的拒绝行为，且对应用友好——应用能快速知道结果并执行相应的错误处理。REJECT-DROP：消极拒绝，静默丢弃所有包REJECT-DROP是消极的拒绝策略，它通过不发送任何响应来模拟网络丢包，让应用在超时后才能判断连接失败。这种策略不暴露拒绝意图，增强了规则屏蔽的隐蔽性，但代价是增加了应用的等待时间，可能影响用户体验。从网络安全的角度看，REJECT-DROP比REJECT更难被探测和绕过，因为探测方无法区分是规则拒绝还是目标不可达。REJECT-NO-DROP：代理层拦截，依赖系统栈行为REJECT-NO-DROP与前两者在实现层级上完全不同，它不涉及网络层的数据包操作，仅在应用层的代理管道中进行拦截。匹配该规则的流量被标记为“不由代理处理”后，完全交给系统网络栈按标准流程处理，而系统在没有有效路由或目标不可达的情况下最终会返回连接错误。这种策略的拒绝行为受系统和应用实现的变量影响，不如前两者在网络层面的行为确定。实际配置中的选择建议广告拦截和域名屏蔽优先使用REJECT对于绝大多数需要阻断特定域名访问的场景，如屏蔽广告域名、恶意软件C&C服务器、隐私追踪器等，REJECT是首选策略。它能够以最快的速度切断连接，避免浏览器或应用长时间等待，提升整体页面加载速度，同时清晰的拒绝信号也便于用户通过浏览器错误提示确认规则生效。REJECT的行为最符合用户对“屏蔽”一词的预期——立即拒绝，不拖沓。隐蔽阻断需求下选择REJECT-DROP在某些特定网络环境中，应用可能对收到RST包存在特殊处理逻辑（如反复重试或记录安全事件），此时REJECT-DROP的静默丢弃方式可以避免触发这些异常行为。例如某些社交应用在收到RST时会弹窗提示网络异常，而静默丢弃则让应用正常超时后自动切换到备用连接机制，用户体验更为平滑。如果用户发现REJECT导致某些应用行为异常，可尝试切换至REJECT-DROP观察是否改善。REJECT-NO-DROP通常不作为常规拒绝策略REJECT-NO-DROP在常规分流配置中的使用频率较低，因其拒绝效果不如REJECT明确且缺乏REJECT-DROP的隐蔽优势。该策略更适合用作规则调试工具，而非生产环境中的拒绝策略。用户在配置文件中如非特殊需求，应优先考虑REJECT和REJECT-DROP。常见问题FAQ

EXTENDED-MATCHING扩展匹配是什么？要开启吗？

EXTENDED-MATCHING扩展匹配作为Shadowrocket中一项优化域名规则匹配精度的功能，其核心价值在于通过更智能的域名层级解析减少分流策略中的误匹配和漏匹配，特别适合配置中包含多级子域名、泛匹配规则或社区维护规则集的进阶用户开启使用。用户应在开启前评估自身配置文件的结构复杂度、设备的性能水平以及对分流精度的实际需求，对于规则简单且运行稳定的配置，保持默认关闭状态即可满足使用需求。开启扩展匹配后，通过连接日志对比开启前后的规则命中变化，访问关键服务验证分流准确性是否提升，同时观察配置加载和设备响应速度是否受到可感知的影响，综合判断是否长期保持开启。对于使用社区规则集且规则集维护者明确建议开启扩展匹配的用户，应遵照维护者的建议启用该功能，确保规则集能够完整发挥其设计的分流效果。用户在调整该设置后若遇到分流异常，可暂时关闭扩展匹配并恢复至默认匹配模式，待排查确认非扩展匹配因素后再决定是否重新开启。EXTENDED-MATCHING扩展匹配的功能定义与作用范围扩展匹配是对域名规则匹配逻辑的精细化增强在Shadowrocket的配置体系中，EXTENDED-MATCHING（扩展匹配）是一项用于优化域名规则匹配精度的功能开关。当该功能开启时，应用在处理域名匹配规则时会采用更智能的匹配算法，能够识别域名中的多级结构并正确匹配子域名与父域名的关系，避免出现因匹配逻辑过于简化而导致的误匹配或漏匹配问题。该功能主要作用于配置文件中以DOMAIN-SUFFIX和DOMAIN-KEYWORD开头的规则条目，不影响IP规则和GEOIP规则的执行逻辑。标准匹配与扩展匹配在处理多级域名时的行为差异在标准匹配模式下，DOMAIN-SUFFIX规则对域名的匹配基于固定的后缀字符串，例如DOMAIN-SUFFIX,google.com,PROXY会匹配所有以google.com结尾的域名，包括mail.google.com和drive.google.com，但在处理泛域名或包含复杂子域结构的域名时可能不够精确。开启扩展匹配后，规则引擎会逐级解析域名的每一层，按照更严格的主机名匹配规则执行，例如对于DOMAIN-SUFFIX,.google.com这样的规则，扩展匹配能够更准确地识别出www.google.com和plus.google.com等完整子域名，同时避免将不属于该域名的类似字符串误判为匹配。扩展匹配针对泛匹配规则的优化在处理包含通配符的泛域名规则时，扩展匹配提供了更符合预期的匹配行为。例如规则DOMAIN-SUFFIX,.youtube.com,PROXY，开启扩展匹配后不仅会匹配www.youtube.com，还会精准匹配m.youtube.com、youtu.be等所有YouTube相关域名变体，而不会错误地将包含youtube字符串但与YouTube无关的第三方域名纳入代理范围。这种精细化的匹配机制有助于减少分流策略中的误判，确保只有目标域名的流量被正确路由。开启EXTENDED-MATCHING对配置加载和运行的影响规则匹配精度的提升有助于减少流量误判对于配置中包含大量DOMAIN-SUFFIX和DOMAIN-KEYWORD规则的用户，开启扩展匹配能够显著提升分流决策的准确性。例如，当规则集中同时存在DOMAIN-SUFFIX,com,PROXY和DOMAIN-SUFFIX,google.com,DIRECT时，标准匹配可能因匹配顺序问题导致google.com被误判为走代理，而扩展匹配通过更细致的域名层级解析，能够确保google.com的直连规则优先于泛匹配的.com规则生效，从而避免不必要的代理流量。扩展匹配对配置文件加载速度的影响由于扩展匹配需要逐级解析域名的每一层结构并执行更复杂的匹配算法，开启后配置文件加载和规则匹配的时间会略有增加。对于包含数百条域名规则的典型配置，这种性能差异通常在毫秒级别，用户几乎无法感知。但对于包含数千条规则且设备性能较低的极端场景，开启扩展匹配可能会导致配置切换时出现短暂的加载延迟，用户需在匹配精度和加载速度之间做出权衡。扩展匹配与规则顺序的协同关系开启扩展匹配后，规则的匹配顺序仍然遵循配置文件中的列表顺序，但匹配逻辑的精细化可能会改变某些规则的实际命中结果。用户在开启该功能后应重新检查配置文件中的规则排列顺序，确保精细化匹配后的命中行为与预期一致。特别是对于同时包含精确域名规则和泛匹配规则的配置，开启扩展匹配后可能需要将更具体的规则置于更靠前的位置，以确保其优先被匹配。何时建议开启EXTENDED-MATCHING多级子域名配置复杂的进阶用户建议开启如果用户的配置文件中包含大量针对特定服务或应用的精细化分流规则，例如为Google系、微软系或社交媒体平台分别配置了多层次的域名规则，开启扩展匹配可以确保这些规则能够精确命中每个服务的所有子域名，而不会因为域名层级的复杂性而导致部分流量被误判。这类用户通常追求高度的分流准确性，开启扩展匹配是提升配置可靠性的有效手段。使用社区维护规则集的用户受益于扩展匹配许多社区维护的规则集在设计时就假设客户端开启了扩展匹配，因为规则集中的域名规则往往采用了针对多级域名的匹配写法。用户如果直接使用这类规则集而未开启扩展匹配，可能会导致部分规则无法按预期生效，出现某些子域名未被覆盖的情况。查看规则集文档或维护者的说明，如果其中建议开启扩展匹配，则用户应遵循该建议以充分发挥规则集的完整功能。遇到域名匹配不准确或流量分流混乱时尝试开启当用户发现某些网站的访问行为与配置预期不符，例如国内网站意外走代理或境外网站直连，而规则本身看起来正确时，开启扩展匹配往往能解决这类域名层级解析偏差导致的匹配问题。开启后重新加载配置并测试访问，观察分流行为是否恢复正常，如果问题依旧则可能是其他配置因素导致，此时可关闭扩展匹配排除该变量的干扰。何时建议保持EXTENDED-MATCHING关闭配置文件规则简单且运行稳定的用户无需开启如果用户的配置规则较为简单，例如只有少量域名规则且主要是直接指向策略组，不涉及复杂的多级域名或泛匹配规则，那么标准匹配模式已经足够满足分流需求。开启扩展匹配不会带来显著的精度提升，反而可能因匹配逻辑的变化引入未知的匹配行为偏差，对于长期运行稳定的配置，保持默认的关闭状态是更保守和可靠的选择。设备性能较低或配置规则极为庞大的场景在旧款iPhone或iPad上运行包含数千条域名规则的配置时，扩展匹配增加的额外计算开销可能对性能产生可感知的影响，表现为配置切换时的加载延迟或节点切换时的响应变慢。对于这类设备，为了维持流畅的操作体验，建议关闭扩展匹配并接受标准匹配带来的微小精度折损，或者通过精简规则集来减少匹配引擎的工作负载。使用V2Ray或Clash等跨平台配置语法的兼容考虑部分从其他代理客户端迁移过来的配置文件可能采用了特定的域名匹配语法，这些语法在其原生环境中依赖特定的匹配模式，而在Shadowrocket中开启扩展匹配后可能改变其原有的匹配行为，导致配置行为与预期不一致。用户应在开启扩展匹配后仔细测试关键域名的路由结果，确保迁移后的配置行为与之前平台保持一致，如有偏差则考虑关闭扩展匹配或调整规则写法。开启后的验证与效果评估方法通过连接日志对比开启前后的匹配变化用户可在开启扩展匹配前后分别开启Shadowrocket的连接日志功能，访问同样的目标域名集合，然后对比两次日志中每个域名匹配的规则条目和执行策略是否发生变化。如果日志显示某些域名在开启扩展匹配后匹配了更精确的规则或改变了代理策略，说明该功能确实对配置产生了影响，用户可根据预期评估这些变化是否符合需求。分域名测试验证特定服务的路由准确性对于用户关心的特定服务如YouTube、Netflix或Google，开启扩展匹配后分别访问每个服务的多个子功能页面（如主站、视频播放、账号管理），并观察每个页面的加载速度和IP出口状态。如果开启前某些子页面偶尔出现加载缓慢或地区限制问题，开启后这些异常得到改善，则说明扩展匹配确实提升了该服务域名的覆盖完整性和路由准确性。性能基准测试评估对设备响应速度的影响用户可在开启和关闭扩展匹配两种状态下分别记录配置文件加载时间、节点切换延迟和日常浏览中的页面加载速度，通过主观感受或使用计时工具对比两种模式下的性能差异。如果在旧款设备上明显感觉开启后操作响应变慢，则关闭该功能恢复速度；如果在主流设备上感觉不出区别，则保留开启状态享受更精准的匹配效果。常见问题FAQ

Shadowrocket预览规则集能看到哪些域名走代理吗？

Shadowrocket的规则集预览功能能够让用户直接查看已添加规则集中包含的具体规则条目，但需要注意预览展示的是规则文件原始内容而非经过整理归纳的纯净域名列表，用户需自行在文本中搜索PROXY或自定义策略组名称来识别哪些域名被配置为走代理。若需要查看当前配置中所有代理域名的汇总视图，可在配置编辑界面选择“导出”或“查看源码”生成完整配置文件，然后在全文搜索PROXY关键词并逐一查看匹配的域名规则条目。对于实时验证特定域名是否走代理的需求，开启Shadowrocket的连接日志功能后访问该域名，日志会显示该请求匹配的具体规则和执行的代理策略，是确认规则生效与否的最精准手段。综合运用预览、源码查看和日志分析三种方法，用户即可全面掌握当前配置中哪些域名走代理、哪些直连，并据此判断规则集是否完整覆盖了自己的常用网站，是否需要对规则集进行补充或调整顺序。规则集预览功能并非直接显示域名列表Shadowrocket内置了规则集内容查看入口在Shadowrocket中，用户可以通过“配置”标签页进入当前激活的配置文件编辑界面，在“规则集”列表中找到已添加的规则集条目，点击进入详情页后，部分版本的Shadowrocket会提供“预览”或“查看规则”的选项。点击该选项后，应用会尝试从本地缓存或远程链接加载规则集内容，并以文本形式展示该文件中的所有规则条目。这些条目通常包含域名规则（如DOMAIN-SUFFIX,youtube.com,PROXY）、IP段规则（如IP-CIDR,192.168.0.0/16,DIRECT）以及GEOIP规则（如GEOIP,CN,DIRECT），用户通过浏览这些规则便可了解该规则集具体涵盖哪些域名以及分配给它们的代理策略。预览内容取决于规则集文件的实际格式规则集文件可能采用不同的组织方式，有些以域名列表形式按行排列，每条域名单独占用一行并附带策略标识；有些则采用更紧凑的格式，将同类域名归入同一组。预览功能展示的是该文件的原始内容，用户看到的是完整的规则条目而非经过应用处理后的抽象列表，因此能够直接识别其中包含的具体域名和通配符模式。如果规则集文件中同时混杂了域名规则和IP规则，预览页面也会如实展示所有类型，方便用户全面了解该规则集的分流范围。预览仅显示已缓存的本地版本而非实时拉取当用户点击预览时，Shadowrocket展示的是该规则集最近一次成功更新后缓存在本地的内容，而非向远程服务器发起实时请求拉取最新版本。这意味着预览看到的规则可能与当前线上最新版本存在差异，如果用户长时间未更新规则集，预览内容可能已经过时。用户在预览之前应先在“配置”标签页执行下拉刷新强制更新所有远程规则集，待更新完成后再进入预览页面查看，以确保展示的是最新规则内容。通过查看完整配置源码间接预览所有代理域名导出完整配置文件查看全部规则的汇总视图当用户希望一次性查看当前配置中所有被标记为代理的域名时，可在“配置”标签页中点击当前配置名称进入编辑界面，然后将页面滚动至最底部，选择“导出”或“查看源码”选项。应用会生成一份包含完整规则列表的文本内容，其中不仅包含所有引用规则集展开后的具体条目，还包括用户手动添加的内联规则。用户可在该文本中搜索PROXY或自定义策略组名称，快速定位所有被标记为代理的域名规则，从而了解哪些域名经过代理节点转发。搜索“PROXY”关键词快速筛选代理域名在导出或预览的完整配置文本中，用户可使用iOS的页面内搜索功能，输入“PROXY”或当前配置中使用的具体策略组名称（如“Streaming”），系统会高亮显示所有匹配该策略的规则条目。通过逐一浏览搜索结果，用户可以系统性地了解哪些域名已被配置为走代理通道，哪些被配置为直连或拒绝。这一方法尤其适用于规则数量庞大、无法逐条手动阅读的场景，通过关键词搜索大大提升了筛选效率。复制配置全文至文本编辑器实现多条件筛选对于配置内容极为复杂的场景，用户可将导出的完整配置文本复制至支持高级搜索和过滤的第三方文本编辑器，利用编辑器的查找、排序和筛选功能进一步分析代理域名的分布情况。例如用户可在编辑器中筛选所有包含“PROXY”的行，并同时排除包含“DIRECT”的行，获得纯净的代理域名列表。这种离线分析方式不受Shadowrocket界面限制，适合需要系统化审查配置规则的进阶用户。利用连接日志功能实时查看实际走代理的域名开启日志记录后访问网站查看实时匹配结果Shadowrocket提供了网络连接日志功能，用户进入“设置”页面找到“日志”选项并开启记录，然后打开Safari或任何应用访问目标网站。日志页面会实时显示每个网络请求的连接记录，包括请求的域名、目标IP地址、匹配的规则类型以及最终执行的代理策略。用户在该日志中搜索“PROXY”或自定义策略组名称，即可准确获知实际访问过程中哪些域名被判定为走代理，哪些被直连，该方式反映的是真实网络请求的处理结果，比静态预览更能反映配置的实际生效情况。日志中的规则命中记录可验证规则集的覆盖范围当用户访问一个网站时，日志会明确显示该域名匹配了规则集中的哪一条规则，并标注该规则所在的规则集来源（如“规则集A”或“内联规则”）。通过逐条查看这些记录，用户可以评估当前引用的规则集是否完整覆盖了自己的常用网站，是否存在遗漏导致部分流量意外直连或走了错误的策略。日志提供的匹配细节是验证规则集有效性的最精准手段，尤其适合在添加或更新规则集后执行验证测试。日志仅记录当前代理会话期间的活动日志功能展示的是从开启日志记录时刻起至停止记录为止所有经过Shadowrocket处理的网络请求记录，关闭代理或退出应用后日志将不再累积新记录。用户应在准备测试时先清空旧日志再开始记录，确保日志内容只反映本次测试期间的活动，避免被历史记录干扰判断。测试完成后可导出日志文件至其他应用进行存档或进一步分析。通过IP出口验证判断特定域名是否走代理访问IP检测网站对比出口IP判断分流结果用户可先确认当前代理节点处于连接状态，然后使用Safari访问http://ipinfo.io查看当前出口IP地址。随后打开一个新的标签页访问一个国内网站，如http://baidu.com，观察该页面加载后再次访问IP检测网站，如果出口IP变为本地网络IP则说明国内域名已正确直连。再访问境外目标域名，如YouTube或Netflix，查看其对应的出口IP是否恢复为代理节点IP，从而判断该域名是否走代理。这种对比验证虽然不能逐一列出域名，但能确认特定域名是否按照预期分流。分域名测试可逐条验证关键网站的代理状态如果用户需要验证多个具体域名的代理状态，可分别在浏览器中访问每个域名，每次访问后立即刷新IP检测网站查看出口IP变化。若访问后出口IP为代理节点IP，则该域名目前走代理；若仍为本地IP，则说明该域名被直连处理。这种方法适合验证少量关键域名，例如YouTube、Google、Twitter等，通过逐一手动测试得到每个域名的实际路由状态，与配置预期进行对比可发现是否有遗漏或错误配置。测试时需注意浏览器缓存和DNS预取的影响浏览器在加载页面时可能会提前解析域名或使用已缓存的DNS记录，导致某些请求在Shadowrocket规则生效前就已经发出，使测试结果与实际路由配置不符。用户在分域名测试时可先清空浏览器缓存或使用隐私模式打开新窗口，并等待数秒确保所有网络请求都经过代理管道处理后再查看IP检测结果。也可使用终端工具或第三方网络诊断应用发送特定的DNS查询和HTTP请求，获得更纯净的测试环境。预览规则集时的显示范围与格式限制远程规则集在未更新时预览内容可能为空对于新添加但尚未执行过拉取操作的远程规则集，用户点击预览时可能看到“内容为空”或“未下载”的提示，因为应用尚未从远程服务器下载该规则集的内容。用户需先在“配置”标签页执行下拉刷新强制拉取所有远程规则集，拉取成功后再进入预览页面即可看到规则内容。如果拉取过程中因网络问题失败，预览仍会保持为空状态，用户需排查网络后再重试更新。预览模式下展示的是原始规则文件而非解析后的归纳预览功能直接展示规则集文件的原始文本内容，而非经过Shadowrocket解析后生成的归纳性统计。这意味着用户看到的是类似DOMAIN-SUFFIX,facebook.com,PROXY这样的完整规则条目，而非一个简洁的“代理域名列表”。如果用户希望获得简洁的域名列表，需要在文本中手动筛选出以DOMAIN-SUFFIX或DOMAIN-KEYWORD开头且策略为PROXY的行，然后复制域名部分生成自己的摘要清单。部分规则集使用正则表达式或通配符增加阅读难度某些高级规则集为了覆盖更多子域名或简化规则条目数量，会使用通配符或正则表达式定义域名匹配规则，例如DOMAIN-SUFFIX,.google.com,PROXY或DOMAIN-KEYWORD,facebook,PROXY。这类规则在预览时不会展开为具体的域名列表，用户看到的将是泛匹配表达式而非完整的域名枚举。如果需要确知这些泛匹配实际覆盖的具体域名，用户需结合自身访问日志或域名知识库进行补充判断。常见问题FAQ

Shadowrocket RULE-SET规则集怎么添加和更新？

在Shadowrocket中添加和更新RULE-SET规则集时，用户首先进入“配置”标签页并点击当前激活的配置文件进入编辑界面，在页面中找到“规则集”设置区域，点击添加按钮选择“URL”类型并粘贴第三方规则集的远程链接，同时在下拉菜单中为该规则集指定统一的代理策略，保存后该引用即加入当前配置。如果需要使用本地存储的规则集文件，则选择“本地文件”类型并从Shadowrocket的应用目录中选取已存入的规则文件完成添加。配置保存后，用户需在“配置”标签页向下拉执行手动刷新，应用会立即拉取所有远程规则集的最新内容并更新本地缓存，更新完成后建议切换至其他配置再切回当前配置，或关闭再开启代理开关，强制应用重新加载配置文件并应用最新规则。为了保持规则集的长期时效性，用户可在Shadowrocket的设置中开启“自动更新规则集”并设定合适的检查间隔，同时开启“仅在Wi-Fi下更新”以避免消耗蜂窝数据流量。当规则集更新失败时，优先在浏览器中测试链接的可访问性，确认是否需要开启代理后再刷新，若链接已失效则需寻找维护者发布的新地址替换原有引用。全部规则集添加并验证通过后，用户即可享受模块化分流规则带来的便捷维护体验，而无需频繁修改主配置文件。理解RULE-SET在配置中的定位与作用RULE-SET是实现分流规则模块化管理的核心组件在Shadowrocket的配置体系中，RULE-SET代表着一组预先编写好的分流规则集合，它允许用户将庞大的规则库从主配置文件中抽离出来，以独立文件或远程链接的形式被引用。这种模块化设计使得用户无需打开配置文件逐行编辑，只需添加一条对规则集的引用指令，即可将外部成百上千条域名或IP规则一次性纳入当前配置的决策流程。RULE-SET的引入极大简化了配置文件的维护工作，尤其适合那些依赖社区维护规则集的用户，通过引用他人持续更新的规则库来保持分流策略的时效性。内联规则与外部规则集在加载逻辑上的本质区别内联规则是直接书写在配置文件中规则列表区域的具体条目，它们随着配置文件的保存而固定下来，修改时需手动编辑配置文件内容。而RULE-SET作为外部引用，在主配置文件加载时由应用动态拉取或读取本地文件内容，将其中的规则展开并插入到引用位置参与匹配。这种动态加载机制使得RULE-SET的内容可以独立于主配置文件更新，当规则集维护者修复了错误或新增了域名分类时，用户仅需刷新规则集即可获得最新规则，无需重新编辑或导入整个配置文件。主流RULE-SET格式与Shadowrocket的兼容范围Shadowrocket支持多种格式的规则集文件，最常见的是基于Clash或Surge格式的规则列表，通常以.list、.conf或.txt作为文件扩展名。这些文件中每行包含一条规则，常见格式包括DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR和GEOIP等类型，与Shadowrocket原生规则的语法保持一致。用户在添加RULE-SET时应确认链接指向的文件格式与Shadowrocket兼容，部分为Clash专属语法编写的规则集可能需要转换后才能正常加载。通过远程URL添加RULE-SET的具体操作步骤在配置编辑界面中找到规则集引用入口用户打开Shadowrocket后进入底部导航栏的“配置”标签页，点击当前激活的配置文件名称进入编辑界面，在配置编辑页面中向下滑动找到“规则集”或“RuleSet”设置区块。该区域专门用于管理外部规则集的引用列表，用户点击右上角的加号或“添加规则集”按钮，即可开始配置一个新的规则集引用条目。对于未显示该选项的配置文件版本，用户可检查配置格式是否为Shadowrocket标准格式，确保配置文件支持外部规则集引用功能。填写远程规则集的URL并指定引用策略在添加规则集的弹出窗口中，用户首先将“类型”选择为“URL”，然后在地址栏中粘贴第三方维护的RULE-SET远程链接，该链接通常以.list或.conf结尾并托管于GitHub、GitLab或个人服务器。随后在“策略”下拉菜单中选择当该规则集内的规则匹配时执行的代理策略，常见选项包括PROXY（走代理）、DIRECT（直连）或REJECT（拒绝连接）。如果规则集文件内嵌了策略信息，用户也可选择“无”让规则集文件自行决定。填写完成后点击保存，该规则集即被添加到当前配置的引用列表。保存配置后规则集即被引用但尚未拉取内容完成规则集条目的添加并保存配置文件后，Shadowrocket只是记录了该规则集的引用地址和策略，并未立即从远程服务器下载规则内容。当用户切换至该配置并开启代理时，应用会在加载配置的过程中根据引用链接拉取规则集内容并将其展开至内存中的规则列表。如果拉取失败，该规则集将被跳过且不会影响其他规则的正常加载，用户可在后续通过手动更新来重试拉取操作。通过本地文件添加RULE-SET的方法将规则集文件存入Shadowrocket的应用目录对于不依赖远程服务器或希望离线使用规则集的用户，可以将事先下载好的规则集文件通过iOS的“文件”应用存储至Shadowrocket的本地目录。用户打开“文件”应用，在“我的iPhone”或“iCloud云盘”中找到Shadowrocket文件夹，将规则集文件（如ruleset.list）复制或拖拽至该目录下。如果该文件夹不存在，首次运行Shadowrocket时会自动创建，用户也可通过应用内的导出功能触发文件夹生成。在配置中引用本地存储的规则集文件完成文件存放后，用户回到Shadowrocket的配置编辑界面，在“规则集”设置区块点击添加规则集，将“类型”选择为“本地文件”，随后应用会弹出文件选择器，引导用户从Shadowrocket目录中选择已有的规则集文件。选中文件后同样需要指定策略或选择“无”让文件内联规则自行决定。保存配置文件后，应用在加载配置时会直接从本地读取该文件内容，无需依赖网络连接，加载速度更快且不受外部服务器可用性影响。本地规则集文件修改后需手动触发重新加载与远程规则集不同，本地文件修改后Shadowrocket不会自动检测变更并更新内存中的规则内容。用户修改了本地规则集文件后，需要返回配置列表重新选择一次当前配置文件，或执行一次配置切换再切回，强制应用重新读取本地文件并加载最新内容。频繁修改本地文件时，用户也可直接重启Shadowrocket应用来触发所有配置的重新加载，确保新规则生效。手动触发RULE-SET更新的具体操作在配置列表页面执行下拉刷新全局更新当用户需要更新当前配置文件中所有远程RULE-SET规则集时，最快捷的方式是进入Shadowrocket的“配置”标签页，在列表区域向下滑动执行下拉刷新操作。应用会遍历当前激活配置文件中引用的所有远程规则集链接，逐一发起网络请求拉取最新的规则内容，并将更新后的内容替换内存中的旧版本规则。下拉刷新完成后，页面顶部会短暂显示更新成功或失败的提示，用户可根据提示判断是否需要进一步处理失败的规则集条目。针对特定规则集条目单独触发刷新如果用户仅希望更新某一个特定规则集而非全部，可在配置编辑界面的规则集列表中找到该条目，左滑或长按后选择“更新”或“刷新”选项。应用仅针对该单个链接发起拉取请求，更新完成后该规则集的本地缓存内容即被覆盖。单独更新在某个规则集更新失败而其他规则集正常时尤为实用，用户无需因单个链接异常而刷新全部规则集，节省网络请求资源。更新后需确认配置已被重新加载手动更新规则集成功只是将最新内容下载到了本地缓存中，但应用当前正在运行的内存规则列表仍基于旧版本规则执行。用户需要执行一次配置切换操作，例如先切换至其他配置再切换回来，或关闭代理开关再重新开启，强制应用重新加载配置文件并读取更新后的规则集缓存内容。这一步骤确保了新规则立即生效，否则最新下载的规则内容要等到下次应用启动或配置自动重载时才会被使用。配置自动更新机制与更新频率管理开启后台自动更新减轻手动维护负担Shadowrocket的设置页面提供了“自动更新规则集”的全局开关，用户开启后，应用会在后台按照预设的时间间隔自动检查所有远程RULE-SET链接的内容是否发生变更，如有变更则自动下载最新版本并更新本地缓存。这一机制免去了用户每天手动下拉刷新的操作，尤其适合依赖多个第三方规则集且规则发布者更新频繁的使用场景。用户只需在首次配置时完成规则集引用，后续的规则同步工作由应用在后台静默完成。自定义更新检查间隔以平衡时效与资源消耗在自动更新开关下方，用户可以进一步调整更新检查的间隔选项，常见的可选值包括每小时、每6小时、每12小时和每天。对于节点或规则变更极频繁的服务商，选择较短间隔能更快获取最新分流策略，但会增加设备的网络请求次数和电量消耗。对于规则集内容相对稳定的场景，每天一次的检查频率足以覆盖绝大多数规则更新需求，同时将后台活动对设备资源的占用降至最低。用户应根据规则集维护者的实际更新频率来设定合理的间隔时间。Wi-Fi与蜂窝数据下的更新策略差异配置Shadowrocket允许用户针对不同的网络环境设置差异化的自动更新策略，用户可在设置中开启“仅在Wi-Fi下更新规则集”选项，避免在蜂窝数据网络下消耗套餐流量。对于文件体积较大的规则集，单个规则集文件可能达到数百KB，在流量有限的套餐下频繁在蜂窝网络更新可能导致额外费用。开启该选项后，应用仅在设备连接Wi-Fi时执行后台自动更新，蜂窝网络下仅支持手动触发更新，有效控制移动数据流量的使用。RULE-SET更新失败或加载异常的常见排查方法网络环境限制导致远程链接无法访问当规则集更新失败时，最常见的原因是当前网络环境无法访问远程链接所在的服务器，尤其当规则集托管于GitHub或境外服务器时，直连网络可能因访问限制而无法拉取内容。用户应先尝试在Safari浏览器中直接打开该规则集链接，观察能否正常显示规则文本内容。若浏览器无法访问，说明需要开启代理后再进行更新操作，用户可先切换至可用的代理节点并确保代理开关开启，然后再次执行规则集刷新，通常即可正常拉取远程内容。链接地址变更或规则集文件被维护者移除第三方规则集的维护者可能因项目迁移、仓库整理或服务停用而变更链接地址或直接移除文件，导致原有的引用链接失效。用户应返回获取该规则集的原始发布页面，查看是否有新的链接地址或迁移公告，将配置中的规则集URL更新为最新地址后再尝试刷新。若规则集已停止维护且无替代链接，用户应考虑寻找同类规则集替换或将该规则集条目从配置中移除，避免每次加载配置时因无效链接而延长加载时间。规则集格式与Shadowrocket解析器不兼容部分从Clash或Surge社区获取的规则集文件可能包含Shadowrocket无法识别的语法结构，例如某些自定义的策略组声明或非标准注释格式，导致应用在加载解析时抛出格式错误。用户可打开规则集文件检查是否每行均为合法的DOMAIN-SUFFIX、IP-CIDR或GEOIP规则，并确保文件中没有混入YAML格式的前置声明。若格式问题较为复杂，用户可尝试使用在线转换工具将规则集转换为Shadowrocket兼容格式后重新保存，或将规则集中的规则条目逐一复制到主配置文件的规则列表中逐步排查问题条目。常见问题FAQ

Shadowrocket怎么把YouTube的流量指定走代理？

在Shadowrocket中指定YouTube流量走代理，最直接的方法是在“按需求连接”设置中为YouTubeApp单独添加代理规则，该方式无需编写配置文件且操作简便，适合希望快速为YouTubeApp加速的用户。对于需要更精细控制域名分流和策略组选择的高级用户，建议在当前激活的配置文件中手动添加DOMAIN-SUFFIX规则，将youtube.com、googlevideo.com、ytimg.com、youtubei.googleapis.com等YouTube相关域名的流量指向PROXY策略或自定义的流媒体策略组，并确保这些代理规则位于国内直连规则之前以保证优先匹配。将YouTube流量指向专门配置的流媒体策略组，在组中放置多个不同地区的节点并设置自动选择或故障转移策略，可实现节点间的平滑切换，确保视频播放的持续流畅。完成配置后，通过访问IP检测网站和查看Shadowrocket连接日志双重验证YouTube流量是否确实经过代理节点，同时开启UDP转发功能以优化基于QUIC协议的YouTube视频流传输。配置过程中需特别注意添加googlevideo.com域名规则，因为该域名承担实际的视频数据传输，缺失该规则会导致首页加载正常但视频无法播放。如果配置后YouTube出现播放错误或缓冲缓慢，应首先尝试切换策略组中的节点至带宽更大或地理更优的节点，再检查节点IP是否被YouTube限制，必要时调整配置中的规则顺序或更新代理节点。最终，通过分流规则将YouTube精准导向代理通道的同时保持国内网站直连，即可在提升视频播放体验的同时不影响国内日常访问速度。通过“按需求连接”功能为YouTubeApp单独设置代理开启按需求连接并添加YouTube的应用规则Shadowrocket的“按需求连接”功能允许用户为特定应用单独指定代理策略，而无需编写复杂的配置文件。用户进入Shadowrocket的“设置”页面，找到“按需求连接”选项并开启，然后点击“添加规则”，在应用选择列表中找到YouTube应用。添加完成后，用户可为该应用选择“代理”策略，此后所有从YouTubeApp发出的网络请求都将自动通过当前选中的代理节点转发，而其他应用则沿用配置文件的全局规则。这一方法操作简单，适用于只想为YouTubeApp加速而不希望影响其他应用流量的场景。按需求连接的规则优先级高于配置文件的分流规则当用户在“按需求连接”中为YouTube设置了代理策略后，该规则会在系统层面优先于配置文件中定义的所有分流规则执行。这意味着即使配置文件中包含了对YouTube域名的直连指令，按需求连接的设置仍会强制YouTube流量走代理通道，实现应用级别的精准管控。这种设计允许用户在不动摇整体分流框架的前提下，针对特定应用临时调整代理策略，尤其适合视频流媒体场景。该功能需保持代理开关持续开启才能生效按需求连接的规则依赖于Shadowrocket的系统级网络拦截通道，因此用户必须确保应用顶部的“代理”开关处于开启状态，按需求连接中为YouTube设定的代理策略才会实际执行。如果代理开关关闭，所有按需求连接的规则均不生效，设备所有网络请求直连发出。用户在完成按需求连接设置后应检查代理开关状态并确认已打开。在配置文件中添加YouTube域名的强制代理规则将YouTube相关域名写入配置规则的代理策略组手动编辑配置文件是高级用户实现精准域名分流的最灵活方式，进入Shadowrocket的“配置”标签页，选择当前激活的配置文件并点击编辑。在规则列表区域添加新的规则条目，将目标域名或域名后缀设置为“代理”策略。例如添加DOMAIN-SUFFIX,youtube.com,PROXY、DOMAIN-KEYWORD,googlevideo,PROXY以及DOMAIN-SUFFIX,ytimg.com,PROXY等规则，这些规则会将YouTube主站、视频流传输和缩略图图床的流量全部导向代理节点，确保视频加载和播放不走直连。规则放置顺序需在泛直连规则之前确保优先匹配Shadowrocket的规则引擎按列表顺序逐条匹配，用户添加的YouTube代理规则必须放置在配置文件中的国内直连规则（如GEOIP,CN,DIRECT）和泛直连规则之前，否则YouTube流量可能先匹配到直连规则而被发送至本地网络，导致规则失效。最理想的位置是规则列表的顶部附近，跟随在其他特定服务代理规则之后，确保YouTube相关域名在被其他规则命中前就被标记为代理。添加youtubei.googleapis.com等API域名以覆盖所有子服务除了主域名和视频流域名外，YouTube的API服务、用户认证和推荐算法等后台功能还依赖youtubei.googleapis.com、googlevideo.com等相关域名。为确保完整的YouTube体验，用户应一并添加DOMAIN-SUFFIX,googleapis.com,PROXY（但此规则会影响所有GoogleAPI，需谨慎）或专门添加DOMAIN,youtubei.googleapis.com,PROXY。最稳妥的方式是添加DOMAIN-KEYWORD,google,PROXY将涉及Google的全部域名走代理，但此方法会过度代理其他Google服务，适合对代理流量不敏感的用户。通过策略组将YouTube流量指向特定优化节点在配置文件中创建专门的流媒体策略组高级用户可在配置文件中创建一个名为“Streaming”或“YouTube”的策略组，并在该组中列出多个经过流媒体优化的代理节点，同时设置选择策略如“延迟最低”或“自动选择”。随后将YouTube相关域名的规则指向该策略组而非直接使用PROXY关键字，例如DOMAIN-SUFFIX,youtube.com,Streaming。这样YouTube流量不仅会走代理，还会自动使用策略组中当前表现最佳的节点，为视频播放提供更稳定的速度和更低的缓冲率。策略组中的故障转移机制保证播放连续性当策略组配置为“故障转移”模式时，如果当前使用的代理节点出现连接问题或速度下降，Shadowrocket会自动将YouTube流量切换至策略组中的下一个可用节点，从而避免视频播放中断。用户可将多个不同地区的节点加入同一策略组，当主节点在晚间高峰拥塞时，备用节点能够及时接管，确保YouTube播放流畅。这一机制比固定单节点更具弹性，适合长期观看YouTube视频的用户。策略组与手动节点选择的协同关系配置了策略组后，用户在Shadowrocket主界面手动选择的节点仅作为默认或策略组后备，YouTube的实际路由由策略组内部的选择逻辑决定。用户可在策略组中定期调整节点的优先级顺序，将当前速度最快的节点置于策略组列表的顶部，以优化YouTube视频加载体验，而无需修改配置文件中的规则。利用“代理”模式强制YouTube走代理但保留其他国内直连的混合方案全局路由设为“代理”会导致所有流量走代理当用户将Shadowrocket的全局路由切换至“代理”模式时，所有设备的网络请求均会经过代理节点转发，YouTube流量自然也包含其中，实现100%代理覆盖。但这种简单粗暴的方式会导致国内网站如百度、淘宝也走代理通道，访问速度显著下降，且消耗代理节点的流量配额，并非针对YouTube优化的理想方案。在“配置”模式下通过规则分流实现精准代理与全局代理不同，将全局路由设为“配置”模式并加载一份包含YouTube代理规则但不包含国内网站代理规则的配置文件，可以做到YouTube流量精准走代理，而国内网站保持直连。这种分流方案在不影响国内网站访问速度的前提下实现了YouTube的代理加速，是最推荐的长期使用方案。用户只需在配置文件中添加YouTube的代理规则，确保其优先级高于国内直连规则即可。切换至“配置”模式后规则立即生效，无需重启应用用户在完成配置文件的修改和保存后，即使代理开关处于开启状态，新的规则也会在数秒内自动加载并应用于后续的YouTube连接请求，无需关闭代理或重新启动应用。用户在修改规则后打开YouTube应用刷新视频列表，即可验证新规则是否生效，流量是否成功经由代理节点转发。检测YouTube流量是否确实走代理的验证方法访问IP检测网站查看当前出口IP地址在开启Shadowrocket并加载包含YouTube代理规则的配置后，用户可使用Safari访问http://ipinfo.io查看当前设备的出口IP地址，然后打开YouTube应用或网页版播放一个视频，同时再次访问IP检测网站，确认显示的IP地址与代理节点的出口IP一致。如果YouTube视频加载快且出口IP始终为代理节点IP，则说明YouTube流量已成功走代理。这种方法最为直观，且能同时验证规则的生效性和代理节点的连通性。使用Shadowrocket的连接日志确认规则匹配开启Shadowrocket的日志功能后，用户打开YouTube并播放视频，在日志中搜索“youtube”或“googlevideo”等关键词，查看每个请求所匹配的规则名称。如果日志显示匹配了PROXY策略或自定义策略组名称，则说明YouTube流量已被正确导向代理通道；如果匹配了DIRECT，则说明规则未生效或优先级不足，需调整配置。日志提供的详细匹配记录是排查规则问题的精准依据。通过YouTube视频的缓冲速度和分辨率判断正常走代理的YouTube视频在播放时，如果代理节点带宽充足且链路稳定，视频会快速加载至较高分辨率，缓冲进度条会明显超前于当前播放位置。如果用户观察到底部缓冲条增长缓慢或视频长时间停留在低分辨率且反复缓冲，即使IP检测显示走代理，也说明该代理节点本身性能不佳，应尝试切换至策略组中的其他节点或更换带宽更大的节点。流量指定后可能遇到的常见问题与应对策略YouTube提示“视频播放错误”或“出现异常”的处理当YouTube走代理后出现播放错误，通常是因为代理节点IP被YouTube识别为异常流量或节点位于YouTube限制的地区。用户可尝试在策略组中切换至其他节点，特别是位于支持YouTube区域的国家或地区的节点。如果节点切换后问题依然存在，可暂时将全局路由切换至“代理”模式进行测试，以排除配置文件规则错误的可能性。若全局代理依然报错，则说明该节点本身已被YouTube限制，需更换节点。配置规则后YouTube首页能打开但视频无法播放YouTube首页加载成功但视频无法播放，表明域名youtube.com的代理规则已生效，但视频流域名googlevideo.com或相关CDN域名未包含在代理规则中。用户应返回配置文件，添加包含DOMAIN-SUFFIX,googlevideo.com,PROXY或DOMAIN-KEYWORD,googlevideo,PROXY的规则，确保视频数据传输也经过代理通道，保存并重新加载配置后播放功能即可恢复。规则添加后国内网站访问速度下降的排查方法如果在添加YouTube代理规则后国内网站加载变慢，可能是由于配置中误将包含google关键字的泛匹配规则放置在了国内直连规则之前，导致部分国内网站的请求也被误判为代理流量。用户应检查配置中是否存在DOMAIN-KEYWORD,google,PROXY这类泛匹配规则，并确认YouTube相关规则之后仍有完整的GEOIP,CN,DIRECT规则匹配国内流量。必要时可将全局路由临时切换至“直连”模式验证国内网站恢复速度，以此确认问题范围。常见问题FAQ

Shadowrocket怎么导入第三方分流规则链接？

在Shadowrocket中导入第三方分流规则链接时，最常用的操作路径是进入底部导航栏的“配置”标签页，点击右上角的加号，选择“从URL下载”并将复制的第三方配置链接粘贴至输入框中，确认后应用自动从远程服务器拉取配置文件并保存至本地配置列表，用户随后在列表中点击新导入的配置名称即可切换启用。用户也可复制配置链接后直接切换至Shadowrocket应用，利用剪贴板自动识别功能触发导入流程，应用会在检测到有效链接后弹出导入提示框。扫描二维码同样能快速导入配置，适合链接以图像形式展示的场景。导入完成后务必在配置列表中确认新配置已被选中启用，并通过访问IP检测网站验证国内网站是否直连、境外网站是否经由代理节点转发，以确认分流规则已按预期生效。如果配置列表长时间未更新或导入失败，可先将配置链接在浏览器中打开验证可用性，确认链接有效后再重试导入操作，同时留意配置格式是否兼容Shadowrocket，避免因格式不匹配导致解析失败。通过配置URL直接导入是最常用的一键式方法复制第三方规则的配置链接并在Shadowrocket中完成导入当用户在GitHub、技术博客或社区论坛中找到第三方维护的分流规则配置时，通常可以获得一个以.conf、.list或远程URL结尾的配置链接。用户需要完整复制该链接，然后打开Shadowrocket，进入底部导航栏的“配置”标签页，点击右上角的加号按钮，在弹出的菜单中选择“从URL下载”。应用会显示一个URL输入框，用户将复制的链接粘贴至该框中，点击“下载”按钮后，Shadowrocket会自动从远程服务器获取该配置文件并添加至本地的配置列表中。下载完成后，新配置会出现在配置列表的末尾，用户点击该配置即可切换启用。导入后需手动切换至新配置才能生效从URL下载配置文件只是将其保存至应用本地，并不会自动替代当前正在使用的配置。用户需要在配置列表中点击刚刚下载的配置名称，应用会立即加载该配置中的规则集合、策略组和节点引用，并在主界面显示当前配置已切换为新导入的规则。切换过程中，如果代理开关处于开启状态，新的分流规则会立即应用于后续的网络请求，无需重启应用或关闭代理。此时访问国内外网站即可验证新配置的分流效果是否满足需求。部分配置链接可能需要使用浏览器的分享功能导入在iOS设备上浏览网页时，如果用户直接在浏览器中点击了第三方规则配置的下载链接，Safari可能会尝试打开配置文件内容而非触发Shadowrocket的导入流程。此时用户可使用浏览器的分享按钮，将当前页面链接分享至Shadowrocket，应用会自动识别链接中的配置内容并弹出导入确认框。这一方式适用于配置托管在支持直接访问的静态文件服务上的场景，操作路径比手动复制粘贴更快捷，且避免了将长链接在应用间切换时可能出现的复制不全问题。通过剪贴板自动识别方式导入配置链接复制链接后打开Shadowrocket触发自动检测与节点URL的一键导入机制类似，Shadowrocket也支持对配置链接的剪贴板自动识别。用户在浏览器或文本应用中完整复制第三方配置的URL后，直接切换至Shadowrocket应用（无需进入任何特定页面），应用会在启动或从后台切换至前台时检测剪贴板内容，如果识别出有效的配置链接格式，会自动弹出提示询问用户是否导入该配置。用户点击确认后，应用会直接拉取远程配置内容并保存至本地，整个过程无需手动进入配置标签页寻找导入选项，进一步简化了操作流程。自动识别对链接格式有一定要求剪贴板自动识别功能对URL格式的识别存在一定条件，配置链接需以.conf、.json或.txt等常见配置文件扩展名结尾，或包含明确的config、rule等关键词，应用才会判定为有效的配置链接。如果第三方提供的链接是短网址或包含跟踪参数的长链接，自动识别可能失效，此时用户应改用手动URL导入方式。自动识别触发后如果用户未在提示框弹出时确认，该链接不会被保存，需要重新复制并再次打开应用。识别失败时可借助共享菜单中转导入如果自动识别未能触发，用户可在复制链接后打开Shadowrocket的“配置”标签页，点击右上角的加号，选择“从剪贴板导入”选项，应用会直接读取当前剪贴板内容并尝试解析为配置文件。这一主动触发的导入方式比自动识别更可靠，且用户能获得即时的导入结果反馈，如解析成功或格式错误的提示，方便快速判断问题所在并重试。通过扫描二维码导入配置链接二维码是配置分享的另一种常见载体部分第三方分流规则的维护者会将配置链接编码为二维码图像发布在网页或社交媒体上，用户无需手动输入长链接，只需在Shadowrocket中点击右上角的扫描图标调出相机，将扫描框对准二维码即可完成识别。识别成功后应用会提取二维码中的配置URL，自动弹出与URL导入相同的确认框，确认后即可拉取配置并保存至本地列表。二维码导入特别适合在电脑屏幕上展示配置链接的场景，避免了跨设备手动输入链接的繁琐和容易出错的问题。扫描历史记录允许重复导入相同配置Shadowrocket会记录每次成功扫描二维码的配置链接，用户在扫描界面中可查看历史扫描列表，选择之前识别过的链接重新导入。当用户在多台iOS设备上配置相同的分流规则时，无需重复扫描同一二维码，从历史记录中选择即可快速完成配置的二次导入。这一特性也适用于用户误删配置后的恢复场景，减少了重新寻找原始配置源的麻烦。二维码扫描适用于配置链接无法直接复制的情况在某些配置发布场景中，链接可能以文本形式展示但处于无法选取复制的位置，例如图片内嵌文字或视频中的短暂展示。二维码扫描则绕过了文本复制环节，直接通过图像编码获取完整链接，避免了手动输入长字符串时的高出错率。用户只需确保相机对焦清晰且二维码完整处于扫描框内，通常1至2秒内即可完成识别。导入后配置的启用、切换与验证新配置不会覆盖已有配置，需手动激活Shadowrocket支持同时存储多份配置文件，从第三方导入的新配置会以独立的条目保存在配置列表中，用户之前使用的配置文件仍然存在且可随时切换回去。这种非破坏性的导入方式允许用户在不同规则集合之间自由试验，无需担心导入新配置会导致原有配置丢失。用户可以在配置列表中上下滑动查看所有已保存的配置，并通过点击配置名称前的选中标记确认当前正在使用的是哪一份。配置切换后立即生效，无需重启应用当用户在配置列表中点击新导入的配置名称时，Shadowrocket会立即加载该配置中的规则并替换内存中的现行规则，整个过程通常在半秒内完成。如果代理开关已开启，所有后续网络请求将按照新配置的分流规则处理，已建立的连接可能会按新规则重新路由，短暂的连接重置属于正常现象。用户可通过访问ipinfo.io等IP检测网站来验证新配置的分流效果，观察出口IP是否根据规则预期发生变化。验证配置规则是否按预期执行导入并切换配置后，用户应执行基本的连通性验证，确保国内网站能够直连访问、境外网站能够通过代理节点访问，且节点切换和策略组选择功能正常。最直接的验证方式是访问“http://ipinfo.io”查看当前出口IP，若显示为国内IP则说明国内流量直连规则生效，若显示为代理节点IP则说明流量经过代理。同时访问“http://ip.sb”等测试站点，对比访问国内和境外网站时返回的IP地址差异，能够直观判断分流规则的执行是否符合预期。第三方配置的更新机制与维护要点部分第三方配置支持远程自动更新如果导入的第三方配置文件提供了持续维护的远程URL，且Shadowrocket在导入时识别了该URL，应用会在配置列表条目中保留来源地址并支持定期刷新。用户可在配置的编辑界面中查看是否包含“更新”或“刷新”选项，如有则可手动触发更新拉取最新规则。部分配置还支持自动更新，当用户开启Shadowrocket的自动配置更新功能时，应用会定期检查远程配置是否有变更并自动应用新内容。导入的本地配置与远程配置在更新行为上的区别从URL导入的配置在本地保存时会分为两种模式：一种是仅保存配置内容而丢弃来源URL的“一次性导入”，另一种是保留URL引用的“远程订阅”。前者无法通过应用内操作更新，用户需要重新导入新链接或手动编辑配置内容；后者则支持通过刷新按钮拉取最新版本。用户在导入时应留意配置列表条目右侧是否存在刷新图标或“远程”标识，以此判断该配置是否支持在线更新。定期清理不再使用的配置保持列表整洁随着用户尝试不同第三方配置的累积，配置列表中可能堆积大量已不再使用的旧配置文件，这些文件虽然不占用显著的存储空间，但会干扰配置切换时的选择和识别效率。用户可在配置列表中左滑不需要的配置条目选择删除，或长按进入编辑模式后批量移除。删除配置不会影响当前正在使用的配置，除非用户删除了当前激活的配置，此时应用会自动回退至默认配置。导入失败的原因排查与处理链接地址无效或网络环境无法访问远程配置源当导入过程中提示“下载失败”或“无法连接服务器”时，最可能的原因是配置链接本身已失效、服务器暂时不可用，或当前网络环境无法直接访问该链接所在域名。用户可先将配置链接复制至Safari浏览器中直接访问，观察是否能够打开并看到配置内容。如果浏览器也无法访问，则需检查链接地址是否正确，或尝试切换至蜂窝数据网络以避开Wi-Fi环境的访问限制。如果链接需要翻墙访问，用户需先开启代理节点再尝试导入。配置格式与Shadowrocket不兼容导致解析失败部分第三方配置是为Clash、Surge等其他代理客户端设计的，其语法规则与Shadowrocket的配置格式不完全兼容。导入时应用会返回“格式错误”或“解析失败”的提示，此时用户无法直接使用该配置。解决办法是寻找明确标注支持Shadowrocket的配置链接，或使用在线转换工具将其他格式的配置文件转换为Shadowrocket可识别的格式。用户也可手动提取其中的规则部分，粘贴至现有的配置文件中。配置内容中包含未定义的策略组或节点引用当配置文件中引用了策略组或节点，但导入后的本地节点列表中不存在对应的节点配置时，Shadowrocket在加载配置时可能报错或部分规则失效。用户在导入第三方配置后，应先检查配置中引用的节点是否已存在于自己的节点列表中，如果缺失则需手动添加对应节点或修改配置中的节点引用。也可以通过将配置中的策略组节点指向自己已有的节点分组来实现兼容。常见问题FAQ

Shadowrocket国内网站访问变慢了，是不是分流规则配错了？

当Shadowrocket国内网站访问变慢时，首先将全局路由切换至“直连”模式进行验证，如果直连后网站速度恢复正常，则明确是配置规则或代理节点的问题，此时应重点审查配置文件中国内流量是否被错误匹配到了代理通道。最核心的检查项是确认配置规则中是否包含了优先级高于代理规则的GEOIP,CN,DIRECT直连规则，并确保该规则位于规则列表的前端而非末尾，使国内网站流量在匹配到其他规则前就被标记为直连。若规则缺失或位置错误，用户可手动添加该规则并调整顺序。对于国内域名解析变慢的问题，检查配置中的DNS设置是否为114.114.114.114或223.5.5.5，并在配置文件中添加DNS分流规则，将国内域名的解析请求指定给国内DNS服务器，避免所有解析请求绕行境外DNS。查看连接日志是精准定位问题规则的有效方法，开启日志后访问变慢的国内网站，观察日志中该域名匹配的规则名称，若显示为PROXY而非DIRECT，则可精准定位问题规则并调整其顺序。完成规则和DNS配置的调整后，保存配置，保持全局路由为“配置”模式重新开启代理，再次访问之前变慢的国内网站进行速度验证。如果经过上述调整后国内访问速度恢复正常，则问题已解决；若仍然存在速度异常，则考虑本地网络质量、设备性能或节点本身回源国内网站链路不佳等因素，可尝试重启路由器和设备或切换至其他节点进行对比测试。梳理配置和验证速度的整个过程能够有效锁定问题根源，恢复国内网站的流畅访问体验。分流规则配置错误确实是导致国内访问变慢的首要原因国内网站流量被错误地匹配到代理规则而非直连通道当Shadowrocket配置文件的规则集合中缺乏完整的国内网站直连规则，或规则的匹配顺序设置不当时，用户访问百度、淘宝、知乎等国内网站时产生的流量可能被错误地判定为“需代理”并转发至境外代理节点。这一过程意味着数据包需要先从设备发送至代理服务器，再由代理服务器回源至目标国内网站，绕行了额外的国际链路。相比直连的本地网络路径，代理通道增加的往返延迟通常在数百毫秒以上，用户直观感受到的就是网页加载时间显著延长，首屏内容出现卡顿或超时。GEOIP和CNIP规则未正确配置导致国内IP段未被识别为直连高效的分流配置通常会包含GEOIP规则，用于识别源IP或目标IP的地理归属，并配合CNIP（中国IP地址段）数据实现国内流量的自动直连。如果配置文件中缺失GEOIP规则的引用，或引用的CNIP数据库版本过旧且未包含最新的IP段分配信息，部分国内网站的IP地址可能未被正确归类为“中国”区域，从而落入代理规则的匹配范围。用户需要检查配置规则中是否包含类似于GEOIP,CN,DIRECT的规则条目，并确认该规则放置在代理规则之前以确保优先匹配。规则顺序错误使后续直连规则无法生效Shadowrocket的规则引擎按照配置文件中规则列表的先后顺序逐条匹配，一旦某个规则成功匹配，后续规则不再执行。如果用户将泛匹配规则如FINAL,PROXY（所有未匹配流量走代理）放置在了国内直连规则之前，或者配置中缺少用于终止匹配的FINAL,DIRECT且直接使用FINAL,PROXY兜底，那么国内网站的流量可能在匹配到GEOIP规则之前就被前置规则命中并送往代理。用户应检查配置文件末尾的兜底规则类型，确保国内网站流量有明确的直连匹配路径而非落入代理兜底。DNS解析环节的配置问题同样影响国内网站访问速度使用境外DNS解析国内域名产生高延迟当Shadowrocket配置中指定了GoogleDNS、CloudflareDNS等境外公共DNS服务器作为解析器时，所有域名解析请求都需要跨越国际网络发送至境外服务器。对于国内网站的域名解析，这种绕行不仅增加了解析耗时（通常从几十毫秒增加至数百毫秒），还可能因境外DNS返回的CDN节点IP并非国内优化节点，导致后续访问进一步变慢。用户应检查配置中的DNS设置，考虑使用114.114.114.114或223.5.5.5等国内公共DNS进行国内域名的解析，或配置规则将国内域名的DNS请求单独发给国内DNS。DNS解析结果被代理污染或缓存过期导致路由异常在某些代理模式下，DNS解析请求可能也经过代理通道发送，此时返回的IP地址是基于境外DNS视角解析的CDN节点，而非针对国内用户优化的边缘节点。即使分流规则正确将流量直连，但连接的目标IP是境外优化的节点，从国内访问该IP仍需跨越国际链路，速度必然受损。用户可尝试在Shadowrocket的DNS设置中启用“使用代理时也使用系统DNS”或“先直连DNS解析”的选项，确保国内域名的解析结果来源于本地网络视角的国内DNS。配置文件中DNS规则未按域名分流导致解析混乱配置文件支持DNS层面的规则分流，允许用户为特定域名指定解析服务器，例如国内域名使用国内DNS，国外域名使用境外DNS。若DNS规则配置不当，例如未加入DOMAIN-SUFFIX,cn,系统DNS或DOMAIN-KEYWORD,baidu,系统DNS等条目，则所有域名的解析请求可能均被发往同一个境外DNS，导致国内域名解析显著变慢且返回次优IP。用户应检查配置文件中是否包含完整的DNS分流规则，并确保其顺序合理。代理节点选择不当与配置模式冲突导致速度下降配置策略组中的节点选择与国内流量匹配错误在配置模式（全局路由设为“配置”）下，配置文件中的策略组定义了不同类别流量的节点选择逻辑。如果配置文件中的默认策略组或兜底策略组引用了一个高延迟或低带宽的代理节点，且国内直连规则未生效，则国内流量会使用该节点进行转发。用户应检查配置中策略组的节点引用和选择策略，确认国内流量是否被正确地分配至DIRECT策略而非代理节点。可临时将全局路由切换为“直连”模式测试国内网站速度是否恢复，若恢复则明确是配置规则的问题。配置中策略组的故障转移机制可能误判导致节点切换部分配置文件中策略组会采用“故障转移”或“延迟最低”选择策略，当策略组内节点延迟测试不准确或某节点短暂不可用时，可能触发策略组切换至延迟较高但稳定性更差的备用节点。而国内流量若因规则错误进入该策略组，则会受到节点切换的影响。用户可检查策略组的节点列表和选择策略，必要时将国内流量相关的策略组固定为DIRECT以规避此类问题。手动选择的节点与配置规则产生优先级冲突当用户在主界面手动选中了一个节点，但配置规则中又将特定域名或IP段的流量指向了策略组时，实际路由由规则指定的策略组决定，主界面的节点选择可能仅作为兜底或特定策略组的备选。用户若发现国内网站走代理，应检查配置规则中是否有明确的GEOIP,CN,DIRECT或IP-CIDR,CNIP,DIRECT规则并确保其放置在代理规则之前，而非依赖主界面节点选择来改变国内流量的路由行为。本地网络环境和设备性能的干扰因素配置文件中规则数量庞大导致匹配效率下降当配置文件中包含数百甚至上千条规则时，每个网络请求都需要依次遍历规则列表进行匹配，虽然单次匹配的延迟在微秒级别，但在高并发请求或设备性能较低的场景下，累计的匹配耗时可能导致感知到的页面加载延迟。用户可精简规则列表，移除重复或已失效的规则，并将泛匹配规则放置在列表末尾以减少匹配次数，提升整体规则引擎的处理效率。设备开启低电量模式或后台应用过多影响处理速度iOS在低电量模式下会限制CPU性能和网络活动，当Shadowrocket需要处理大量规则匹配和加解密操作时，性能受限可能导致数据处理延迟累积。用户可检查设备是否处于低电量模式，并关闭不必要的后台应用，释放系统资源以提升Shadowrocket的规则处理速度。重启设备也能清除系统缓存，恢复网络模块的正常响应速度。本地网络本身存在波动或带宽被其他应用占用即便分流规则完全正确，本地网络质量仍是影响国内网站访问速度的基础因素。用户可关闭Shadowrocket的代理开关，直连状态下测试国内网站的加载速度，如果直连同样缓慢，则问题不在代理配置层面，而是Wi-Fi信号质量、运营商网络拥塞或家中其他设备占用带宽所致。若直连正常而代理开启后变慢，则需回到配置和节点的排查路径。配置修改后的快速诊断与验证方法切换全局路由至“直连”模式验证分流规则准确性当怀疑国内网站变慢是由于分流规则错误导致流量被代理时，最直接的验证方法是将Shadowrocket的全局路由切换至“直连”模式，该模式会绕过所有配置规则和代理节点，使设备所有流量直接通过本地网络发出。若切换直连后国内网站访问速度恢复正常，则明确是配置规则或代理节点的转发问题。若直连模式下依然缓慢，则问题在于设备本地网络或目标网站服务端，而非Shadowrocket配置。查看连接日志确认国内域名是否触发代理规则Shadowrocket提供了网络活动日志功能，用户开启日志记录后访问变慢的国内网站，在日志中可看到该域名的连接记录以及匹配的规则名称。若日志显示匹配规则为PROXY或具体的策略组名称（而非DIRECT），则说明分流规则确实将该域名判定为需代理的流量，需要调整配置文件中的规则顺序或新增直连规则。日志功能是定位规则错误最直观的工具，比猜测更能精准锁定问题规则条目。逐条审查配置规则排查优先级和遗漏规则用户应打开当前选中的配置文件，检查规则列表的排列顺序是否符合预期的匹配优先级。关键检查点包括：直连规则（如GEOIP,CN,DIRECT）是否放置在代理泛匹配规则之前；是否存在针对常见国内域名的显式DIRECT规则；FINAL或兜底规则是否设置为DIRECT而非PROXY。合理的规则结构应确保国内流量优先匹配直连路径，国外或未分类流量才进入代理通道。配置优化与国内网站加速的调整策略导入经过广泛验证的懒人规则集作为配置基础对于不熟悉手动编写配置规则的用户而言，直接使用社区维护且经过广泛验证的规则集可以有效避免国内流量误走代理的问题。这类规则集通常包含完整的GEOIP和CNIP直连规则，并定期更新以覆盖新的国内IP段和域名，用户只需导入配置并少量调整策略组即可获得较为理想的分流效果，大幅降低因规则缺陷导致的访问变慢概率。在DNS设置中使用国内公共DNS并启用DNS分流修改Shadowrocket的DNS设置为“114.114.114.114,223.5.5.5”并在配置文件中配置DNS规则，将国内域名（如.cn后缀或含有关键词baidu、taobao的域名）的解析请求指定为这些国内DNS，确保解析结果是最优的国内CDN节点。同时保持境外域名使用系统DNS或境外DNS，实现解析环节的分流优化，减少国内域名解析的延迟。定期更新CNIP数据库以保持IP段规则的有效性国内运营商会不定期调整IP地址段的分配，过时的CNIP数据库可能将部分新的国内IP段识别为境外地址，导致直连规则失效。用户应定期更新Shadowrocket的CNIP数据库文件，或在配置中引用提供实时更新的在线CNIP规则源，确保国内IP段规则始终覆盖最新的分配情况，避免因IP段规则过期导致国内流量被误判为代理。常见问题FAQ

Shadowrocket“配置”模式和“代理”模式有什么区别？

在Shadowrocket中，“配置”模式和“代理”模式服务于完全不同的功能层级，代理开关是整个应用的激活总闸，决定是否启用网络拦截和转发管道，关闭时所有代理功能失效，开启时设备流量进入Shadowrocket管控。而配置模式（通常指全局路由中的“配置”选项）决定了代理管道激活后如何对每个数据包进行分流决策，配置文件中包含的规则、策略组和节点选择逻辑被完整执行，实现国内直连、国际代理、应用分流等精细化的流量管理。用户在日常使用中建议保持代理开关常开，将全局路由设为“配置”模式并加载一份规则完善的配置文件，这样既能享受代理服务又不会影响国内网站访问速度。当需要所有流量全部经由代理节点转发时（如隐私敏感场景），将全局路由切换至“代理”模式，此时配置文件中的所有分流规则被忽略，实现百分百代理覆盖。两种模式可以通过主界面的下拉菜单随时切换，无需关闭代理或重启应用，用户可根据不同网络环境和隐私需求灵活选择。配置文件的切换同样支持热切换，用户可以在代理开启状态下从配置列表中直接选择另一套配置，应用会立即加载新规则并应用至后续网络请求。禁用代理或切换配置均不会清除或修改配置文件本身的内容，所有规则、策略组和节点引用在开关关闭时仍被完整保存，再次开启时可无缝恢复使用。功能定位的根本差异：规则管理vs开关控制“代理”模式是启用或禁用网络隧道功能的全局开关在Shadowrocket主界面底部，用户可以找到“代理”开关按钮，这是一个二进制的功能总闸，用于决定当前设备是否启用网络代理通道。当开关处于开启状态时，应用会根据当前选定的节点和配置规则对所有网络请求进行转发或直连处理，此时设备的所有网络流量都受到Shadowrocket的管控。当开关关闭时，应用完全退出代理状态，所有网络请求直接通过设备本身的基础网络通道发出，不受任何代理规则或节点的影响，相当于Shadowrocket进入“休眠”模式，此时在应用内切换节点或修改配置均不会对实际网络产生任何影响。“配置”模式是预设的规则集合而非即时生效的开关“配置”在Shadowrocket中指的是一个完整的规则配置文件，它包含了代理规则、分流策略、策略组定义以及节点引用等一系列网络行为准则的集合，本质上是一个“如何分流”的决策框架而非“是否启用代理”的总开关。用户可以创建或导入多个不同的配置文件以适应不同的网络使用场景，例如“日常上网”配置包含优化网页访问的规则集，“游戏加速”配置包含UDP转发优化和特定端口的策略组。但配置文件本身不会自动生效，需要用户在“代理”开关开启的状态下选择特定配置，应用才会按照该配置的规则执行网络分流。两者之间的关系是“代理”决定功能是否激活，而“配置”决定激活后如何工作。配置的多样性提供场景化切换能力而代理仅控制启用状态一个显著的差异在于，用户可以在不关闭代理的前提下自由切换不同的配置文件，从而实现网络分流策略的即时调整，而不需要频繁开关代理总闸。例如在办公网络环境中使用一套对内网资源直连的配置，在家中网络切换至优化流媒体访问的配置。代理开关只有“开”和“关”两种状态，不提供任何策略层面的灵活性，而配置模式则允许用户预设多种行为模板，在代理启动时选择最匹配当前场景的方案。这种分离设计使得用户既能快速关闭所有代理功能，又能在需要代理时灵活调整其行为模式。代理开关控制的执行层面与配置控制的决策层面代理开关作用于设备最底层的网络请求路由当用户打开Shadowrocket的“代理”开关时，应用会在iOS系统层面注册一个虚拟网络接口，通过NetworkExtension框架接管设备所有应用程序的网络请求。这一操作发生在操作系统的网络栈底层，所有来自Safari、微信、邮件客户端等应用的网络数据包都会被重定向至Shadowrocket的处理管道。关闭开关时，应用会向系统注销该虚拟接口，网络请求恢复为直接通过物理网络接口发出。这个过程是一个二元的“接管或放弃”决策，不涉及任何关于如何处理流量的具体指令。配置决定代理启用后每个数据包的具体去向代理开关开启后，每个被接管的数据包需要决定是经由代理节点转发、直接由本机发出还是丢弃，这一决策逻辑完全由当前选定的“配置”来提供。配置文件中定义了一系列规则，例如“哪些域名走代理”、“哪些IP段直连”、“哪些应用绕过代理”，以及“遇到匹配多条规则时按什么顺序执行”。配置不直接控制数据包的收发，而是为数据包提供一份“导航地图”，告诉代理管道如何处理每个到达的请求。没有配置文件（或选用了空配置）时，即使代理开关打开也无法正常转发数据。切换配置时无需关闭代理即可完成规则更新这一特性体现了配置与代理的独立性，用户可以在保持代理开关持续开启的状态下，直接从配置列表中切换到另一套配置，应用会立即用新规则替换旧规则并应用于后续的所有网络请求。切换过程中已建立的TCP连接可能断开并按照新规则重建，但用户无需手动执行“关闭代理-切换配置-重新开启”的繁琐流程。这种设计使得用户能够在不同场景间平滑过渡，例如进入公司内网后切换到包含内网直连规则的配置，离开时再切换回公网代理配置。代理模式下的全局路由选项与配置规则的协同关系代理开关开启后全局路由设定与配置规则共同决定路由结果当代理开关开启时，Shadowrocket主界面底部的“全局路由”选项（如配置、代理、直连、场景）与配置文件中的详细规则形成上下级协作关系。若用户选择“配置”作为全局路由模式，则代理管道完全遵循当前配置文件中编写的所有规则和策略组，配置文件中的每条分流规则都会被执行和评估。若用户选择“代理”模式，则代理管道忽略配置文件中除节点选择外的所有分流规则，直接将所有流量无条件转发至当前选定的代理节点，相当于配置规则被全局覆盖。“配置”路由模式下配置规则获得完整执行权限当全局路由选项设为“配置”时，Shadowrocket会加载当前配置文件中的全部规则列表，按照规则定义的优先级顺序逐条评估每个网络请求，匹配到对应的策略后执行转发、直连或拒绝等操作。这允许用户通过配置文件实现极其精细的流量管理，例如将国内网站直连、境外网站代理、特定应用绕过代理、广告域名拒绝等复杂策略。配置模式的价值在于其灵活性和可定制性，适合对网络行为有细分需求的进阶用户。“代理”路由模式使配置规则失效实现全局代理将全局路由设为“代理”时，即使当前选定的配置文件中包含丰富的规则定义，Shadowrocket在转发数据时也会完全忽略这些规则，直接将所有网络请求无差别地发送至当前选中的代理节点。这一模式取消了所有基于域名、IP或应用的流量区分，实现百分百的代理覆盖。适合在需要确保所有流量都经过代理的隐私敏感场景，或临时测试节点速度时使用，此时配置规则被全局覆盖而不发挥任何分流作用。配置的保存与切换独立于代理开关状态配置切换在代理关闭时仍可进行用户即使将“代理”开关完全关闭，仍然可以在Shadowrocket的配置列表中选择和切换不同的配置文件。这种设计使得用户可以在代理功能未激活时提前选择好下次开启时希望使用的配置方案，开关开启后应用直接应用当前选定的配置开始工作。例如在进入会议室前关闭代理并切换到“内网访问”配置，会议结束后开启代理时自动沿用该配置，无需在开启代理后再花时间切换。配置编辑和导入导出不与代理状态绑定无论“代理”开关处于开启还是关闭状态，用户始终可以自由编辑配置规则、创建新的配置文件或通过二维码和链接导入外部配置。这些管理操作不依赖代理通道本身的可用性，即使当前设备完全没有网络连接，用户依然可以在应用内查看和修改配置内容。这种独立性确保了用户可以在任何时刻准备工作所需的配置模板，再在需要时通过开启代理来激活它们。配置中保存的节点信息不受代理开关影响配置文件内部可能直接嵌入了节点列表或引用了特定订阅分组，这些节点信息的加载和更新与“代理”开关状态无任何关联。用户可以在代理关闭状态下刷新订阅、测试节点延迟或修改配置中的节点引用，所有操作结果会在代理开启后立即生效。代理开关仅控制这些节点和配置是否真正被应用于设备网络流量，不干预配置文件的维护过程。模式选择适用场景的具体建议日常使用推荐配置模式实现国内直连国际代理对于绝大多数用户的日常上网场景，将全局路由设为“配置”模式并加载一份规则完善的配置文件是最合理的选择。配置模式能够自动判断哪些网站走代理、哪些直连、哪些被屏蔽，在保证境外服务可用的同时不影响国内网站的加载速度，且避免了全局代理模式下可能引起的网银、政务网站访问异常。一份优秀的配置文件可以覆盖绝大多数用户的日常需求，无需频繁手动干预。需要完全隐匿流量时切换至代理模式在隐私高度敏感或网络审查严格的场景下，将所有流量强制经由代理节点转发是保护身份和通信内容的必要手段。此时用户应将全局路由切换至“代理”模式，确保从操作系统更新到即时通讯消息的所有数据包都不直接暴露在本地网络中，即使配置文件中原本有直连规则也不会生效。但需注意，全局代理模式下流量消耗增加，且部分依赖本地网络的服务如局域网打印、本地服务器访问将无法正常工作。故障排查时利用直连模式隔离配置影响当怀疑配置规则出现问题时，用户可以临时将全局路由切换至“直连”模式，该模式下代理开关即使开启也不会转发任何流量到代理节点，所有请求直接走本机网络，且绕过配置文件中除DNS外的所有规则。这可以帮助用户判断网络问题是出在代理节点、配置规则还是设备基础网络层面，是排障过程中的重要诊断工具。配置中节点的选择机制与代理开关的关系配置中的策略组节点在代理开启后才被使用每个配置文件中可以定义多个策略组，每个策略组引用一组代理节点并规定了选择策略，例如“选择延迟最低的节点”或“按用户手动选择”。这些策略组中的节点列表和选择逻辑在配置被加载时即保存在内存中，但只有在代理开关开启且全局路由设为“配置”时，这些节点才会实际处理网络流量。代理关闭时，配置中的节点信息只是静态数据，不参与任何网络通信。代理开关开启且配置模式激活时策略组节点处于活跃状态当用户在配置模式下开启代理后，配置文件中的所有策略组开始生效，Shadowrocket会按照每个策略组的定义自动选择对应节点转发匹配的流量。例如“Netflix”策略组中配置了多个流媒体优化节点，当配置规则判定某条流量属于Netflix时，代理管道会从该策略组中选取一个节点进行转发，而不是使用当前主界面选中的节点。这意味着在配置模式下，主界面的节点选择可能仅作为默认或备用策略的参考，实际路由行为由配置规则中的策略组决定。单节点选择模式与配置文件的覆盖关系当全局路由设为“代理”而非“配置”时，配置文件中的策略组和规则完全被忽略，代理管道直接使用用户在主界面节点列表中手动选中的那个单一节点作为所有流量的转发目标。这种模式与配置策略组无关，即使配置中定义了复杂的策略组也不会生效。这允许用户在配置模式下精细分流和代理模式下简单全局代理之间快速切换。常见问题FAQ

Shadowrocket订阅更新提示“SSL证书验证失败”怎么解决？

当Shadowrocket订阅更新提示SSL证书验证失败时，首先检查设备系统时间是否准确，在“设置→通用→日期与时间”中确保“自动设置”开启且时间显示正确，这是最容易被忽视但解决率最高的步骤。若时间无误，将订阅链接复制至Safari浏览器中直接访问，观察是否能正常打开并返回节点配置内容，若浏览器也提示证书错误并显示具体原因（如过期或不受信任），则明确为服务端证书问题。作为临时恢复方案，在订阅编辑界面中开启“跳过证书验证”选项可立即绕过验证并完成更新，但更新成功后应关闭该选项并联系服务商更新有效证书。若服务商提供自签名证书，可要求对方提供证书文件，通过邮件安装至设备并在“证书信任设置”中开启完全信任，此后该订阅的SSL验证将正常通过。更换公共DNS如114.114.114.114可排除运营商劫持引起的证书不匹配，而最终可靠的解决方案仍是推动服务商更换由权威CA签发且包含完整证书链的标准SSL证书。执行上述步骤后，订阅更新通常能够恢复正常，若所有尝试均无效则考虑切换至HTTP订阅链接作为临时手段，但务必在服务商修复证书后尽快回到HTTPS通道以确保订阅内容的传输安全。证书过期或自签名是导致验证失败的常见原因SSL证书具有明确的有效期，过期后即被系统拒绝SSL证书由证书颁发机构签发时设定了固定的有效期限，通常为一年或更长时间，一旦超出该期限，证书即被视为无效。当Shadowrocket向订阅服务器发起HTTPS请求时，iOS系统会强制校验服务器返回的证书有效期，若当前设备时间超出了证书的有效期范围，系统将直接终止连接并返回验证失败错误。服务商若未及时更新即将过期的证书，所有使用该订阅的用户在证书到期后都将无法完成更新，此时用户端没有任何绕过的可能，除非服务商续期或更换证书。自签名证书未被iOS系统信任库收录导致验证失败部分小型服务商或自建订阅源为节省成本，会使用自行签发的SSL证书而非向权威CA机构购买，这类自签名证书不在iOS系统的受信任根证书列表中。当Shadowrocket尝试连接时，系统无法找到与该证书匹配的信任链，便会判定为验证失败并中断请求。与过期证书不同，自签名证书本身可能仍在有效期内，但因缺乏权威背书而被系统拒绝，用户需要手动将自签名证书导入设备并设置为信任才能通过验证。证书域名与请求域名不匹配同样是验证失败的诱因SSL证书在签发时绑定了特定的域名或泛域名范围，当Shadowrocket请求的订阅URL中的域名与证书所声明的域名不一致时，iOS系统会判定该证书不适用于当前连接。这种不匹配可能源于服务商更换了域名但证书未同步更新，或用户使用的订阅链接指向了与证书不匹配的备用域名。设备端在握手阶段即检测到不匹配并终止连接，反馈给Shadowrocket的错误信息同样归类为SSL验证失败，用户需检查订阅链接的域名是否与证书绑定的域名一致。设备系统时间不准确会直接触发证书验证错误证书有效期校验完全依赖设备本地时间的准确性iOS在验证SSL证书时，会将证书中的生效时间和失效时间与设备当前的系统时间进行比对，只有当设备时间落在有效期内时验证才能通过。如果用户设备时间被手动调整或自动同步失效导致与标准时间偏差过大，即使证书本身完全正常，系统也会因时间戳不在有效期内而拒绝连接。这种时间偏差导致的验证失败在网络错误提示中与真实证书问题显示完全相同的SSL错误信息，用户必须首先排除时间因素才能判断是否为证书本身问题。关闭自动时间同步后手动调整可能引发偏差部分用户出于省电或特定应用需求会关闭“设置→通用→日期与时间”中的“自动设置”功能，改为手动指定时间。如果手动设置的时间与实际标准时间相差数小时甚至数天，所有基于时间验证的SSL证书都将失效。即使开启了自动设置，若设备长期未连接网络或NTP服务未能成功同步，系统时间也可能与实际时间产生数分钟的偏差，足以影响证书有效期校验。用户应首先检查并确保自动时间同步处于开启状态，必要时手动触发同步。重启设备强制NTP同步可纠正时间偏差当发现设备时间与标准时间存在偏差时，简单的开关“自动设置”通常能触发一次NTP同步请求，但若该操作无效，重启设备是最可靠的手段。系统在启动过程中会主动向苹果时间服务器发起同步请求并校准时钟，重启后时间通常能恢复准确。执行重启后，用户应再次进入日期时间设置确认时间已校正，然后重新打开Shadowrocket执行订阅刷新，多数因时间偏差导致的SSL验证错误在此步骤后即可解决。在Shadowrocket中临时关闭证书验证可快速恢复更新订阅编辑界面中存在“跳过证书验证”选项Shadowrocket在订阅配置中提供了“跳过证书验证”或“允许不安全连接”的开关，开启该选项后，应用在拉取订阅内容时将忽略iOS系统的SSL证书校验结果，直接接受服务器的任何证书并完成连接。用户进入订阅编辑页面，在高级设置或安全选项区域中找到该开关并打开，保存后重新刷新订阅，通常能够立即绕过证书验证错误完成更新。这一操作仅需数秒即可执行，是遇到SSL验证失败时最快速的应急恢复手段。关闭验证仅影响订阅拉取通道而非代理连接本身需要注意的是，“跳过证书验证”选项仅针对订阅更新时的HTTPS请求生效，不影响用户后续使用代理节点时的连接安全。代理节点的加密传输依赖于节点自身的协议加密或TLS配置，与订阅拉取的证书验证相互独立。因此用户可以在订阅更新成功后立即将该选项重新关闭，恢复正常的证书验证机制，避免长期绕过验证带来的安全风险。这种临时性的操作既解决了更新受阻的问题，又不影响日常使用的安全基线。长期关闭验证存在中间人攻击的潜在风险虽然关闭证书验证能够快速解决更新问题，但长期保持该选项开启意味着设备不再验证订阅服务器的身份真实性，攻击者可能通过DNS劫持或ARP欺骗将用户导向伪造的订阅服务器，推送恶意节点配置。这些伪造的节点可能窃取用户的代理流量或植入恶意规则。因此关闭验证仅应作为临时排障手段，在确认服务商证书问题解决后应立即重新开启，或通过手动导入证书的方式建立安全的信任关系。更换DNS或修改订阅链接中的域名为IP地址绕过验证更换公共DNS可排除运营商DNS劫持造成的证书不匹配部分网络运营商的DNS服务器在解析域名时，可能将订阅链接的域名指向了缓存的备用IP或广告劫持页面，导致用户实际连接的服务器并非订阅服务商的原服务器，其SSL证书自然与域名不匹配。用户可在Shadowrocket的设置中将DNS修改为114.114.114.114或8.8.8.8等公共DNS，确保域名解析到正确的服务器IP，此时证书域名与实际访问域名一致，验证错误即告解除。更换DNS后重新刷新订阅，通常能解决因DNS劫持引发的SSL问题。将订阅链接中的域名替换为服务器IP地址可规避证书域名检查如果服务商的SSL证书绑定的是IP地址而非域名，或用户希望通过直连IP来避免DNS解析环节，可直接在订阅链接中将域名部分替换为服务器的真实IP地址。但需注意，替换为IP地址后，证书中的域名验证仍会进行，只有当证书同样绑定了该IP或使用泛域名证书时才能通过验证。大多数公共CA签发的证书不支持IP绑定，因此这一方法仅适用于服务商明确提供了IP证书的场景，普通用户不建议随意替换。修改Hosts文件实现域名到IP的本地映射对于无法直接修改订阅链接的场景，用户可通过修改设备Hosts文件将订阅域名强制指向特定IP地址，从而跳过DNS解析环节，避免运营商DNS劫持或域名污染。iOS设备修改Hosts需要借助描述文件或第三方工具，操作相对复杂，但一旦配置成功，所有指向该域名的请求都会直接发往指定IP，SSL握手时证书域名与请求域名保持一致，验证错误随之解决。该方法适合高级用户，普通用户可优先考虑更换DNS。手动导入并信任服务端证书可根治验证问题从服务商获取证书文件并安装至iOS钥匙串当订阅服务商使用自签名证书或私有CA签发的证书时，用户可要求服务商提供该证书的.crt或.pem格式文件，通过邮件或云盘传输至iOS设备。点击证书文件后，系统会提示安装描述文件，安装完成后该证书即被添加至设备的证书存储区。随后进入“设置→通用→关于本机→证书信任设置”，找到刚刚安装的证书并开启完全信任开关，此后系统在验证该证书时即可通过。通过Safari访问订阅链接触发证书下载和信任流程部分服务商允许用户通过Safari浏览器直接访问订阅链接，当证书不被信任时，浏览器会显示“此连接不是私密连接”的安全警告，但提供“继续”或“显示详情”选项，用户可点击“显示详情”并选择“信任此证书”，系统会引导安装证书描述文件。安装完成后再次回到Shadowrocket刷新订阅，此时系统已信任该证书，验证错误即被解决。这一方法适用于证书本身有效但未被iOS信任库收录的场景。信任自签名证书后需注意证书更新时的重复操作自签名证书同样具有有效期，当证书过期后服务商更换新证书时，用户需要重新下载并信任新证书，旧证书的信任状态不会自动覆盖。因此手动导入证书的方式需要用户在每个证书周期内重复执行一次导入信任操作，不能一劳永逸。建议用户在操作完成后将证书文件妥善保存，便于下次到期时快速导入，避免因证书过期再次导致订阅更新失败。联系订阅服务商更新证书是最终的可靠解决方案服务商端证书过期需由其自行续期当SSL验证失败的根本原因在于服务商证书已过期且未续期时，用户端任何操作都无法真正解决问题，因为过期证书不会因本地信任设置而复活。此时用户应立即通过邮件、工单或即时通讯渠道联系服务商，告知其订阅链接的SSL证书已过期，需要尽快更新或替换证书。专业服务商通常会在收到通知后数小时内完成证书续期或更换，用户等待服务端更新后重新刷新订阅即可恢复正常。请求服务商提供兼容iOS的证书链避免中间证书缺失部分服务商配置的SSL证书缺少完整的中间证书链，桌面端浏览器因缓存了中间证书而能正常访问，但iOS设备缺乏这些中间证书则验证失败。用户可以告知服务商检查其证书配置是否包含了完整的证书链，确保服务器返回的证书包含所有中间证书，以便iOS能够完整构建信任链。服务商调整配置后，用户无需任何本地操作即可正常更新。切换至HTTP订阅链接作为最后的备选方案如果服务商短期内无法解决SSL证书问题，且用户急需更新节点，可询问服务商是否提供HTTP协议（非加密）的订阅链接作为临时替代。HTTP链接不涉及证书验证，可以绕过SSL错误，但所有订阅内容将以明文传输，存在被中间节点窃听的风险。用户使用HTTP链接更新后，应尽快在服务商修复证书后切换回HTTPS订阅，避免长期使用明文传输。常见问题FAQ