分类： 未分类

Shadowrocket 下载资讯、Android 使用教程与问题排查资料。

DNS直连回退代理（dns-direct-fallback-proxy）要开启吗？

dns-direct-fallback-proxy是否开启取决于用户当前网络环境对DNS解析的干扰程度以及自身的访问需求：当直连DNS能够正常解析访问的域名时保持关闭以维持最优速度和最低隐私风险；当频繁遇到“DNS解析失败”或因污染导致特定境外网站无法访问时，开启该功能可为失败解析提供一条经代理节点的备用通道，显著提升访问成功率。建议优先尝试更换dns-server为223.5.5.5、119.29.29.29等国内公共DNS或1.1.1.1等境外DNS来改善直连解析效果，若优化后问题仍存在再启用回退。开启后需注意其对首次访问境外域名时的解析延迟影响（通常增加200至800毫秒），并确保配置文件中的DNS规则未强制直连特定域名，以免回退机制被规则屏蔽。对于重度境外访问用户和技术工作者，开启此开关并结合规则模式使用可有效提升分流准确性和整体代理稳定性；对于日常普通浏览用户，保持默认关闭即可满足使用需求，待遇到具体问题时再针对性开启。验证开启效果的最佳方式是在访问解析困难的域名时开启连接日志，若日志中显示解析请求走代理通道且页面加载成功，则说明回退机制已正常工作。最后需留意，回退机制仅作用于DNS解析环节，不改变节点自身的连通性，如果代理节点本身不可用，回退同样无法获得有效解析结果。功能定义：理解dns-direct-fallback-proxy的作用边界该功能是DNS解析失败后的应急通道开关dns-direct-fallback-proxy是Shadowrocket中一项针对DNS解析异常的容灾机制，其核心作用在于当设备通过直连方式向本地DNS服务器或配置的dns-server发起域名解析请求时，如果该请求因超时、网络不通或被污染而返回无效结果，应用将自动切换至代理通道重新发起一次DNS查询。这一“回退”动作仅在前端DNS解析彻底失败时触发，并不影响解析正常时的常规流程，其设计初衷是在本地网络受到DNS干扰时，利用代理节点的远程解析能力作为备份通道，确保用户仍能获取正确的域名IP。直连DNS与代理DNS的路径差异决定了回退的价值在正常的代理流程中，DNS解析通常分为两种方式：直连解析指设备直接向本地或公共DNS服务器发送UDP查询请求，这一过程不经过代理节点，速度最快但容易被运营商污染或防火墙拦截；代理解析则是将DNS查询请求封装后通过代理节点转发至远端DNS服务器，虽然因路径变长而增加延迟，但能够规避本地网络对特定域名的解析干扰。dns-direct-fallback-proxy的作用就是在直连解析失败时，自动降级至代理解析路径，相当于为DNS解析增加了一道安全网。该开关默认关闭且不影响常规解析流程Shadowrocket在出厂设置中默认关闭此选项，意味着当用户未主动开启时，应用仅依赖直连DNS进行解析，一旦直连解析超时或失败，应用将直接返回解析错误，不会尝试通过代理通道补救。对于绝大多数网络环境正常的用户而言，默认关闭状态并不会带来任何负面体验，因为国内主流公共DNS的解析成功率已接近100%。只有当用户频繁遇到“无法解析服务器地址”或访问特定境外域名时DNS报错，才需要考虑开启此功能来获得代理层面的解析冗余。工作机制：回退触发的条件与执行顺序回退仅在直连解析彻底失败后才会介入Shadowrocket在执行DNS解析时遵循严格的优先级顺序：首先尝试向dns-server配置中填写的所有DNS服务器发起并发查询，如果任意一台服务器在超时窗口内返回有效响应，则解析流程结束，dns-direct-fallback-proxy不会被激活。只有当所有配置的DNS服务器均未响应、返回格式错误或被污染为无效IP时，回退机制才会被触发，此时应用会将域名解析请求重新封装并通过当前选中的代理节点发送至远程DNS服务器。这一设计确保了回退不会干扰正常解析流程，仅在“救命”时刻发挥作用。开启后代理解析的超时时间独立于直连超时当dns-direct-fallback-proxy开启且直连解析失败触发回退时，Shadowrocket会为代理解析路径设置一个独立的超时计时器，通常比直连超时更长，以补偿代理通道额外的网络传输延迟。这意味着用户在访问境外网站时，如果直连DNS被污染导致无响应，回退至代理解析可能需要在原有等待时间上额外增加数秒，用户感知到的总解析时间可能达到3至8秒。但一旦解析成功，该域名的IP会被缓存并用于后续访问，后续连接的响应速度恢复正常，超时的额外成本仅在首次访问或缓存过期时发生。回退解析结果享有与直连解析同等的缓存优先级无论DNS解析是经由直连通道完成还是通过代理回退完成，最终获得的IP地址都会以相同权重存入Shadowrocket的本地DNS缓存，并在缓存有效期内（通常为TTL值设定的300至600秒）被直接复用。这意味着即使直连解析失败触发了回退，回退成功的域名在后续访问中不会再次经历代理解析的延迟，直接命中缓存。这种缓存策略使得回退带来的额外延迟影响被限制在“域名初次访问”阶段，对于频繁访问的常用网站，用户几乎感觉不到回退机制的存在。开启优势：抗污染能力与访问成功率显著提升有效规避运营商对特定境外域名的DNS污染国内部分网络运营商会针对特定境外域名实施DNS污染，即向用户的查询请求返回一个虚假的国内IP地址而非真实的境外服务器IP。当直连DNS返回被污染的IP时，Shadowrocket的规则引擎可能因该IP属于国内地址而将请求判定为直连，或代理节点向错误IP发起连接导致访问失败。开启dns-direct-fallback-proxy后，一旦检测到直连解析返回的IP属于已知污染特征（如位于国内保留地址段或无法建立连接），用户可配合配置规则强制触发回退，通过代理通道获取未被篡改的真实IP，从而恢复对该域名的正常访问。在公共Wi-Fi或受限网络下保持域名解析能力酒店、机场、咖啡厅等公共场所提供的Wi-Fi网络通常会强制使用运营商指定的DNS服务器，这些服务器可能对非网页类流量、非标准端口或特定境外域名实施解析限制。在这些网络环境下，直连DNS解析特定域名可能频繁超时或返回错误结果，导致用户无法正常使用代理服务。开启dns-direct-fallback-proxy后，即使本地公共DNS拒绝解析目标域名，Shadowrocket仍能通过代理通道完成解析，确保用户的网络访问不受公共网络DNS策略的限制，提升了代理在各种受限网络环境下的可用性。与规则模式协同提高分流规则的匹配准确性在规则模式下，GEOIP规则和基于域名后缀的路由决策都依赖于DNS解析返回的IP地址。当直连DNS因污染返回错误IP时，规则引擎可能错误地将境外域名判定为国内流量而走直连，或反之。开启回退功能后，通过代理解析获得真实IP能够确保规则引擎获取到正确的IP归属地信息，从而使GEOIP,CN,DIRECT等规则准确生效，减少因DNS污染导致的分流失效问题，提升规则模式的整体分流精度和访问成功率。潜在风险：速度牺牲与隐私考量开启后首次访问境外域名可能增加1至3秒延迟直连DNS解析通常在20至50毫秒内完成，而回退至代理解析需要将DNS查询包经代理节点加密传输至远端服务器再返回结果，整个往返耗时通常增加200至800毫秒，在网络质量不佳时可能超过2秒。如果直连解析因污染返回了错误IP但并未触发超时，应用可能不会自动启用回退，此时用户需要手动配置规则或调整测试手段来强制回退。对于追求极致解析速度的用户，开启回退意味着在直连失败时需要等待更长的代理解析周期，首次访问新域名时的页面加载速度会有所下降。代理通道解析的所有域名记录将被节点服务商知晓直连DNS模式下，用户的域名解析请求仅暴露给本地网络和DNS服务商，而开启回退后，所有因直连失败而触发的代理解析请求将经过代理节点的服务器转发，这意味着代理服务商能够获取用户正在访问的域名列表。对于注重隐私的用户而言，这一额外的信任风险需要权衡：虽然回退仅发生在解析失败时而非每次访问，但长期使用过程中仍有大量境外域名的解析记录会经手代理节点。用户应选择已建立隐私信任的代理服务商，或结合加密DNS（DoH/DoT）来降低这一层面的隐私顾虑。可能掩盖本地网络或DNS配置的真实问题开启dns-direct-fallback-proxy后，代理解析的备用通道可能掩盖本地DNS服务器配置不当或网络环境本身存在的解析故障。用户可能因此忽略了对运营商DNS劫持、本地hosts文件错误或路由器配置异常等问题的排查，长期依赖回退机制维持解析可用性，而在无代理环境下（如关闭Shadowrocket后）仍然遇到访问故障。对于希望定位和修复本地网络根本问题的用户，建议在不开启回退的状态下先完成DNS配置的排查和优化，确认直连解析已无法解决时再启用回退作为补充手段。适用场景：强烈建议开启的三种典型情况频繁访问受限境外域名且直连解析长期失效当用户日常需要访问的境外技术文档、开源社区或社交媒体域名在直连DNS下持续无法解析，而通过代理节点手动测试该域名解析正常时，开启dns-direct-fallback-proxy能够自动将失败的解析请求转由代理通道完成，无需用户手动切换DNS或修改hosts文件。这种场景下的用户最直接受益于回退机制，因为它针对的就是直连解析失败这一核心痛点，且开启后用户的访问习惯和节点选择无需任何调整，即可获得更稳定的域名解析结果。处于公共网络或运营商DNS频繁劫持的环境中如果用户经常出差或旅行，频繁连接酒店、会议中心、校园网等公共Wi-Fi网络，这些网络往往存在DNS劫持或解析限制问题，开启回退功能可以确保代理服务在任何受限网络下保持域名解析能力，避免因网络环境变更导致代理不可用。对于需要频繁切换网络环境的移动用户而言，dns-direct-fallback-proxy提供了一层自动化的环境适配，降低了每次切换网络后手动调整DNS设置或测试解析的维护成本。使用规则模式且GEOIP规则匹配频繁出现偏差当用户在规则模式下发现部分境外网站的流量未能正确进入代理通道，且排查配置规则无误后问题仍存在，可尝试开启dns-direct-fallback-proxy。回退机制通过代理解析获取真实的境外IP地址，使GEOIP,CN规则能够准确判断目标IP归属地，从而将正确的流量导向代理通道。如果开启后分流准确性明显提升，则说明直连DNS污染是此前分流失效的根本原因，用户应保持开启状态并定期检查解析质量。决策指南：根据自身需求选择开启或保持关闭日常综合上网用户建议保持默认关闭对于大多数只访问常规境外社交、视频和搜索服务，且当前网络环境下直连DNS解析正常的用户，dns-direct-fallback-proxy的功能价值有限。默认关闭状态下，直连DNS快速完成解析，访问速度最优，且不会额外增加隐私风险。只有当用户明确遇到“DNS解析失败”或特定域名无法解析的报错时，才有必要考虑开启此开关。优先建议用户先尝试更换dns-server为国内公共DNS或境外DNS来改善直连解析效果，将回退功能作为最后一道防线而非首选方案。重度境外访问及技术工作者强烈建议开启对于需要频繁访问开源代码仓库、技术论坛、开发者文档以及各类被限制域名且这些域名在直连解析下频繁失败的用户，开启dns-direct-fallback-proxy能够显著提升访问的可靠性和规则分流精度。这类用户对访问稳定性的要求高于对首屏加载速度的极致追求，且其访问的域名列表往往涉及大量境外地址，直连DNS污染的概率较高，回退机制提供的解析容错价值明显超过其延迟成本和隐私代价。开启后仍需配合配置文件中的DNS规则协同工作即使开启了dns-direct-fallback-proxy，如果配置文件中的DNS规则区块已为特定域名指定了直连或拒绝策略，回退机制可能因规则层级的限制而无法生效。用户应在配置文件中确保不存在针对目标域名的强制直连DNS规则，并在Shadowrocket的DNS设置中保持“通过代理更新DNS”等相关选项与回退功能协调一致，避免因规则冲突导致回退机制被意外屏蔽。正确的做法是将此功能作为全局兜底策略，与规则模式中的远程DNS或DNSoverHTTPS功能互补使用，而非相互替代。常见问题FAQ

dns-server填了多个DNS地址，是并发的还是顺序的？

在Shadowrocket的dns-server配置中，填入多个DNS地址时执行的是并发查询机制，所有服务器同时发起请求，应用采纳第一个成功返回有效响应的结果，其余响应则被丢弃。这一机制能够在提升解析速度的同时提供容错冗余，但要求用户必须确保所填DNS服务器属于同一解析阵营，绝不可将国内公共DNS与境外DNS混用，否则国内DNS因响应速度领先会率先返回被污染的虚假IP，而境外DNS的抗污染优势因响应较慢被完全抵消，导致境外网站解析异常。正确的配置策略是国内访问为主且依赖规则分流的用户使用双国内DNS组合如“223.5.5.5,119.29.29.29”，利用并发冗余加速国内CDN调度并增强容错；对境外访问解析精度要求较高的用户则单独使用单境外DNS如“1.1.1.1”以避免污染；通过场景功能在不同网络环境切换DNS策略则可实现两者的动态平衡。配置完成后，应通过连接日志验证实际采用的DNS服务器IP，确认解析速度与正确性符合预期，并定期检查DNS响应质量，及时调整组合以适应网络环境的变化。并发查询机制的核心原理与执行逻辑Shadowrocket内置并发DNS查询引擎的工作方式当用户在Shadowrocket的DNS覆写或配置文件中填写多个DNS服务器地址时，应用内部会启动一个并行查询引擎，该引擎会同时向列表中的所有DNS服务器发送相同的域名解析请求。每个查询独立进行，互不阻塞，应用会等待最先返回有效解析结果的服务器，并立即采纳该结果用于后续的网络连接，同时自动取消或忽略其余尚未完成的查询。这一并发机制与传统的顺序查询（逐个尝试直至超时）有本质区别，其设计目标是在保证解析速度最大化的同时提供一定的容错能力，确保单个DNS服务器的延迟波动或临时故障不会拖累整个解析流程。并发查询中的超时与响应处理策略在并发查询过程中，Shadowrocket为每个DNS请求设置了统一的超时时间窗口，通常为2至5秒。如果在超时窗口内没有任何DNS服务器返回有效响应，应用会判定DNS解析失败并返回错误。一旦有某台服务器率先返回了包含有效A记录或AAAA记录的响应，应用会立即采用该IP地址并关闭其他正在进行的查询通道，不会等待其他服务器的响应，也不会对后续到达的结果进行任何比较或筛选。这种“先到先得”的策略最大化了解析速度，但也意味着如果最快响应的服务器返回了错误或非预期的IP地址，应用也会直接使用，不会因为后续有更正确的结果而重新尝试。并发并不等同于负载均衡或故障转移并发查询与负载均衡（将请求轮流分配给不同服务器）或故障转移（主服务器失败后才切换备用）是完全不同的机制。在并发模式下，所有服务器同时被使用，不存在主备之分，也不存在按比例分配请求的逻辑。每次解析都是一次“竞速”，速度最快的服务器获胜，这意味着解析结果可能在不同时间、不同网络环境下由不同的DNS服务器提供，具有随机性。用户无法通过调整地址列表的顺序来指定优先使用某一台服务器，因为顺序在并发模式下不影响响应顺序，只影响哪些服务器参与并发竞赛。并发查询与顺序查询在实际体验中的差异顺序查询下的延迟累加效应在传统的顺序查询机制中，当用户配置了多个DNS服务器时，应用会按照列表顺序依次尝试。首先向第一个DNS发送请求，如果在规定的超时时间（通常为数秒）内未收到响应，才会切换到第二个DNS继续尝试，依此类推。这意味着如果列表中的第一个DNS服务器网络延迟较高或暂时不可用，用户需要等待完整的超时周期后才能获得解析结果，累积延迟可能达到数秒甚至更长，严重影响网页加载速度。顺序查询在保证可靠性方面有一定作用，但以牺牲速度为代价，尤其当列表中的首选DNS出现问题时体验极差。并发查询将解析时间压缩至最快服务器的响应时间Shadowrocket采用的并发查询机制完全消除了顺序等待的弊端，解析总时间仅取决于所有DNS服务器中响应最快的那一台，而不会受到慢速或超时服务器的拖累。当用户填写了多个DNS地址时，最慢的服务器可能需要数百毫秒才响应，但最快的可能在10毫秒内返回，此时整个解析流程在10毫秒内即告完成，其余服务器的响应被直接忽略。这种机制使得用户无需担心某台DNS临时出现高延迟，因为其他并行服务器能够即时填补，整体的解析稳定性得到了显著提升。并发查询对国内CDN调度的影响由于并发查询采用“先到先得”原则，实际返回解析结果的DNS服务器通常是物理距离最近、网络延迟最低的那一台。在大多数情况下，国内用户填写多个国内DNS时，响应最快的往往是位于同一运营商网络的服务器，其返回的CDN节点IP地址也是针对该用户地理位置优化的最佳节点。但如果用户混入了境外DNS，由于国际延迟较高，境外DNS几乎永远不会在竞速中获胜（除非国内DNS全部超时），因此对CDN调度的影响极小。然而一旦国内DNS因网络波动响应变慢，境外DNS的响应可能在超时窗口内胜出，返回的可能是境外CDN节点，导致国内网站访问变慢。混用国内外DNS是导致解析异常的最常见误区国内DNS率先返回被污染的虚假IP当用户将国内公共DNS（如223.5.5.5）与境外DNS（如1.1.1.1）同时填入dns-server时，并发查询机制会优先采用最先返回的结果。对于被境内防火墙污染的境外域名，国内DNS会快速返回一个被篡改的虚假IP地址，通常在20毫秒内即可响应，而境外DNS虽然能返回正确IP，但因国际延迟需要150毫秒以上。由于国内DNS响应速度远远领先，Shadowrocket会采纳虚假IP并将用户导向错误的目标，导致该境外网站完全无法访问。这种“快而错”的结果使境外DNS的抗污染优势在并发模式下被完全抵消，混用策略适得其反。境外DNS胜出时会导致国内网站跨网访问在极端网络条件下，如果国内DNS服务器恰好出现高延迟或丢包，响应时间可能超过境外DNS，此时境外DNS会率先返回解析结果。对于国内网站域名，境外DNS通常会返回针对海外用户调度的CDN节点IP，这些IP往往位于北美或欧洲，而非国内优化节点。用户访问国内网站时，请求会被路由至海外CDN再回源，造成数倍甚至数十倍的延迟增加，国内网站加载变得极为缓慢。这种偶然性的跨网解析使得网站速度时快时慢，用户体验极不稳定，且问题难以排查，容易被误认为是节点故障。正确的DNS组合策略是保持阵营统一为了避免并发机制下出现“快而错”或“慢而错”的解析异常，用户应确保填写的所有DNS服务器属于同一解析阵营。如果需要国内网站加速和精准CDN调度，应当全部使用国内公共DNS，例如“223.5.5.5,119.29.29.29”，两者均能快速返回正确的国内CDNIP，且解析质量高度一致。如果需要抗DNS污染以访问境外受限网站，则应当只填写一个境外DNS（如“1.1.1.1”），因为并发下多个境外DNS效果相同，且不会与国内DNS形成有害竞赛。绝不可将国内和境外DNS混填，否则无论哪方胜出都无法获得预期的解析效果。针对不同网络需求推荐DNS组合策略日常综合上网首选双国内DNS冗余组合对于绝大多数普通用户而言，日常上网同时需要访问国内网站和境外网站，且主要依赖配置文件中的分流规则进行路由控制，此时最推荐的DNS组合是两个国内公共DNS。用户可以将“223.5.5.5,119.29.29.29”填入dns-server，两款DNS同属国内权威服务商，均支持ECS精准调度，解析国内CDN的结果高度一致且速度极快。并发模式下，响应更快的那一台会率先返回结果，另一台作为冗余备份，当其中一台因网络波动暂时失效时，另一台自动接管，既保证了速度又提升了容错性。这种组合不会引入污染风险，因为国内DNS对境外域名的解析结果虽然可能被污染，但用户的境外访问请求在规则模式下会走代理节点，节点自身会进行远程DNS解析来获取正确IP，本地DNS结果仅用于GEOIP规则判断，对实际代理通道的影响有限。对境外访问解析精度要求高时单独使用境外DNS如果用户主要访问境外服务且对DNS解析的准确性要求极高，希望完全避免任何被污染的风险，应当放弃国内DNS，单独将“1.1.1.1”或“8.8.8.8”填入dns-server。此时所有DNS查询均通过代理节点的加密通道或直接发往境外DNS，不受境内污染干扰，解析到的IP地址均为真实的外网地址。但需注意，单独使用境外DNS会牺牲国内网站的CDN调度精度，国内网站访问速度可能略有下降，因此该策略更适合将全局路由设为“代理”模式的重度境外用户，对于需要平衡国内外访问的普通用户并非最优选择。利用场景功能在不同网络环境切换DNS策略Shadowrocket的场景功能允许用户为不同场景绑定独立的DNS覆写配置，用户可以利用这一特性实现DNS策略的动态切换。在家用Wi-Fi网络下使用双国内DNS组合以获得最快的国内访问速度，在公共Wi-Fi或蜂窝网络下切换至单一境外DNS以增强隐私保护和抗污染能力。通过场景的自动触发或手动切换，用户无需反复修改全局DNS设置，即可在不同网络环境中应用最适合的DNS解析策略，既发挥了并发冗余的优势，又规避了混用带来的潜在问题。验证并发生效状态的实操方法通过连接日志确认实际采用的DNS服务器用户开启Shadowrocket的连接日志功能后访问任意网站，在日志的解析记录行中可以看到“DNS查询”或“DNS响应”条目，其中会明确标注本次解析实际采用的DNS服务器IP地址。通过多次访问不同域名并观察日志，用户可以统计出在自己的网络环境中哪一台DNS服务器响应最快、被采用频率最高，从而验证并发机制的实际运行效果。如果日志中频繁出现某一特定IP地址，说明该DNS服务器在并发竞速中持续胜出，反之偶尔出现的IP则说明该服务器在特定网络条件下也能赢得竞速。使用网络诊断工具对比单服务器与多服务器解析时间用户可以先单独填入一台DNS服务器（如223.5.5.5），在Shadowrocket开启代理后访问固定测试域名并记录页面加载时间，然后切换至双DNS组合（如223.5.5.5,119.29.29.29）重复测试。对比两次加载时间，如果双DNS组合下的加载速度明显加快或更加稳定，说明并发冗余带来了实际体验的提升。如果无明显差异，则说明单台DNS已足够满足当前网络环境的需求，用户可选择保持单服务器配置以避免不必要的复杂性。模拟DNS故障验证并发冗余的有效性用户可以通过暂时断开网络或使用防火墙规则模拟某台DNS服务器不可用的情况，然后观察Shadowrocket是否能够自动切换至另一台DNS完成解析。例如在Wi-Fi设置中修改路由表或使用代理工具阻塞特定DNS服务器的IP，然后访问一个未被本地缓存的域名，检查日志中是否记录到了另一台DNS服务器的成功响应。如果并发冗余配置正确，应用会在首台DNS超时后立即采用次快服务器的结果，解析不会失败，页面正常加载，从而验证并发机制在故障场景下的容错能力。与分流规则协同时的注意事项本地DNS解析结果影响GEOIP规则的匹配Shadowrocket的规则模式中，GEOIP,CN,DIRECT规则依赖于目标IP的归属地判断，而这个IP正是由dns-server配置的DNS服务器解析得到的。当用户同时填写了223.5.5.5和119.29.29.29时，对于国内网站的解析，两者都会返回国内IP，因此GEOIP规则正常工作，国内流量直连。对于境外网站，返回的IP可能是国外地址（如果未被污染），GEOIP规则会判定为非CN，从而走代理。但如果DNS被污染返回了国内IP，则GEOIP规则会错误地将该境外网站判定为国内流量而直连，导致访问失败。因此，用户需清楚DNS解析结果直接影响规则引擎的路由决策。代理节点的远程DNS解析可以覆盖本地DNS结果当配置文件中策略组引用的代理节点启用了“远程DNS”或“通过代理解析”选项时，该节点会在代理服务器端进行独立的DNS查询，其解析结果用于实际的数据转发，而本地dns-server解析的IP仅用于规则匹配（如GEOIP）。这意味着即使本地DNS被污染返回了错误IP，代理节点仍然可以通过远程解析获取正确IP并完成访问。因此，对于使用规则模式且节点支持远程DNS的用户，国内DNS组合的污染问题对实际访问的影响会被远程解析机制缓解，用户可安心使用双国内DNS享受加速优势。DNS覆写配置应与配置文件中的DNS规则保持一致部分高级配置文件中会包含独立的DNS规则区块，用于为特定域名指定不同的DNS服务器。如果用户同时配置了全局dns-server和配置文件内的DNS规则，两者的执行顺序存在明确层级：配置文件中的DNS规则优先级高于全局dns-server。用户应确保全局DNS组合与配置文件DNS规则中的服务器属于同一解析阵营，避免出现全局使用国内DNS而规则中为境外域名指定了境外DNS（此时并发逻辑在不同层级分别执行，互不干扰）的情况，造成规则执行结果与预期不符。常见问题FAQ

Shadowrocket DNS覆写用223.5.5.5还是119.29.29.29好？

在Shadowrocket的DNS覆写设置中，223.5.5.5和119.29.29.29在基础性能、解析成功率、ECS精准调度以及对分流规则的影响上表现高度接近，两者的差异不足以让普通用户在日常使用中感受到明显的优劣势差别，选择的核心依据应围绕自身日常访问的主要服务生态和本地运营商的网络兼容性。若用户大量使用阿里系应用，223.5.5.5的同生态解析调度可能带来边缘优势；若日常深度依赖微信或腾讯系游戏，119.29.29.29则可能更为顺手。最稳妥且实用的做法是将两款DNS同时填入覆写字段，以“223.5.5.5,119.29.29.29”的顺序配置，让设备优先使用阿里DNS并在其不可用时自动切换至DNSPod，实现冗余容错与生态互补。配置完成后需通过连接日志验证DNS覆写已生效，并将该配置保存至常用的场景中。若后续遇到特定域名解析缓慢或返回错误IP的极个别情况，可临时清空DNS覆写回退至系统默认DNS，或切换至加密DNS方案来规避国内明文DNS在抗污染能力上的共同短板。两款DNS的选择不应对日常代理体验产生决定性影响，将更多注意力放在节点质量和配置文件的分流规则优化上，比在DNS数值间反复纠结更能有效提升整体网络访问体验。两家国内公共DNS的核心性能与定位对比阿里DNS与DNSPod在基础设施层面的差异223.5.5.5隶属于阿里巴巴集团，依托阿里云遍布全球的机房资源和强大的BGP网络调度能力，其在国内的解析响应速度长期位居前列，尤其对阿里系生态内的服务（如淘宝、钉钉、阿里云）有着天然的解析优化。119.29.29.29则归属于腾讯云DNSPod，作为国内最早提供公共DNS服务的厂商之一，其在解析稳定性和节点覆盖上同样出色，特别对腾讯系应用（如微信、腾讯云、游戏）有着深度的调度优化。两者的基础设施均达到了运营商级别的可靠性，但在极个别边缘节点或特定运营商线路上，解析延迟可能存在毫秒级的细微差异，这种差异通常远低于用户感知阈值。两款DNS在基础延迟与解析成功率上的实际表现从全国范围的实测数据来看，223.5.5.5和119.29.29.29的解析响应时间均稳定在10至30毫秒之间，解析成功率常年保持在99.9%以上，两者在纯解析性能上难分伯仲。对于身处南方电信或北方联通等主流运营网络的用户，两者的表现几乎一致，用户无法通过日常网页加载速度感知到两者之间的差异。只有在部分小众运营商或跨网调度场景下，由于各厂商的骨干网出口策略不同，解析结果的IP质量才可能出现差异，导致访问特定服务时的加载速度有所不同。选择应基于网络环境而非单纯的性能数字既然两者的基础性能极为接近，用户在选择时不应过分纠结于理论上的延迟数值，而应更多地考虑自身所处的网络环境和日常访问的主要服务。如果用户的网络本身存在频繁的丢包或高延迟，更换DNS带来的解析时间优化对比网络自身的传输延迟几乎可以忽略不计。因此，将选择焦点放在解析结果的精准度以及对特定生态服务的适配性上，远比执着于毫秒级的性能差异更有实际意义。ECS（EDNS客户端子网）支持对国内CDN加速的影响ECS功能精准度决定国内资源的加载速度ECS（EDNSClientSubnet）功能允许DNS服务器在解析域名时获取用户的大致地理位置信息，从而返回离用户最近的CDN节点IP地址，这一机制对国内视频网站、应用商店下载和云服务的加速至关重要。223.5.5.5依托阿里云在全国超过三十个可用区部署的解析节点，能够精确识别用户的运营商和所在城市，返回的CDN调度结果往往能精确到市级范围。119.29.29.29同样具备完善的ECS支持，借助腾讯云广泛的边缘节点网络，其在国内主要城市的解析精度同样达到市级水准，对于主流网站和应用的加速效果与前者不相上下。对跨运营商访问的解析优化差异在跨网访问场景下（如电信用户访问联通机房的服务器），ECS功能收集到的用户IP段信息会被DNS服务器用来选择最优的跨网边界节点。223.5.5.5因阿里云拥有丰富的BGP带宽储备，在跨网解析调度上积累了较多的优化经验，能够有效降低跨运营商访问时的跳数。119.29.29.29则依托DNSPod长期深耕DNS领域的调度算法，在复杂的跨网环境中同样表现稳定，能够返回相对均衡的CDNIP。实际体验中，两款DNS在跨网场景下的差异仅在网络高峰期或特定区域才会显现，普通用户在日常使用中很难通过主观感受区分。海外CDN解析结果受ECS影响返回边缘节点当访问使用了全球CDN加速的境外服务时，ECS功能会向权威DNS服务器传递用户的IP段信息，从而帮助CDN系统判断应将用户调度到哪个地理区域的边缘节点。223.5.5.5由于是国内DNS，其传递的ECS信息会被境外CDN识别为中国用户，通常返回香港、日本或新加坡等邻近地区的节点IP。119.29.29.29的行为逻辑完全一致，两者在海外CDN解析上的表现高度趋同，因为决定调度结果的并非DNS服务商本身，而是目标CDN系统对ECS信息的响应策略，两款DNS仅作为信息的传递者。两款DNS在代理环境下对分流规则的影响DNS解析结果直接决定GEOIP规则的命中判断在Shadowrocket的规则模式下，当配置文件中包含GEOIP,CN,DIRECT规则时，规则引擎会根据目标IP是否属于中国IP段来决定是否直连。如果DNS覆写使用的223.5.5.5或119.29.29.29对某个境外域名返回了国内CDN的IP地址（这在国内网站访问中是完全正常的），则该请求会因为IP归属地判定为国内而走直连通道。两款DNS都会在国内网站解析时返回国内IP，在境外网站解析时返回境外IP，在这个维度上两者的行为完全一致，不会因选择不同而导致分流逻辑出现差异。对代理域名的解析结果影响策略组节点选择当配置文件中为特定境外服务配置了策略组并绑定了多个代理节点时，DNS解析返回的IP质量决定了策略组在“自动选择”或“延迟最低”模式下测得的延迟数值。223.5.5.5和119.29.29.29均为国内权威DNS，对境外域名的解析都会返回该域名在全球范围内的最优IP之一，而不是像某些境外DNS那样可能返回针对海外用户调度的IP。因此两款DNS解析出的境外目标IP都能被Shadowrocket的代理节点正常访问，不会因解析到错误IP而导致策略组频繁切换或误判。两款DNS均不会主动拦截或污染合规域名作为国内合法运营的公共DNS服务，223.5.5.5和119.29.29.29均会按照中国法律法规要求对部分境内外的非法域名实施解析阻断。这意味着对于某些在境内被屏蔽的境外域名，无论使用哪一款DNS，都无法获取到正确的IP地址，解析结果可能为空或被指向无效地址。在这种情况下，用户需要依赖代理节点自身的DNS解析功能（如远程DNS）来绕过本地DNS的限制，单纯更换国内公共DNS无法解决这一问题，两款DNS在该场景下表现完全一致。DNS污染与劫持场景下的抗干扰能力对比明文DNS在污染面前的天然弱势与两家的差异223.5.5.5和119.29.29.29均使用标准的UDP53端口明文传输DNS查询请求，这种协议特性决定了它们都无法抵抗针对特定域名的DNS污染攻击。当网络中间节点（如运营商）对特定境外域名实施伪造应答时，两款DNS返回的正确结果都会被污染数据包覆盖，用户设备最终收到的是被篡改的错误IP。两者在抗污染能力上处于同一水平线，因为它们都依赖于明文传输协议，没有像DoH或DoT那样的加密隧道来保护查询过程免受中间人篡改。在运营商劫持场景下的表现差异部分地区的网络运营商会将无法解析或解析失败的域名请求劫持至广告页面或搜索引导页，这种现象在用户输入不存在的域名时尤为常见。223.5.5.5和119.29.29.29作为第三方公共DNS，在解析正常域名时的响应权威性高于运营商默认DNS，能够有效减少因运营商DNS缓存污染导致的解析错误和劫持。两款DNS对NXDOMAIN（域名不存在）响应均返回标准的空结果而非劫持IP，因此在对抗运营商劫持方面两者都能发挥显著的改善作用。加密DNS作为补充方案的必要性如果用户所处的网络环境存在严重的DNS干扰或需要访问高度受限的境外服务，那么无论选择223.5.5.5还是119.29.29.29，都无法从根本上解决DNS污染和阻断问题。此时用户必须在Shadowrocket的DNS设置中配置DoH（DNSoverHTTPS）或DoT（DNSoverTLS），并指向境外加密DNS服务商，才能确保解析请求的完整性和私密性。两款国内DNS在抗干扰维度上的差异极小，用户在两者之间做选择不应以抗污染能力作为主要考量，而应将加密DNS作为应对此类问题的技术储备。根据网络环境和需求选择合适DNS的策略优先基于运营商网络选择同生态DNS对于大多数普通用户而言，在这两款DNS之间选择时可以遵循“哪个快就用哪个”的简单原则——分别在设备上设置223.5.5.5和119.29.29.29，通过访问国内主流网站或使用网络测速工具对比页面的首屏加载速度，选择感觉更流畅的那个。如果用户是阿里云或淘宝的重度用户，223.5.5.5可能因同生态调度优势带来细微加速；如果是腾讯游戏或微信的频繁使用者，119.29.29.29则可能提供更优的解析结果。这种基于自身使用习惯的选择比单纯依赖评测数据更为实用。将其中一款设置为主DNS另一款设为备用在实际配置中，用户不必局限于单一选择，可以在Shadowrocket的DNS覆写字段中同时填写两个IP地址，将223.5.5.5设置为主要DNS，119.29.29.29设置为次要DNS。当主DNS在极个别情况下出现解析超时或服务器不可用时，设备会自动切换到备用DNS完成解析，这种冗余配置既保留了两款DNS的优点，又规避了单点故障风险，提升了整体解析的可靠性和容错能力。结合使用场景动态切换DNS策略如果用户在不同网络环境（家庭Wi-Fi、公司网络、蜂窝数据）中的解析体验存在明显差异，可以利用Shadowrocket的场景功能为不同场景绑定不同的DNS覆写配置。例如在家庭网络中使用119.29.29.29配合腾讯系服务加速，在移动网络中使用223.5.5.5配合阿里系加速，通过场景切换实现DNS策略的动态调整。这种灵活的配置方式充分发挥了两款DNS各自的生态优势，避免了固定使用某一款而牺牲部分场景下的解析质量。在Shadowrocket中配置与验证DNS覆写的操作要点正确填写DNS覆写字段并保存配置用户进入Shadowrocket的“设置”页面，找到“DNS覆写”或“自定义DNS”输入框，将选定的DNS服务器地址（单个或多个用逗号分隔）填入该字段。填写后需确保输入格式正确，例如“223.5.5.5,119.29.29.29”，避免在IP地址之间添加多余的空格或中文符号。保存设置后，该DNS配置立即生效，所有经过Shadowrocket处理的DNS查询请求都将优先使用覆写指定的服务器，而非设备系统默认的运营商DNS。配置完成后验证生效状态与解析效果为了确认DNS覆写已正确生效，用户可在Shadowrocket开启代理后访问国内知名网站的IP检测页面，同时开启应用内的连接日志功能。在日志中查找DNS解析条目，如果显示的DNS服务器地址为223.5.5.5或119.29.29.29，则说明覆写配置已成功。访问“http://ip.sb”等网站观察网页加载速度，与使用运营商DNS时的速度进行对比，如果解析环节的延迟有所降低或CDN调度结果更优，即可确认所选DNS对当前网络环境具有正向改善效果。遇到解析异常时的快速回退方案如果在使用223.5.5.5或119.29.29.29后遇到部分网站无法打开或解析缓慢的异常情况，用户可以立即回到DNS覆写设置页面清空输入框，使设备恢复使用运营商默认DNS或系统DNS。这种快速回退机制确保了用户可以在两款DNS之间灵活切换或完全放弃使用第三方DNS，而不会因DNS配置问题影响基本的网络访问能力。在确认具体哪款DNS导致问题后，可以选择另一款单独使用或继续回退至默认DNS，保持网络访问的持续可用性。常见问题FAQ

Shadowrocket分应用代理模式和规则模式能同时用吗？

在Shadowrocket中，分应用代理模式和规则模式不仅可以同时启用，而且在实际使用中遵循“分应用优先、规则兜底”的协同逻辑，两者在功能定位上互补而非冲突。分应用代理在系统进程层面依据应用包名进行路由决策，其执行顺序在规则引擎之前，具有绝对优先级，当按需求连接中为某应用配置了策略时，该应用的流量直接按该策略处理，完全跳过规则引擎的域名和IP匹配，即使配置文件中包含冲突规则也不生效。同时启用两种模式时，用户需在“设置→按需求连接”中为特定应用配置策略，并保持主界面的全局路由为“配置”模式以激活规则引擎，此时按需求连接覆盖的应用执行分应用策略，未覆盖的所有应用流量进入规则引擎按域名和IP规则进行智能分流，两者在流量处理管道中无缝衔接。日常使用建议以规则模式为核心分流框架，仅在银行App、特定游戏或内网工具等极少数应用需要强制直连或强制代理时才在按需求连接中添加对应的分应用策略，以此实现“通用分流精准化、特殊应用可控化”的最佳平衡。如需验证两者的实际生效情况，开启连接日志查看每个请求标注的策略来源，即可明确区分是该请求走了分应用代理还是规则模式。场景配置中可将两种模式的不同组合保存为独立场景，以便在不同网络环境下快速切换整体的管控策略组合。两种模式在功能定位上的本质区别分应用代理基于应用包名进行进程级决策Shadowrocket的分应用代理功能（通常体现为“按需求连接”中的应用规则）是在系统进程层面进行流量捕获和路由判断，它依据的是每个网络请求所属的应用包名或应用名称，而非请求的目标域名或IP地址。当用户为微信App设置为“直连”策略时，所有由微信进程发出的网络请求，无论目标是国内还是境外服务器，均被直接标记为直连通道。这一决策发生在流量进入规则引擎之前，完全绕过了后续的所有域名和IP匹配逻辑，是基于“谁发起的请求”而非“请求去往哪里”的粗粒度管控。规则模式基于域名和IP进行网络特征匹配规则模式（全局路由设为“配置”）则是依托配置文件中的规则列表进行逐条匹配，匹配的依据是每个请求的目标域名、目标IP地址所属的地理位置或IP段范围。例如DOMAIN-SUFFIX,google.com,PROXY规则匹配的是目标域名的后缀，GEOIP,CN,DIRECT匹配的是目标IP归属地。这种决策完全独立于发起请求的应用是哪个，仅关注“请求要去哪里”，是一种基于网络层特征的细粒度分流机制。两种模式的工作维度完全不同，一个关注“谁在发”，一个关注“发给谁”。两种机制在网络协议栈中处于不同层级分应用代理的拦截点位于iOS系统的网络扩展框架层，在应用进程发出请求后、数据包进入Shadowrocket的处理管道之前即被执行。规则模式的匹配则发生在数据包已经进入Shadowrocket的内部管道后，此时应用层信息已被剥离或标记，规则引擎仅看到目标地址和协议类型。由于分应用代理在更早的阶段介入，其决策结果在逻辑上位于规则引擎的上游，这种层级差异决定了两者在同时启用时的优先级顺序。两者同时启用时的执行顺序与优先级规则分应用代理的决策优先于规则模式的域名匹配当用户同时开启了分应用代理（即在“按需求连接”中为特定应用配置了策略）并保持全局路由为“配置”模式时，Shadowrocket的实际执行顺序是：首先检查当前请求所属的应用是否在按需求连接列表中配置了策略。如果配置了，则直接应用该策略，并且完全跳过后续的规则引擎评估，不再执行任何域名或IP规则的匹配。这意味着即使配置文件中包含了对该应用目标域名的代理规则，只要按需求连接中将其设为直连，该应用的请求仍会直连，规则模式中的对应规则不会生效。冲突场景下分应用代理的设置覆盖规则模式当两者的策略方向发生冲突时，分应用代理拥有绝对优先级。例如用户在按需求连接中将YouTubeApp设为“直连”，同时在配置文件中添加了DOMAIN-SUFFIX,youtube.com,PROXY的代理规则，此时打开YouTubeApp产生的所有网络请求都会直连，配置规则完全不生效。这种覆盖机制确保了用户对特定应用的管控意图不受全局分流规则的干扰，但也要求用户在同时使用两种模式时必须清楚分应用代理的“一票否决权”，避免配置规则时产生预期之外的覆盖。规则模式处理分应用代理未拦截的剩余流量分应用代理仅对在“按需求连接”列表中明确配置了策略的应用生效，对于所有未在该列表中配置策略的应用，其流量不受分应用代理的干预，完整进入规则引擎的匹配流程。这意味着用户可以将分应用代理作为一种“特例处理”工具，强制某些关键应用（如网银App、内网办公应用）直连或走特定代理，而其余所有应用的流量完全交给规则模式按域名和IP进行精细化分流。两种模式在这种场景下形成了“特例覆盖+通用分流”的互补关系，而非互斥关系。实际使用场景中的协同工作方式精细化管控策略搭配全局分流框架用户可以利用分应用代理为少数特殊应用设定强制路由策略，同时保持规则模式处理其余所有流量的通用分流。例如将银行类App设置为强制直连，避免金融交易数据经过不可控的代理节点；将游戏App设置为强制代理以优化游戏延迟；而微信、浏览器等通用应用则交由规则模式根据目标域名自动判断是直连还是走代理。这种组合方案既满足了个别应用的严格路由要求，又保留了规则模式对绝大多数流量的智能分流能力，是两者协同的最佳实践。规则模式作为兜底处理分应用代理未覆盖的所有请求当用户仅对少量应用配置了按需求连接策略，而全局路由保持在“配置”模式时，所有未被按需求连接匹配的应用流量会正常进入规则引擎。此时规则模式中的FINAL兜底规则（通常设为PROXY）确保未被任何规则显式匹配的境外请求走代理，而GEOIP,CN,DIRECT规则保障国内网站直连。分应用代理没有配置的应用数量越多，规则模式承担的分流任务就越重，两者在逻辑上无缝衔接，不会出现流量因未匹配任何策略而丢失的情况。场景化配置中两者的动态组合用户可以在不同的场景中分别决定是否启用分应用代理以及如何与规则模式组合。例如在“家庭”场景中同时开启分应用代理（仅让NetflixApp强制走代理）和规则模式（其余流量按规则分流）；在“办公”场景中关闭分应用代理，完全依赖规则模式处理所有流量；在“公共Wi-Fi”场景中启用分应用代理将浏览器以外的所有应用强制直连，仅浏览器流量进入规则模式。通过场景功能结合两种模式的开关状态，用户可为不同网络环境定制差异化的组合策略。同时启用时的典型配置方法与注意事项在“按需求连接”中为应用指定策略并保持全局路由为配置模式实现两者同时启用的前提是：进入Shadowrocket的“设置→按需求连接”页面，开启该功能并添加需要特殊管控的应用，分别为其选择“代理”、“直连”或“拒绝”策略。同时确保主界面的全局路由下拉菜单保持在“配置”模式（即规则模式），不可切换至“代理”或“直连”，否则规则引擎不会被激活，分应用代理将独自决定所有流量的路由，规则模式无法发挥任何作用。避免为系统关键应用设置冲突的代理策略分应用代理的优先级高于规则模式，如果用户误将系统关键应用（如“设置”、“AppStore”）设置为“代理”而当前节点不可用，可能会导致系统更新、应用下载等关键服务失效。同时，若将某些依赖本地网络的服务（如“文件”App访问局域网NAS）设置为“代理”，可能导致内网资源无法访问。建议只在按需求连接中配置非系统级的常规应用，且尽量以“直连”策略为主，代理策略仅针对明确需要翻墙的应用，避免影响系统基础功能。分应用代理的策略不会因配置文件切换而失效按需求连接中配置的应用策略是独立于配置文件的全局设置，不会因为用户切换了不同的配置文件或场景而改变。这意味着用户即使更换了规则集或配置，之前设定的银行App直连策略依然有效，无需重复配置。这种持久性确保了应用级别的管控意图始终得到执行，不会因分流规则的调整而意外失效，但也要求用户在修改配置文件规则时记住分应用代理的存在，避免在规则中做出与分应用策略冲突的修改而无法生效。两者冲突时的判定逻辑与验证方法通过连接日志查看实际生效的决策依据当用户不确定某个应用的流量是走了分应用代理的策略还是规则模式的规则时，可开启Shadowrocket的连接日志功能并打开该应用触发网络请求。日志中每个连接记录会明确标注该请求的来源应用、目标域名以及最终执行的策略名称。如果日志显示策略来源为“按需求连接”或直接标注了“应用规则”，则说明该请求被分应用代理拦截并决策；如果显示匹配了某条DOMAIN-SUFFIX规则，则说明该请求进入了规则引擎处理。日志是区分两者实际生效情况的最直接工具。IP出口验证确认应用是否真正走了预期通道除了日志查看外，用户还可通过访问IP检测网站来验证应用的出口IP。在被测试应用内打开浏览器访问http://ipinfo.io，查看显示的IP地址是代理节点IP还是本地网络IP，结合该应用在按需求连接中的策略和规则模式中的规则进行判断。如果策略设为直连但出口IP为代理IP，说明规则模式可能覆盖了分应用代理（但实际不会发生）；如果策略设为代理但出口IP为本地IP，则需检查按需求连接是否生效或节点是否连通。按需求连接的“直连”设置会无视配置规则当按需求连接中某应用被设为“直连”时，该应用的所有请求在日志中会显示直接匹配了“按需求连接-直连”策略，且完全不会在规则引擎中留下匹配记录，即使配置文件中包含该域名的PROXY规则，日志中也不会有该规则的命中记录。这种现象确认了分应用代理的绝对优先级，用户在排障时应优先检查按需求连接中的策略设定，而非在规则模式中反复寻找原因。综合建议与最佳实践日常使用以规则模式为主，分应用代理为辅对于绝大多数用户而言，规则模式已经能够满足国内直连、国际代理的分流需求，无需额外配置分应用代理。仅在个别应用需要强制直连（如银行App）或强制代理（如特定游戏）时，才在按需求连接中为该应用单独配置策略。这种“默认规则分流、特例应用管制”的组合既保持了配置的简洁性，又实现了特殊需求的精准满足。分应用代理的优先级决定其应谨慎配置由于分应用代理的策略会完全覆盖规则模式中对应的域名规则，用户在配置按需求连接时应充分理解这一优先级关系，避免因为随意设置代理或直连策略而导致意料之外的路由行为。建议在添加按需求连接规则时先通过日志确认该应用的流量当前在规则模式下是如何处理的，再决定是否需要通过分应用代理进行强制覆盖，而非盲目添加规则。多场景下的灵活组合提升使用效率用户可以在不同场景中启用或禁用按需求连接功能，或保留相同的按需求连接配置但切换不同的配置文件，实现分应用策略与规则策略的多样化组合。例如在家庭场景中保留银行App直连的按需求规则并加载通用配置，在办公场景中同样保留该规则但加载专门优化内网访问的配置，使相同的分应用策略在不同规则框架下发挥差异化的整体效果。常见问题FAQ

Shadowrocket场景模式（场景）功能怎么用？

Shadowrocket的场景模式是一项将节点、配置文件、全局路由模式和按需求连接规则打包整合的一键切换机制，用户通过创建多个场景来应对不同网络环境和使用需求下的差异化代理配置。创建场景时进入场景管理界面点击加号，为场景命名后分别绑定目标节点、目标配置文件以及所需的全局路由模式，并可选关联按需求连接规则，保存后即生成一个完整的配置方案。手动切换时在场景列表中点击场景名称即可立即应用该场景的全部设置，主界面顶部信息栏同步更新为当前激活的场景信息。场景还支持基于Wi-Fi网络名称SSID的自动触发，用户为场景绑定家庭或公司Wi-Fi名称后，设备连接至对应网络时Shadowrocket自动切换场景，实现完全无感的配置变更。对于需要精细管理的用户，可为家庭网络、办公环境、蜂窝数据和特定应用分别创建场景并绑定差异化配置，在需要时通过手动点击或自动触发完成切换，减少日常使用中重复调整节点和配置的频率。场景的配置信息随配置文件的导出和导入一同备份，用户可通过iCloud或AirDrop在不同设备间迁移场景定义，但需确保目标设备上的节点列表与场景绑定一致，否则切换后可能出现无可用节点的错误。场景切换不会自动开启代理开关，用户需保持代理常开或切换后手动开启，且场景预设会覆盖主界面手动选择的节点，用户如需临时调整可在场景切换后再行修改节点。该功能的自动化特性显著降低了多环境用户的维护成本，让Shadowrocket在不同的网络条件下始终保持最优的代理配置方案。场景模式的功能定位与核心价值场景是一套完整配置方案的一键切换机制Shadowrocket的场景模式（Scene）本质上是一个多维度配置快照的集中管理入口，它将用户在特定网络环境下的全部设置——包括当前选中的节点、激活的配置文件、全局路由模式以及“按需求连接”规则——打包成一个独立的场景单元。用户在配置好一套完整的代理方案后，将其保存为一个场景并赋予名称（如“办公室”、“家庭”、“蜂窝网络”），此后只需在场景列表中点击该场景名称，应用便会自动恢复当时保存的所有设置，实现整套网络配置的一键切换。这种机制避免了用户在不同网络环境间移动时需要逐个调整节点、切换配置、修改全局路由模式的繁琐操作。场景与配置文件是不同层面的管理概念尽管场景的切换会联动加载对应的配置文件，但两者并非同一概念。配置文件是一组规则集合和策略组定义的静态文件，决定了“流量如何分流”；而场景则在配置文件之上叠加了节点选择、全局路由模式和按需求连接规则等动态设置，决定了“当前使用的完整代理状态”。用户可以基于同一份配置文件创建多个场景，每个场景绑定不同的节点或不同的全局路由模式，从而在不同使用场景下快速复用同一套分流规则但改变其执行方式。场景模式特别适合多网络环境切换的移动用户对于经常在家庭Wi-Fi、公司办公网络、公共热点和蜂窝数据之间切换的用户而言，场景模式显著提升了代理工具的日常使用效率。用户可以为每个网络环境预设独立的一套配置方案——例如在家庭网络下使用规则模式配合流媒体优化节点，在公司网络下使用全局模式确保所有流量加密，在蜂窝网络下使用轻量级配置以节省流量——当身处不同环境时，仅需一次点击即可完成全部配置的切换，而无需逐一调整节点、配置和模式。创建和配置场景的具体操作步骤进入场景管理界面并创建新场景用户在Shadowrocket底部导航栏中点击“场景”标签页，进入场景管理界面。初次使用该功能时，列表可能为空或仅包含一个默认场景。用户点击右上角的加号按钮，在弹出的新建场景窗口中首先填写场景名称（如“回家”或“移动网络”），以便后续在列表中快速识别。该名称仅用于本地显示和识别，不影响网络配置的任何功能性。为场景绑定节点、配置和全局路由模式在新建场景的编辑页面中，用户需要从下拉菜单中选择该场景要绑定的核心要素：在“节点”选项中选择此场景下希望使用的代理节点，在“配置”选项中选择该场景激活时要加载的配置文件，在“模式”选项中选择全局路由模式（配置、代理、直连或场景）。这三项是决定网络行为的最基本变量。例如用户可以创建一个“流媒体”场景，绑定日本优化节点、加载包含YouTube代理规则的配置、模式选择“配置”，保存后该场景即代表一个完整可用的流媒体代理方案。关联按需求连接规则与其他高级设置在场景编辑界面的底部，用户还可以选择关联预先配置好的“按需求连接”规则，这些规则指定了特定应用或目标域名在该场景下的代理策略。关联后，当该场景被激活时，相应的按需求连接规则自动生效，无需单独开启。部分版本的Shadowrocket还允许场景保存额外的设置状态，如是否开启UDP转发、是否启用IPv6、DNS配置等高级选项，为用户提供了高度定制化的场景封装能力。用户可根据自身需求逐一勾选并配置。保存场景并验证切换效果完成所有字段的设置后，用户点击右上角的“保存”按钮，新场景即出现在场景列表中。用户可立即点击该场景名称执行切换，Shadowrocket会自动加载绑定的节点和配置、切换全局路由模式并激活按需求连接规则。验证切换效果最直接的方式是观察主界面顶部显示的当前节点名称和配置文件名称是否与场景预设一致，以及访问IP检测网站确认出口IP是否符合预期。如果切换后效果不理想，用户可返回场景编辑页面调整任意绑定项后重新保存。场景的切换方式与触发逻辑手动切换是最直接的使用方式用户在场景列表中选择任意场景并点击，即可立即切换到该场景所保存的完整代理状态。切换过程中，Shadowrocket会按照场景中绑定的配置和节点顺序重新加载所有资源，主界面的顶部信息栏会同步更新为当前激活的场景名称、节点名称和配置文件名称。手动切换的操作路径清晰直观，适合用户在不同时段或不同地点主动调整代理方案时使用。场景可通过Wi-Fi网络名称自动触发切换Shadowrocket的场景功能支持基于Wi-FiSSID的自动触发机制，用户可在场景编辑界面的“触发条件”中指定一个或多个Wi-Fi网络名称（SSID）。当设备连接至该名称的Wi-Fi网络时，Shadowrocket会自动激活对应的场景，无需用户手动操作。例如用户可设置“家庭”场景在连接至家庭路由器SSID时自动生效，“办公室”场景在连接至公司网络时自动生效。自动触发机制使得代理配置的切换完全透明化，用户在不同Wi-Fi网络间移动时无需任何操作即可获得适配当前环境的代理方案。蜂窝网络与特定时间段的自动化切换除了Wi-FiSSID触发外，部分版本的Shadowrocket还支持基于网络类型（蜂窝数据）或特定时间段的自动场景切换。用户可为“移动数据”场景设置触发条件为“网络类型为蜂窝”，当设备断开Wi-Fi并切换至蜂窝网络时自动激活，确保在室外使用流量时有一套轻量且省电的代理配置方案。基于时间的触发则可实现“白天工作模式”和“晚间娱乐模式”的自动轮换，但该功能的具体支持程度因版本而异，用户需查看自己的Shadowrocket版本确认可用选项。场景切换不会影响已开启的代理开关状态当用户切换场景时，Shadowrocket的代理开关状态（开启或关闭）不会被场景切换操作改变。如果代理开关处于开启状态，切换场景会立即应用新场景的节点和配置并继续代理连接；如果代理开关处于关闭状态，切换场景仅更新本地配置状态而不实际连接代理。用户可在代理开关开启时自由切换场景，切换过程中已建立的连接可能会短暂中断并按新场景的配置重新建立，这是正常的行为。场景功能的典型使用场景与配置示例家庭网络场景：规则模式配合流媒体节点用户在家庭Wi-Fi环境下通常需要同时访问国内网站和观看境外流媒体视频。用户可创建“家庭”场景，绑定延迟较低且带宽充足的流媒体优化节点，激活包含完整分流规则的配置文件，全局路由模式设为“配置”。保存后每当在家使用设备时，切换至该场景即可获得国内网站直连、YouTube和Netflix走代理节点的理想分流效果。办公网络场景：全局模式保护公司内网访问安全在公司网络环境下，用户可能连接至内部的邮件服务器和协作工具，同时需要访问境外技术文档。用户可创建“办公”场景，绑定一个隐私保护能力较强的节点，配置文件可选择精简版以避免内网流量被错误分流，全局路由模式设为“代理”（全局模式）。切换至该场景后，所有流量包括内网访问请求均经过加密隧道，有效保护公司网络环境中的通信隐私。蜂窝数据场景：轻量配置节省流量消耗当用户在外出时使用蜂窝数据网络，流量配额有限且网络信号可能不稳定。用户可创建“移动”场景，绑定响应速度快的节点，使用包含精简规则的配置文件以减少不必要的代理请求，全局路由模式设为“配置”。该场景可同时关联“按需求连接”规则，仅让少量关键应用走代理，其他应用直连以节省流量。当设备连接至蜂窝网络时，该场景可通过自动触发功能立即生效。特定应用场景：一键切换至游戏加速状态用户可创建“游戏”场景，绑定专门针对UDP转发优化且延迟极低的节点，加载包含游戏流量代理规则的配置文件，全局路由模式设为“配置”。在该场景的按需求连接规则中，将用户常玩的游戏App设置为强制代理，确保游戏数据包获得最优网络路径。准备玩游戏时切换至该场景，日常使用的代理配置不受影响，游戏结束后切回原场景即可恢复日常设置。场景的备份、导出与跨设备同步场景配置随配置文件导出一并保存当用户执行Shadowrocket的“导出配置”操作时，应用不仅会导出配置文件本身，还会将当前所有已保存的场景定义一并打包至导出文件中。这意味着用户可以通过导出配置文件的方式完整备份自己的场景方案，在重装应用或切换至新设备后，通过“导入配置”即可恢复全部场景定义和绑定的设置。不同设备间通过iCloud或AirDrop同步场景对于使用同一AppleID登录多台iOS设备的用户，Shadowrocket的配置备份文件可通过iCloud云盘或AirDrop传输至另一台设备并导入，实现场景定义的跨设备同步。用户在手机配置好的“家庭”和“办公”场景导入至iPad后，iPad即可获得相同的场景列表和设置，无需在每台设备上重新创建场景。同步时需注意另一台设备上的节点列表是否与场景绑定的节点一致，否则需调整节点引用。场景删除与修改不影响配置文件的内容用户在场景管理界面中删除或修改某个场景时，该场景绑定的配置文件和节点列表不会受到任何影响，配置文件本身仍然完整保存在“配置”标签页中，节点列表也保持不变。场景仅仅是对其他设置的引用组合而非配置的复制品，因此删除场景不会导致配置丢失。用户可大胆尝试创建多个场景并进行调整，随时删除不再需要的场景而不担心影响其他配置。常见问题FAQ

Shadowrocket规则模式下部分网站走不了代理是什么原因？

在Shadowrocket规则模式下部分网站走不了代理时，首先应检查配置文件中规则的排列顺序，确保针对该网站的代理规则或策略组引用位于GEOIP,CN、IP-CIDR,CNIP等直连规则之前，否则该网站的请求可能因匹配了国内IP段规则而被直连。开启连接日志功能，访问该网站后查看日志中显示的匹配规则——如果匹配了DIRECT，则需要调整规则顺序或添加该域名的代理规则；如果匹配了REJECT或REJECT-DROP，则说明被去广告规则拦截，应将代理规则放置在去广告规则之前或直接从规则中排除该域名。检查配置文件的FINAL兜底规则，确认其策略为PROXY而非DIRECT，确保所有未被明确匹配的境外请求都能落入代理通道。对于特定域名的代理规则，确认其规则类型（DOMAIN、DOMAIN-SUFFIX或DOMAIN-KEYWORD）与实际访问的域名格式一致，必要时将DOMAIN改为DOMAIN-SUFFIX以覆盖所有子域名。检查DNS解析结果是否将该域名解析为国内IP，如是则通过更换DNS或为域名指定特定DNS服务器来获取境外IP，避免因IP归属地判定为国内而走直连。如果在规则模式下某个策略组引用的节点不可用或策略组名称与规则中引用的名称不一致，则需检查策略组定义的有效性并更新节点列表或修正名称。经过上述排查后，若该网站仍无法走代理，可尝试在全局模式下确认节点本身工作正常，然后返回规则模式通过逐步禁用部分规则的方式缩小问题范围，最终定位到影响该网站的规则条目并进行针对性修复。日常使用中建议定期更新规则集和CNIP数据库，并保持规则顺序的合理性，以预防部分网站“走不了代理”问题的发生。规则匹配顺序错误导致代理规则被直连规则覆盖直连规则放置在代理规则之前会提前命中Shadowrocket的规则引擎严格按照配置文件中规则列表的先后顺序逐条匹配，一旦某个规则命中，后续规则不再执行。如果用户在配置中将GEOIP,CN,DIRECT或IP-CIDR,CNIP,DIRECT等国内直连规则放置在了针对特定境外域名的代理规则之前，当访问这些境外网站时，如果该网站的服务器IP恰好属于国内IP段或被CNIP数据库收录，请求会优先匹配直连规则而直接走本地网络，完全跳过后面的代理规则。这种顺序错误是导致部分网站“走不了代理”的最常见原因，用户应检查规则顺序，确保所有PROXY规则和策略组引用位于DIRECT规则之前。FINAL兜底规则被设置为直连导致未匹配流量不走代理配置文件中通常会包含一条FINAL或兜底规则，用于处理所有未被前面规则匹配的流量。如果用户将FINAL设置为DIRECT（例如FINAL,DIRECT），那么任何未在规则列表中被明确匹配的域名或IP都将走直连通道。当用户访问的境外网站未被规则明确覆盖时，请求就会落入FINAL的直连范围，表现为走不了代理。用户应检查配置文件的最后一条规则，确保兜底策略为PROXY或指向包含可用节点的策略组，同时将有特殊需求的网站单独添加代理规则。规则顺序调整建议与优先级规划一个合理的配置文件应遵循“特例优先、代理次之、直连再次、兜底代理”的规则排列原则：将最需要精确匹配的规则（如特定域名代理规则、去广告拒绝规则）放在最顶部，随后是GEOIP,CN和CNIP直连规则，然后在FINAL之前放置PROXY兜底规则。用户可在Shadowrocket的配置编辑界面中通过拖动规则条目或点击“排序”功能调整顺序，确保代理规则不会被直连规则提前覆盖，从而使境外网站流量正确进入代理通道。特定域名的代理规则未添加或规则写法不匹配规则集中未包含目标网站的域名当用户依赖社区规则集或通用配置时，这些规则集可能未覆盖某些小众或新建的境外网站。未在规则列表中出现过的域名在匹配流程中找不到对应规则，最终落入FINAL兜底策略，如果兜底策略为直连则导致无法走代理。用户应通过Shadowrocket的连接日志捕获该网站发起的域名请求，然后手动在配置文件中添加该域名的代理规则，确保其路径清晰且位于直连规则之前。域名规则类型选择错误导致匹配失败Shadowrocket支持多种域名规则类型，包括DOMAIN（精确匹配）、DOMAIN-SUFFIX（后缀匹配）和DOMAIN-KEYWORD（关键词匹配）。如果用户将规则写作DOMAIN,example.com,PROXY但实际访问的是www.example.com，则DOMAIN精确匹配无法命中。正确的写法应为DOMAIN-SUFFIX,example.com,PROXY以匹配所有子域名，或DOMAIN,www.example.com,PROXY针对特定子域名。用户应检查规则写法是否与实际的访问域名一致，确保匹配条件正确覆盖目标网站。网站使用IP直连方式完全绕过域名规则部分网站或App在连接阶段直接通过IP地址发起请求而非域名，这类请求在Shadowrocket中无法被任何基于域名的规则（DOMAIN-SUFFIX、DOMAIN-KEYWORD等）匹配，因此即使配置了相应的代理规则也无法生效。处理这类情况需要用户将规则类型调整为IP-CIDR，将该网站或服务所属的IP段纳入代理范围。用户可通过连接日志获取该网站解析到的实际IP地址，或通过nslookup命令查询域名对应的IP段，然后在配置中添加相应的IP-CIDR规则并设为PROXY。策略组配置不当导致节点选择异常策略组引用了无效或不可用的节点当配置文件中将特定域名的流量指向某个策略组而非直接设置为PROXY时，该策略组内部包含的节点列表和选择策略决定了实际使用的代理节点。如果策略组中的所有节点均已失效、超时或不可用，且策略组未配置备用节点或故障转移机制，流量将因无可用节点而无法走代理，可能表现为连接超时或回退至直连。用户应检查策略组中列出的节点是否全部有效，必要时将策略组的节点列表更新为当前可用的节点，或为主策略组添加备用节点实现冗余。策略组的自动选择逻辑选择了高延迟或不可用节点当策略组采用“自动选择”或“延迟最低”策略时，Shadowrocket会定期测试组内所有节点的延迟并自动切换到测试结果最优的节点。如果测试过程因网络波动产生不准确的结果，或某个节点在测试瞬间响应快但实际传输能力差，用户可能被分配到一个表现不佳的节点，导致虽然“走了代理”但速度极慢，主观上误以为是“走不了代理”。用户可手动切换策略组中的节点选择，或临时将策略组的选择策略改为“手动选择”以固定使用某个已知好用的节点。规则中策略组名称与实际配置不一致配置文件中的规则条目可能引用了某个策略组名称，但该名称在配置文件的策略组定义区域中不存在或已被重命名，Shadowrocket在加载配置时无法找到对应的策略组，该规则将失效，流量落入后续规则处理。用户应进入配置编辑界面，核对每个规则引用的策略组名称是否与策略组列表中的名称完全一致，大小写敏感。修正不一致的引用后重新加载配置即可恢复。DNS解析环节将域名解析至国内IP导致路由错误境外网站使用了国内CDN节点回源地址部分国际网站在国内部署了CDN加速节点，当用户通过国内DNS服务器解析该网站域名时，返回的是国内CDN节点的IP地址而非境外源站地址。Shadowrocket的规则引擎根据目标IP地址进行路由决策，如果该IP属于国内IP段且GEOIP,CN,DIRECT规则位于代理规则之前，则该请求会被判定为“国内流量”而走直连。用户即使配置了该域名的代理规则，也因DNS返回的IP归属地问题导致规则被覆盖。解决方法是在配置文件中为特定域名指定DNS解析服务器，强制使用境外DNS获取原始IP地址。DNS解析结果受到运营商DNS污染的影响国内部分网络运营商的DNS服务器对境外域名实施污染，返回错误的IP地址或屏蔽解析请求，导致Shadowrocket无法获取到目标网站的真实IP，即使规则指定走代理，连接也可能因DNS解析失败而无法建立。用户可更换DNS为8.8.8.8或1.1.1.1等境外公共DNS，并在Shadowrocket的DNS设置中启用“DNSoverHTTPS”以确保解析请求加密且不被篡改。同时，在配置文件中添加DNS规则，将特定域名的解析请求强制发送至指定DNS服务器，避免运营商的干扰。DNS缓存导致旧解析IP仍被使用设备或路由器本地缓存了该域名之前解析的IP地址，即使已经更改了配置或DNS设置，旧IP仍被用于连接请求。用户可清除iOS设备的DNS缓存（通过开关飞行模式或重启设备），或等待缓存过期后重新解析。在Shadowrocket中关闭再开启代理开关也可触发新DNS查询，确保使用最新的解析结果进行路由。去广告规则误将目标网站视为广告或追踪域名社区规则集将正常网站域名列入屏蔽列表部分去广告规则集为了覆盖面广泛，可能将某些正常服务的域名误判为广告或追踪服务器而添加了REJECT规则。当用户访问该服务时，Shadowrocket在规则匹配过程中发现该域名匹配了REJECT规则，直接拒绝连接而不走代理通道，导致用户感觉网站“走不了代理”实际上是被拦截了。用户可通过连接日志查看该域名实际匹配的规则，如果发现匹配了REJECT规则，则将该域名从去广告规则中排除或单独添加一个DOMAIN-SUFFIX,example.com,PROXY规则并放置在去广告规则之前。规则匹配了REJECT后代理规则无法覆盖由于Shadowrocket的规则匹配是按顺序执行的，如果去广告的REJECT规则位于用户自定义的代理规则之前，该域名在匹配到代理规则前就已被REJECT命中并拒绝，后续的代理规则完全不会被评估。用户应调整配置中的规则顺序，将特定域名的代理规则放置在所有去广告规则之前，确保代理优先于拒绝。或在连接日志确认后，直接删除或禁用针对该域名的REJECT规则。REJECT-DROP导致连接超时而非明确的拒绝提示REJECT-DROP规则通过静默丢弃数据包而不返回任何错误信号，使得用户在浏览器中看到的是长时间加载后超时，而非明确的“连接被拒绝”，更容易被误认为是“代理失效”或“走不了代理”。用户应检查配置中是否存在REJECT-DROP规则命中了目标域名，如有则将该规则改为REJECT或在代理规则之前添加该域名的PROXY规则进行覆盖。常见问题FAQ

Shadowrocket测试节点是否正常，为什么要先切全局模式？

测试Shadowrocket节点时先切换至全局模式，核心目的在于排除配置文件中所有分流规则、策略组和去广告规则对测试流量的干扰，确保测试请求完整地经过选定代理节点往返。规则模式下国内直连规则、策略组覆盖和REJECT拒绝规则可能导致测试流量未经过代理节点或被本地拦截，使得测试结果完全无法反映节点的真实连通性和性能。切换全局模式后，所有流量无差别地通过当前选中的单一节点转发，用户访问IP检测网站可立即确认出口IP是否变为代理IP——若显示代理IP则节点连通正常，若显示本地IP或连接失败则节点不可用。确认节点在全局模式下工作正常后，用户切回规则模式验证分流规则的完整性，如果规则模式下特定网站无法访问，则问题明确指向配置规则而非节点本身，此时应开启连接日志查看该域名的匹配规则，针对性调整规则顺序或补充缺失规则。在日常使用中保持“全局模式测节点、规则模式用分流”的流程，每次遇到网速异常时先切全局验证节点状态再回规则排查规则问题，能够显著提升排障效率并确保节点选择的准确性。规则模式下的分流干扰会导致测试结果不准确规则模式可能将测试流量错误地判为直连当用户在规则模式（全局路由设为“配置”）下测试节点时，当前激活的配置文件中包含的大量分流规则会参与每一个网络请求的决策。如果配置文件中的GEOIP,CN,DIRECT或特定域名直连规则恰好在节点测试请求的匹配路径上，测试流量可能被规则引擎判定为“需直连”而直接绕过了待测试的代理节点。此时用户看到的“连接成功”状态实际上反映的是本地网络是否可达，而非该代理节点是否可用，测试结果完全失去了参考价值。切换全局模式可以规避所有分流规则的干扰，确保每个测试包都经过待测节点的完整转发链路，获得真实的节点连通性和延迟数据。配置中的策略组可能将测试流量引向非目标节点在规则模式下，用户主界面手动选中的节点不一定是实际处理流量的节点。配置文件中的策略组可能通过“自动选择”、“延迟最低”或“故障转移”逻辑覆盖了主界面的节点选择，导致测试请求实际被发送至策略组中的其他节点而非用户意图测试的那个节点。这种策略组覆盖行为在复杂配置中极为常见，用户往往在不知情的情况下测试了错误的节点。全局模式则完全忽略策略组定义，直接使用主界面当前选中的单一节点作为所有流量的唯一出口，确保测试目标与用户预期一致。去广告规则和REJECT规则可能阻断测试请求规则模式下的配置文件中如果包含了REJECT或REJECT-DROP规则，且测试目标域名或IP恰好匹配了这些拒绝规则，测试请求可能在到达代理节点之前就被本地规则引擎拦截并返回失败。用户此时得到的“节点不可用”结论完全是误导性的，因为被拒绝的是测试请求本身而非节点故障。全局模式由于不执行任何配置规则，能够彻底排除这类本地拒绝规则对节点测试的干扰，使测试结果只反映节点自身的连通状态。全局模式提供纯粹的代理通道测试环境全局模式强制所有流量经过选定的单一节点当用户将全局路由切换至“代理”（全局）模式时，Shadowrocket会关闭所有分流逻辑和规则引擎，直接使用用户在节点列表中手动选中的那个节点作为唯一转发目标。每个测试数据包从设备发出后，完整地经过“设备→代理节点→目标测试服务器→代理节点→设备”的往返路径，不经过任何直连通道或备用节点的干预。这种纯粹的代理通道测试能够准确反映该节点在当前网络环境下的真实延迟、丢包率和带宽表现，是最可靠的节点质量评估方式。全局模式测试结果可用于横向对比不同节点在相同的全局模式下分别测试多个节点，得到的延迟数值和连接成功率具有相同的测量基准，因为每次测试都排除了配置规则和策略组的变量干扰，唯一的变化仅仅是节点本身。用户可以通过这种对比测试轻松筛选出当前网络环境下表现最优的节点，将延迟最低、丢包最少的节点设为默认使用。如果用户在规则模式下分别测试不同节点，测试路径可能因规则匹配差异而不同，导致对比结果失去公平性。全局模式下的测试速度更直接反映节点性能规则模式下每个请求都需要经过规则引擎的逐条匹配，虽然单次匹配耗时在微秒级别，但累计起来仍会对测试结果产生微小偏差。全局模式完全跳过规则匹配环节，测试流量从设备到代理节点的通道最为直接，所测得的延迟数值最能反映节点本身的网络链路质量，而不包含规则引擎的处理开销。对于需要精确测量节点延迟的用户而言，全局模式是获取可靠数据的前提条件。规则模式与全局模式测试结果的典型差异规则模式下显示“已连接”但全局模式下无法访问这是一种常见的反向场景，当用户在规则模式下看到节点状态为已连接且能正常访问境外网站时，切换至全局模式反而无法访问。这说明用户当前使用的配置文件存在问题——规则模式下的“已连接”可能来自配置文件中的直连规则（国内流量直连），而用户实际在访问的境外网站可能因策略组配置不当未能正确经过代理节点。切换至全局模式后，所有流量强制走代理，如果此时无法访问，则明确说明该节点实际不可用或当前网络环境无法连接该节点，用户应立即切换节点或排查本地网络是否阻止了代理连接。规则模式下测试延迟极低但实际使用卡顿当用户在规则模式下测试某个节点时显示的延迟数值非常低（如数十毫秒），但切换至该节点实际使用时却感觉网页加载缓慢或视频缓冲频繁。这种情况通常是因为规则模式下的测试请求匹配了直连规则，实际测量的是本地网络的响应速度而非代理节点的延迟。切换至全局模式后重新测试该节点，用户会看到真实的代理延迟数值——可能高达数百毫秒甚至超时，这才解释了实际使用中卡顿的原因。全局模式通过暴露真实的节点延迟，帮助用户做出正确的节点选择决策。全局模式下测试通过但规则模式下特定网站打不开当用户在全局模式下确认某个节点工作正常，但切换回规则模式后某个境外网站无法加载时，问题出在配置文件而非节点本身。可能原因包括：该网站的域名未被规则覆盖导致走了直连，或者该域名被去广告规则误判为REJECT，或者策略组引用了错误的节点。用户通过全局模式先确认节点健康，再回到规则模式排查配置问题，这种“先确认节点，再检查规则”的排障顺序是最高效的流程。如何正确地进行节点测试与验证切换全局模式执行初步连通性测试用户在进行节点测试前，首先将全局路由下拉菜单切换至“代理”（全局）模式，确保所有分流规则和策略组被临时禁用。然后选择目标节点并开启代理开关，访问http://ipinfo.io或http://ip.sb等IP检测网站，确认当前出口IP已变为代理服务器的IP地址。如果IP检测成功显示代理IP，则说明节点基本连通；如果显示本地IP或页面无法加载，则该节点在当前网络环境下不可用。这一初步测试耗时仅需10秒，是验证节点可用性最直接的方式。在全局模式下进行速度与延迟实测通过IP检测确认节点连通后，用户在全局模式下使用Shadowrocket的“延迟测试”功能或通过实际浏览视频、下载文件来评估节点的速度和稳定性。延迟测试结果可以反映节点到目标服务器的响应速度，而实际浏览大文件或4K视频时的加载速度则更贴近日常使用体验。用户可在此阶段切换多个节点，分别记录每个节点的延迟和速度数据，进行横向对比筛选出性能最佳的节点。回到规则模式验证分流规则的完整性确认某节点在全局模式下表现良好后，用户将全局路由切回“配置”（规则）模式，保持同一节点选中，然后访问之前测试过的境外网站（如YouTube、Google）和国内网站（如百度、淘宝）。如果境外网站能正常访问且IP显示为代理地址，国内网站能正常访问且IP显示为本机地址，则说明当前配置的分流规则完整且生效。如果某个网站无法访问或路由错误，用户可开启连接日志查看该域名的匹配规则，针对性调整配置文件中的规则顺序或添加缺失的规则条目。建立日常使用的节点切换流程在完成全局模式下的节点测试和规则模式下的分流验证后，用户应将测试通过且性能最优的节点设为主要使用节点，并保持规则模式作为日常默认模式。当日常使用中感觉到网速明显下降或节点频繁断线时，重复上述测试流程——先切全局模式验证节点当前连通性和速度，若节点故障则切换备用节点并重新测试，若节点正常但规则模式下访问异常则调整配置规则。这种“全局模式测节点、规则模式用分流”的分工模式能够最大化日常使用的稳定性和排障效率。常见问题FAQ

Shadowrocket全局模式、规则模式、直连模式分别适合什么场景？

在Shadowrocket中，全局模式、规则模式和直连模式分别服务于完全不同的使用需求：全局模式将所有流量无差别地通过代理节点转发，适合公共Wi-Fi环境下的隐私保护和需要完全隐藏IP的特殊场景，但会牺牲国内网站的访问速度；规则模式通过分流规则智能判断每个请求的去向，实现国内直连、国际代理的自动切换，是绝大多数用户日常综合上网的最佳选择，其分流效果取决于配置文件的完整性和准确性；直连模式则完全绕过代理，所有流量直接走本地网络，既是网络故障排查时的快速诊断工具，也是无需代理的临时场景下的最优选择，同时不影响配置编辑和管理操作。用户应根据当前所处的网络环境、访问目标和隐私需求灵活切换三种模式，日常使用优先保持规则模式并定期维护配置文件，遇到隐私敏感场景时临时切换至全局模式，网络异常时通过直连模式快速定位问题根源。三种模式之间切换时无需关闭代理开关，通过主界面底部下拉菜单即可完成即时切换，切换后建议刷新受影响的页面或重启应用以确保新路由策略完整生效。对于同时使用多个配置文件的用户，模式切换与配置切换相互独立，用户可在任意模式下加载不同的配置文件，实现模式和规则的双重组合以满足更精细的网络管理需求。全局模式：所有流量无差别经过代理节点全局模式的核心功能与行为特征当用户将Shadowrocket的全局路由切换至“代理”模式（通常被称为全局模式）时，应用会忽略配置文件中定义的所有分流规则和策略组，直接将设备上所有应用的每一个网络请求都通过当前选中的代理节点转发至目标服务器。无论是Safari浏览网页、微信收发消息、系统更新检查还是邮件同步，所有流量无一例外地经过代理通道，设备的外网IP统一显示为代理服务器的出口IP。这种模式不区分国内或国外网站，不区分应用类型，实现百分百的代理覆盖，是最纯粹的代理使用方式。全局模式最适合隐私高度敏感的场景当用户身处公共Wi-Fi网络（如机场、咖啡馆、酒店）时，全局模式可以确保所有网络流量都经过加密隧道传输，避免敏感信息如登录密码、聊天内容、浏览记录在开放网络中裸奔。对于需要隐藏自身真实IP和地理位置的所有在线活动，全局模式提供了最彻底的匿名保护，因为任何对外连接都显示为代理节点的IP而非本机IP。在需要访问某些对来源IP有严格限制的境外服务时，全局模式也能保证所有请求都从同一IP发出，避免因部分流量直连导致访问被拒绝。全局模式适合网络环境极为严格的场景在部分对网络流量实施严格审查和干扰的环境中，一些应用可能尝试通过非标准端口或自定义协议直连外网，而配置文件中的规则可能无法覆盖所有这些非标准流量。全局模式通过将全部流量强制导入代理通道，从根本上杜绝了任何应用绕过代理直连的可能性，确保所有流量都受到代理节点加密和转发。这种模式在规避网络封锁时最为彻底，尤其适合需要访问高度受限内容或使用某些特定应用的场景。全局模式的代价是国内网站访问速度下降全局模式下，用户访问百度、淘宝等国内网站时，请求也会先发往境外代理节点，再由代理节点回源至国内目标服务器。这一绕行增加了数百毫秒的额外延迟，国内网站的加载速度会明显变慢，同时代理节点的流量消耗也显著增加，可能消耗更多套餐配额。此外，部分依赖本地网络的服务（如局域网打印机、NAS访问、本地DNS解析）在全局模式下可能无法正常工作，因为这些服务的请求也被错误地送往代理节点而非本地网络。规则模式：智能分流实现国内外网站区别对待规则模式根据分流规则决定每个请求的去向当用户将全局路由设为“配置”模式（即规则模式）时，Shadowrocket会完全遵循当前配置文件中定义的规则列表和策略组，对每个网络请求进行逐条匹配评估。规则引擎根据域名、IP段、GEOIP归属地、应用类型等多种条件，将请求分类为“走代理”、“直连”或“拒绝”，从而实现国内网站直连加速、境外网站代理访问的分流效果。这是Shadowrocket最核心、最灵活的工作模式，也是绝大多数用户日常使用的默认模式。规则模式是日常综合上网场景的最佳选择对于同时需要访问国内服务（如微信、淘宝、百度）和境外服务（如Google、YouTube、GitHub）的普通用户而言，规则模式能够智能地在两种网络环境间自动切换，实现“国内直连、国际代理”的最优路由策略。访问国内网站时直接走本地网络，享受低延迟和高带宽；访问境外网站时自动走代理节点，确保内容可访问。这种模式不牺牲国内访问速度，同时保证了境外服务的可用性，是体验最为平衡的使用方式。规则模式适合需要精细化分流控制的重度用户当用户对不同应用、不同域名甚至不同URL路径有差异化代理需求时（例如YouTube走特定流媒体优化节点、Netflix走解锁节点、国内银行App直连、游戏走UDP加速节点），规则模式通过配置文件和策略组的组合能够实现极其精细的流量管理。用户可以为不同服务指定不同的策略组，策略组中配置多个节点并设置自动选择或故障转移策略，实现节点级的智能调度。这种定制能力是全局模式完全不具备的，适合对网络行为有细分需求的技术用户。规则模式的效能高度依赖配置文件的完整性和准确性规则模式的效果完全取决于当前激活的配置文件中是否包含了完整且顺序合理的分流规则。如果配置中缺少国内IP段的直连规则或GEOIP规则，部分国内网站可能被误判为代理流量而变慢；如果去广告规则不完整，应用内的广告可能无法被拦截。用户需要定期更新规则集和CNIP数据库，或使用社区维护的成熟配置，才能确保规则模式长期稳定运行。直连模式：绕过代理直接使用本地网络直连模式使所有流量不经过代理节点当用户将全局路由切换至“直连”模式时，Shadowrocket会完全停止对所有网络请求的拦截和转发，所有流量直接通过设备的基础网络通道发出，不经过任何代理节点，也不执行配置文件中任何分流规则。此模式下，Shadowrocket的代理开关虽然可保持开启状态，但代理通道被逻辑性禁用，应用实际上退化为一个纯粹的配置管理工具，所有网络行为恢复到设备未安装Shadowrocket时的原生状态。直连模式是快速验证本地网络是否正常的诊断工具当用户怀疑代理节点或配置规则存在问题时，将全局路由切换至直连模式可以快速排除代理层面的干扰，直接测试设备的基础网络连通性。如果直连模式下国内网站访问正常而规则模式下变慢，则问题出在配置规则或代理节点上；如果直连模式下也无法访问，则说明问题在本地Wi-Fi、蜂窝网络或运营商层面。直连模式是网络故障排查流程中必不可少的诊断工具，帮助用户快速缩小问题范围。直连模式适用于无需代理的临时场景当用户身处无需代理即可正常访问境外服务的网络环境（如海外出差、境外办公），或当用户只需要使用本地网络服务（如访问内网资源、局域网打印）时，可将全局路由切换至直连模式，避免代理节点对本地网络访问造成不必要的干扰。在此模式下，节点选择和配置规则均被忽略，网络性能达到设备自身的物理上限，适合对速度和延迟有极致要求的场景。直连模式不影响规则编辑和配置管理操作即使全局路由设置为直连模式，用户仍然可以自由编辑配置文件、添加节点、刷新订阅和执行配置切换等所有管理操作。这些操作的结果在用户切换回规则模式或全局模式后会立即生效。这种设计允许用户在不需要代理时（如本地网络环境良好）仍能维护配置，为后续需要代理的场景做好准备，而不必反复开关代理。三种模式的场景选择策略与切换建议日常使用：规则模式是首选对于绝大多数用户的绝大多数使用场景，规则模式提供了代理功能与访问速度的最佳平衡。用户只需维护一份包含完整分流规则的配置文件（或使用社区维护的成熟规则集），即可实现国内网站直连加速、境外网站自动代理、广告域名屏蔽等综合效果。规则模式下用户无需关心每次访问的网站是走代理还是直连，应用会自动做出最优决策，适合长期开启并作为日常默认模式。隐私敏感或网络封锁严格时：全局模式覆盖更彻底当用户连接至不安全的公共Wi-Fi、需要完全隐藏自身真实IP、或身处对网络流量实施严格审查的地区时，全局模式通过将所有流量强制加密转发，提供了最彻底的隐私保护和绕过能力。虽然国内访问速度会下降，但在这些特殊场景下安全性和可用性优先于速度。用户在使用全局模式后，应记得切换回规则模式或直连模式，避免长期全局代理导致国内网站访问缓慢和流量消耗过快。网络排障或无需代理时：直连模式快速恢复当用户遇到网络连接异常，不确定是代理问题、配置问题还是本地网络问题时，将全局路由切换至直连模式可立即恢复设备的基础网络访问能力，同时帮助定位问题环节。当用户身处无需代理的环境或需要访问本地局域网资源时，直连模式也可作为临时模式使用，待环境变化后再切换回规则模式。灵活切换：三种模式可通过主界面下拉菜单即时切换Shadowrocket主界面底部的全局路由下拉菜单允许用户在不关闭代理开关的情况下，随时在“配置”（规则模式）、“代理”（全局模式）、“直连”（直连模式）和“场景”之间自由切换。用户可在一天中根据不同的网络环境和访问需求动态调整模式，例如在办公室使用规则模式，回家后切换至全局模式保护隐私，网络异常时临时切换至直连模式排障，无需重启应用或修改任何配置。常见问题FAQ

Shadowrocket去广告规则添加后App内广告还有怎么办？

当Shadowrocket添加去广告规则后App内广告依然出现时，首先开启应用连接日志功能，在广告加载过程中捕获App发起的网络请求，从日志中识别出疑似广告的域名（通常包含ad、ads、doubleclick、googlesyndication等特征关键词），然后进入当前激活的配置文件的规则列表，手动添加这些域名规则并将策略设为REJECT，保存配置并重新加载后再次测试广告是否消失。如果日志中无法捕获广告请求，可能源于App使用了IP直连方式绕过域名规则，此时应检查设备的DNS设置是否开启广告过滤功能，或在配置文件中添加DNS规则将疑似广告域名解析至无效IP地址。对于已缓存广告素材的App，添加规则后需要在iOS的iPhone存储空间中卸载并重新安装该App以清除本地缓存，然后重新打开验证去广告效果。同时检查配置文件中的规则顺序，确保所有REJECT去广告规则位于GEOIP、CN等直连规则之前，避免广告域名在匹配到拒绝规则前被直连规则提前命中。当以上操作均尝试后广告仍未消失，则确认该App的广告使用了与正常内容相同的域名且无法通过域名规则区分，此时可考虑在Shadowrocket中启用MitM解密功能并结合URL-REGEX规则拦截广告路径，但需注意MitM可能触发部分应用的SSLPinning保护机制导致App网络异常。去广告是一个需要持续维护的过程，用户需定期更新社区规则集并针对自己常用App手动补充遗漏的广告域名，逐步完善规则库。如果去广告需求强烈且手动维护成本过高，可考虑更换为AdGuard等专业去广告工具，或在系统层面使用支持广告过滤的DNS服务，与Shadowrocket配合实现多层防护。规则本身未覆盖该App的广告域名去广告规则集的覆盖范围存在局限性社区维护的去广告规则集（如adblock.list、neoHosts等）虽然涵盖了数万个已知的广告和追踪域名，但不可能穷举互联网上所有App使用的广告服务器。每个App可能对接不同的广告联盟或使用自定义的广告分发域名，规则集维护者未能收录的广告域名自然不会被屏蔽。当用户在Shadowrocket中添加了通用去广告规则后，如果某个App内的广告依然出现，首先应怀疑是该App使用的广告域名未被当前规则集覆盖，而非规则配置错误。通过连接日志捕获遗漏的广告域名用户打开Shadowrocket的连接日志功能，然后打开仍有广告的App并触发广告加载，在日志中观察该App产生的所有网络连接请求。广告请求通常会指向包含ad、ads、doubleclick、googlead、googlesyndication等关键词的域名，或指向某些非常规端口。用户从日志中识别出疑似广告域名的条目后，可手动将该域名添加至配置文件的规则列表中，指定策略为REJECT或REJECT-DROP。添加完成后重新加载配置并再次打开App测试广告是否消失，这是针对特定App广告最精准的补全方式。使用“抓包”工具辅助发现隐藏的广告请求对于Shadowrocket日志无法捕获到的加密或非标准端口广告请求，用户可借助MitM（中间人）解密功能或第三方抓包工具（如Surge、Charles）来分析App的完整网络行为。这类工具能够解密HTTPS流量并展示请求的完整URL路径，从而发现隐藏在加密请求中的广告服务器地址。识别出这些域名后，同样将其添加至Shadowrocket的拒绝规则中即可生效。需要注意的是，使用MitM功能需在设备安装并信任对应证书，操作有一定复杂度，适合进阶用户。规则匹配顺序不当导致去广告规则未生效去广告规则被前置的直连规则覆盖Shadowrocket的规则引擎按列表顺序逐条匹配，一旦某个规则命中，后续规则不再执行。如果用户在配置文件中将国内直连规则（如GEOIP,CN,DIRECT）或泛域名直连规则放置在去广告规则之前，而App的广告域名恰好属于国内IP段或匹配了泛直连规则，则广告请求会优先被直连规则命中并直接发出，完全跳过后续的去广告拒绝规则。用户应检查配置文件中的规则顺序，确保所有REJECT规则（包括去广告规则集引用）位于DIRECT规则之前，或至少位于可能覆盖该广告域名的直连规则之前。去广告规则集引用位置过晚导致失效当用户通过RULE-SET引用外部去广告规则集时，该引用在配置规则列表中占据特定位置。如果该引用位于多个泛匹配规则之后，或者位于FINAL兜底规则之后，则规则集中的所有规则都不会被评估，广告流量可能直接落入其他规则的处理范围。用户应在配置编辑界面中调整规则集的排列顺序，将去广告规则集尽量上移，放置在GEOIP,CN,DIRECT等大规模匹配规则之前，确保广告域名在被直连规则覆盖之前就能命中拒绝规则。特定App使用IP直连方式绕过域名规则部分App为了绕过域名级别的广告拦截，会直接通过IP地址请求广告内容，而非通过域名。去广告规则集中的DOMAIN-SUFFIX和DOMAIN-KEYWORD规则对IP直连请求无效，因为IP请求不包含域名信息，无法匹配任何基于域名的规则。用户可尝试在规则中添加IP-CIDR规则，将广告服务器的IP段直接标记为REJECT，但IP段信息较难获取且变化频繁。更多时候，用户需结合GEOIP规则或配置更严格的DNS解析来间接处理IP直连广告。DNS解析环节未被纳入拦截链去广告规则仅作用于HTTP/HTTPS层面的请求Shadowrocket的域名规则拦截发生在连接建立阶段，主要针对应用发起的域名解析和HTTP/HTTPS请求。但部分App内置了DNS解析逻辑或使用了HTTPDNS服务，直接通过IP地址连接广告服务器，完全绕过了域名匹配规则。这种情况下，即使规则集中包含了广告域名，App也不会向Shadowrocket发出包含域名的请求，规则自然无法命中。用户需检查设备的DNS设置，将DNS服务器切换至支持广告域名过滤的公共DNS（如AdGuardDNS），在解析层面即阻断广告域名的IP返回。配置DNS规则将广告域名解析至无效地址在Shadowrocket的配置文件中，用户可以添加DNS级别的规则，将特定广告域名指向无效的IP地址（如0.0.0.0或127.0.0.1）。当App尝试解析该域名时，DNS服务器返回无效IP，连接随即失败，广告无法加载。这种方式的优势在于即使App采用非标准端口或加密协议请求广告，只要其依赖域名解析，DNS规则即可生效。用户可将日志中捕获的广告域名批量加入配置文件的DNS规则区域，策略设为REJECT或指向黑洞IP。开启Shadowrocket的“DNSoverHTTPS”防止广告域名被篡改部分运营商或恶意软件可能篡改DNS响应，将广告域名解析至正常IP以使广告穿透拦截。用户可在Shadowrocket的设置中开启“DNSoverHTTPS”或“DNSoverTLS”，并指定支持广告过滤的DNS服务器（如https://dns.adguard.com/dns-query），确保每个DNS查询都经过加密且返回的解析结果经过过滤，从源头切断广告域名的可达性。这种加密DNS方式还能规避运营商对特定域名的DNS污染，确保去广告规则在实际解析环节得到执行。App端缓存和预加载机制导致广告残留App已将广告内容预缓存至本地存储许多App在加载广告时会提前预取多个广告内容并缓存在设备本地，当用户随后添加去广告规则时，这些已缓存的广告素材可能仍然在有效期内，App会优先展示缓存内容而非重新发起网络请求。用户可在添加去广告规则后，进入iOS的“设置→通用→iPhone存储空间”，找到该App并执行“卸载App”（保留文稿数据）或“删除App”（清除所有数据），重新安装后App的广告缓存被清空，新的网络请求才会被去广告规则拦截。注意卸载App可能导致部分登录状态和数据丢失，需提前备份。清除App内广告标识符（IDFA）减少定向广告部分App使用的广告基于设备广告标识符（IDFA）进行定向投放，即使网络请求被拦截，App仍可能基于本地缓存的IDFA和用户画像展示之前预加载的广告内容。用户可在“设置→隐私→跟踪”中关闭“允许App请求跟踪”，并前往“设置→隐私→分析与改进”中重置广告标识符。这一操作虽然不直接拦截广告请求，但能减少App基于用户画像加载针对性广告的动机，部分依赖定向广告的App在无法获取IDFA后可能自动减少广告展示频率。App重启或设备重启后验证效果添加去广告规则并清除缓存后，用户应强制关闭App（从后台多任务卡片中上滑退出），然后重新打开App测试广告是否消失。如果重启App后广告仍然存在，可尝试重启整个设备，因为部分App的广告服务在系统启动时即与广告服务器建立了长连接，设备重启会重置所有网络连接状态，使新的去广告规则得以完整生效。广告使用HTTPS且规则未启用MitM解密广告域名规则拦截不依赖解密即可生效需要明确的是，Shadowrocket的域名规则拦截发生在TLS握手之前，即使广告请求使用HTTPS加密，只要App在连接阶段发送了域名（通过SNI字段），规则引擎即可根据域名信息命中REJECT规则，无需解密流量内容。因此，用户无需开启MitM功能即可拦截大部分HTTPS广告域名。如果广告请求使用了加密DNS或IP直连方式绕过了域名暴露，才需要考虑更深层次的拦截手段。MitM解密可识别URL路径级别的广告请求部分App的广告请求与正常内容请求共用同一域名，仅通过URL路径（如/api/ad/）来区分。这种情况下，基于域名的REJECT规则无法精准拦截，因为拒绝整个域名会导致正常内容也无法加载。用户可在Shadowrocket中启用MitM解密功能，在配置文件中添加更精细的URL-REGEX规则，匹配包含/ad/、/ads/、/banner/等广告路径的请求并单独拒绝，而允许同一域名下的其他路径通过。MitM功能的启用需要安装和信任证书，且在iOS14及以上系统需要额外开启“解密HTTPS流量”的权限，操作门槛较高。MitM可能引发应用证书锁定（SSLPinning）问题部分安全级别较高的App（如银行、支付类App）以及一些主流社交App会启用SSLPinning机制，禁止任何中间人解密其HTTPS流量。当用户启用MitM功能并尝试解密这些App的通信时，App会因证书不匹配而拒绝连接，表现为网络异常或加载失败。因此，用户在使用MitM拦截广告时需注意区分App类型，对于启用了SSLPinning的App，即使广告未被屏蔽，也不应强制启用MitM，以免影响App正常使用。规则集格式错误或未正确加载检查规则集是否在配置列表中被激活用户在添加去广告规则集后，需要确认该规则集已被正确引用至当前激活的配置文件中，且配置文件处于启用状态。进入“配置”标签页，点击当前配置名称进入编辑界面，在规则集列表中确认去广告规则集条目是否存在且未被禁用。如果规则集条目显示为灰色或带有禁用标记，需重新启用或重新添加。同时确保当前配置名称左侧有蓝色选中标记，表明该配置确实处于激活状态，否则规则不会生效。验证规则集是否成功拉取并缓存对于远程去广告规则集，用户应进入“配置”标签页下拉刷新，观察规则集更新时是否返回成功提示。如果刷新过程中出现错误，规则集内容未被正确拉取，则去广告规则为空，自然无效。用户可进入该规则集的预览页面，查看是否已显示出具体的规则条目。如果预览为空，说明规则集未成功下载，需检查网络连接或更换规则集链接后重新添加。规则集内规则语法错误导致部分条目被忽略如果去广告规则集中的某些条目使用了Shadowrocket不支持的语法（如Clash专属的DOMAIN-SET类型），应用在加载时会跳过这些不兼容的条目而不报错，导致部分广告域名未被覆盖。用户可仔细阅读规则集发布页面的说明，确认该规则集是否明确标注“兼容Shadowrocket”。如不兼容，可寻找专门为Shadowrocket适配的去广告规则集，或将不兼容的规则条目手动转换为Shadowrocket支持的格式再内联添加。常见问题FAQ