资讯与使用教程

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

Shadowrocket fallback备用节点组怎么设置？

在Shadowrocket中设置fallback备用节点组，核心操作是进入配置文件的proxy-groups段落，创建type为fallback的策略组并将节点按优先级顺序填入proxies列表，同时配置url和interval参数实现连通性探测。配置过程中需确保策略组名称与规则中引用的名称完全一致，且节点名称与proxies段落中的定义精确匹配。保存配置后需关闭再开启代理开关强制重载，使策略组定义完整生效。验证配置的最佳方式是修改首选节点的端口号为无效值，观察应用是否在数秒内自动切换至次选节点且访问恢复正常，同时开启连接日志查看切换记录。日常维护中，定期检查fallback组中各节点的实际可用性，及时移除长期失效的节点并补充新的可靠节点，保持策略组的容灾能力。对于进阶需求，可将fallback组嵌套使用或在其列表末尾添加DIRECT直连作为兜底，避免所有节点失效时的完全断网，同时利用策略组隔离不同应用的流量域，实现区域级别的故障隔离，使单点故障的影响范围被最小化。理解fallback策略组的设计定位与运行逻辑fallback组按固定优先级顺序选择节点而非动态测速在Shadowrocket的配置体系中，fallback策略组是一种基于固定优先级顺序进行节点选择的机制，当用户将多个节点按照期望的使用顺序排列在该策略组中时，所有流量会优先交由列表中的第一个节点承载。一旦该节点因网络波动、服务器维护或防火墙阻断而无法建立有效连接，策略组会自动沿列表向下滑落，尝试第二个、第三个直至找到首个能正常响应的节点。这种切换不依赖实时测速的延迟数值作为决策依据，而是基于连通性的二元判断，适合网络环境波动频繁且追求稳定兜底的场景。fallback组与手动选择节点在故障感知方式上的本质区别手动选择节点时，如果当前使用的节点突然失效，用户需要主动感知网络异常并手动切换至备用节点，这一过程既存在感知延迟也依赖用户的操作及时性。而配置fallback策略组后，Shadowrocket会在后台持续监控当前节点的可用性，一旦检测到连接中断或超时，自动切换动作在数秒内即可完成，用户甚至无法察觉节点已经更换。这种自动化的故障转移机制将所有备用节点的切换逻辑预先固化在配置中，避免了人工干预带来的响应滞后和操作失误。策略组中的节点顺序直接决定了容灾的优先级阶梯在fallback策略组中，节点的排列顺序不是随意排列的装饰性列表，而是承载着明确的优先级逻辑，排在第一位的节点是首选用例，排在第二位的节点在第一节点失效时接管，依此类推。用户在配置时应按照节点质量从高到低、延迟从低到高、带宽从大到小的顺序进行排列，确保在网络正常情况下始终使用最优节点，仅在最优节点完全不可达时才降级至次优节点。这种阶梯式的容灾策略保证了网络质量随节点可用性自然衰减，而不会出现因随机选择导致的质量骤降。在Clash格式配置文件中定义fallback组的完整写法在proxy-groups段落中声明类型为fallback的策略组当用户使用Clash格式的配置文件时，需要在proxy-groups区域中创建一个新的策略组条目，将其type字段明确设置为fallback，并在proxies字段中以YAML列表的形式按优先级顺序列出所有备选节点的名称。例如配置name:Fallback-Group、type:fallback、proxies:下方缩进排列-HK-01、-JP-02、-US-03，即表示流量优先使用HK-01节点，不可用时切换至JP-02，再不可用则切换至US-03。该配置完成后，用户需要在规则条目中将目标域名或策略指向该策略组的名称。配置url参数实现周期性连通性探测与健康检查为了让fallback组能够准确判断当前节点是否可用，用户需要在策略组定义中同时配置url和interval参数，指定一个可靠的测试目标地址和探测周期。url通常填入http://www.gstatic.com/generate_204或http://cp.cloudflare.com这类能够稳定返回标准响应的地址，interval参数设置检测间隔，例如interval:300表示每300秒探测一次当前节点的连通性。当探测请求超时或返回非预期状态码时，Shadowrocket会判定当前节点不可用并自动触发向下游节点的切换动作。在fallback组中混用不同协议类型的节点时的兼容考量用户可以在同一个fallback策略组中混合放置Shadowsocks、VMess、Trojan等不同协议的节点，但需注意各协议对UDP转发、加密方式和TLS配置的兼容性差异。当fallback组从一种协议节点切换至另一种协议节点时，已建立的TCP连接会被重置并按新协议的参数重新握手，用户可能感知到短暂的连接中断。建议在配置时尽量将协议类型相同的节点排列在一起，或确保不同协议节点对目标服务的访问能力一致，避免因协议差异导致切换后特定应用无法正常工作。将现有节点纳入fallback组的配置操作步骤进入配置编辑界面并定位至策略组定义区域用户打开Shadowrocket后进入底部导航栏的“配置”标签页，点击当前激活的配置文件名称进入编辑界面，在配置内容中找到proxy-groups段落。如果该段落不存在，用户需要手动在配置文件中添加这一结构，并确保其位于proxies节点列表段落之后。定位到策略组定义区域后，用户即可开始创建新的fallback策略组或修改已有的策略组类型为fallback，所有后续的节点引用和参数配置均在此区域完成。填写策略组名称并按照优先级顺序列出节点名称在proxy-groups区域新增一行或多行定义fallback策略组的条目，首先通过name字段为该策略组赋予一个易于识别且不与现有策略组重复的名称，然后通过proxies字段按优先级从高到低列出所有备用节点。节点名称必须与proxies段落中定义的节点名称完全一致，包括大小写和特殊字符，任何拼写偏差都会导致该节点被策略组忽略且不报错。建议用户先复制节点列表中已有的节点名称，再粘贴至策略组中以避免手输错误。保存配置并执行重载使策略组定义生效完成策略组的添加或修改后，用户点击编辑界面的保存按钮将更改写入配置文件，然后回到Shadowrocket主界面关闭再开启代理开关，强制应用重新加载完整配置并初始化新增的策略组结构。重载完成后，用户可以在节点列表或策略组选择界面中看到新创建的fallback策略组名称及其包含的节点列表，此时该策略组已可被配置文件中的规则条目引用。如果策略组未出现在列表中，则需返回配置编辑界面检查缩进和语法是否正确。fallback组与url-test组的核心区别与适用场景fallback组依赖静态优先级而url-test组依赖动态测速fallback策略组的决策逻辑完全基于用户预先设定的节点排列顺序，只要当前节点能够通过连通性探测，流量就始终停留在该节点上，不会因为其他节点延迟更低而主动切换。而url-test策略组会在后台持续对所有节点进行延迟测速，并在每次请求时将流量分配至当前测速结果最优的节点，即使原节点仍可用也可能因延迟波动而频繁切换。对于希望网络出口保持长期稳定的用户而言，fallback组的静态优先级切换模式比url-test组的动态切换模式更可预测且更易于排查。fallback组适合追求稳定连续性而url-test组适合追求极致速度当用户在观看视频直播或进行外服游戏对战时，频繁的策略组切换会导致连接中断或操作卡顿，此时fallback组仅在当前节点彻底不可用时才切换的保守逻辑能够最大程度地维持连接的连续性。而对于网页浏览或API调用这类单次请求寿命极短、对延迟敏感但允许连接重建的场景，url-test组自动选择最低延迟节点的机制能够持续优化访问速度。用户应根据具体的应用场景选择合适的策略组类型，同一配置文件中可以同时包含fallback和url-test组分别服务不同类型的流量。两种策略组在配置文件中的语法定义几乎一致但type字段不同在Clash格式配置文件中，fallback组和url-test组的写法差别极小，仅需将type字段从fallback改为url-test即可完成类型的切换，其余proxies、url和interval参数的配置方式完全相同。这种语法上的高度相似性使得用户可以在两种策略之间快速实验和切换，通过在测试环境下观察数日的实际表现来确认哪种策略组更适合自己的网络环境和访问习惯，最终保留效果更佳的那一种作为长期配置。配置后验证fallback切换是否生效的方法通过手动断开首选节点的可用性触发强制切换配置完成后，用户可以通过断开当前首选节点的网络连接或临时修改其服务器地址为无效值来模拟节点失效场景，然后观察Shadowrocket是否在数秒内自动切换至列表中的下一个节点。最便捷的方式是在节点编辑页面中将首选节点的端口号修改为错误端口，保存后保持代理开启并访问任意测试网站，如果应用能够自动切换到次选节点且网页正常加载，则说明fallback切换机制已正确激活。测试完毕后务必还原节点的正确端口号以避免长期使用无效配置。查看连接日志中的切换记录验证自动化动作在触发切换测试的同时，用户应开启Shadowrocket的连接日志功能，在日志中搜索“fallback”或“policygroup”等关键词，查看是否有明确的策略组切换记录。日志会详细记录当前节点因何种原因被判定为不可用（超时、连接拒绝、证书错误等），以及策略组已切换至哪个备用节点，这些信息能够帮助用户确认切换机制是否按预期工作。如果日志中无任何切换记录但访问依然正常，则可能是当前节点并未真正失效，测试条件需要调整。通过策略组状态指示器确认当前活跃节点在Shadowrocket的节点选择界面或策略组展开视图中，处于活跃状态的节点通常会带有特殊的视觉标记或高亮显示，用户可以通过观察该标记的变化来确认fallback组当前实际使用的节点。当首选节点恢复可用后，策略组并不会自动回切至首选节点，这种设计避免了因短暂网络波动导致的频繁切换震荡，用户可在策略组界面手动点击首选节点强制回切，或等待应用下次启动时重新评估节点顺序。多层级fallback嵌套与故障隔离的高级策略将fallback组作为更大fallback组中的子节点实现多层容灾用户可以在一个外层fallback策略组的proxies列表中引用另一个内层fallback策略组的名称，而不是仅填入具体的节点名称，这种嵌套结构使得容灾逻辑具备层次化的表达力。外层策略组优先尝试完整的子策略组，当子策略组中的所有节点全部失效时，才向外层列表的下一个条目滑落。这种多层设计允许用户为不同地区或不同运营商分别创建独立的子策略组，在外层按地理区域设置优先级，实现区域级别的故障隔离和自动切换。结合DIRECT直连作为fallback列表最后的兜底选项在fallback策略组的节点列表末尾，用户可以填入DIRECT关键字作为最终的降级通道，当所有配置的代理节点均不可用时，策略组会自动切换至直连模式，确保设备至少保持基本的网络访问能力而不会完全断网。这种配置尤其适合在公共Wi-Fi环境下使用，当所有代理节点因网络限制无法连接时，直连兜底能够保证用户仍能访问内网资源和国内网站，避免因代理失效导致的完全断网。填入DIRECT时需注意该条目在列表中放置在最后一位，以免直连提前接管而浪费可用的代理节点。使用策略组隔离不同应用流量的故障域在配置文件中通过多个规则条目将不同应用或不同域名的流量分别指向不同的fallback策略组，可以实现故障域的隔离——当某个地区的节点全部失效时，仅影响对应分组内的流量，其他地区的应用不受波及。例如将流媒体流量指向包含日本和美国节点的fallback组，将开发工具流量指向包含欧洲节点的fallback组，两组之间互不干扰，单一地区的网络故障不会引发全局性瘫痪。这种细粒度的策略组分配是大型配置文件的进阶管理手段，能够显著提升整体网络的容错韧性。常见问题FAQ

Shadowrocket配置文件的YAML/INI格式不能出错，怎么检查格式问题？

当配置加载时遇到格式错误提示，第一步应进入日志页面查看具体的错误行号和描述，而不是逐行盲目翻阅整个文件，日志中的“unexpectedtoken”或“invalidsyntax”等关键词通常已将问题范围精确到特定行。如果日志提示不够明确，可使用外部代码编辑器打开配置文件，开启显示空格和Tab等不可见字符的功能，检查缩进是否全部统一使用空格而非混用Tab键，并确认每个段标识的方括号完整闭合。对于YAML格式配置，逐级核对每一层的缩进偏移量是否一致，确保所有冒号后正确添加了一个空格且键名大小写与实际引用的策略组名称完全匹配。修正后将文件保存为UTF-8withoutBOM编码并重新导入Shadowrocket，再次尝试加载并观察日志是否仍有报错，如此反复缩小问题区域直至配置被完整加载。为防范未来再次出现格式问题，建议在每次成功加载后立即导出配置备份，并在后续修改前先备份当前可用版本，便于在误操作后快速回退至稳定状态。格式类型识别与检查策略的差异化选择区分原生INI结构与Clash格式的语法特征Shadowrocket的默认配置文件采用类似INI的结构，以方括号包裹的段标识如[General]、[Rule]、[Host]分隔不同功能区域，每一行以等号连接键值对构成具体参数。当这些段标识出现拼写错误或方括号未闭合时，应用在加载配置文件时会直接抛出段解析异常而不会尝试纠正，因此检查的首要动作就是逐一确认每个段起始行的括号完整性以及段名称是否与官方支持的列表完全一致。对于不熟悉标准段名称的用户，可参考Shadowrocket内置的默认配置进行对照，避免因自定义非标准段名导致整段配置被忽略。YAML格式下缩进与空格敏感性的特殊要求如果采用的是兼容Clash生态的YAML格式配置，其语法规则与INI截然不同，完全依赖缩进层级来表达配置项之间的从属关系，任何不一致的空格数量都会导致解析器无法识别所属层级。YAML对大小写敏感且要求冒号后必须跟一个空格才能被正确识别为键值分隔，这些细微之处正是格式错误的高发区域，用户需要单独审视。在动手修改之前，应先根据配置文件的首行或文件扩展名确定自己正在处理的是哪一类格式，因为针对INI的检查方法完全无法应用在YAML上，准确识别类型后才能选择合适的检查策略。通过配置预览功能快速验证文件可读性在投入大量时间逐行排查之前，用户可以利用Shadowrocket内置的配置预览或加载测试功能进行快速验证，进入配置编辑界面后选择“预览”或“测试”选项，应用会在不实际启用代理的情况下模拟加载过程并反馈初步的解析状态。如果预览过程中直接弹出格式错误提示并附带行号或段名称，则说明问题较为明显且位于报错位置附近，用户可将排查范围大幅缩小。如果预览通过但实际代理行为异常，则问题可能不在格式层面而在逻辑层面，此时需要转换排查方向。标点符号与空格细节的逐项排查等号两侧空格规范及列表分隔符检查在INI风格配置中，键值对的标准写法要求等号两侧不得存在多余空格，虽然Shadowrocket对等号前后的空格有一定容错性，但混合使用带空格与不带空格的写法可能导致特定参数解析异常。对于多个值组成的列表型参数，如dns-server或skip-proxy，各项之间必须使用英文逗号分隔且逗号后建议紧跟一个空格，混用中文逗号或缺少分隔符会导致应用将整个字符串视为单一无效值。用户应逐行检查每个键值对，确保等号位置正确且列表项之间的分隔符统一使用英文标点。注释符号的位置与多行注释的写法限制配置文件中的注释以分号或井号开头，但该注释符号必须位于行首或键值对之后且与有效内容之间留有空格，如果注释符号被放置在行中间且与有效内容未正确分隔，可能导致该行有效内容被意外截断。INI格式不原生支持多行注释，连续使用多个单行注释是唯一合法的写法，将多行文本包裹在引号或括号内并非标准注释方式，这种误用常导致后续行的配置被忽略而用户不自知。检查时应特别留意那些以非标准字符开头的行，确认其确实是有效的配置指令而非被误写的注释。引号与转义字符在路径或特殊值中的使用当配置值中包含空格、等号或逗号等特殊字符时，应用要求将这些值用双引号包裹以避免解析歧义，例如包含空白的节点备注或带有特殊符号的密码字段。如果用户省略了必要的引号，应用可能将特殊符号误判为分隔符或结束标记，导致该行被切分为多个碎片而使后续配置混乱。检查时应定位所有包含特殊字符的值，确认其首尾是否有匹配的双引号包裹，并留意引号本身是否为英文直引号而非中文弯引号，两者字符编码不同且无法被解析器识别。YAML缩进层级的系统化验证方法使用等宽字体与高亮编辑器识别视觉错位YAML格式对缩进的要求极为严格，使用等宽字体编辑配置文件是避免缩进混淆的首要条件，因为不等宽字体下两个空格与一个Tab键的视觉宽度可能相同从而导致肉眼无法分辨差异。建议用户将配置文件内容复制至支持语法高亮和缩进指示线的代码编辑器中，例如VisualStudioCode或SublimeText，这些工具能清晰显示每行的缩进层级并用虚线或垂直线连接同层级的配置项。通过观察缩进指示线是否对齐，可以快速发现那些偏离了所属层级的行，这类错误通常是YAML加载失败的核心原因。混用空格与Tab键导致的隐性不一致问题许多格式错误源于在同一文件中混用了空格和Tab键进行缩进，虽然两者在视觉上可能呈现相同的对齐效果，但解析器对此极为敏感并会抛出缩进不一致的错误。大多数现代代码编辑器在右下角状态栏会显示当前文件的缩进字符类型，用户应检查该设置并确保整个文件统一使用空格缩进（推荐两个或四个空格），同时开启编辑器的“显示空白字符”功能以直观展示所有不可见的空格和Tab符号。如果发现Tab键被意外插入，可使用编辑器的查找替换功能将所有Tab批量替换为固定数量的空格。列表项与字典项之间的缩进层级关系确认YAML中的列表以短横线加空格表示，字典以键值对表示，当列表项本身包含字典时，子字典的缩进必须相对于短横线进一步缩进以建立从属关系。用户应检查每个短横线后的内容是否正确缩进，以及同一列表下的所有条目是否保持相同的缩进起始位置，任何偏移都会导致解析器将一个子项误解为上一级配置。对于嵌套较深的结构，可在每个层级入口处添加注释行标记当前层级深度，便于在后续检查时快速确认各配置项是否处于正确的位置。利用Shadowrocket日志反馈定位违规行加载失败时的具体行号与错误类型提示当配置文件存在格式错误时，Shadowrocket在尝试加载该配置的瞬间会生成详细的错误日志，其中包含导致解析失败的行号以及错误类型描述，例如“unexpectedtoken”或“invalidkeyvalue”。用户应关闭再开启代理开关触发重新加载，然后立即进入日志页面查看最新的报错记录，这些提示往往直接指向问题所在的段落。与浏览器的开发者工具类似，Shadowrocket的错误日志是最精准的诊断依据，用户不应在没有查阅日志的情况下盲目逐行搜寻。通过分段注释法隔离可疑配置区块当日志提供的行号指向一个段落但用户无法立即识别具体错误时，可以采用二分注释法逐步缩小范围，先将配置文件下半部分的所有行全部注释掉然后尝试加载，如果加载成功则说明错误在下半部分，反之则在上半部分。如此反复操作可将搜索范围从数百行缩小至数行，显著提升定位效率。每次注释或取消注释后保存配置并执行一次加载尝试，利用日志反馈验证当前范围是否已排除错误，直至精确定位到引发失败的单一配置行。日志中的警告信息同样值得重视除了导致加载完全失败的严重格式错误外，日志中偶尔会出现仅输出警告而不中断加载的问题，例如某个参数值已被弃用或某个键名拼写接近但非标准选项。这些警告虽然不影响配置的加载和代理的基本启用，但可能导致特定参数被忽略或使用默认值，从而间接引起分流行为与预期不符。用户在排查格式问题时也应一并浏览日志中的警告信息，针对已弃用的参数及时更新至新写法，避免因忽略警告而长期使用不完整的配置。第三方语法验证工具的辅助检查手段在线YAML解析器对缩进和键值对的快速校验对于YAML格式的配置文件，用户可以将其内容复制至在线的YAML语法验证网站，这些工具能够独立于Shadowrocket对文件进行解析并详细标出错误位置和原因，尤其擅长检测缩进混用、冒号缺失和结构层级错位等问题。在线验证器的反馈通常比Shadowrocket的日志更详细且附带可视化标记，用户可据此快速修正配置。验证通过后再将内容粘贴回Shadowrocket的配置编辑界面保存，即可确保格式层面已无显著问题。INI语法检查工具对段标识和重复键名的检测对于INI风格配置，存在专门的语法检查工具用于扫描段名称重复、段括号不闭合以及同一段内重复定义相同键名等问题，这些工具能将潜在的逻辑错误一并提示给用户，而不仅是表面的格式瑕疵。使用这些工具时需注意工具对INI语法规范的严格程度可能与Shadowrocket的实际容错范围略有差异，少量警告可能实际不影响使用，但全部错误提示都值得认真核对。版本控制与差异对比防范新错误的引入在手动修改配置文件时，如果不小心删除了某个必要的分隔符或引入了非法字符，修改前后的变化往往难以凭记忆回溯。建议用户在每次修改前保存一份确认可用的配置副本作为基准，修改遇到格式错误时使用文本对比工具将当前版本与基准版本进行逐行对比，快速定位新增的差异行。这种差异对比方式能在数秒内凸显出被误改的部分，远比重新逐行阅读整个配置文件高效，且能有效防范因手误引入的隐蔽格式问题。加载流程与编码格式的最终确认UTF-8withBOM编码对Shadowrocket的兼容性影响Shadowrocket对配置文件的编码格式有一定要求，绝大多数情况下标准UTF-8编码能够正常加载，但如果文件保存时包含了BOM头，应用可能将BOM字符误读为配置内容的一部分而导致首行解析异常。用户在外部编辑器修改配置并保存时，应确认保存选项中的编码格式为“UTF-8withoutBOM”，避免因编码问题导致配置无法加载。如果配置在电脑上编辑后导入Shadowrocket频繁报错，优先检查文件编码是否符合要求。换行符格式在不同操作系统间的转换Windows系统下的文本文件默认使用CRLF作为换行符，而iOS设备期望的是LF格式的换行符，当配置文件在Windows电脑上编辑后直接传输至Shadowrocket时，文件中的CRLF字符可能被应用解析为配置值的组成部分，导致参数值被意外截断。建议用户在跨平台编辑配置文件时使用支持换行符转换的编辑器，统一将换行符设置为LF后再保存，或使用Shadowrocket内置的配置编辑功能直接修改以避免此类兼容性问题。保存后执行完全的配置重载而非仅切换场景修改配置文件并修正所有格式错误后，用户需要确保新配置被应用完整加载，简单地在配置列表点击切换可能不会触发完全重载，建议关闭再开启代理开关强制应用重新加载整个配置。加载完成后检查主界面显示的配置名称是否正确，并访问几个测试网站确认分流行为和代理状态符合预期。如果加载后仍有个别功能异常，返回日志页面查看是否存在未被注意到的警告信息，并重复上述检查流程直到所有日志条目均符合预期为止。常见问题FAQ

Shadowrocket always-reject-url-rewrite是什么功能？

在Shadowrocket配置文件中配置always-reject-url-rewrite功能时，实际上是在[URLRewrite]区域编写以REJECT为动作的正则匹配规则，每条规则占据一行，格式为“正则表达式留空或任意占位REJECT”，例如^https?://(.*)\.ads\.example\.com/.*REJECT即可屏蔽该域名下所有广告素材请求。编写规则前应先开启连接日志访问目标页面，从日志中精准复制需要拦截的完整URL路径作为正则表达式的匹配对象，确保拦截范围仅覆盖广告或追踪请求而不误伤正常功能路径。保存配置文件后切换一次配置或重载使规则生效，再次访问目标页面并查看日志中是否有“URLRewriteREJECT”记录来验证拦截是否成功。若发现某个应用因接口被拒绝而功能异常，可在该规则前添加一条更精确的放行规则或直接删除该条拒绝规则来快速恢复。随着目标网站或应用更新版本导致请求路径变化，用户需定期复查日志并调整正则表达式的匹配范围，确保拦截规则始终保持有效而不产生误伤。对于调试阶段或临时需要的拒绝规则，可在正则表达式前添加注释符号便于临时禁用，从而在精准拦截与功能完整性之间保持灵活可控。功能本质与核心作用将URL重写动作强制转为拒绝响应在Shadowrocket的配置体系中，always-reject-url-rewrite并不是一个独立的开关参数，而是指在配置文件的[URLRewrite]区域中，将特定规则的动作（Action）直接设置为REJECT的一种行为模式。当一条URL重写规则以REJECT作为动作指令时，Shadowrocket在匹配到该规则所定义的正则表达式后，不会像常规的重写规则那样将请求重定向至另一个地址，而是立即向请求方返回一个拒绝响应，通常表现为TCP连接重置或HTTP错误状态码，从而在请求发出后的极短时间内终止整个通信流程。作用于应用层的完整URL路径而非仅限域名与分流规则中的REJECT策略作用于基于域名的流量拦截不同，always-reject-url-rewrite模式下的拒绝行为基于完整的URL路径进行匹配，包括协议头、域名、端口、路径以及查询参数中的具体字符串。这种精确到路径级别的拦截能力使得用户能够针对特定API接口、统计脚本或广告素材的精确地址进行定向屏蔽，而不会影响到同一域名下的正常功能路径，实现了在应用层数据包发出之前即完成拦截判断的精细化管控。该功能本质上属于本地拦截而非服务器端过滤当REJECT动作被触发时，Shadowrocket会在设备本地直接终止该请求的发出过程，整个过程不涉及与代理节点或目标服务器的任何网络通信。这意味着拦截行为不会消耗代理流量，也不会在远程服务器留下任何访问日志记录，所有判断和执行均在本地完成。这种本地化的拦截机制不仅提升了隐私保护水平，也大幅减少了因等待远程响应而产生的页面加载延迟。执行逻辑与匹配优先级基于正则表达式的拦截时机早于普通规则匹配URL重写规则中的REJECT动作在Shadowrocket的处理管道中拥有极高的执行优先级，它在请求进入规则引擎进行GEOIP或域名匹配之前即被触发。当设备发出的网络请求的完整URL与[URLRewrite]区域中的正则表达式匹配成功且动作为REJECT时，该请求会立即被拦截，不会继续进入后续的配置文件规则匹配流程，也不会触发DNS解析或代理节点连接。这种前置拦截机制使得用户能够在不影响任何分流规则的前提下，精准切除特定路径的请求。精确匹配与通配符匹配的覆盖范围差异在[URLRewrite]中配置REJECT规则时，用户可以使用完整的正则表达式语法来定义匹配条件，既可以针对单个精确URL进行拦截，也可以通过通配符批量屏蔽符合特定模式的一类请求。精确匹配适合拦截某个应用程序中固定的统计上报接口，而通配符匹配则适合屏蔽整个广告联盟的素材请求路径。由于正则表达式的匹配过程需要逐字符验证，过于宽泛的匹配模式可能增加每个请求的处理时间，但现代设备上的性能损耗几乎可以忽略。规则顺序决定多个匹配模式之间的仲裁逻辑当[URLRewrite]区域中存在多条规则且某条请求同时匹配了多条规则时，Shadowrocket按照配置文件中规则列表的先后顺序逐条评估，并将第一条匹配成功的规则的动作作为最终执行结果。这意味着用户可以通过调整规则顺序来实现优先级控制，将更精确的匹配规则放在更宽泛的规则之前，避免因宽泛规则提前命中而导致精确规则无法生效。如果用户希望某些路径走代理而非拒绝，则需要确保相应的重写或放行规则排在该拒绝规则之前。典型应用场景与配置写法屏蔽应用程序内的统计和行为追踪接口绝大多数移动应用和网站为了收集用户行为数据，会在后台向特定的统计服务器发送包含设备信息和操作记录的HTTP请求，这些请求通常指向/api/track、/analytics或/log等固定路径。通过在Shadowrocket的[URLRewrite]区域添加一条匹配这些路径的正则表达式并将其动作设为REJECT，用户可以彻底阻断这些隐私数据的传出。配置写法例如^https?://(.*)\.analytics\.com/.*REJECT，即可屏蔽所有来自该统计域名的请求。拦截广告素材和追踪像素的精确加载路径许多广告系统和追踪服务将广告素材和追踪像素部署在特定的路径下，例如/ad/banner或/pixel/impression，这些路径与主站功能路径明确区分。通过编写针对这些路径的拒绝规则，用户可以精准移除页面中的广告元素而不影响网站的正常内容加载。always-reject-url-rewrite模式的路径级匹配能力在此场景下尤为突出，它允许用户保留同一域名下的功能请求，仅阻断包含广告关键词的路径请求。阻断特定版本检测或强制更新检查接口部分应用会定期向服务器请求版本更新信息，并在检测到新版本后强制用户升级或限制旧版本功能的使用。通过捕获并拒绝这些更新检查接口的请求，用户可以在一定程度上阻止应用的强制升级行为，保留当前版本的使用权限。配置时需先通过连接日志捕获该应用的更新请求URL，提取出其中固定的路径部分或特征参数，然后编写对应的正则拒绝规则，例如^https?://(.*)\.update\.com/v1/checkREJECT。与普通REJECT规则的区别与联系普通REJECT规则作用于域名/IP层面在配置文件的规则列表中，REJECT策略针对的是整个域名或IP地址段的流量，一旦匹配，该域名下的所有请求无论路径如何都会被拦截。这种粗粒度的拦截方式虽然配置简便，但对于混合了广告和正常内容的同一域名场景无能为力，拦截整个域名会导致正常功能也无法使用。而always-reject-url-rewrite模式通过正则表达式匹配精确的请求路径，在保留核心功能的前提下只移除不需要的部分，两者在拦截粒度上存在本质差异。两种拒绝机制在请求管道中互为补充普通REJECT规则在请求经过分流规则引擎时被触发，而[URLRewrite]中的REJECT动作在规则引擎之前介入，两者在Shadowrocket的处理管道中分别作用于不同阶段。用户可以根据具体的拦截需求选择合适的手段——当需要屏蔽整个广告域名时使用规则列表中的REJECT，当需要屏蔽同一域名下的特定路径时使用[URLRewrite]中的REJECT。这两种机制可以共存于同一配置文件中，分别针对不同粒度的拦截目标进行协同工作。错误使用路径级拒绝可能导致功能不可用由于[URLRewrite]中的REJECT基于正则表达式进行匹配，如果用户编写的匹配模式过于宽泛或包含了正常功能路径，可能导致应用的核心请求被误拦截，表现为页面白屏、数据加载失败或功能按钮无响应。与普通域名级别的拒绝相比，路径级拒绝的破坏范围更隐蔽且难以排查，用户在编写规则时建议先通过日志确认目标请求的完整URL结构，再使用捕获组或限定符精确匹配目标部分，避免使用过于宽泛的.*匹配整个路径。开启后的副作用与兼容性风险应用错误处理机制可能引发异常行为并非所有应用都设计了优雅的失败降级机制，当某个后台统计接口的请求被REJECT后，部分应用可能因无法收到预期响应而触发异常处理分支，例如反复重试、弹窗报错或直接崩溃闪退。尤其当被拒绝的接口承担了用户认证或功能配置加载等关键任务时，应用的正常运行可能受到严重影响。用户开启该功能后应密切观察常用App的运行状态，一旦发现异常行为应立即禁用相应规则并寻找更精确的匹配方式。HTTPS场景下路径级匹配仍然有效但依赖域名暴露在HTTPS加密连接中，请求的完整URL路径在TLS握手完成后才会被发送，但Shadowrocket作为中间层代理能够在本地截获解密后的请求内容并执行[URLRewrite]匹配，因此路径级拒绝在HTTPS环境下依然有效。然而，该匹配过程依赖于应用在请求中明确暴露域名和路径信息，如果应用使用了IP直连或自定义协议，则无法被[URLRewrite]捕获，此时路径级拒绝规则不会生效，用户需退回到域名级别的规则控制。规则调试期间可能导致误伤并难以快速定位由于[URLRewrite]中的规则不生成明确的网络错误提示，被拒绝的请求通常表现为连接超时或加载失败，普通用户难以区分是节点故障、目标服务器宕机还是本地的URL拒绝规则所致。在调试阶段，建议用户先保持代理开关开启并访问目标测试页面，同时开启连接日志查看是否有请求命中REJECT规则，如果发现被拒绝的请求影响正常功能，可临时禁用该规则或将动作改为DIRECT进行对比测试。配置建议与实际操作步骤在配置文件的URLRewrite区域填写REJECT指令用户首先打开当前激活的配置文件进入编辑界面，滑动至[URLRewrite]区域，在该区域中添加一行符合标准格式的规则条目，语法为“正则表达式目标地址动作”，其中目标地址部分可留空或在拒绝场景下填入REJECT关键字。典型的写法例如^https?://(.*)\.doubleclick\.net/.*REJECT，表示所有匹配该正则表达式的请求均被本地拒绝。每行规则占据独立一行，Shadowrocket按照从上到下的顺序依次执行匹配。通过连接日志验证REJECT规则是否正常触发保存配置文件并切换至该配置生效后，用户可开启Shadowrocket的连接日志功能，然后访问包含目标拦截请求的网站或应用。在日志输出中搜索对应域名或路径片段，如果某条请求的匹配结果显示为“URLRewriteREJECT”或类似的明确标识，则说明该拒绝规则已被成功触发并执行。如果日志中未出现任何与目标请求相关的记录，则可能是正则表达式写法不匹配或该请求在进入[URLRewrite]之前已被其他机制拦截。将成熟规则迁移至场景配置实现灵活切换对于经过充分调试并确认不会造成误伤的稳定拒绝规则，用户可以将其所在配置文件保存为专用的去广告配置或场景，并在不同的网络环境中按需调用。用户也可以在配置文件中为[URLRewrite]中的规则添加注释标记，将测试中的规则与已验证规则区分开来，便于后续维护和快速回退。随着目标应用更新迭代导致请求路径发生变化，用户需定期复查规则的匹配有效性，及时更新或移除失效的规则条目以确保拦截效果持续生效。常见问题FAQ

配置文件里的[General]字段有哪些常用参数？

在Shadowrocket的配置文件中，[General]字段提供了数十个精细参数用于控制应用的核心行为逻辑，日常使用建议保持dns-server填入223.5.5.5和119.29.29.29以兼顾解析速度与容错，loglevel设置为info以便于日常监控和故障排查，tfo和udp-relay根据节点支持情况开启以提升网络响应和游戏兼容性，而mitm和debug等高性能开销参数则保持关闭以免影响设备续航和隐私安全。对于需要频繁切换网络环境的用户，同时开启dns-direct-fallback-proxy和fallback-dns形成三级DNS容灾链条，可有效应对公共Wi-Fi或移动网络下的解析异常。修改任何参数前务必先通过导出功能备份当前完整配置文件，调整完毕后切换配置或重载使新参数生效，并持续观察网络访问速度和稳定性变化来验证调整效果。复杂参数如skip-proxy和skiptunnel的调整应结合连接日志逐步验证直连和代理的分流比例，避免因排除范围过大导致部分应代理流量走直连影响访问体验。定期复查[General]字段的参数设置确保其仍匹配当前网络环境和节点特性，是维持Shadowrocket长期稳定高效运行的重要维护步骤。代理模式与运行基础设置dns-server参数指定全局DNS解析服务器在[General]字段中，dns-server参数用于定义Shadowrocket在进行域名解析时使用的DNS服务器地址，可填入单个或多个IP地址，多个地址以逗号分隔。该参数直接影响所有经过代理的流量解析速度和准确性，建议优先填入国内公共DNS如223.5.5.5以提升国内网站访问速度，同时可追加119.29.29.29作为冗余备份。如果用户需要抗污染效果，也可单独填入1.1.1.1等境外DNS，但需注意混用国内外DNS可能导致解析异常，因为并发查询机制会采纳最快响应的结果。loglevel参数控制应用日志输出级别loglevel参数用于设置Shadowrocket记录日志的详细程度，可选的级别包括info、warning、error和debug，其中info级别记录常规连接和解析信息适合日常使用，debug级别则会输出最详细的调试信息包括每次规则匹配和数据包处理细节。该参数对于排查连接故障和验证规则是否生效至关重要，当用户遇到节点连接异常或分流错误时，可将级别临时调至debug以获取完整的诊断依据，排查完毕后恢复至info避免日志过度占用存储空间。ipv6参数开启或关闭IPv6流量处理ipv6参数决定Shadowrocket是否处理设备的IPv6流量，设置为true时应用会接管IPv6数据包并按照配置规则进行分流或代理，设置为false则完全忽略IPv6请求。在纯IPv4网络环境下建议保持false避免不必要的解析尝试，而在支持IPv6的家庭宽带或移动网络中开启可提升访问IPv6资源的体验。如果用户发现某些网站加载缓慢且日志中出现IPv6相关错误，可尝试关闭此参数强制使用IPv4通道。网络行为与容灾策略配置dns-direct-fallback-proxy参数控制DNS解析失败时的备用路径dns-direct-fallback-proxy参数设置当直连DNS解析失败时是否自动切换至代理节点进行远程DNS解析，设置为true时应用会在直连DNS全部超时后通过代理通道重新发起查询。该功能在网络环境中DNS污染或公共DNS不可达时能够显著提升解析成功率和访问稳定性，但开启后首次访问新域名可能因代理解析路径变长而增加200至800毫秒延迟。对于频繁切换网络环境的移动用户建议开启，而对于网络稳定的家庭用户可根据实际解析质量决定是否启用。fallback-dns参数指定系统DNS回退地址fallback-dns参数用于定义当所有自定义DNS服务器均不可用且dns-direct-fallback-proxy也失败时的最终解析通道，填入系统分配的DNS地址或运营商提供的DNS可确保在最极端网络故障下保持基本访问能力。该参数应与dns-server中的地址保持同一阵营，避免在回退场景下引入污染风险。在纯IPv6网络环境中该参数需填入具备IPv6可达性的地址，否则回退可能因协议不匹配而失效。tfo参数启用TCP快速打开减少握手延迟tfo（TCPFastOpen）参数设置为true时允许应用在TCP三次握手完成前就开始传输数据，减少了一次往返延迟，尤其适合高频短连接的场景如网页浏览和API请求。该功能需要代理节点和服务端同时支持才能生效，在支持的环境下可降低约一个RTT的延迟，显著改善页面首屏加载速度。但部分老旧节点可能不支持该特性，开启后如出现连接异常可关闭此参数。性能优化与资源管理参数udp-relay参数控制UDP流量转发通道udp-relay参数决定是否允许UDP数据包经过代理通道，设置为true时Shadowrocket会捕获所有UDP请求并封装进代理隧道，这对于外服游戏、VoIP通话和WebRTC实时通信至关重要。如果该参数为false且用户尝试玩外服游戏，战斗数据将直接走本地网络绕开代理，导致操作延迟极高或频繁掉线。开启前需确认当前节点协议支持UDP转发，否则该参数无实际效果且可能造成UDP数据包丢失。skiptunnel参数配置不走代理的IP地址段skiptunnel参数允许用户指定完全绕过Shadowrocket代理处理的IP地址或CIDR段，填入的流量将直接由系统网络栈发出而不经过任何规则匹配或节点转发。该参数常用于将局域网内网IP段或特定直连服务器IP列入排除列表，避免内部网络请求被错误地送往代理节点导致访问失败。例如填入192.168.0.0/16可将所有内网流量直连，确保打印机、NAS等本地服务正常工作。tcp-keep-alive参数调整TCP连接保活间隔tcp-keep-alive参数设置TCP长连接的空闲保活探测间隔，以秒为单位，默认值通常为60秒，表示如果连接空闲60秒则发送保活包检测对端是否存活。适当缩短该值可更快检测到断线的代理节点并触发重连，但过于频繁的保活包会消耗额外带宽和设备电量。在网络质量不稳定的移动环境中建议保持默认或调至30秒，在固定宽带环境下可延长至120秒以减少不必要的探测流量。解密与高级功能开关skip-proxy参数排除特定域名的代理处理skip-proxy参数允许用户指定完全跳过代理的域名或后缀列表，配置的域名将直接直连而不经过任何代理节点和规则判断，该参数的使用优先级高于所有配置文件规则。该参数适合将内网服务域名或已知无需代理的国内服务域名列入其中，确保即使代理开关开启这些流量也不受干扰。与skiptunnel类似，该参数作用于应用层域名而非网络层IP地址，两者可配合使用实现多层面的直连控制。mitm参数开启HTTPS解密功能总开关mitm参数设置为true时启用Shadowrocket的HTTPS中间人解密能力，允许应用截获并修改加密流量内容，实现URL级别的规则匹配和广告脚本注入。开启后需在配置文件的[Host]或[URLRewrite]区域指定具体需要解密的域名列表，否则该参数不会生效。该功能会显著增加CPU负载和延迟，且可能触发银行应用的SSLPinning保护，建议仅在调试或特定去广告需求时开启，日常浏览保持关闭。dns-fallback-proxy参数与直连回退的区别dns-fallback-proxy参数与dns-direct-fallback-proxy功能相似但作用范围不同，前者在全局DNS解析失败时触发回退至系统DNS，后者则在直连DNS失败时通过代理通道重新解析。两者可同时开启形成“自定义DNS→代理解析→系统DNS”的三级容灾链条，有效应对各种网络环境下的DNS故障。建议在频繁切换Wi-Fi网络的场景下同时开启，而在网络稳定且对隐私要求较高的环境中仅开启代理解析回退而关闭系统DNS回退。规则引擎与匹配行为控制geoip-country参数指定IP归属地数据库路径geoip-country参数用于指定Shadowrocket加载的GEOIP数据库文件路径，该数据库用于判断目标IP地址所属国家或地区，是配置文件中GEOIP规则能够正常工作的核心依赖。默认情况下应用内置了精简版数据库，覆盖主要国家IP段，但用户可替换为社区维护的完整版数据库以提升IPv6地址段和新兴国家IP的识别精度。更新数据库后需重启Shadowrocket或重新加载配置使新数据库生效。exclude-route参数排除指定网络接口的流量拦截exclude-route参数允许用户指定不经过Shadowrocket代理处理的网络接口或路由表条目，填入相应的接口名称后可避免特定网络路径的流量被VPN接管。该参数极少用于日常配置，仅在设备同时连接多个网络接口（如同时使用Wi-Fi和USB网络共享）且需要特定接口流量直连时才会使用。普通用户无需调整该参数，保持默认值即可保证所有网络流量被统一处理。advertise-ipv6参数控制IPv6地址的广告行为advertise-ipv6参数控制Shadowrocket在代理通道中是否通告设备具备IPv6能力，设置为true时节点会向目标服务器表明客户端支持IPv6协议，可能获得IPv6格式的响应数据。该参数适用于纯IPv6节点或双栈节点环境，但在纯IPv4网络中开启可能导致解析结果出现IPv6地址而无法连接。用户应根据当前节点和网络环境的IPv6支持情况动态调整，避免因协议不匹配导致访问异常。日志与调试辅助参数debug参数开启超详细调试信息输出debug参数设置为true时Shadowrocket会输出比logleveldebug更底层的系统级日志，包括socket状态、系统调用返回值和协议栈交互细节，是排查节点连接根本问题的高级工具。该参数产生的日志数据量极大，持续开启会迅速填满存储空间并显著影响设备性能，仅在开发者指导下或复现特定网络故障时临时开启，排查完毕后必须立即恢复为false。logfile参数指定日志文件的存储位置logfile参数用于定义Shadowrocket日志文件的保存路径和文件名，用户可自定义存储位置以便于日志文件的导出和分析。默认情况下日志存储在应用沙盒内，普通用户无需修改该参数，但对于需要将日志传输至电脑进行深入分析的高级用户，可将路径指向iCloud云盘或共享目录以简化导出流程。修改该参数后需重启应用使新路径生效。warning-log参数单独记录警告级别日志warning-log参数设置为true时Shadowrocket会单独生成一份仅包含warning及以上级别的日志文件，与主日志文件分离存储，便于用户快速浏览潜在问题而无需过滤大量info信息。该参数对于日常监控代理运行状态非常实用，开启后用户可定期检查警告日志文件，及时发现节点延迟波动、规则匹配异常或DNS解析失败等潜在隐患，在问题影响使用前提前处理。常见问题FAQ

HTTPS解密（HTTPS Decryption）功能怎么用？要不要开？

针对普通用户的日常使用场景，HTTPS解密功能应始终保持在默认关闭状态，常规的域名分流和REJECT规则已能覆盖绝大部分访问需求，无需为了去广告而承担隐私泄露和性能损耗的风险。如需在特定调试场景下使用该功能，先在Shadowrocket的设置中点击生成并安装证书，务必前往“设置-通用-关于本机-证书信任设置”手动开启根证书的完全信任开关，否则解密功能无法生效。随后在当前激活的配置文件编辑界面中找到MitM或HTTPS解密白名单区域，精确填入需要解密的域名（如具体的视频网站域名），切忌使用通配符匹配所有域名，使用完毕后及时关闭该功能开关或切换至不含解密配置的备用场景，并定期访问检测网站验证无异常证书活动，以此在获取高级功能的同时守住基本的隐私安全边界。功能本质与基础运行逻辑中间人解密机制的工作原理HTTPS解密本质上是在本地设备与远程服务器之间建立一个受控的中间人代理通道，当Shadowrocket启用该功能后，应用会使用自签发的根证书替换服务器原有的SSL证书，从而截获并解密加密的传输数据。解密后的流量在应用内部经过规则引擎的审查和修改（如去除广告标签或修改响应头），之后重新加密并发送至目标服务器，实现内容级的深度干预。这一过程使得用户可以查看和修改请求体与响应体中的具体内容，其精细度远高于基于IP或域名的普通分流规则，但代价是彻底打破了端到端的加密原则。与常规代理模式的根本差异与常规的域名代理不同，HTTPS解密作用于应用层数据而非网络层路由，它允许用户查看和修改网页源码中的广告脚本或API返回的JSON字段。在不开启此项功能的情况下，Shadowrocket仅能根据目标域名或IP地址判断数据包的走向（代理或直连），无法感知包裹内部的具体内容。一旦开启，所有匹配规则的加密流量都将被拆包检查，这是实现视频网站去广告或模拟特定App请求等高级功能的必要条件，但同时也将用户的所有网络活动完全暴露给了本地的代理程序。数据包处理路径的显著变化开启该功能后，所有匹配解密名单的HTTPS请求都会经历“解密-审查-重新加密”的完整循环，每一次数据包传输都需要经过两次非对称加密握手和两次对称加密的加解密运算。这与普通代理模式仅进行简单的TCP转发形成了鲜明对比，处理路径的延长直接导致了CPU负载增加和响应延迟上升，用户在开启前必须清晰认识到这一性能代价。启用前的必备条件与证书安装流程根证书的生成与系统信任设置在Shadowrocket的设置页面中找到HTTPS解密开关并首次开启时，应用会自动生成一份专用的根证书，用户必须手动将该证书安装至iOS设备的系统钥匙串中，否则所有解密动作都会因证书无效而失败。安装路径为点击“安装证书”后跟随系统描述文件引导完成注册，此步骤仅需执行一次，后续更新Shadowrocket版本时通常无需重复操作，但若重装应用则需重新安装证书。证书信任设置的二次确认环节证书安装完成后还需要进入系统的证书信任设置进行二次确认，具体位置在“设置-通用-关于本机-证书信任设置”中，找到对应名称的证书并开启完全信任开关。如果遗漏此步骤，即使证书已安装在设备中，系统在TLS握手阶段仍会因信任链不完整而拒绝连接，导致所有启用解密的网站直接报错或无法加载，这是初次使用者最容易忽略且影响范围最广的关键环节。配置文件中解密白名单的激活操作在完成系统层级的信任后，用户还需进入当前激活的配置文件编辑界面，在HTTPS解密或MitM设置区域开启功能总开关，并在此处填入需要被解密的域名列表。只有在列表中明确声明的域名流量才会被解密，未声明的域名仍然保持端到端加密，这种白名单机制避免了不必要的性能损耗和隐私入侵风险，确保解密操作仅作用于用户指定的目标，而非全局无差别拦截。配置文件中域名解密的规则写法与应用策略精确指定需要解密的域名范围在配置文件的解密主机名列表中，用户需要输入确切的域名或使用通配符来指定范围，例如“*.example.com”将匹配该域名的所有子域名。列表中的域名与常规代理规则不同，它不决定流量走向而是决定哪些流量进入解密管道，只有同时满足代理策略和解密名单的请求才会被拆包检查，两者缺一不可，任何一方的遗漏都会导致解密功能不生效。缩小解密名单以降低性能损耗建议用户尽可能缩小解密名单的范围，只将确实需要修改内容的流媒体或广告密集站点加入列表，而非将所有境外域名全部列入。粗放地将整个互联网流量都纳入解密范围不仅会消耗大量CPU资源用于加解密运算，还会显著增加设备发热和电池消耗，且可能因频繁处理加密握手而导致页面加载速度出现可感知的下降，这种性能代价在旧款设备上尤为明显。验证域名是否成功进入解密通道对于使用了URL重写或脚本修改等进阶功能的用户，域名列表的准确性直接影响脚本能否获取到正确的响应数据。如果目标域名未正确填入解密名单，重写规则将因无法读取加密内容而失效，用户可通过查看连接日志中是否出现“MitM”成功标记来验证该域名是否已被正确纳入解密通道，这是排查功能失效问题的最直接手段。开启后对网速与设备性能的实际影响加解密开销带来的处理器负载增加HTTPS解密涉及两次完整的非对称加密握手和两次对称加密的加解密运算，每一次数据包传输都需要经历“解密-审查-重新加密”的完整循环，这比普通代理模式多出了至少一倍的CPU计算量。对于较旧的iPhone机型或电池健康度较低的状态下，持续进行大规模流量的解密操作可能导致设备明显发热并加快电量消耗，这是开启前必须考虑的性能代价，且该代价随流量规模线性增长。网页加载速度的延迟表现在网页加载速度方面，首次访问被解密域名时浏览器需要额外的时间来验证并接受Shadowrocket签发的替换证书，这通常会增加几百毫秒的握手延迟。虽然后续连接因会话复用会有所改善，但整体页面加载时间依然会因解密处理而比常规代理模式延长约10%至30%，对于仅需正常访问而非屏蔽广告的用户而言，这种速度牺牲并不值得，且累积效应会让日常浏览体验变得拖沓。实时应用场景下的操作滞后风险如果设备主要应用于外服游戏或实时音视频通话这类对延迟极其敏感的场景，开启HTTPS解密带来的额外处理时间可能会在关键时刻造成操作滞后或语音断续。建议在这些场景下临时关闭该功能或通过场景功能切换至不含解密规则的备用配置，以确保网络链路的响应速度优先于内容修改能力，避免因追求广告屏蔽而牺牲核心应用的交互实时性。应用兼容性风险与SSLPinning冲突金融类应用的强制证书校验阻断现代银行App、支付工具以及部分主流社交应用普遍实施了SSLPinning技术，即应用内部预置了服务器证书的哈希值，一旦检测到代理工具替换了证书便会立即中断连接并弹出安全警告。当HTTPS解密开启且这些应用的域名被误列入解密名单时，用户将遭遇频繁的登录失败或页面无法加载，且难以通过常规的代理规则调整来恢复，必须从名单中移除这些域名才能恢复正常功能。浏览器层级的证书安全警告即使是未实施SSLPinning的应用，开启解密后也可能因Shadowrocket的根证书与系统时间或地区设置不匹配而触发浏览器级别的安全警告，要求用户手动点击“继续访问”才能加载页面。对于普通用户的日常浏览而言，每一次访问都出现证书警告会严重破坏上网体验的流畅性，这使得该功能只适合在受信任的调试环境中开启，而非作为通用的加速或去广告工具使用。隔离风险的配置管理策略用户在决定是否开启时，应优先评估自己的应用使用清单，如果经常使用网银转账或企业级办公软件，保持该功能关闭是最稳妥的选择。若确实需要针对特定视频网站去广告，可创建一份独立的白名单配置文件，在需要时手动切换至该配置，使用完毕后立即切回常规配置，以此作为隔离风险的手段，避免因解密功能全局开启而影响所有应用的正常运行。普通用户与高级用户的决策权衡标准日常用户的关闭建议对于绝大多数仅需要日常网页浏览、视频观看和社交聊天的普通用户而言，HTTPS解密功能带来的安全风险和性能损耗远远超过了其去广告带来的视觉收益，强烈建议保持默认关闭状态。常规的基于域名的代理规则已经能够处理绝大多数国内外网站的访问需求，去广告需求可交由更专业的浏览器插件承担，无需在代理工具层面强行介入加密流量，这是最安全且最高效的使用方式。高级开发者的受控开启条件只有具备编程基础或需要抓取App接口数据、调试前端脚本的高级开发者，才适合在明确理解证书替换原理的前提下开启此项功能，并严格控制解密域名列表的长度。这类用户通常能够识别哪些域名值得解密，也清楚如何通过日志排查因证书问题导致的异常，其操作具有明确的调试目的而非模糊的“优化”期待，且能够接受由此带来的安全折衷。域名阻断作为解密功能的替代方案如果用户的主要诉求是去除视频应用中的片头广告，建议优先尝试规则集层面的域名阻断而非全面解密，因为大多数广告请求通过阻断信令域名即可被屏蔽，无需深入到数据包内部修改字段。只有确认域名阻断完全无效且愿意接受安全折衷时，再将HTTPS解密作为最后的实验手段，并严格限定在仅针对该特定应用的有限域名范围内，且在使用完毕后立即关闭。常见问题FAQ

Shadowrocket WebRTC真实IP泄露怎么防止？

要有效防止Shadowrocket下的WebRTC真实IP泄露，核心操作是进入当前配置文件的规则列表，添加一条针对stun关键词的DOMAIN-KEYWORD拒绝规则并将其调整至列表顶部，确保所有信令握手请求被第一时间截断。与此同时保持UDP转发功能开启并选择支持UDP协议的节点，强制将UDP打洞数据封装进代理隧道，从传输层面堵截直连出口。完成规则配置后立即访问WebRTC泄漏检测网站验证防护效果，只有检测页面仅显示代理IP而不出现本地IP时，防护才算真正生效。在后续使用中将这套规则保存至常用场景，并在系统或应用更新后重新检测，即可长期稳定地避免因WebRTC导致的隐私暴露风险。对于使用非浏览器应用的用户，同样可通过连接日志监控并补充遗漏的UDP直连记录，确保所有网络出口始终统一于代理节点。泄露原理与风险本质WebRTC协议如何绕过常规代理通道WebRTC是一个内置在现代浏览器和部分应用中的实时通信协议，其设计初衷是在NAT环境中实现点对点直连，为此会主动向STUN服务器发起请求以获取设备的真实公网IP和本地内网IP。这一过程发生在应用层之下，且独立于传统的HTTP代理设置。当Shadowrocket仅处于规则模式时，浏览器发出的WebRTC请求往往不会经过应用层的代理调度，导致真实IP直接暴露给服务器，即使用户已经开启了代理连接，检测网站依然能够读取到家庭宽带的原始出口地址。WebRTC流量特征与代理通道的冲突区分于常规网页请求，WebRTC使用特定的信令机制和UDP打洞技术，这种流量特征使得即使开启了全局代理，部分浏览器内核（如WebKit）仍会绕过系统VPN的虚拟网卡直接发送STUN查询数据包。在iOS生态中，Safari和部分内嵌浏览器的应用对这一机制的支持较为激进，用户可能在毫不知情的情况下，在访问账号绑定页面或观看流媒体时，将家庭宽带IP完全暴露给远端服务器，而Shadowrocket的界面却依然显示节点连接正常。真实IP泄露带来的账户安全与风控风险这种泄露带来的直接风险包括隐私地理位置暴露、绕过代理节点的地域伪装以及被目标服务商识别为多人共用一个网络环境。对于注重账号安全和地区解锁的用户而言，真实IP与代理出口IP的不一致极易触发风控机制，导致登录异常或服务封锁。例如流媒体平台检测到真实IP与代理IP跨洲差异时会强制退出登录，游戏平台则可能因IP不一致判定账号共享而施加临时限制，因此识别并阻断这一类特殊的流量请求是保护网络隐私中不可忽视的关键环节。核心防护方案一：通过配置规则阻断STUN服务器在分流规则中添加STUN域名拒绝策略最直接且高效的防护手段是在Shadowrocket的当前配置文件中，手动添加针对STUN服务器域名的拒绝规则。用户需要进入配置编辑界面的规则列表区域，新增条目并将域名类型设为DOMAIN-KEYWORD，匹配关键词如stun、turn、ice，并将策略强制设为REJECT或REJECT-DROP。这样一来，当浏览器或应用试图向这些标准的信令服务器发起握手请求时，连接会被瞬间截断，真实IP的获取流程在第一步即被终止，无需依赖浏览器的额外设置。补充IP规则与社区规则集以扩大拦截面除了基于域名的匹配外，用户还应考虑添加基于IP地址的阻断规则，因为部分STUN服务器采用动态IP或直接以IP形式提供访问。通过添加IP-CIDR规则并指向已知的STUN服务提供商IP段，可以形成双层拦截网。建议配合社区维护的WebRTC阻断规则集导入，这些规则集通常已覆盖主流的公共STUN地址，用户只需在配置中引用该远程规则集即可快速生效，避免手动逐一收集所有可能泄露渠道的繁琐过程。调整规则顺序确保拒绝策略优先执行在添加规则时需特别注意规则的排列顺序，务必确保这些拒绝规则位于任何泛直连规则或FINAL代理规则之前。若拒绝规则被前置的直连规则提前命中，STUN请求将绕开阻断逻辑直接发出，导致拦截完全失效。保存修改后需要切换一次配置或重启代理开关强制重载规则，随后通过专用的WebRTC泄漏检测网站即可验证阻断效果，如果检测页面不再显示真实IP，说明规则已正确生效。核心防护方案二：调整全局路由模式统一出口控制全局代理模式对WebRTC流量的强制管控作用将全局路由从“配置”模式临时切换至“代理”（全局）模式，可以有效解决因分流规则不完善导致的WebRTC流量绕过代理的问题。全局模式下Shadowrocket会强制接管所有系统流量，无论数据包属于何种协议都一律通过代理节点转发，对于使用UDP打洞的WebRTC流量，这种强制管控能够避免其利用规则漏洞直连网络，确保真实IP不会在规则匹配间隙中泄露出去，为排查规则问题提供干净的测试环境。全局模式作为应急手段与规则修正的辅助工具然而全局模式会将国内网站流量也推入代理通道导致访问速度下降，因此更优的策略是将此方法作为应急测试手段。用户可以先开启全局模式访问检测网站，如果此时真实IP不再泄露，则说明问题确实出在原有配置文件的规则覆盖不完整上，用户可以据此反推并修正规则文件，最终切回规则模式的同时保持阻断效果，实现速度与安全兼顾。永久全局模式的适用场景与取舍考虑对于不需要访问国内网站或追求极致隐私保护的用户，永久保持在全局模式下使用Shadowrocket配合支持UDP转发的节点，可以直接从流量入口层面彻底封堵WebRTC直连的可能性。这种方案牺牲了国内访问的延迟表现，但换来了更严密的网络行为统一性，确保所有应用和浏览器进程的数据包出口完全一致，杜绝了协议层面可能存在的任何直连漏洞。核心防护方案三：启用UDP转发与节点协议适配UDP转发如何封印WebRTC的打洞能力WebRTC的IP获取严重依赖UDP协议的连接性，开启Shadowrocket的“UDP转发”功能是强化防护的关键一环。当UDP转发启用后，所有本应发出直连的STUN探测数据包会被应用程序捕获并封装进代理隧道，从而无法触及本地网络接口。这相当于将打洞工具直接封印在代理通道内，使其失去了向STUN服务器询问真实IP的能力，从数据链路层面切断了泄露源头。确认节点协议支持UDP转发的必要条件开启UDP转发前必须确认当前使用的代理节点协议是否原生支持UDP中转，Shadowsocks、VMess均具备成熟的支持，而部分Trojan节点需检查服务端配置。若节点不支持UDP转发，强行开启不仅无法阻断WebRTC泄露，反而可能因UDP数据包在隧道口堆积导致网络延迟增加。用户应在节点编辑页面查看该节点的协议标识，确认支持UDP后再结合规则阻断执行双重保险，确保防护功能与代理性能同时在线。UDP转发与域名拒绝规则的互补防御关系在实际配置中UDP转发与域名拒绝规则是互补而非替代关系，域名拒绝规则在应用层拦截握手信令，而UDP转发在传输层强制改变数据走向。两者同时生效时，即便某条恶意请求绕过了域名关键词拦截，其发出的UDP查询包也会因强制隧道转发而无法直接连接本地网络。这种多层防御策略能够应对STUN服务器IP频繁变更或使用加密协议伪装的情况，大幅提升防护的鲁棒性。泄露风险的验证与持续监控方法通过专业检测平台进行配置有效性验证完成上述规则配置与模式调整后，用户必须通过专业的WebRTC泄漏检测网站进行实时验证。在开启Shadowrocket代理的状态下访问这些站点，如果检测结果显示的公网IP与当前代理节点的出口IP完全一致，且未列出本地运营商的真实IP地址，则说明防护策略已成功生效。建议同时使用Safari和常用应用的内置浏览器分别测试，确保不同浏览器环境下的安全性一致。利用连接日志辅助排查阻断是否正常触发验证过程中若发现检测结果同时显示了代理IP和本地真实IP，说明分流规则仍存在覆盖漏洞，此时需要返回配置检查是否漏掉了诸如Host或Origin头的匹配。用户也可以利用Shadowrocket的连接日志，在访问检测页面的同时观察日志中是否有STUN域名的连接被标记为REJECT，以此来确认阻断规则是否被正常触发，这是比单纯看检测结果更具参考价值的排障数据，能快速定位规则失效的具体环节。定期重新检测以应对网络环境动态变化网络环境是动态变化的，STUN服务器列表并非固定不变，因此防护配置需要持续维护。建议用户每隔一定周期重新运行一次泄漏检测，特别是当应用或系统更新之后。同时关注社区规则集的更新动态，及时将新增的STUN服务域名同步至自己的拒绝名单中，确保随着互联网基础设施的变化，Shadowrocket的防护策略始终处于最新且有效的状态。综合防护策略与最终操作建议构建常态化WebRTC防护的核心配置方案综合所有防护手段，最平衡且高效的方案是在保持规则模式作为日常使用模式的前提下，在配置文件中导入或手动编写针对STUN关键词的REJECT规则，并明确将UDP转发功能保持开启状态。同时利用Shadowrocket的场景功能将这套完整的防护配置打包保存，以便在连接不同的Wi-Fi网络时快速调用，避免重复配置规则或遗漏关键参数，让安全策略随场景无缝切换。浏览器层面加固作为辅助防线但非核心对于偶尔使用浏览器访问敏感账号或进行异地登录操作的用户，可以考虑在浏览器层面安装禁用WebRTC的扩展插件作为辅助防线，虽然这独立于Shadowrocket，但能形成客户端与代理应用的双重保险。不过最可靠的手段永远是代理规则层的强制阻断，因为这直接作用于网络数据包层面，无论应用端的设置如何变化，隧道口都保持着严密的过滤机制。养成验证习惯确保持续合规切勿因嫌麻烦而跳过验证步骤，仅凭经验判断配置有效往往会导致在实际攻击或风控场景下措手不及。养成每次调整配置文件后立即执行泄漏检测的习惯，并定期检查日志中是否存在非预期的UDP直连记录，这不仅能确保当前网络状态的安全合规，也能帮助用户及时发现Shadowrocket版本更新后可能引入的配置兼容性问题。常见问题FAQ

Shadowrocket玩外服游戏需要UDP转发吗？不开会有什么影响？

在Shadowrocket中配置外服游戏时，首先进入应用的设置页面找到UDP转发选项并将其开启，然后选择明确标注支持UDP协议的代理节点，开启代理后进入游戏进行完整的匹配和对局测试，观察战斗过程中的延迟数值和操作响应是否与登录界面的显示一致。对于实时竞技类游戏，保持UDP转发常开是确保操作同步和避免掉线的基本前提，而对战过程中如果发现开启后延迟反而波动剧烈，则需切换至延迟更低或地理位置更近的节点，因为UDP转发的实际效果高度依赖节点自身的网络质量和服务端配置。开启前可通过连接日志查看是否有UDP连接记录，确认该节点确实具备UDP代理能力，若日志中长时间无UDP记录则果断更换节点。对于回合制或卡牌类游戏，若关闭转发后游戏运行流畅且不掉线，可不开启以节省节点UDP带宽资源，但一旦出现匹配后无法加载对局的情况，仍需及时开启UDP转发来恢复完整功能。完成配置后，在Shadowrocket的规则模式中为游戏的目标域名和IP段配置代理策略，确保TCP和UDP流量均走同一节点通道，避免因规则遗漏导致部分数据包绕过代理而影响战斗体验的稳定性。外服游戏协议构成与UDP的实际定位登录与数据同步依赖TCP而实时对战依赖UDP现代网络游戏的网络通信通常采用双协议栈设计，TCP协议负责账号登录验证、商城购买、好友列表刷新以及游戏内聊天文本的传输，这些数据对完整性要求极高，丢失任何一段都可能导致状态不同步。UDP协议则专门承载实时性要求最高的对战数据，包括玩家位置移动、技能释放判定、伤害数值计算以及射击类游戏的弹道同步，这些数据允许少量丢失但绝不能等待重传，因为重传带来的延迟会直接破坏游戏操作的即时反馈。外服游戏服务器在设计时会将UDP流量视为玩家是否“在线且活跃”的核心判断依据，如果服务器持续未收到客户端的UDP心跳包，会判定该玩家已失去连接并强制将其踢出对局。国内直连外服UDP通道几乎不具备可用性国内玩家访问外服时，UDP包因无连接特性且缺乏重传机制，在跨洋路由中极易被运营商丢弃或延迟剧烈波动，这正是裸连外服频繁卡顿和掉线的根源所在。与TCP的可靠传输不同，UDP数据包在穿越多个路由节点时不会要求中间设备确认接收，一旦某个节点发生拥塞或丢包，游戏数据直接丢失且没有补救机制，玩家感知到的就是角色瞬移或技能无法释放。即使家庭宽带带宽充足，跨境的UDP包也可能因运营商的QoS策略被降级处理，优先级低于网页浏览和视频流量，进一步恶化了游戏体验。Shadowrocket默认配置仅代理TCP流量Shadowrocket对TCP流量的代理极其成熟且默认开启，所有登录认证和界面数据能够顺畅通过代理节点到达外服服务器，但UDP流量在默认配置下并不会自动进入代理隧道。如果用户只依赖规则模式中的域名匹配，往往只能覆盖游戏登录服务器的TCP请求，而对战中动态IP的UDP数据包则完全处于代理覆盖范围之外。这种配置偏差导致许多玩家误以为配置了代理就能畅玩外服游戏，却在进入对局后遭遇严重的延迟和掉线问题，根源就在于UDP流量从未经过优化通道。UDP转发开关直接影响战斗数据的传输路径开启后UDP数据包完整进入加密隧道当用户在Shadowrocket的设置页面中找到并开启UDP转发选项后，应用会捕获设备发出的所有UDP数据包，将它们封装进代理节点支持的传输协议中，通过加密隧道完整转发至代理服务器，再由代理服务器向游戏目标服务器发出。整个过程与TCP流量共享同一个代理通道，确保所有游戏数据无论是登录认证还是战斗同步都经过同一条优化后的网络路径，避免因路径分裂导致的网络质量不一致问题。开启后玩家在游戏内看到的延迟数值将真实反映代理节点到游戏服务器的链路质量。关闭时战斗数据完全绕开代理走本地直连若UDP转发保持关闭状态，Shadowrocket会完全忽略UDP流量，所有游戏对战的实时数据包直接通过设备的物理网络接口发出，不经过任何加密或代理隧道。这意味着游戏战斗数据走的是一条完全独立的直连路径，与代理节点当前所处的地理位置和网络优化毫无关联，即使代理节点延迟低至50毫秒，战斗数据的实际延迟依然取决于本地网络到外服服务器的跨境路由质量。这种分裂带来的直接后果是，玩家登录时走的是延迟优化后的代理隧道，进入对局后却切换至未经优化的本地网络，网络质量出现断崖式变化。路径分裂导致登录延迟低但对局体验极差登录界面显示的绿色延迟数值仅代表TCP认证通道的响应时间，而玩家真正关心的对战卡顿和掉线则完全由UDP路径决定。当UDP转发关闭时，游戏登录和商城界面流畅运行，一旦加载进入实际对局，操作响应就变得极为迟钝，角色动作滞后于按键输入半秒以上。这正是因为UDP转发未开启造成的路径不统一，玩家对局中的每一个操作指令都通过直连的UDP通道发送，完全绕过了本可优化跨境路由的代理节点，导致战斗体验与裸连几乎无异。不开启UDP转发时游戏内的典型异常表现匹配成功却无法加载进入对局最为典型的异常是在游戏匹配成功后加载进入对局的瞬间，进度条长时间卡在最后一点无法完成，随后弹出“连接服务器超时”或“无法加入比赛”的错误提示。这是因为游戏客户端在加载阶段需要向战斗服务器发起UDP握手请求以建立实时数据通道，而该请求因未走代理被远端服务器直接拒绝或在中途丢失，导致加载流程无法完成。玩家在匹配界面等待数分钟后被强制退出并收到惩罚警告，反复尝试仍无法正常开局。对局中频繁瞬移和技能延迟对于射击类或MOBA类游戏，即使勉强进入了对局，玩家会频繁出现角色瞬移、技能释放延迟、击杀判定滞后甚至直接被服务器踢出房间并收到“高延迟”或“网络不稳定”的警告。这些现象源于关键帧数据在直连路径上丢失率极高，服务器因长时间收不到客户端的UDP位置更新响应而主动中断连接，或通过算法补偿玩家的位置，导致画面中出现诡异的闪现和回弹。队友视角中该玩家的角色会频繁卡顿或原地踏步，严重影响团队协作和胜负走向。严格NAT限制导致匹配范围极小部分游戏存在“内网穿透”或“NAT类型检测”机制，在UDP转发关闭时，代理节点与本地网络之间的NAT映射不一致，可能导致严格的NAT类型限制，使得玩家无法与特定地区的玩家进行P2P连接。这种情况下玩家会发现匹配等待时间远超正常水平，或只能匹配到同一极小范围的玩家群体，游戏体验大打折扣。开启UDP转发后，代理节点作为中转能够统一NAT映射行为，大幅扩大可匹配的玩家池，提升匹配速度和对手多样性。开启UDP转发所需满足的服务器与节点前提条件节点协议必须原生支持UDP代理能力并非所有类型的代理节点都支持UDP转发功能，Shadowsocks协议对UDP转发的支持最为成熟且默认开启，VMess和VLESS协议同样在传输层提供了UDP转发能力，但部分老旧或精简配置的服务器端可能关闭了UDP端口映射。Trojan协议在处理UDP转发时依赖TLS隧道封装，对服务器端的资源配置要求较高，部分免费或低配置节点可能限制UDP流量的带宽或完全禁用该功能。用户需要确认所选节点的协议类型和服务商是否明确标注支持UDP转发，否则即使客户端开启也无法生效。服务端UDP端口映射必须正确配置即使协议本身支持UDP转发，代理服务器的实际配置决定了该功能是否可用，部分节点服务商为了节省服务器资源或简化防火墙规则，默认关闭了UDP关联的端口映射，导致客户端的UDP数据包到达服务器后无法被正确转发至目标游戏服务器。用户在开启Shadowrocket的UDP转发后如果游戏体验毫无改善，很大概率是服务端未开放UDP转发通道，此时切换至另一个明确标注支持UDP的节点是最直接的解决方案，无需在客户端反复调试其他参数。节点基础网络质量决定UDP转发的实际效果除了协议支持外，代理服务器本身的带宽和丢包率同样决定UDP转发的实际效果，UDP流量因无重传机制对网络抖动极为敏感，如果节点服务器本身存在高丢包率，开启UDP转发反而可能因隧道封装增加额外延迟，使游戏体验比关闭时更差。因此开启前应先通过TCP延迟测试和实际游戏加载速度确认节点基础质量达标，选择距离游戏服务器地理位置较近且带宽充足的节点，再启用UDP转发功能以获得最优效果。判断当前节点是否支持UDP转发的验证与排查方法通过实际对局测试是最直接的验证方式最直接的验证方法是开启Shadowrocket的UDP转发选项并进入游戏进行实际对战测试，观察对战过程中的延迟、丢包和稳定性是否显著优于关闭状态。如果开启后游戏体验明显改善且不再出现掉线或瞬移现象，则说明当前节点支持UDP转发且功能正常，这是最贴近真实使用场景的验证方式。建议在同一网络环境和同一时段内分别在开启和关闭状态下进行至少两局完整对局测试，通过对比操作反馈的即时性来判断UDP转发是否生效。利用连接日志查看UDP连接记录用户也可以利用Shadowrocket的连接日志功能进行辅助判断，在对战过程中查看日志中是否有UDP类型的连接记录以及这些连接是否成功通过代理节点建立。如果日志中显示UDP连接尝试被标记为“直连”或直接缺失相关记录，则说明UDP转发未能生效，需要排查节点配置或更换支持UDP的节点。日志中若出现“UDPoverTCP”或类似字样，则表明应用正在尝试通过TCP隧道封装UDP数据，虽然能够工作但效率较低，建议寻找原生支持UDP转发的节点。使用第三方测速工具对比开启前后的差异用户可使用第三方UDP测速工具或专门的游戏网络测试软件，在开启和关闭UDP转发两种状态下分别测试到外服游戏服务器IP的UDP延迟和丢包率。若开启后UDP延迟显著降低且丢包率归零，则说明节点的UDP转发通道工作正常且对游戏数据有明显优化效果。如果测速结果显示开启前后延迟无变化或开启后延迟反而升高，则表明该节点在UDP转发层面的配置存在问题，应果断切换节点或联系服务商确认UDP转发功能的实际可用性。针对不同游戏类型的UDP转发策略取舍建议实时对战类游戏强制开启UDP转发对于FPS射击游戏、MOBA竞技游戏以及赛车竞速类游戏，UDP转发应当始终保持开启状态，因为这些游戏的操作反馈和胜负判定完全依赖于毫秒级的UDP数据传输，关闭转发将导致无法正常对战。用户应将UDP转发视为这些游戏能够流畅运行的前提条件，而非可选的优化选项，如果当前节点开启后效果不佳，优先更换支持UDP转发的节点而非关闭功能。回合制或卡牌类游戏可灵活取舍对于回合制策略游戏、卡牌对战游戏或纯PVE刷图类游戏，如果游戏服务器允许纯TCP通信或对UDP依赖较低，关闭UDP转发可能不会导致掉线，而开启转发反而因加密和隧道封装增加微小的操作延迟。这类游戏用户可根据实际体验灵活开关，如果关闭后游戏运行流畅且不掉线则无需强制开启，以节省代理节点的UDP带宽资源用于其他应用。部分卡牌游戏仅在对战动画播放时使用UDP，此时关闭转发的负面影响几乎不可察觉。移动端游戏UDP转发带来的改善更为显著部分跨平台游戏在移动端和PC端的网络优化策略不同，移动端游戏往往对UDP的依赖程度更高且优化空间更大，因此即使同款游戏在PC上关闭UDP转发可玩，在iPhone或iPad上开启UDP转发带来的改善可能更为明显。手机设备的无线网络环境本就比有线网络更容易出现波动，UDP转发的加密隧道能够在一定程度上稳定数据传输路径，减少因Wi-Fi信号干扰导致的丢包。建议用户在初次配置游戏代理时先在开启状态下进行完整测试，再根据实际感受决定后续是否保持开启。常见问题FAQ

IPv6 Only网络下DNS怎么配置？

在纯IPv6网络中配置Shadowrocket的DNS，核心策略是首选填写国内公共IPv6DNS作为主解析服务器，如阿里DNS的2400:3200::1或DNSPod的2402:4e00::1，并将两个地址同时填入DNS覆写字段以利用并发查询的容错优势。针对境外域名可能遇到的解析污染问题，用户需保持dns-direct-fallback-proxy开关开启，并在节点的编辑页面或全局设置中启用远程DNS解析选项，确保代理通道能够独立完成境外域名的正确解析而不受本地IPv6DNS污染结果的影响。对于配置文件中的分流规则，务必补充IP-CIDR6类型的国内IPv6地址段直连规则，例如IP-CIDR6,240e::/20,DIRECT覆盖中国电信IPv6段，IP-CIDR6,2408::/20,DIRECT覆盖中国联通IPv6段，并将这些规则置于GEOIP规则之前，防止国内IPv6流量因数据库覆盖不全而错误地落入代理通道。同时检查代理节点自身是否具备IPv6可达性或是否支持通过IPv6隧道进行连接，如节点完全不支持IPv6，则在纯IPv6网络下该节点无法使用，需切换至具备IPv6出口能力的节点。配置完成后访问IPv6测试网站确认出口IP协议族是否正确，并开启连接日志验证DNS查询实际采用的服务器IP和解析结果的有效性，确保所有配置在纯IPv6环境下按预期工作。若该网络环境为IPv6优先而非纯IPv6，则用户可保留IPv4DNS作为备用并适当调整回退策略，不必严格按照纯IPv6方案全盘替换。网络环境差异决定了DNS服务器的可达性要求纯IPv6网络中DNS查询必须基于IPv6传输在纯IPv6（IPv6Only）网络环境中，设备仅配置了IPv6地址和路由，所有网络流量包括DNS查询请求都必须通过IPv6协议栈传输。如果用户将Shadowrocket的DNS覆写指向一个仅有IPv4地址的公共DNS服务器（如223.5.5.5），设备根本无法向其发起UDP连接，因为该地址在当前网络下不可达，导致所有域名解析失败。因此在IPv6Only网络中配置DNS的核心前提是：所填写的DNS服务器地址必须同时具备IPv6可达性，即服务器本身拥有全球单播IPv6地址且当前网络允许访问该地址。国内主流公共DNS均提供了稳定的IPv6解析节点国内主流的公共DNS服务商均已提供IPv6解析节点，阿里DNS的IPv6地址为2400:3200::1，腾讯DNSPod的IPv6地址为2402:4e00::1，114DNS的IPv6地址为240e:56:4000::114。这些地址在纯IPv6网络下可直接访问，无需依赖IPv4隧道或转换机制。用户在配置时应优先选择这些国内IPv6DNS，因为它们距离近、延迟低，且对国内CDN节点的调度精准度远高于海外IPv6DNS，能够确保国内网站在纯IPv6环境下的加载速度。配置前需验证设备与IPv6DNS之间的实际连通性用户需要特别注意，仅将DNS服务器地址改为IPv6格式并不能完全解决问题，还需要确认当前设备的Wi-Fi或蜂窝网络确实获取到了有效的IPv6DNS分配信息。如果网络本身是“IPv6优先”而非“IPv6Only”，设备可能仍依赖IPv4进行DNS查询，此时配置需根据实际路由策略调整。最直接的验证方法是在Shadowrocket关闭状态下，使用系统网络诊断工具ping通上述IPv6DNS地址，确认ICMPv6响应正常后再进行Shadowrocket内的配置。适用于纯IPv6网络的DNS服务器地址选型策略国内IPv6DNS与海外IPv6DNS的取舍需基于访问重心在纯IPv6网络下，国内IPv6DNS（如2400:3200::1）能够快速解析国内网站的AAAA记录或IPv6化的域名，返回距离用户最近的IPv6CDN节点，提供极低的解析延迟。海外IPv6DNS（如2606:4700:4700::1111）虽然也能在纯IPv6环境下访问，但其服务器物理位置远在海外，解析国内域名时往往返回针对海外用户调度的IPv6地址，导致国内网站访问绕行，速度显著下降。混用国内外IPv6DNS会因并发机制导致预期外的解析结果对于需要同时访问国内外网站的用户，不建议在纯IPv6网络中混用国内外IPv6DNS。并发查询机制下，国内IPv6DNS通常响应更快，会抢先返回国内CDN的IPv6地址，这本身是优点，但对于被污染的境外域名，国内DNS可能返回无效或错误的IPv6地址。因此用户需要根据自身访问重心选择阵营：以国内访问为主则使用国内IPv6DNS，以境外访问为主且需抗污染则应单独使用海外IPv6DNS。通过代理节点远程DNS实现国内外解析的精准分工如果用户的代理节点本身具备完整的IPv6双栈能力且规则模式配置得当，最稳妥的组合是以国内IPv6DNS作为主解析源，利用dns-direct-fallback-proxy或配置文件的远程DNS规则，将特定境外域名的解析请求通过代理节点转发至海外DNS完成。这样既保障了国内网站的极致速度，又确保境外受限域名能够获得正确解析，兼顾了速度和可达性。在Shadowrocket中正确填写IPv6地址的格式与注意事项IPv6地址在DNS覆写输入框中的标准写法Shadowrocket的DNS覆写输入框支持直接输入IPv6地址，无需特殊封装或添加方括号，用户只需将2400:3200::1或2402:4e00::1等地址以逗号分隔填入即可。与IPv4配置一样，多个IPv6DNS同样采用并发查询机制，响应最快的服务器胜出。但需注意，如果同时填入国内和海外IPv6地址，国内地址因延迟极低会抢先返回结果，而海外地址几乎不会在竞速中胜出，但其抗污染优势也随之失效。输入格式的完整性检查与地址可达性验证输入IPv6地址时务必检查格式的完整性，避免省略地址中的关键冒号或压缩过度导致Shadowrocket无法识别。标准的IPv6压缩格式如2400:3200::1是被完整支持的，但用户应确保该地址在当前网络下路由可达，否则填入不可达的IPv6DNS会导致解析超时并触发后续的容灾回退机制。建议先在浏览器或终端工具中测试该IPv6地址的响应情况，确认可达后再填入配置。保存配置后需刷新代理状态以应用新的DNS设置保存DNS覆写设置后无需重启Shadowrocket，但应关闭再重新开启一次代理开关，强制应用重新加载DNS配置并刷新本地缓存。在纯IPv6网络中，DNS解析的缓存策略与IPv4相同，但IPv6地址本身的TTL可能较长，修改DNS后需确保所有旧缓存已过期或被主动清除，否则修改后的DNS可能无法立即生效。用户可通过访问一个全新域名或清除应用缓存来验证新配置是否按预期工作。代理节点在纯IPv6网络下的DNS查询路径选择本地DNS解析与远程DNS解析的路径差异当用户使用SS或VMess等协议节点时，Shadowrocket默认在本地执行DNS查询，然后将解析到的IP地址通过代理节点转发。在纯IPv6网络中，如果本地DNS返回的是IPv4地址（A记录）而网络无法路由IPv4，代理连接将失败。此时用户需要在节点配置或全局设置中启用“通过代理节点解析DNS”或“远程DNS”选项，让代理服务器本身执行DNS查询，由其所在网络环境返回目标服务器的真实IP（可能是IPv4或IPv6），再建立隧道进行数据转发。远程DNS对本地污染解析结果的覆盖机制启用远程DNS后，本地DNS覆写的作用范围被限定于GEOIP规则的分流判断，而实际的连接目标由代理服务器解析结果决定。这意味着即使本地配置的是国内IPv6DNS，针对境外域名的解析结果被污染，只要该域名走代理通道，代理服务器通过海外DNS解析获取的正确IP仍能保证访问成功。因此用户可放心使用国内IPv6DNS享受本地直连网站的CDN加速，而不必担心污染影响代理访问。节点对远程DNS功能的支持程度决定配置的可用性需要注意的是，并非所有代理节点都支持远程DNS功能，部分老旧的SS节点或配置不完整的服务端可能无法处理代理解析请求。用户在纯IPv6网络中遇到节点连接成功但无法访问任何网站时，应优先检查当前节点是否支持远程DNS解析，并在Shadowrocket的节点编辑页面或全局设置中明确开启该选项。如果节点不支持，则需选择同时具备IPv6AAAA记录和良好IPv6路由的节点，或者将本地DNS完全切换为海外IPv6DNS以确保解析结果的正确性。分流规则在纯IPv6环境下的适应与调整GEOIP数据库对IPv6地址段的覆盖存在局限性规则模式下，GEOIP,CN,DIRECT规则依赖目标IP的归属地判断，但默认的GEOIP数据库对IPv6地址段的覆盖可能不如IPv4全面，部分中国境内的IPv6地址段可能未被识别为CN归属，导致本应直连的国内IPv6流量被错误地送往代理节点，降低访问速度且消耗流量。用户应确保Shadowrocket的GEOIP数据库更新至最新版本，或补充添加IP-CIDR6规则，手动写入中国运营商的IPv6地址段以实现精准直连。手动补充IP-CIDR6规则确保国内IPv6流量精准直连IP-CIDR规则在纯IPv6网络下无法匹配IPv6地址格式，用户需将涉及国内直连的规则类型修改或复制一份为IP-CIDR6，并填入国内IPv6的CIDR段，例如IP-CIDR6,240e::/20,DIRECT覆盖中国电信IPv6段，IP-CIDR6,2408::/20,DIRECT覆盖中国联通IPv6段。这些规则应放置在GEOIP,CN规则之前，确保IPv6流量在进入GEOIP判断前即被精准直连，避免因数据库覆盖不全导致的路由偏差。基于域名的分流规则在IPv6网络中依然完全有效对于代理境外流量的规则，DOMAIN-SUFFIX和DOMAIN-KEYWORD规则在纯IPv6网络中依然有效，因为这些规则匹配的是域名而非IP地址，与网络协议栈无关。用户只需确保配置文件中的直连规则能够同时处理IPv4和IPv6地址段，否则纯IPv6下的国内流量可能因未命中任何规则而落入FINAL,PROXY兜底策略，导致所有国内流量都走代理，速度变慢且流量消耗加剧。容灾与兜底机制在纯IPv6下的特殊配置回退系统DNS在纯IPv6环境中可能带来反效果DNS查询失败时回退系统DNS在纯IPv6网络中可能产生意料之外的效果，因为大多数网络环境下的系统DNS仍以IPv4为主。如果自定义IPv6DNS全部超时并触发回退系统DNS，系统可能返回一个IPv4地址或通过IPv4通道查询，导致设备在纯IPv6网络中无法建立连接。用户应考虑在纯IPv6环境下关闭该回退选项，或确保系统DNS本身也具备IPv6可达性，否则回退行为可能适得其反。dns-direct-fallback-proxy在纯IPv6下应始终保持开启dns-direct-fallback-proxy在纯IPv6网络中作用更加关键，因为当本地DNS无法解析出正确的IPv6地址或返回污染结果时，通过代理节点远程解析往往能获得正确的目标IP。建议在纯IPv6网络中保持该开关开启，并结合节点的远程DNS功能，形成“本地IPv6DNS优先解析→失败后代理解析”的双重保障，确保在任何网络故障情况下都能获得有效的解析结果。利用配置文件为境外关键域名单独指定代理解析用户在配置纯IPv6网络的DNS时，应优先保障本地国内IPv6DNS的稳定响应，同时开启dns-direct-fallback-proxy以应对境外域名的解析污染或失败。在Shadowrocket的配置文件中，建议为境外关键域名单独配置通过代理解析DNS的规则，或利用策略组的“远程DNS”选项，使特定流量的解析请求完全经由代理节点发出，从源头上规避本地网络对境外DNS解析的干扰，提升整体连接的可靠性和访问成功率。常见问题FAQ

DNS查询失败时回退系统DNS怎么设置？

在Shadowrocket中设置“DNS查询失败时回退系统DNS”的操作路径为：进入应用的“设置”页面，在DNS相关配置区域找到对应的开关选项并切换至开启状态，该功能无需额外配置参数，开启后立即生效。该设置的作用是在用户配置的所有自定义DNS服务器（如223.5.5.5、119.29.29.29或1.1.1.1等）因网络阻断、服务器故障或UDP端口封锁而全部无法响应时，自动降级至iOS系统默认的DNS服务器完成解析，确保设备在网络环境恶劣的情况下仍能维持基本的域名解析能力。它区别于dns-direct-fallback-proxy（后者通过代理节点远程解析），两者在解析失败的不同阶段介入，且可同时开启形成“自定义DNS→代理解析→系统DNS”三级容灾链条。开启回退系统DNS的最佳时机是用户经常切换网络环境（如出差、旅行或连接公共Wi-Fi）或曾遇到公共DNS在特定网络中被屏蔽的场景；而对于网络环境稳定的家用或办公用户，保持关闭状态可维持解析路径的简洁性并便于故障排查。配置完成后，通过访问全新域名并开启连接日志，可验证回退是否按预期工作——日志中若显示“fallbacktosystemresolver”则表明自定义DNS全面超时且系统DNS已接管。该设置应作为DNS容灾的最后防线使用，用户优先优化dns-server的质量和配置dns-direct-fallback-proxy，以降低系统DNS回退的实际触发频率。对于追求极致隐私保护的用户，关闭此选项并通过保持自定义DNS高可用或使用加密DNS来避免运营商DNS的介入，更符合其安全偏好。日常使用中，多数用户的DNS解析不会触发此回退，该开关的存在更多是为“万一”情况提供一道安全网，而非改变日常的解析行为。功能定义：理解回退系统DNS的真实含义该设置是DNS解析链的最后一道保护机制DNS查询失败时回退系统DNS是Shadowrocket中一项独立于dns-direct-fallback-proxy的容灾设置，其作用在于当应用配置的自定义DNS服务器（无论是公共DNS还是代理DNS）因网络问题、服务器宕机或被污染等原因无法返回有效解析结果时，自动降级至iOS系统默认的DNS服务器重新发起解析请求。系统DNS通常由当前Wi-Fi网络或蜂窝网络运营商自动分配，虽然解析速度和精准度不如公共DNS，但在公共DNS完全不可用的极端情况下，能够作为最后的解析手段确保设备基本网络访问能力。回退系统DNS与回退代理DNS是两条完全独立的备用路径用户需要区分两个容易混淆的功能：dns-direct-fallback-proxy是在直连DNS解析失败时通过代理节点远程解析，而本设置则是在所有自定义DNS均失败后，直接使用iOS系统默认DNS进行解析。前者利用代理通道的境外DNS能力，后者则回退至运营商或本地路由器分配的DNS，两者作用在不同的解析失败阶段。如果代理节点可用，优先使用代理解析能获得更抗污染的结果；如果代理节点也不可用或用户未开启代理，系统DNS回退则是最后的生存手段。该选项默认关闭且仅作用于自定义DNS全部失效的场景Shadowrocket在出厂设置中默认关闭此选项，意味着当用户配置的dns-server列表中所有DNS服务器均无法响应时，应用将直接报错并放弃解析，不会自动切换至系统DNS。关闭状态下，自定义DNS的稳定性直接决定了DNS解析的成败，一旦公共DNS出现区域性故障或网络屏蔽，用户可能大面积无法访问网站。开启后，应用在自定义DNS全面失败时会主动调用系统DNS，虽然速度可能稍慢或受运营商限制，但能保证基本网络连通性。设置位置与操作步骤详解在Shadowrocket设置页面定位回退系统DNS开关用户打开Shadowrocket应用后，点击底部导航栏的“设置”选项卡进入应用设置页面，在设置列表中向下滑动至“DNS”相关区域或“网络”设置区块。在该区域中，用户可以找到名为“DNS查询失败时回退系统DNS”或“FallbacktoSystemDNS”的开关项，该开关通常位于“DNS覆写”输入框下方不远处，与“通过代理更新DNS”和“DNS直连回退代理”等选项并列。此开关仅有开启和关闭两种状态，不涉及参数输入。开启后无需额外配置即自动生效当用户将该开关切换至开启状态后，该功能立即生效，不需要重启应用或重新加载配置文件。开启后，每次DNS解析流程都会在最后阶段增加一个“系统DNS保底”步骤：优先尝试dns-server中配置的DNS服务器→如果全部失败且开启了dns-direct-fallback-proxy则尝试代理解析→如果代理解析也失败或未开启→回退至系统DNS。系统DNS的调用完全由Shadowrocket在后台自动完成，用户无需手动输入任何IP地址。通过连接日志验证回退是否生效用户可在开启该功能后访问一个全新或缓存已过期的域名，同时在Shadowrocket中开启连接日志功能。在日志的DNS解析记录中，如果看到类似“DNSqueryfallbacktosystemDNS”或“usingsystemresolver”的提示，则说明自定义DNS已全部失效且回退系统DNS被成功激活。此时日志中会显示实际采用的DNS服务器IP地址，通常就是当前Wi-Fi路由器分配的DNS或运营商下发的DNS，用户可以据此判断回退是否按预期工作。与dns-server配置的协同关系与触发逻辑回退系统DNS仅在自定义DNS全部无响应时触发Shadowrocket在执行DNS解析时遵循严格的优先级顺序：首先向dns-server字段中填写的所有DNS服务器（无论填了几个）发起并发查询，如果其中任意一台在超时窗口内返回有效响应，则解析流程在回退系统DNS启动之前即告结束。只有在所有自定义DNS服务器均因网络不可达、UDP53端口被防火墙阻断或服务本身宕机而无法返回任何响应时，回退系统DNS才会被激活。这意味着日常解析顺畅时此功能完全不参与，只有在公共DNS大规模故障时才派上用场。自定义DNS返回污染结果时不会触发系统DNS回退一个关键的行为细节是：如果dns-server中的DNS服务器返回了格式正确但内容被污染的IP地址（即返回了一个虚假的IP），Shadowrocket会将此视为“解析成功”而非“查询失败”，因此不会触发系统DNS回退。回退机制仅针对“无响应”、“超时”或“返回格式错误”这类明确的技术失败，不涉及对解析结果正确性的判断。污染问题的解决仍需依赖dns-direct-fallback-proxy或更换DNS服务器，回退系统DNS无法改善被污染的错误结果。系统DNS回退与dns-direct-fallback-proxy的独立性和互补性两者在解析失败的不同阶段介入：当自定义DNS全部无响应时，如果dns-direct-fallback-proxy处于开启状态，应用会先尝试通过代理通道进行远程DNS解析；只有当代理通道解析也失败或该开关关闭时，才最终回退至系统DNS。这意味着开启dns-direct-fallback-proxy后，系统DNS回退的触发概率大幅降低，因为代理解析往往能够绕过本地网络限制获取正确结果。两者的合理组合是：优先保障代理解析作为备用，系统DNS作为最后保底，实现最高等级的解析可靠性。开启后的实际效果与典型应用场景公共DNS区域性故障时的自动解析保底当用户配置的公共DNS（如223.5.5.5、119.29.29.29）因服务器维护、区域性网络故障或运营商对特定UDP端口的临时限制而出现大面积超时时，开启回退系统DNS能够确保设备自动切换至当前网络运营商分配的DNS进行解析。虽然运营商DNS可能不如公共DNS精准，但至少能保证基本网页访问和网络应用正常工作，用户不会因公共DNS故障而完全断网。这种自动降级在用户毫无感知的情况下完成，避免了手动改换DNS的麻烦和时间成本。旅行或频繁切换网络环境时的自动适配当用户出差或旅行，在不同城市的酒店、机场或办公场所频繁切换Wi-Fi时，每个网络分配的系统DNS都不同，且部分公共Wi-Fi可能屏蔽了对公共DNS的UDP53端口访问。开启回退系统DNS后，即使用户配置的公共DNS在某酒店网络中被封锁，Shadowrocket能够自动切换至该酒店网络分配的本地DNS完成解析，确保网络连接不中断。这种机制大大提升了代理工具在不同网络环境下的自适应性，减少了用户手动调整配置的频率。在无代理环境且自定义DNS不可达时的基础网络保障如果用户在某些场景下关闭了Shadowrocket的代理开关，但仍然保留了自定义DNS设置（如223.5.5.5），而当前网络恰好无法访问该公共DNS（如公共Wi-Fi禁止外部DNS），此时开启回退系统DNS可以确保关闭代理后设备依然能通过系统DNS进行正常的域名解析，避免因自定义DNS不可用而导致即使关闭代理也无法上网的窘境。这一场景尤其适合那些习惯在代理和直连之间频繁切换的用户。潜在风险与适用边界运营商DNS可能存在污染或劫持风险系统DNS通常由运营商自动下发，国内部分运营商可能对特定境外域名实施DNS污染或插入广告页面。开启回退系统DNS后，在自定义DNS全部失效的极端情况下，这些被污染的解析结果会被采纳，导致访问境外受限网站时返回错误IP。虽然这种场景发生在“自定义DNS全部失效”的极端条件下（概率较低），但用户如果主要依赖代理访问受限内容，污染仍可能造成访问失败。用户可通过dns-direct-fallback-proxy优先代理解析来规避此风险。系统DNS解析速度可能慢于优质公共DNS运营商下发的系统DNS服务器通常位于用户所在城市的网络节点，物理距离近，但服务质量参差不齐，部分地区的运营商DNS服务器负载较高或配置陈旧，解析响应时间可能比公共DNS更长。在自定义DNS全部失效触发回退后，用户访问新域名时的页面加载速度可能比平时略微下降，但对于已缓存的域名无影响。这种速度降低仅限于公共DNS彻底不可用的极端情况，日常使用中用户几乎不会感知。回退至系统DNS后的解析结果可能影响分流规则系统DNS返回的IP地址归属地可能与公共DNS不同，当回退激活后，GEOIP,CN等规则依赖的目标IP发生改变，可能导致部分域名的分流路由出现偏差。例如系统DNS返回的国内CDNIP可能使本来应该走代理的境外域名被判定为国内流量而直连。虽然这种情况仅发生在自定义DNS全部失效的短暂故障窗口，且用户往往在此时更关注“能否访问”而非“分流精度”，但追求极致分流准确性的用户需留意这一影响。配置建议与最佳实践日常综合用户推荐保持关闭以减少变量对于大多数使用稳定网络环境且自定义DNS（如223.5.5.5、119.29.29.29）长期运行良好的用户，建议保持此开关关闭。关闭状态下，DNS解析路径更简单纯粹，出现问题时日志也更容易定位原因（直接指向自定义DNS故障而非系统DNS回退的干扰）。仅在明确遇到“自定义DNS全部无响应”且需要保持基本网络连通性的场景下，才考虑临时开启。多数情况下，通过更换dns-server中的IP地址或使用dns-direct-fallback-proxy已能解决解析问题，系统DNS回退属于最后手段。高频网络环境切换用户建议永久开启对于经常出差、旅行或连接各种公共Wi-Fi的用户，建议将该开关永久开启。因为不同网络的DNS访问策略差异极大，公共DNS在某些网络中可能被屏蔽，开启回退系统DNS可确保在任何网络环境下都能获得基本的解析能力，避免因DNS配置导致的断网体验。搭配dns-direct-fallback-proxy同时开启，可形成“自定义DNS→代理解析→系统DNS”三级容错链条，覆盖绝大多数DNS解析异常情况。在场景配置中绑定差异化策略用户可利用Shadowrocket的场景功能，为不同使用场景绑定不同的DNS容灾策略。例如在“家庭”场景中，因网络稳定且公共DNS可访问，可关闭回退系统DNS以保持解析路径简洁；在“移动数据”或“公共Wi-Fi”场景中，开启回退系统DNS以增强网络兼容性。通过场景切换，用户无需全局统一设置，即可在不同网络环境中应用最适合的DNS容灾策略，既满足了稳定网络的极致速度需求，也保障了多变网络的基本可用性。常见问题FAQ