作者： longuser

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

Shadowrocket加密DNS（DoH、DoT、DoQ）怎么配置？

在Shadowrocket中配置加密DNS（DoH、DoT、DoQ）时，标准操作是进入“设置-DNS”界面，在DNS服务器列表输入框中分别粘贴DoH的完整HTTPS地址或填写带端口853的DoT域名，亦可添加遵循“quic://”格式的DoQ地址，逐条添加后根据访问侧重将国内或国际服务器拖动排序至合理位置，然后返回主界面确保VPN连接处于激活状态使配置生效。配置完成后务必清除本地DNS缓存并通过实时日志确认每个目标域名的解析请求已从加密通道发出且返回IP正确，若解析异常则检查服务器地址可访问性并临时切换回明文DNS作为恢复手段，确认稳定后可关闭DNS劫持模块避免双重拦截干扰，让加密解析在保障隐私的同时与代理链路协同工作、稳定输出正确的域名解析结果。加密DNS与传统DNS的本质差异加密协议的三重技术优势DoH（基于HTTPS的DNS）、DoT（基于TLS的DNS）和DoQ（基于QUIC的DNS）是三种主流的加密DNS协议，它们共同解决了传统UDP53端口明文DNS查询存在的隐私泄露和内容篡改风险。传统DNS在设备与服务器之间传输时完全裸露，网络运营商或中间攻击者可以轻松截获并记录用户的每一个域名访问记录，甚至向查询响应中注入错误的IP地址实施DNS污染。加密DNS通过TLS或QUIC加密层将所有查询内容封装为密文传输，网络路径上的任何中间节点都无法读取查询内容也无法伪造响应结果，从根本上保障了解析链条的完整性和私密性。三种协议的技术路线差异DoH使用标准的HTTPS协议作为传输通道，将DNS请求封装在HTTP的POST或GET请求中发送，复用443端口使其流量特征与普通的网页浏览难以区分，具备最佳的穿透性和抗干扰能力。DoT则使用独立的TLS连接并绑定853专用端口，相比DoH少了一层HTTP封装开销解析速度略快，但独立的端口特征使其更容易被网络策略识别和拦截。DoQ是三者中最为前沿的方案，基于UDP的QUIC协议实现，在弱网环境下具备更快的连接建立速度和更强的丢包恢复能力，但当前支持该协议的服务商数量相对有限。加密DNS在代理链路中的核心价值在Shadowrocket的代理工作流中引入加密DNS，不仅保障了查询隐私，更是对抗DNS污染、确保代理节点获得正确目标IP的关键技术手段。当用户访问被污染的境外域名时，传统DNS会返回虚假的IP地址导致连接失败，而加密DNS通过境外服务器完成解析，返回的是目标网站的真实境外IP。结合代理链路的远端解析策略，加密DNS让域名查询与数据传输走同一条安全通道，消除了整个访问链路中最薄弱的明文环节，是构建完整加密代理体系不可或缺的一环。DoH协议的配置方法与参数填写获取可靠的DoH服务器地址配置DoH的第一步是获取服务商提供的DoH接入URL，这些地址通常以“https://”开头并在路径中包含特定的查询接口标识。国际主流服务商包括Cloudflare的“https://cloudflare-dns.com/dns-query”、Google的“https://dns.google/dns-query”以及Quad9的“https://dns.quad9.net/dns-query”，国内则推荐阿里云“https://dns.alidns.com/dns-query”和腾讯云“https://doh.pub/dns-query”以确保国内域名的低延迟解析。用户在获取地址后应先在浏览器中访问该链接，如果返回“400BadRequest”或类似响应则说明地址可访问且格式正确，如果返回超时则需更换其他服务商地址。在DNS服务器列表中添加DoH条目进入Shadowrocket的“设置-DNS”配置界面，在DNS服务器输入框中完整粘贴DoH的URL地址，输入完成后点击键盘换行键即可将条目添加至下方的服务器列表。添加时需注意URL必须包含完整的“https://”协议头，不能省略或误写为http，因为Shadowrocket严格依据协议头来识别DoH类型并启用对应的加密解析逻辑。如果需要同时配置多个DoH服务作为备选，重复粘贴操作即可依次添加，应用会在解析时并发请求所有列表中的DoH服务器并采用最快返回的有效结果。保留明文DNS作为加密解析的补充尽管DoH提供了优秀的隐私保护，但在网络环境极度受限或DoH服务器不可达的极端情况下，用户应在DNS列表中保留一至两个可靠的明文DNS作为保底解析通道。在DoH条目之后添加“223.5.5.5”或“119.29.29.29”等国内公共DNS的IP地址，Shadowrocket在执行并发查询时如果加密通道无响应，会自动切换至明文通道进行解析兜底。这种混合配置策略在确保加密解析优先的同时也大幅提升了网络在各种复杂环境下的容错性和稳定性，避免了因单一加密通道故障导致的全局断网风险。DoT协议的配置步骤与端口规范填写DoT服务器地址与853端口DoT协议的配置相对直接，用户无需输入完整的URL格式，只需在DNS服务器输入框中填写服务器域名或IP地址，并在其后使用冒号追加标准DoT端口853即可完成基本配置。有效的DoT服务器地址格式为“1.1.1.1:853”或“dns.google:853”，Shadowrocket在检测到端口为853时会自动启动TLS加密握手流程与服务器建立安全的解析通道。输入完成后点击换行键将条目加入服务器列表，应用会在首次解析请求发出时与服务器完成TLS证书验证和会话协商。指定SNI字段增强TLS握手兼容性在某些网络环境下，直接通过IP地址连接DoT服务器可能因TLS证书的域名验证失败而导致握手中断，此时用户可以在DoT地址后追加“#”符号并填写SNI（服务器名称指示）字段来强制指定证书校验域名。完整的格式为“1.1.1.1:853#cloudflare-dns.com”，这样的写法告诉Shadowrocket在TLS握手阶段使用“cloudflare-dns.com”来验证服务器证书，同时实际的网络连接仍指向IP地址1.1.1.1。SNI字段的填写解决了部分DoT服务器不支持直接IP访问时的证书校验问题，确保加密解析通道在任何网络环境下都能稳定建立。DoT与DoH的双协议并行部署DoT和DoH在技术实现上互不冲突且可以同时存在于DNS服务器列表中，Shadowrocket会在每次域名解析时并发向所有协议类型的服务器发起查询请求，返回最快的正确结果即为最终解析值。用户可以将DoH服务器作为优先的穿透首选，同时将DoT服务器作为加密保底，两种协议复用不同的传输层通道，单一协议的故障或干扰不会影响另一种协议的正常运作。这种双协议并行的冗余架构在对抗复杂网络环境下的DNS干扰时表现出极高的可靠性，即便某种加密DNS协议在特定网络中被封锁，另一种协议仍然可以维持正常的加密解析服务。DoQ协议的前瞻性配置与兼容性理解DoQ基于QUIC的协议特性DoQ是DNS-over-QUIC的缩写，它利用QUIC协议的多路复用和0-RTT握手特性，将DNS查询的建立延迟压缩到极致，尤其适合在移动网络和高丢包率的弱网环境中发挥优势。与DoH和DoT基于TCP不同，DoQ通过UDP传输数据且内置了拥塞控制和丢包恢复机制，在信号不佳的移动场景中表现远优于基于TCP的加密DNS协议。但DoQ作为较新的技术标准，目前公开提供DoQ服务的公共DNS服务商还相对有限，主要集中Cloudflare（端口784）和Quad9（端口8853）等少数技术前瞻的厂商。DoQ服务器地址的特殊格式要求在Shadowrocket中添加DoQ服务器时，输入格式必须遵循“quic://域名或IP:端口”的固定范式，例如“quic://cloudflare-dns.com:784”或“quic://9.9.9.9:8853”，应用会根据前缀“quic://”自动识别并启用基于UDP的QUIC解析通道。与DoH的URL格式不同，DoQ地址不需要完整的路径后缀，只需指定服务器地址和对应端口即可，Shadowrocket会在QUIC会话建立后自动协商标准的DNS-over-QUIC请求格式。输入完成并保存后，应用在首次解析时会尝试与DoQ服务器完成QUIC连接握手，若网络环境和服务器均支持，加密解析通道即告建立。当前版本兼容性与降级策略由于DoQ仍处于技术推广阶段，不同版本的Shadowrocket对DoQ协议的支持程度可能存在差异，用户在配置后若发现解析异常可通过实时日志查看具体的握手错误信息。如果当前使用的Shadowrocket版本不支持DoQ或网络环境不兼容该协议，应用会自动将该条目降级为普通的UDP明文解析并忽略加密特性，用户可从日志中获知降级信息并决策是否继续使用。为了确保解析服务的绝对连续性，建议将DoQ作为高级补充选项而非唯一的解析通道，同时保留DoH或DoT作为主力的加密解析方案。国内外DoH服务器的混合排列策略国内服务器优先保障本土访问速度在DNS服务器列表中，用户应将国内的DoH服务器（如阿里云和腾讯云）排列在最前端，因为国内服务器在解析国内主流域名时能够返回经过优化的本地CDN节点IP，确保百度、淘宝、微信等高频访问网站的页面加载速度最优。国内DoH服务器同样通过HTTPS加密通道传输查询内容，在隐私保护和抗污染能力上与国际服务器一致，但对国内域名的解析准确性和响应速度具有天然的地缘优势。将国内服务器前置也符合“高频命中规则前置”的性能优化原则，绝大多数网络请求的域名解析需求能够由列表前端服务器快速响应，有效降低解析延迟。国际服务器保障境外域名的纯净解析在国际DoH服务器的选择上，Cloudflare和Google的公共DNS在解析境外域名时返回的是全球最优的AnycastIP地址，且能够有效规避因本地网络策略导致的域名污染问题。将这些国际服务器放置在列表的中后段位置，确保在解析境外域名时国内服务器若返回异常结果，应用能够快速从备用国际服务器获得纯净的正确解析。混合列表中的国际服务器与国内服务器形成解析互补，国内服务器专注于速度和准确性，国际服务器专注于抗污染和覆盖面，两者共同构建了一个既能快速响应国内域名又能准确解析境外域名的完整解析矩阵。根据网络环境动态调整列表组合当用户处于国内网络环境时，可适当增加国内DoH服务器的比重并在列表中置前；当用户通过代理节点访问境外网络时，可增加国际DoH服务器的数量并提升其在列表中的优先级。用户可以在Shadowrocket中创建多个配置文件，每个配置文件预设不同的DNS服务器组合和排序，并通过按WiFi自动切换配置的快捷指令在不同网络环境下自动加载对应的DNS配置。这种基于网络环境的动态DNS调整策略，让用户在国内和境外网络之间移动时始终拥有最优的域名解析路径和抗污染能力。配置后的验证流程与故障速排通过实时日志确认加密通道启用完成DNS覆写配置后，用户应当立即打开Shadowrocket的实时日志功能并访问一个目标域名，在日志输出中搜索包含“DNS”或“解析”标签的记录，查看每条记录的解析服务器地址和响应状态。如果日志中显示的服务器地址与用户配置的DoH或DoT地址一致，且记录尾部标注有“TLS”或“HTTPS”的加密标识，则说明加密解析通道已成功建立并处于正常工作状态。若日志中显示的解析服务器地址与配置不一致或未显示加密标识，则表明配置未被正确加载，需要返回DNS设置页面检查地址格式和协议头是否填写正确。清除缓存与强制刷新解析状态在修改DNS配置后，iOS系统和Shadowrocket的内部缓存中可能仍保留着旧配置下的解析结果，导致新配置的DoH或DoT通道无法立即生效。用户应在DNS配置页面底部点击“清除DNS缓存”按钮强制清空所有本地缓存的记录，同时关闭并重新开启VPN连接让网络栈完全重置，确保后续发出的每一个域名解析请求都完全基于新配置的加密通道发起。清除缓存后重新访问目标网站并通过实时日志观察每次解析的详细过程，确认所有域名查询均已经过配置中的DoH或DoT服务器完成，无任何请求回落至明文DNS通道。故障识别与紧急回退方案当配置加密DNS后出现大面积网页无法打开或解析超时的情况，用户应首先检查DoH或DoT服务器地址是否可访问，在浏览器中尝试访问DoH的URL地址或通过telnet测试DoT的853端口连通性。若确认服务器地址无误但仍解析异常，可以临时将DNS配置切换回明文DNS（如114.114.114.114）作为应急恢复手段，待网络环境稳定后再逐步重新启用加密通道。持续的解析失败可能源于本地网络对非标准端口的封锁或对HTTPS流量的拦截，此时用户可通过代理节点完成DoH解析请求的转发，即在使用代理模式的前提下刷新DNS配置。常见问题FAQ

Shadowrocket的DNS覆写怎么设置？

在Shadowrocket中配置DNS覆写时，用户应当先从“设置”页面进入“DNS”配置面板，在DNS服务器列表中添加国内和境外组合服务器确保基础解析覆盖，然后根据网络环境决定是否开启DNS劫持来拦截硬编码请求，在配置文件中为代理域名规则启用force-remote-dns修饰符以保障远端解析的准确性和抗污染能力，并可针对特殊域名在Hosts模块添加静态IP映射以超越所有解析策略实现强制路由。配置完成后务必执行清除DNS缓存操作并通过实时日志验证每个目标域名的实际解析服务器和返回IP，确认无误后在后续使用中定期检查服务器列表的可用性和Hosts记录的时效性，当网络异常时优先通过关闭劫持或恢复默认DNS列表来回退配置并逐步排查故障环节。DNS覆写的核心功能与入口定位理解DNS覆写在代理链路中的作用DNS覆写是Shadowrocket中一项关键的域名解析干预功能，它允许用户自定义设备发出的所有DNS查询请求的目标解析服务器，并控制这些查询通过何种网络路径发出。在默认情况下iOS设备使用运营商或本地网络分配的DNS服务器进行域名解析，但这些服务器在解析境外域名时可能返回被污染的错误IP地址，导致代理通道完全失效。DNS覆写通过在VPN隧道内部接管所有DNS请求，让用户将解析任务交给更可靠且支持加密传输的DoH或DoT服务器，确保每次域名查询都能获得准确无误的IP地址，从根本上规避了DNS污染对代理访问的干扰。设置入口的具体位置与界面导航在Shadowrocket主界面中点击底部导航栏的“设置”标签进入全局设置页面，在众多配置项中找到并点击“DNS”选项即可进入DNS覆写的核心配置界面。该界面自上而下依次排列着“DNS服务器”列表、备用DNS配置、DNS劫持开关以及Hosts静态记录等关键设置模块，每个模块对应不同的覆写策略和适用场景。不同版本的Shadowrocket在界面布局上可能存在细微差异，但“DNS”选项始终位于设置列表的前半部分，用户可通过滑动列表快速定位并进入该配置面板。启用DNS覆写前的系统权限确认DNS覆写功能依赖于Shadowrocket的VPN隧道处于激活状态才能正常工作，因为所有经过覆写的DNS查询都需要通过虚拟网卡进行拦截和重定向。在配置DNS覆写之前用户应当确保应用已成功建立VPN连接，并确认iOS系统设置中Shadowrocket的“蜂窝网络”和“后台应用刷新”权限均已开启，否则DNS请求可能绕过VPN直接由系统默认DNS服务器处理。如果VPN连接状态不稳定或权限配置不完整，即使DNS覆写设置保存成功，实际解析效果也可能无法正常体现。基础DNS服务器列表的配置方法在DNS设置中添加自定义服务器地址在DNS配置界面顶部找到“DNS服务器”输入框，点击后手动输入希望使用的DNS服务器IP地址或加密协议链接，输入完成后点击键盘上的“换行”或“返回”键即可将该服务器添加至下方的使用列表。用户可以根据解析需求同时添加多个DNS服务器，Shadowrocket在执行域名解析时会同时向所有列表中的服务器发起查询，并采用最快返回正确结果的应答作为最终解析值，这种并发查询策略既保证了解析速度也提升了容错率。如果需要移除某个服务器，左滑该条目并点击“删除”按钮即可完成移除操作。国内与国际服务器的组合推荐方案为了兼顾国内网站的低延迟解析和境外网站的抗污染解析，推荐用户将国内公共DNS与境外安全DNS同时填入服务器列表，形成内外兼顾的混合解析策略。国内推荐使用阿里云DoH（https://dns.alidns.com/dns-query）和腾讯云DoH（https://doh.pub/dns-query），这两组服务器在大陆网络环境下解析速度快且支持加密传输，能够确保国内域名的快速准确解析。国际方面推荐接入Cloudflare的1.1.1.1和Google的8.8.8.8作为补充，这些服务器在解析境外域名时返回不受污染的正确IP地址，两者组合能够覆盖绝大多数的国内国际访问场景。服务器排列顺序对解析效率的优化作用DNS服务器在列表中的排列顺序会影响Shadowrocket并发查询时的处理优先级，虽然应用会同时向所有服务器发起请求，但列表靠前的服务器会在请求构造阶段获得更优先的处理资源分配。高频访问国内域名的用户应当将国内DNS服务器放置在列表前端，使得大多数国内域名的解析请求由国内服务器优先响应，缩短整体的解析等待时间。列表顺序的调整通过长按条目右侧的拖动柄上下移动即可完成，用户可以根据自身的网络使用习惯随时调整排列次序以获得最佳的解析体验。DNS劫持与强制重定向的设置理解DNS劫持对硬编码请求的拦截逻辑某些应用程序在代码中硬编码了固定的DNS服务器地址（如8.8.8.8），这些请求会绕过Shadowrocket的DNS服务器列表直接发送至硬编码的目标服务器，导致用户的自定义DNS覆写策略对这些应用完全失效。DNS劫持功能通过拦截所有目标端口为53的DNS查询数据包，强制将这些请求重定向至用户指定的DNS服务器，从而彻底接管应用中所有硬编码的DNS查询行为。开启劫持后即使用户不手动修改系统DNS设置，所有应用和系统服务的域名解析请求都会被Shadowrocket的VPN隧道捕获并按覆写规则处理。劫持目标地址与端口的具体填写规范在DNS配置界面的“DNS劫持”模块中，用户需要在输入框中填写希望重定向到的目标DNS服务器地址及端口，常见格式为“8.8.8.8:53”或“1.1.1.1:53”，填写完成后点击开关按钮即可激活劫持功能。如果用户同时在DNS服务器列表中配置了加密DoH服务器，劫持地址同样可以填写这些加密服务器的IP地址和对应端口，将所有明文DNS请求统一转发至加密解析通道。劫持地址的端口号必须为53（标准DNS端口）或853（DNS-over-TLS端口），填写非标准端口可能导致劫持功能无法正常拦截和转发请求。劫持开启后的流量路径变化DNS劫持功能激活后，设备上所有发往任意DNS服务器的UDP端口53请求都会被VPN隧道截获并替换目标地址为用户指定的劫持目标，从网络层面看这些请求的原始目标被完全覆盖。这种强制重定向同时覆盖了系统级DNS查询和应用内置的硬编码DNS请求，确保用户配置的DNS覆写策略在所有网络场景下都具有绝对的控制权。但劫持功能一旦开启，某些依赖于特定DNS响应进行网络连通性检测的应用可能因解析路径改变而出现短暂的网络感知异常，用户在开启该功能后应观察常用应用的行为是否出现非预期的变化。基于规则集的精细化DNS分流为代理规则启用force-remote-dns参数在Shadowrocket的配置文件中，用户可以在RULE-SET规则后方添加“force-remote-dns”修饰符，强制匹配该规则的域名解析请求通过代理节点所在的远端DNS服务器完成解析。该修饰符的作用在于当某个域名被明确划分为代理流量时，其DNS解析也同时交由境外DNS服务器处理，彻底规避本地DNS污染或运营商劫持对解析结果的干扰，确保代理节点获取到的是目标网站的真实境外IP地址。在配置文件中添加该修饰符后，代理链路的DNS解析路径与数据转发路径保持一致，有效消除因解析结果错误而导致的连接失败或路由错误。国内直连域名保持本地解析的策略对于配置文件中的国内网站直连规则，用户应当确保这些规则不添加force-remote-dns修饰符，使其保持由本地DNS服务器解析的默认行为，从而获得最快的域名响应速度和最低的解析延迟。国内主流网站如果通过境外DNS服务器解析，可能返回的是针对境外用户的CDN节点IP地址，导致访问速度大幅下降甚至出现访问被拒绝的情况。通过区分代理域名和直连域名的DNS解析路径，用户可以在保障境外网站可访问性的同时，维持国内网站的高速稳定访问体验。规则中DNS修饰符的添加方法与注意事项在配置文件的规则列表编辑界面中，用户点击具体规则条目后可以在策略动作区域找到并勾选“force-remote-dns”选项，勾选后该规则的所有匹配请求都会强制通过远端DNS解析。这一修饰符只对策略动作为PROXY的规则有效，对于DIRECT或REJECT动作的规则添加该修饰符不会产生任何实际效果，因为直连和拒绝流量本就不涉及代理节点的DNS通道。用户在添加修饰符时应当合理评估每个代理域名的解析需求，避免不加区分地为所有代理规则统一添加该参数，以减少不必要的远端DNS查询对解析速度的影响。本地静态DNS记录（Hosts）的覆写设置Hosts静态映射的功能定位与适用场景在DNS配置界面的底部找到“Hosts”模块，用户可以在这里添加自定义的域名到IP地址的静态映射记录，这些记录在Shadowrocket的DNS解析过程中拥有最高的优先级。Hosts映射适用于需要将特定域名固定指向某个IP地址的场景，例如将内部OA系统的域名映射到公司内网IP、屏蔽特定网站的访问（映射到127.0.0.1）、或在测试环境中强制域名指向测试服务器IP。Hosts记录的优先级高于任何DNS服务器返回的解析结果，是实现域名级别的强制路由控制的最直接手段。静态记录的添加格式与操作步骤在Hosts模块中点击右上角的加号图标进入添加记录界面，第一行输入需要映射的完整域名（如“test.internal.com”），第二行输入对应的IP地址（如“192.168.1.100”），点击保存后该静态记录立即生效。添加完成后返回DNS配置主界面，可以看到新记录出现在Hosts列表中，每条记录以“域名->IP地址”的形式清晰展示，用户可以随时点击编辑或左滑删除进行管理。对于需要批量添加大量Hosts记录的高级用户，可以通过导入.conf格式的配置文件一次性完成多条记录的批量添加，大幅提升配置效率。Hosts记录与规则引擎之间的优先级关系Hosts静态记录在Shadowrocket的处理流程中位于DNS解析的最前端，当某个域名在Hosts列表中存在映射时，引擎会直接使用该IP地址而不会向任何DNS服务器发起查询请求，这意味着Hosts记录完全绕过了DNS服务器列表和劫持配置。Hosts记录的优先级高于配置文件中所有基于域名的分流规则，因为域名在进入规则匹配之前就已经被解析为IP地址，后续的规则引擎处理的是IP层面的匹配。利用这一高优先级特性，用户可以通过Hosts记录强制将特定域名的流量定向到特定IP，实现比规则分流更底层的路由控制。配置后的验证、缓存清理与故障恢复通过实时日志验证DNS解析结果完成DNS覆写配置后，用户打开Shadowrocket的实时日志功能并访问一个目标网站，在日志输出中查找包含“DNS”或“解析”标识的条目，可以清楚看到该域名实际使用了哪个DNS服务器进行解析以及返回的IP地址。日志中的解析记录能够直接验证DNS服务器列表是否生效、劫持功能是否成功拦截了硬编码请求以及force-remote-dns修饰符是否被正确执行。如果日志显示解析服务器并非用户配置的目标服务器，说明配置过程中存在格式错误或权限问题，需要返回设置页面逐一检查每个配置项。清除本地DNS缓存强制应用新配置在修改DNS覆写设置后，Shadowrocket和iOS系统层面可能仍然缓存着旧配置下获得的DNS解析结果，导致新配置无法立即生效。用户应在DNS配置页面底部点击“清除DNS缓存”按钮强制清空所有本地缓存的解析记录，同时也可以在iOS“设置-通用-日期与时间”中开关一次“自动设置”来触发系统级DNS缓存的刷新。清除缓存后重新访问目标网站，所有域名解析请求都会基于最新的覆写配置重新发起查询，用户可以通过实时日志确认新配置已正确加载并返回预期的解析结果。配置失效时的回退方案与故障排查当DNS覆写配置导致网络出现大面积解析异常时，用户可以快速回退到默认解析设置，在DNS配置界面中逐一删除所有自定义DNS服务器条目并在劫持模块关闭开关，配置保存后Shadowrocket将恢复使用系统默认的DNS解析路径。如果回退后网络仍然异常，用户可尝试重启iPhone彻底重置系统网络栈，清除所有残留的缓存和路由表数据后再逐步重新配置DNS覆写选项。在重新配置过程中应当逐步添加各个DNS组件（先加服务器列表再开劫持），每添加一个组件都通过日志验证其效果，避免一次性启用所有功能导致故障原因无法定位。常见问题FAQ

Shadowrocket按WiFi网络自动切换配置怎么设置？

在Shadowrocket中实现按WiFi网络自动切换配置时，用户应当在快捷指令中创建以WiFi连接为触发条件的个人自动化，将目标配置的URLScheme切换命令嵌入其中并关闭运行前询问以实现静默执行。完整的操作流程为：先确认配置文件名称和SSID的精确拼写，再进入快捷指令应用创建自动化并设置WiFi触发条件，在操作中添加URL和打开URL两个块并填入切换命令，保存后关闭运行前询问即完成单WiFi规则创建。对于多个网络场景，为家庭、公司、公共等不同WiFi分别创建独立的切换规则并为关键网络配置断开时的回退规则，同时定期检查自动化的执行记录以确保持续有效性，当自动化失效时使用Siri快捷指令或桌面书签作为手动切换的应急方案。自动切换的技术实现原理与前置条件基于iOS快捷指令的自动化调度机制Shadowrocket本身并未内置按WiFi网络自动切换配置的原生选项，该功能需要借助iOS系统自带的“快捷指令”应用来实现间接控制。用户通过在快捷指令中创建个人自动化触发器，当设备连接或断开特定WiFi网络时，系统会自动执行预设的URLScheme命令来通知Shadowrocket执行配置切换操作。这种外部调度机制充分利用了iOS系统的自动化能力，使得配置切换无需用户手动介入即可在后台完成，但同时也要求用户对快捷指令的创建流程有一定熟悉度。系统权限与后台运行的必要条件为了确保WiFi触发时的配置切换能够顺利执行，用户需要提前在iOS系统设置中为快捷指令应用开启“允许不受信任的自动化”选项，并确保Shadowrocket的后台应用刷新权限处于启用状态。快捷指令自动化依赖于系统的定位和网络权限，用户在首次创建自动化时系统会弹出权限请求弹窗，必须点击“允许”才能让自动化在无用户干预的情况下正常触发。如果后台刷新权限被关闭，设备锁屏后快捷指令可能无法及时唤醒Shadowrocket执行切换命令，导致自动化失效。配置切换针对不同网络环境的实际价值按WiFi自动切换配置在家庭、公司和公共场所等不同网络环境下有着极高的实用价值，用户可以根据每个网络的特点预设最优的代理策略和路由规则。在家中连接家庭WiFi时自动加载“家庭配置”采用直连为主的分流策略，在公司WiFi下自动切换至“工作配置”使用特定节点访问内网资源，在连接公共WiFi时自动启用“安全配置”强制所有流量走代理以保护隐私。这种自动化切换让用户彻底告别手动切换配置的繁琐操作，设备在不同网络间移动时始终处于最佳网络策略的覆盖下。准备阶段获取配置文件名称与SSID参数在Shadowrocket中确认配置文件精确名称创建自动化命令前用户首先需要进入Shadowrocket的配置页面，查看当前已保存的所有配置文件的完整名称列表，因为URLScheme命令中的配置名称参数必须与列表中的名称完全一致才能成功切换。配置文件名称区分大小写且包含空格，用户应当长按配置名称选择复制而非手动输入，避免因大小写或字符差异导致命令执行失败。如果配置名称中包含中文或特殊符号，URLScheme中应当使用原始字符而无需进行URL编码，因为Shadowrocket的解码器会自动处理这些字符。记录目标WiFi网络的SSID全称在快捷指令中设置WiFi触发条件时，系统会要求用户输入或选择目标网络的SSID，这个SSID必须与设备实际连接的网络名称完全匹配才能触发自动化。用户可以在iPhone的“设置-WiFi”中查看当前连接网络的完整名称并截图保存，特别注意SSID中的空格、大小写和特殊符号，任何细微的差异都会导致触发条件不满足。如果需要为多个WiFi网络创建不同的切换规则，应当逐一记录每个网络的准确SSID并分类整理，避免在后续创建自动化时混淆导致配置错位。掌握URLScheme的命令格式规范Shadowrocket支持通过URLScheme接收外部应用的切换指令，标准格式为“shadowrocket://config/switch?name=配置名称”，其中“config/switch”指定操作类型为切换配置，“name”参数后跟随目标配置的完整名称。在执行该命令时Shadowrocket会自动加载目标配置文件并重新加载规则引擎，无需用户确认即可完成配置替换。如果目标配置名称在应用中不存在，命令执行时不会产生任何切换效果也不会给出错误提示，因此提前核验配置名称的准确性是确保自动化成功的前提。创建快捷指令自动化检测WiFi网络进入快捷指令的自动化管理界面用户打开iPhone上的“快捷指令”应用后，点击底部导航栏的“自动化”标签进入自动化管理界面，如果从未创建过任何自动化则页面显示为空。点击页面右上角的加号图标选择“创建个人自动化”，系统会列出所有可用的触发事件类型，用户需要从中选择“WiFi”作为本次自动化的触发条件。进入WiFi设置页面后系统会显示当前及历史连接过的WiFi网络列表，用户选择目标网络即可完成触发条件的设置，同时可以勾选“已连接”或“未连接”来细化触发时机。选择目标网络并设定触发时机在WiFi触发条件配置界面中，用户可以通过点击“选择网络”从列表中选取目标SSID，若列表中没有目标网络则可以手动输入其精确名称。触发时机选择“已连接”表示当设备成功连接该WiFi网络时执行自动化，选择“未连接”则适用于断开该网络时触发的反向场景，用户可根据实际切换方向做出选择。设定完成后点击“下一步”进入操作添加界面，此时系统已保存触发条件并等待用户配置具体的执行动作。完成自动化创建并关闭运行前询问在操作添加界面点击“添加操作”搜索“URL”并选择该操作类型，在URL输入框中粘贴之前准备好的Shadowrocket切换命令，然后再次点击“添加操作”搜索“打开URL”并将其添加到流程中，确保两个操作按先后顺序排列。添加完成后点击“下一步”进入设置确认界面，最关键的一步是关闭“运行前询问”开关，这样当WiFi触发条件满足时系统会自动执行切换命令而无需用户手动确认。关闭该开关后系统会弹出风险提示，用户点击“不询问”即可完成创建并保存该自动化规则。在快捷指令中嵌入切换配置的URLScheme指令添加URL操作并粘贴切换命令在快捷指令自动化编辑器的操作添加界面中，点击“添加操作”后搜索框输入“URL”，从搜索结果中选择“URL”操作类型并将该操作块拖入流程编辑器，然后在其输入框中粘贴格式为“shadowrocket://config/switch?name=配置名称”的完整命令。若需要切换的配置文件名称较长或包含特殊字符，建议先在备忘录中编辑好命令文本并复制，再粘贴到URL操作块中以避免手动输入出错。多个URL操作可以在同一自动化中串联使用，但针对单一WiFi的切换只需一个即可完成。追加打开URL操作确保指令执行仅仅定义URL操作并不足以让系统执行该链接，用户必须在其后添加“打开URL”操作块才能触发Shadowrocket对命令的实际响应。在URL操作块下方点击加号再次搜索“打开URL”并选择该操作类型，此时系统会自动将前一个URL操作块的内容作为参数传入，用户无需额外设置即完成联动。确认两个操作块在流程中呈上下串联排列，没有其他操作插入中间打断执行链条，然后点击“完成”保存自动化规则。添加条件判断增强切换逻辑的精确性当用户需要在连接同一WiFi但处于不同时间段时执行不同的配置切换，可以在自动化中添加基于时间或设备状态的条件判断块来实现更精细的控制。在URL操作之前插入“如果”条件块，设置条件为“当前时间”在特定范围内，然后根据条件成立与否分别执行不同的URLScheme命令。条件判断的引入扩展了自动化的适用场景，让用户能够在家庭WiFi下根据时段自动切换日间模式和夜间模式的配置文件，实现更加智能的分时调度。配置多WiFi场景下的差异化切换规则为家庭网络创建专属切换规则针对家庭WiFi场景，用户应创建一条连接家庭SSID时触发切换至“家庭配置”的自动化规则，该配置通常将FINAL兜底策略设置为PROXY实现境外网站的自动代理，同时将局域网地址和常用国内网站强制直连。在快捷指令中设置触发网络为家庭路由器的SSID，操作部分使用URLScheme切换至预先调试好的家庭配置文件，保存后每次回家连接WiFi时配置自动切换到位。家庭网络下用户通常有稳定的带宽且延迟敏感度较低，该配置可以兼顾高带宽视频播放和代理访问的双重需求。为公司网络和工作环境独立配置当设备连接公司WiFi时，用户可能需要切换至专门优化的“工作配置”，该配置将公司内网地址段设置为直连以确保OA系统、代码仓库和内部API的正常访问，同时将境外技术文档和开发工具域名通过稳定的代理节点访问。在公司WiFi的自动化规则中应当填入公司SSID作为触发条件，并在切换命令中指定工作配置的精确名称，确保进入办公区域后网络策略自动适配。工作配置还应当关闭基于地理位置的分流规则避免因内网IP归属地变化导致路由错误，对于企业级网络环境还需注意避免与公司自有的VPN服务产生冲突。设置断开特定WiFi时的回退规则除了连接WiFi时的切换外，用户还应当为重要WiFi网络配置断开时的回退自动化，确保离开家庭或公司环境后配置自动恢复至移动网络下的默认状态。在创建自动化时触发条件选择“未连接”并指定对应的家庭或公司SSID，执行切换命令指向“移动配置”或“通用配置”作为离网后的默认策略。回退规则的配置确保了设备在蜂窝网络下能够以最适配当前环境的配置运行，避免因上一环境的配置残留导致移动网络下的访问异常。自动化运行异常的排查与手动触发替代方案WiFiSSID精确匹配导致触发失败的处理当设备连接了目标WiFi但快捷指令自动化未能按预期触发时，首要排查项是SSID是否与设置时的网络名称完全匹配，包括大小写、空格和特殊字符的差异。用户可以在连接WiFi后进入快捷指令的自动化页面手动点击运行该规则进行测试，如果手动运行成功而自动触发失败则说明SSID匹配存在问题，需要删除原有触发条件后重新选择或输入网络名称。某些路由器的SSID在广播时可能包含隐藏字符，建议在iPhone的WiFi设置中完整复制网络名称后粘贴到快捷指令的触发条件中。后台运行权限与通知设置的影响快捷指令自动化在设备锁屏或应用未在前台时依赖于系统的后台任务调度机制，如果用户关闭了快捷指令的后台应用刷新权限或开启了低电量模式，自动化可能被系统延迟执行或完全取消。进入“设置-通用-后台应用刷新”确保快捷指令的开关处于开启状态，同时在“设置-快捷指令-高级”中开启“允许不受信任的自动化”以解除系统对非标准自动化的限制。如果自动化执行时没有弹出任何提示且切换未生效，可以尝试重启iPhone重新加载系统自动化调度服务。使用Siri语音或桌面书签作为应急替代当WiFi自动化因系统限制或网络环境异常而无法正常工作时，用户可以预先创建Siri快捷指令作为手动触发配置切换的应急方案，在快捷指令应用中创建名称为“切换家庭配置”的快捷指令并内置相应的URLScheme命令。创建完成后用户可通过说出“嘿Siri，切换家庭配置”来手动执行配置切换，或者在桌面添加该快捷指令的小组件图标实现一键点击切换。这种手动替代方案虽然无法达到自动化的免操作体验，但在自动化失效时作为可靠的备用切换手段能够确保用户始终可以快速调整网络配置。定期检查自动化的运行日志和触发记录也是预防突发失效的有效手段。常见问题FAQ

Shadowrocket直连模式和关闭代理有什么区别？

要准确区分Shadowrocket直连模式和关闭代理的实际差异，关键在于理解两者在系统VPN插槽占用和规则引擎活跃状态上的本质区别。直连模式保留了VPN隧道激活状态，占用系统唯一VPN插槽且规则引擎和DNS缓存仍处于活跃待命状态，但所有流量不经过代理转发直接本地发出，切换回代理模式时无需重新加载配置即可瞬时恢复。彻底关闭代理则释放了全部系统资源，VPN插槽被清空、规则引擎停止运行、DNS缓存清空，设备网络栈完全回归纯净状态，但重新开启代理时需要完整的VPN隧道重建和配置文件加载流程。在实际使用中，频繁切换网络状态时优先使用直连模式以获得快速切换体验，进行网络故障排查或需要启动其他VPN工具时应彻底关闭代理以避免插槽冲突，公共Wi-Fi认证场景下同样推荐关闭代理以确保认证流程不受干扰。VPN隧道激活状态与系统资源占用的根本差异系统级别的VPN服务存活状态直连模式下，Shadowrocket的VPN服务进程依然在系统后台活跃运行，保持对网络接口的监听状态，而关闭代理则彻底终止了该服务的全部进程并回收系统分配的资源。此时直连模式的系统级VPN隧道并未拆除，应用仍占用着唯一的网络扩展插槽，这使得设备状态栏的VPN图标持续显示，表示虚拟网卡仍处于激活状态。关闭代理则完全释放了该插槽，系统网络栈回归到未安装任何VPN配置时的纯净状态，网络数据不再经过任何第三方应用的过滤和转发，设备状态栏的VPN图标彻底消失。内存与后台进程的资源占用对比直连模式保留了Shadowrocket的核心进程在后台运行，虽然不进行数据转发但依然占用少量的内存和CPU资源用于维持隧道心跳和监听系统网络事件，而关闭代理后应用进入完全休眠状态，不占用任何系统资源。直连模式下应用的后台刷新、规则集自动更新和订阅定时刷新等任务仍然可以正常执行，因为进程处于活跃状态。关闭代理后这些定时任务全部暂停，直到用户手动开启代理服务后才会恢复调度，从功耗角度看关闭代理比直连模式更为省电。状态栏图标与系统设置的显示差异直连模式激活时，iOS系统的控制中心和状态栏顶部会持续显示VPN连接标志，并在设置应用中显示Shadowrocket的VPN配置处于已连接状态，这会让部分用户误以为代理仍在工作。关闭代理后这些视觉标识全部消失，系统设置中的VPN状态显示为未连接，用户在查看设备网络状态时能够明确判断当前没有代理服务在运行。这种显示差异直接影响用户对设备当前网络状态的认知判断，直连模式下的VPN图标往往让普通用户产生困惑而误以为数据仍在经过境外节点。网络请求处理链路与路由逻辑的实质区别流量拦截与直通的第一道关卡直连模式下，设备发出的所有网络请求依然首先经过Shadowrocket的虚拟网卡进行拦截和初步检查，应用虽然不会将数据包转发至代理节点但会执行一系列轻量级的本地判断逻辑。关闭代理后，网络请求完全绕过Shadowrocket的处理链路，直接从系统网络栈发送至物理网卡发出，中间没有任何中间层参与检查或路由决策。直连模式下即便不进行代理转发，应用仍然能够读取请求的目标地址和端口信息，这在隐私层面上意味着数据包的头信息仍然经过了第三方应用的处理流程。规则引擎是否介入匹配流程直连模式中，配置文件中的部分规则逻辑依然会被引擎执行，例如预匹配的局域网直连规则和基于IP地址段的快速筛选仍然会生效，但这些匹配结果全部指向DIRECT动作而不会产生代理转发。关闭代理后规则引擎完全不启动，配置文件中的任何DOMAIN-SUFFIX规则、GEOIP规则和策略组定义都不再发挥任何作用，所有请求不再经过规则匹配流程直接发出。规则引擎是否参与处理直接影响了DNS解析路径的选择，直连模式下用户配置的DNS覆写和自定义DNS服务器仍然会生效。数据包封装与本地协议栈的交互关系直连模式下，网络数据包在被虚拟网卡接收后直接交由本地物理网络接口发出，未经过代理协议的加密封装和隧道传输，因此数据包在网络中的传输格式与普通上网完全一致。关闭代理时，数据包甚至不会经过虚拟网卡的接收环节，直接从应用层下发至传输层再交由物理网卡发送，其路径更加直接且少了一道内核态与用户态之间的上下文切换开销。从网络延迟角度看，关闭代理比直连模式的路径更短，但两者的实际速度差异在毫秒级别，用户在日常使用中几乎无法感知。系统VPN插槽与多应用并存时的兼容性差异VPN单插槽机制对并行应用的限制iOS系统允许且仅允许一个VPN服务同时占用系统VPN插槽，直连模式下的Shadowrocket已经占用了这个唯一的插槽，导致任何其他VPN应用（如企业级L2TP/IPSec、WireGuard或其他代理工具）无法同时建立连接。关闭代理释放了该插槽，其他VPN应用即可正常启动并建立独立的加密隧道，用户可以在Shadowrocket关闭的状态下自由使用公司VPN或专用游戏加速器。这种插槽独占特性意味着直连模式虽然不转发代理流量，但阻止了其他VPN服务的正常运行。企业VPN与L2TP等服务的启动冲突当用户需要连接公司内网使用的CiscoAnyConnect或基于IPSec的L2TPVPN时，如果Shadowrocket处于直连模式，系统会提示VPN冲突无法建立新连接，用户必须先将Shadowrocket彻底关闭才能启动企业VPN连接。关闭代理后Shadowrocket释放了对VPN框架的占用，企业VPN可以正常调用系统接口建立隧道，内网资源访问不受任何干扰。切换到企业VPN连接后如果需要重新使用Shadowrocket，又必须断开企业VPN才能获得系统插槽的控制权，这种互斥关系使得用户需要在不同VPN工具之间频繁切换。个人热点与网络共享功能的影响范围当iPhone开启个人热点共享蜂窝网络给其他设备时，如果Shadowrocket处于直连模式，共享出去的流量路径会与主机设备的网络设置保持一致，连接的设备所发出的请求同样不会经过代理转发但系统VPN插槽仍然被占用。关闭代理后设备网络栈重置，个人热点功能在无VPN干扰的状态下运行更为稳定，连接的设备不会因主机VPN配置残留而导致网络异常。部分用户在开启个人热点后遇到连接设备无法上网的问题，往往是因为Shadowrocket未完全关闭而处于直连状态所导致的兼容性问题。操作反馈与用户交互体验的具体区别界面按钮状态与连接动画的不同反馈直连模式下，Shadowrocket主界面中央的大圆形连接按钮显示为已连接状态的蓝色或绿色，并伴有持续旋转的环形动画来表示VPN隧道处于激活状态，但按钮下方的状态文字明确标注为“直连”而非“代理”。关闭代理时该按钮显示为未连接状态的灰色并附有“已断开”的标签，环形动画完全停止，界面整体给人以服务已退出的明确反馈。用户通过主界面的视觉元素可以在一秒内快速判断当前是直连还是完全关闭，这种即时反馈降低了误判应用状态的可能性。重启设备后应用的默认行为差异当iPhone重启后，如果上次退出时Shadowrocket处于直连模式，系统会尝试恢复该VPN配置并重新激活虚拟网卡，应用可能在开机后自动进入直连状态并持续占用系统VPN插槽。如果上次关闭时选择了彻底断开代理，重启后Shadowrocket保持完全关闭状态，不会自动启动任何网络拦截服务。这种开机自恢复行为可能导致用户在不知情的情况下系统VPN插槽一直被Shadowrocket占用，后续启动其他VPN工具时遇到冲突而无法连接。后台刷新与推送通知的传输路径直连模式下系统后台应用刷新和推送通知的数据流量同样经过Shadowrocket虚拟网卡的拦截处理，但直接交由本地网络发出，不会经过代理节点的加密传输，因此推送延迟和刷新效率与关闭代理时基本一致。关闭代理后这些后台流量不再经过任何中间层的检查，路径更为精简，对于依赖即时推送的通讯应用而言关闭代理可以减少极微量的处理延迟。但两种模式下推送通知的实际到达时间差异在正常网络环境中完全不可感知，普通用户无需为此担忧。网络连接中断与恢复流程上的不同表现网络切换时的重连与重建机制直连模式下，当设备从Wi-Fi切换至蜂窝数据或在不同Wi-Fi网络间漫游时，Shadowrocket的VPN隧道依然保持激活状态，系统仅需更新底层物理接口的路由表而不需要重建虚拟网卡配置。关闭代理后，网络切换完全不涉及Shadowrocket的任何参与，系统按照默认的网络栈完成切换流程，切换速度略快于直连模式因为少了一道虚拟网卡适配环节。频繁切换网络的移动场景中，关闭代理能够获得最干净的切换体验，但直连模式带来的切换延迟增加同样在毫秒级，用户实际难以察觉。DNS缓存与路由表的刷新策略直连模式下，Shadowrocket内部维护的DNS缓存和路由表依然会根据访问记录持续更新，尽管不进行代理转发但缓存策略照常执行，这导致设备在后续切换回代理模式时DNS解析速度更快。关闭代理后应用清空所有运行时缓存，下次开启代理时需要重新建立完整的DNS缓存和路由表数据，初期几次域名解析的响应时间可能略慢于直连模式持续运行时。用户如果频繁在开启和关闭代理之间切换，直连模式作为中间状态可以保留缓存数据从而加快下次代理启动后的初始化速度。测速工具与连通性诊断的结果偏差直连模式下，部分网络测速工具和连通性诊断应用可能因为检测到系统VPN插槽被占用而误判网络链路存在代理，导致测试结果出现偏差或显示非预期的网络路径。关闭代理后测速工具直接测量物理链路的真实带宽和延迟，获得的数据更能反映本地网络的实际质量。用户在进行网络故障排查时，应当彻底关闭Shadowrocket而非仅切换至直连模式，以获得最纯净的诊断环境，避免VPN插槽占用对测速结果产生干扰。直连模式相较于关闭代理的独特应用价值保留规则配置与快速切换的优势直连模式最大的实用价值在于保留了完整的规则引擎、策略组和节点列表在内存中，用户从直连模式切换回代理模式时，所有配置状态被完整保留且无需重新加载，切换过程在瞬间完成。关闭代理后应用释放所有运行时资源，重新开启时需要重新加载配置文件、解析规则集、建立VPN隧道并与节点服务器完成握手，整个过程通常需要数秒至十余秒。当用户需要频繁在代理和非代理状态之间切换时，直连模式提供了近乎无缝的切换体验，大幅缩短等待时间。解决特定应用网络检测失效的场景部分应用会通过检测系统VPN状态来判断设备是否使用了代理，并据此改变自身行为（例如禁用部分功能或要求额外验证），直连模式下这些应用检测到VPN插槽被占用会触发相应的策略调整。如果用户需要模拟或绕过这种基于VPN状态的检测逻辑，直连模式提供了在不实际发送代理流量的情况下维持VPN激活状态的方案，这在测试环境和逆向分析场景中具有独特的实用价值。关闭代理则无法满足这类需要维持VPN状态占用的特殊需求。作为故障排查中间态的诊断价值当用户遇到节点连接失败或规则分流异常时，先将应用切换至直连模式可以快速验证问题是否源于代理节点本身而非应用配置或网络基础环境。如果在直连模式下访问国内网站正常而切换回代理模式时失败，则可以明确故障范围在代理节点或订阅链路内，无需浪费时间排查配置文件或本地网络设置。直连模式作为代理开启和完全关闭之间的中间诊断态，能够帮助用户迅速定位问题归属层，是高效排查Shadowrocket故障的重要工具。常见问题FAQ

Shadowrocket全局代理模式下国内网站打不开怎么办？

当Shadowrocket在全局代理模式下国内网站打不开时，最迅速的应急操作是将路由模式切换回“配置”让国内流量恢复直连，或通过“设置-按应用代理”将浏览器等关键应用强制设置为直连状态，绕开全局代理对国内访问的限制。要彻底解决该问题，长期方案应是放弃全局代理模式，构建一套完整的配置模式分流规则集，通过GEOIP,CN规则和DOMAIN-SUFFIX国内直连规则实现国内外流量的智能分流，仅在需要全局隐藏IP访问所有服务的特殊场景下才临时启用全局代理并结合按应用直连豁免。若全局代理模式下出现特定域名访问失败，可通过手动指定国内DNS服务器或添加DNS覆写规则修正域名解析结果，从根本上确保国内网站始终获得正确的IP地址和最优的访问路径。全局代理模式对国内流量的影响机理强制隧道将所有流量导入代理节点全局代理模式的核心逻辑是强制所有网络请求全部经由选定的代理节点转发，无论目标是国内网站、境外网站还是内网设备，都不会进入配置文件的规则引擎进行分流判断。这种模式下，用户访问百度、淘宝等国内网站时，设备发出的请求首先被封装后发送至代理服务器，由代理服务器再从境外向目标国内网站发起访问。由于代理节点的出口IP通常位于境外，国内网站收到的请求来源是境外地址，这使得网站可能会将用户识别为境外访问者，返回境外版本的页面内容或直接拒绝来自境外IP的访问请求。国内CDN节点因代理出口IP而失效百度、腾讯、阿里巴巴等大型国内网站普遍使用CDN内容分发网络来加速用户访问，当用户直接访问时，CDN系统会根据用户请求的源IP地址自动分配距离最近、网络最优的缓存节点。但在全局代理模式下，CDN系统获取到的是代理节点的出口IP而非用户的真实IP，由于该IP位于境外，CDN会将用户导向境外的缓存节点而非国内节点，导致访问速度急剧下降甚至完全无法建立连接。这种路由错位是全局代理模式下国内网站访问体验急剧恶化的最主要原因。代理节点对国内流量的策略限制部分代理服务商为了优化节点负载和节省国际带宽，会在节点端配置针对国内流量的路由策略，例如将流向国内IP地址段的请求直接丢弃或强制直连而拒绝转发。当用户在Shadowrocket中开启全局代理模式时，这些被节点端策略限制的国内访问请求会直接失败，返回连接超时或被拒绝的错误提示，用户完全无法通过该节点访问任何国内服务。这种限制在服务商看来是合理管理资源的手段，但用户在不知情的情况下使用全局代理就会遭遇国内网站的集体不可用。国内网站打不开的即时应急方案快速切换至配置模式恢复国内访问当用户发现全局代理模式下国内网站无法打开时，最直接且有效的应急操作是将Shadowrocket的路由模式从“代理”切换回“配置”。在主界面顶部的模式选择区域点击当前模式名称，从弹出的选项列表中选择“配置”模式，应用会立即停止将所有流量转发至代理节点，恢复使用配置文件中的分流规则进行智能路由。切换完成后，访问百度、淘宝等国内网站时，请求会按照配置文件中的GEOIP,CN规则或DOMAIN-SUFFIX直连规则被正确指向本地网络，绕过代理节点直连国内服务器，页面加载恢复正常。为特定国内网站添加按应用直连策略如果用户因特殊需求必须维持全局代理模式（例如需要隐藏真实IP访问所有服务），可以通过按应用代理功能为浏览器或特定应用单独设置强制直连策略。进入Shadowrocket的“设置-按应用代理”列表，找到正在使用的浏览器应用（如Safari、Chrome），将该应用的状态开关切换为关闭（灰色），此操作会使该应用的所有流量强制直连本地网络而不受全局代理模式影响。这样用户既保留了其他应用的全局代理状态，又能正常访问国内网站，但需要注意该操作仅对设置了直连的应用生效，其他应用仍然受全局代理影响。临时关闭VPN连接访问国内服务在紧急情况下如果用户急需访问国内网站且无法通过模式切换解决，可以暂时断开Shadowrocket的VPN连接，在系统状态栏点击VPN图标选择断开或直接在Shadowrocket中点击“停止”按钮。断开VPN后所有流量恢复本地直连，用户可无障碍访问所有国内网站，待国内访问完成后重新连接VPN恢复全局代理状态。此方案虽然操作简单但无法同时访问境外网站，仅适合短时间国内服务使用场景，不具备长期使用的实用性。从根本上优化全局代理与国内访问的兼容性分流规则优先于全局代理的配置方案与其使用全局代理模式导致国内网站访问障碍，更优的长期解决方案是使用配置模式并搭配完善的规则集，让国内外流量自动分流。用户应当导入社区维护的GEOIP规则集和国内网站直连规则集，在配置文件中将GEOIP,CN规则指向DIRECT策略，将所有境外网站流量的兜底规则指向PROXY策略。这种配置实现了与全局代理几乎相同的覆盖效果（所有境外网站自动走代理），同时国内网站始终直连本地网络，访问速度和稳定性均不受代理节点的影响。策略组实现按需代理的精细化调度在配置文件中创建多个策略组并为其分配不同的路由策略，用户可以手动选择哪些流量走代理哪些直连，实现介于全局代理和配置文件分流之间的灵活模式。例如创建一个“代理模式”策略组包含所有境外节点和一个“直连模式”策略组指向DIRECT，然后在配置中将规则根据需求指向不同的策略组，配合策略组的手动切换能力可以实现一键改变全部流量的去向而不影响分流规则的逻辑结构。这种方案的综合灵活性远超简单的全局代理切换。双配置方案满足不同使用场景切换用户可以为“国内优先”和“境外优先”两种使用场景创建独立的配置文件，每个配置文件预设最适配该场景的路由模式和规则集。例如在国内优先配置中，FINAL兜底策略设置为DIRECT，仅少数需要代理的服务通过PROXY规则精确匹配；在境外优先配置中，FINAL兜底策略设置为PROXY，仅少数需要直连的国内服务通过DIRECT规则精确匹配。当用户在不同场景间切换时，只需在配置页面选择加载对应的配置文件即可，所有路由逻辑已经预先优化妥当，无需手动调整模式或规则。全局代理模式下DNS污染导致的访问故障排查全局代理中DNS解析路径的异常变化当Shadowrocket处于全局代理模式时，设备的所有DNS查询请求同样会被封装并通过代理节点发出，这意味着域名解析不再依赖本地运营商的DNS服务器，而是经过代理节点所在网络进行解析。如果代理节点所在的DNS服务器存在对国内域名的解析错误或缓存污染，用户在浏览器输入“baidu.com”后获得的可能是错误的IP地址，直接导致访问失败。这种DNS层面的问题在配置模式下可能不会暴露，因为配置模式下国内网站的DNS查询通常由本地DNS服务器完成，解析结果准确且快速。强制使用本地DNS解析国内域名为了解决全局代理模式下的DNS污染问题，用户可以在Shadowrocket的“设置-DNS”配置中手动指定一组可靠的国内DNS服务器（如119.29.29.29或223.5.5.5），并启用“通过代理解析DNS”功能的精确控制。更为彻底的解决方案是在DNS配置中添加针对国内域名的DNS覆写规则，强制特定域名的解析请求绕过代理通道直接由本地DNS服务器处理，确保国内域名始终获得准确的IP解析结果。DNS覆写规则的配置需要对DNS解析机制有一定理解，但能够从根本上根除全局代理模式下的DNS污染隐患。使用IP直连方式绕开DNS解析环节对于经常访问的国内网站，用户可以通过查询其IP地址后在浏览器中直接使用IP访问，从而完全绕开DNS解析环节。用户在终端中使用ping命令或nslookup工具获取目标网站当前的IP地址，将该IP输入浏览器地址栏即可直接访问。但该方案存在IP地址随时变更的风险，只适合临时使用而不作为长期方案。按应用代理模式实现国内与境外流量的共存精准控制单个应用的全局代理状态在Shadowrocket的“设置-按应用代理”功能中，用户可以为浏览器类、视频类、社交类等需要访问国内和境外的核心应用单独设置代理策略，使其不受全局模式或配置模式的统一限制。将浏览器应用设置为未配置状态使其流量接受配置文件的规则分流，将游戏应用强制直连保障低延迟，将社交应用强制代理确保境外服务可用，这种精细化的应用级控制实现了不同应用间的路由隔离，克服了单一模式无法同时满足国内和境外访问需求的根本困境。系统应用与第三方应用的分流差异iOS系统中的应用（如Safari浏览器、AppStore、系统更新服务）与第三方应用在全局代理模式下的行为存在差异，部分系统应用会绕过VPN通道直接使用系统网络栈，导致这些应用在国内网站访问上不受全局代理影响反而表现正常。但当用户发现某些系统应用可以正常访问国内网站而第三方应用无法访问时，可以适当参考按应用代理的配置来对特定第三方应用进行策略隔离，减少全局模式对关键应用访问的影响。应用策略的优先级与模式切换的联动当按应用代理配置与路由模式同时生效时，应用级策略的优先级高于全局模式设置，即使处于全局代理模式下，被设置为强制直连的应用仍然会绕过代理节点直接访问本地网络。利用这一优先级特性，用户可以在维持全局代理模式的同时，通过按应用代理列表将浏览器、即时通讯等需要国内访问的关键应用全部设置为强制直连，其他应用保持代理状态，从而实现全局代理框架下的国内外流量并存。常见问题FAQ

Shadowrocket开屏广告模块怎么添加？WhatsHub的规则能用吗？

在Shadowrocket中添加开屏广告拦截功能时，用户应先从GitHub等可靠渠道获取专为Shadowrocket或Surge格式优化的开屏广告模块规则集的RAW链接，然后进入配置页面的规则列表添加类型为RULE-SET的引用条目并粘贴该链接，策略动作选择REJECT，保存后将新条目拖动至规则列表的最前端以确保最高匹配优先级，最后执行配置重载让规则生效。关于WhatsHub规则，其Surge格式的规则集在Shadowrocket中基本可用，用户只需从WhatsHub仓库中确认获取Surge版本而非Clash版本的RAW链接，按相同方式导入即可。若导入后出现解析警告，可在日志中查看不兼容条目并酌情删除。建议将WhatsHub通用规则集与专门的开屏广告模块同时引用，让前者覆盖常规广告拦截、后者精准狙击开屏广告，并开启两者的订阅自动更新以保持规则的持续有效性，当遇到误拦时将受影响的功能域名添加前置豁免规则以覆盖拦截动作。开屏广告拦截的核心实现原理与模块化方案开屏广告拦截基于规则集的工作机制Shadowrocket拦截开屏广告的本质是通过规则集匹配应用启动时请求的特定域名或URL，这些请求通常指向广告联盟的素材分发服务器或数据统计接口，当匹配到这些广告相关域名时，应用会执行REJECT动作直接丢弃请求。由于开屏广告的域名集合庞大且更新频繁，依赖于用户手动逐个添加域名完全不现实，因此通过引入社区维护的专门化规则集是最主流且高效的实现路径。这些专门化的规则集与通用的广告拦截规则不同，它们深度聚焦于各类App启动时的开屏广告特征域名，并针对国内主流应用进行了定向优化。模块化规则集与通用规则的本质区别通用的广告拦截规则集覆盖面广但针对性较弱，对于开屏广告这类通常埋藏在应用深层代码中的加载请求识别效果有限。而专门的开屏广告模块规则集则通过逆向分析和抓包验证，精准定位了数百款常用应用开屏广告的触发域名和接口路径，这些域名往往在常规广告列表中并不突出，却是开屏广告的关键加载节点。此类模块化规则集的设计思路是“小而精”，条目数量通常保持在数十到百余条之间，但命中率远高于庞大的综合规则库。用户可以根据自身需求灵活启用或关闭特定模块，避免因加载过大的通用规则集而影响设备性能。规则模块在配置文件中的独立引用方式在Shadowrocket的配置体系中，用户可以通过添加多条RULE-SET指令来分别引用不同的规则模块，开屏广告模块与普通广告拦截模块、隐私追踪拦截模块可以作为三个独立的外部规则集在同一配置文件中共存。这种模块化架构使维护变得极为清晰：当需要更新开屏广告规则时，用户仅需刷新该特定模块的订阅源，无需对整个配置文件进行全量更新。各模块在规则列表中的排列顺序同样遵循优先级逻辑，开屏广告模块应当被置于列表最前端，确保应用启动时的第一波广告请求能被最高优先级拦截。开屏广告规则集的获取与导入路径针对Shadowrocket优化规则集的来源推荐目前中文互联网上针对Shadowrocket专门优化的开屏广告规则集主要集中在GitHub平台，其中较为活跃的维护者包括以“app-adblock”命名的系列仓库。用户可以直接在GitHub搜索“开屏广告规则”或“Shadowrocketlaunchad”等关键词，根据仓库的星标和最近更新日期筛选出活跃度高且评价良好的项目。推荐优先选择那些规则源文件明确标注为“适用于Shadowrocket”或“Surge格式”的仓库，避免下载适用于Clash或QuantumultX等其他平台的格式版本，因为这些版本的规则语法与Shadowrocket存在差异，直接导入可能导致解析失败。开屏广告模块的手动添加步骤获取到开屏广告规则集的RAW链接后，打开Shadowrocket进入“配置”页面，在规则列表底部点击“添加规则”按钮，从规则类型下拉菜单中选择“RULE-SET”。将复制的RAW链接粘贴至地址输入框中，在下方的策略动作栏选择“REJECT”，点击保存后即可在规则列表中看到新添加的模块条目。此时长按该条目左侧的拖动柄将其移至列表的最前端，确保开屏广告拦截在规则匹配的早期阶段就介入。完成位置调整后返回配置页面顶部，点击“重新加载”按钮使新规则生效，后续应用启动时开屏广告请求将自动被拦截。通过订阅源方式实现规则模块的自动更新为确保持续获得最新的开屏广告域名更新而不需要每次手动操作，用户可以在Shadowrocket的订阅管理中将该规则集的RAW链接添加为独立的订阅源。添加时在订阅类型中选择“规则集”而非“节点”，并开启自动更新功能将刷新间隔设置为“每天”或“每12小时”。规则维护者通常会在新App版本更新或广告联盟更换域名时及时同步规则集，用户开启自动更新后即可在无需人工干预的情况下保持拦截能力的最新状态。更新完成后规则集内容会自动重载，开屏广告拦截始终处于活跃且最新状态。WhatsHub规则在Shadowrocket中的兼容性与使用分析WhatsHub规则库的定位与格式特征WhatsHub是中文网络上较为知名的规则维护组织，其产出的规则集广泛被Clash、Surge和QuantumultX等代理工具的用户使用。该组织的规则覆盖范围包括广告拦截、隐私追踪屏蔽和恶意域名防护，以其维护频率高和域名覆盖面广受到认可。然而WhatsHub官方针对不同客户端分别维护着不同格式的规则版本，其面向Surge的版本与Shadowrocket的规则语法高度兼容，因为两者共享相近的规则类型命名和参数结构。用户在使用WhatsHub规则时必须在仓库中找到明确标注为Surge兼容的版本，而不要使用Clash的YAML格式版本。Surge格式与Shadowrocket格式的兼容性边界Shadowrocket的规则引擎在设计上对Surge格式的规则集有着良好的兼容性，两者在DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR等核心规则类型上保持一致，仅在少数扩展字段和注释语法上存在细微差异。这意味着WhatsHub官方维护的Surge规则集在导入Shadowrocket后能够被正常解析并执行REJECT或PROXY动作，无需进行任何格式转换。但如果用户误用了Clash版本，规则文件中的YAML结构和策略组定义会导致Shadowrocket的解析器完全无法识别，整个规则集将被跳过而不会生效。因此确认导入的版本来源是使用WhatsHub规则的首要前提。直接使用Surge规则集的具体操作指引当用户在WhatsHub仓库中找到其Surge规则集的RAW链接后，该链接的导入方式与普通Shadowrocket规则集完全一致，均为在配置页面的规则列表中添加类型为RULE-SET的条目并粘贴该RAW链接。在策略动作选择上，针对广告拦截用途应选择REJECT，如果希望将WhatsHub的隐私追踪规则用于拦截则可同样选择REJECT。WhatsHub规则集在Shadowrocket中的匹配效率与原生规则集无异，因为引擎在处理时不会区分规则是来自本地内联还是外部Surge格式文件。跨平台规则在Shadowrocket中的兼容边界虽然Shadowrocket能够识别Surge格式的多数规则类型，但对于Surge配置文件中特有的策略组嵌套、外部脚本引用和特定参数修饰符，Shadowrocket的解析器会直接忽略或报错。因此当用户从WhatsHub获取的Surge规则集包含这些Shadowrocket不支持的语法元素时，解析过程中会出现警告但不会导致整个规则集失效，大部分可识别的规则仍然会被正常加载。建议用户在导入WhatsHub规则后打开Shadowrocket的实时日志，观察是否有“unsupportedruletype”或“parsewarning”等提示信息，并根据日志中的提示删除或修改不兼容的规则条目，从而获得纯净可用的规则子集。WhatsHub规则的自定义适配与手动优化识别并移除不兼容规则条目当WhatsHub的Surge规则集在Shadowrocket中出现解析警告时，用户可以在导入后进入配置页面的规则列表，定位到该规则集的条目并点击展开查看详细内容。在所有被标记为警告的行中找到使用了Shadowrocket不支持的规则类型或参数修饰符的条目，在规则集列表中左滑该条目选择“编辑”并删除对应行，或者在规则集整体的策略设置中将该规则集的动作切换为忽略特定条目。但需注意直接修改外部规则集文件需要将其改为本地存储形式，较为繁琐，对于多数警告，如果不影响核心拦截功能，用户可以选择忽略。针对开屏广告的定向补充规则WhatsHub的通用规则集虽然覆盖广泛，但在最新的开屏广告域名更新上可能存在数小时到数天的滞后，用户若遇到某个特定应用的开屏广告未被拦截，可以通过实时日志抓取该应用的广告请求域名，然后手动添加补充规则并放置在WhatsHub规则集之前。通过将自定义补充规则与WhatsHub的通用规则集组合使用，用户能够在享受大覆盖面规则便利性的同时，快速响应新出现的开屏广告变化，弥补通用规则集的更新延迟。这种混合策略充分发挥了模块化的优势，让拦截精度和更新速度均达到最优。规则集顺序调整与优先级设置当配置文件中同时引用了WhatsHub的通用广告规则集和专门的开屏广告模块规则集时，排列顺序应按照“专用模块在前、通用模块在后”的原则进行设置。具体操作为在规则列表中长按各规则集条目左侧的拖动柄，将开屏广告专用模块拖动至列表最前端，再将WhatsHub通用规则集放置在专用模块之后，最后再放置GEOIP直连规则和代理规则。此顺序确保了最适配开屏场景的专用规则拥有最高匹配优先级，且不会被通用规则的某些豁免条目覆盖。规则导入后的效果验证与误拦处理开屏广告拦截效果的快速验证方法在完成规则导入和配置重载后，用户应当选择一款此前在启动时频繁展示开屏广告的应用（如主流新闻或购物App），完全关闭该应用后台后重新冷启动。观察启动过程中的广告页面是否出现空白或立即跳转至应用主界面，如果广告被成功拦截则页面上通常显示为短暂的黑色或白色闪烁。为了获取更客观的验证结果，建议在不同时间段重复测试同一应用多次，排除广告缓存和网络请求波动带来的干扰。同时也可借助Shadowrocket的实时日志检查应用启动过程中是否有请求被成功匹配REJECT动作，日志中显示的拦截记录是拦截生效的有力证明。被误拦功能域名的豁免处理方法当添加WhatsHub规则或开屏广告模块后发现某个应用的核心功能无法正常使用（例如无法加载内容列表、无法播放视频或登录失败），该问题大概率是该应用依赖的某个第三方接口域名被误识别为广告域名而拦截。用户需打开Shadowrocket的实时日志，重现应用的功能异常场景，从日志中筛选出被REJECT的请求并识别出可能导致功能故障的目标域名。确认域名后返回配置页面，在该域名被广告规则匹配之前添加一条新的DOMAIN-SUFFIX规则并将策略设置为DIRECT，利用前置规则的高优先级来覆盖广告拦截的REJECT动作。规则集更新频率与拦截覆盖度的平衡WhatsHub规则集的更新频率通常为每周数次至每日更新，而开屏广告模块的更新频率则可能更高，两者组合使用时用户应确保各订阅源的自动刷新间隔能够匹配各自的更新节奏。对于更新频繁的规则集，建议将刷新间隔设置为“每6小时”以保证拦截的时效性，对于变化较慢的通用规则集则可设置为“每天”以节省流量和后台刷新电量。同时，用户也可以关注规则维护者的Telegram频道或GitHubRelease页面，了解每次更新的具体内容，以便决定是否立即执行手动更新。常见问题FAQ

Shadowrocket 广告拦截规则去哪里找？johnshall的规则库怎么用？

在Shadowrocket中配置johnshall广告拦截规则库时，标准操作是先从GitHub仓库中获取适用于Shadowrocket的规则集RAW链接并复制到剪贴板，随后进入应用配置页面的规则列表中添加类型为RULE-SET的引用条目并将链接粘贴保存，同时将策略动作设置为REJECT以确保匹配的广告域名被直接丢弃。保存完成后务必点击配置页面的重新加载按钮使新规则进入引擎的匹配内存，随后在订阅管理中将该规则集添加为订阅源并开启自动更新功能以保持拦截规则的时效性，最后通过访问含广告的测试页面验证拦截效果，针对被误拦的功能性域名单独添加前置豁免规则并将其放置在广告规则集之前以确保优先放行，从而构建一套精准高效且持续更新的广告拦截体系。主流广告拦截规则的获取渠道GitHub开源社区与规则集合寻找Shadowrocket广告拦截规则的首选平台是GitHub，大量开发者和规则维护者在这里托管并持续更新他们的规则集文件。用户可以直接在GitHub搜索框中输入“ShadowrocketADBlock”、“广告拦截规则”或“Surge规则”等关键词，根据仓库的星标数、更新频率和活跃度来筛选高质量且维护稳定的规则源。主流的中文规则库包括blackmatrix7维护的“分流规则”集合、DivineEngine的规则库以及专门针对广告拦截的ADgk等，这些规则集覆盖了国内外主流广告联盟、追踪服务器和恶意软件分发域名的全面拦截。社区论坛与规则分享站点除了GitHub外，V2EX、NGA以及一些专门讨论代理工具的中文社区论坛中，用户也会定期分享自用的广告拦截规则集链接或配置文件模板。这些分享通常附带规则作者的详细说明和使用场景建议，用户可以从中获取到GitHub上不易发现的个性化规则集。部分规则维护者还会在Telegram频道中实时推送规则更新动态，用户加入这些频道可以第一时间获知规则集的新增域名和重大变更，保持拦截规则的及时性与有效性。通过规则集合的RAW链接直接引用获取规则集的最便捷方式是从维护者的仓库中直接复制RAW格式的规则集文件链接，这类链接以“.list”或“.conf”结尾，指向的是未经过GitHub页面渲染的纯文本规则内容。RAW链接是Shadowrocket中“RULE-SET”指令可以直接引用的目标地址，用户无需手动下载和导入文件，通过该链接即可让应用实时拉取最新的规则数据。用户应当优先选择仓库中明确标注“适用于Shadowrocket”或“Surge兼容”的规则集文件，避免引入格式不兼容的规则导致解析错误。johnshall规则库的定位与特性johnshall规则库的核心定位johnshall规则库是中文互联网中专注于Shadowrocket广告拦截与去重的知名规则集合，以其高覆盖率和低误杀率受到广泛认可。该规则库主要针对国内主流App的开屏广告、网页弹窗以及视频流媒体中的贴片广告进行了深度优化，通过持续更新广告域名黑名单来应对不断变化的广告投放渠道。规则库的设计目标是在不破坏主流网站和应用程序正常功能的前提下，尽可能全面地屏蔽各类广告请求，同时保持规则文件的轻量化和高匹配效率。规则库的覆盖范围与更新机制johnshall规则库覆盖了包括GoogleAdServices、DoubleClick、百度联盟、腾讯广告等国内外主要广告平台的域名，同时包含了对常见统计追踪服务和社交组件请求的拦截。规则维护者通过自动化脚本定期从多个广告域名源抓取新增的广告投放域名，经过筛选验证后合并入规则集，确保库中域名的新鲜度和有效性。用户可以通过查看规则库在GitHub上的提交记录来了解最近一次更新包含的新增域名数量，以此评估规则库的维护活跃程度。适用场景与兼容性说明该规则库专为Shadowrocket的RULE-SET引用格式设计，与Surge、Clash等其他代理工具的规则语法存在差异，用户应使用专为Shadowrocket适配的版本以避免解析错误。johnshall规则库适用于绝大多数使用Shadowrocket进行日常网络访问的用户，尤其在浏览国内资讯网站、使用社交媒体App和观看在线视频时拦截效果最为显著。对于使用国外网站频率较高的用户，该规则库同样覆盖了国际主流广告平台，但在拦截覆盖面上更侧重于中文互联网环境的广告生态。johnshall规则库的手动导入与配置方法获取规则集链接与添加步骤首先通过浏览器访问johnshall规则库的GitHub发布页面或仓库根目录，在文件列表中找到明确标注为Shadowrocket专用的规则集文件（通常命名为“shadowrocket_adblock.list”或类似），点击进入文件详情页后复制RAW格式的链接地址。打开Shadowrocket进入“配置”页面，在规则列表区域点击底部的“添加规则”按钮，在弹出的规则类型下拉菜单中选择“RULE-SET”选项，该选项专门用于引用外部规则集文件。将复制的RAW链接粘贴到地址栏中，在策略动作栏选择“REJECT”以确定匹配规则后的执行动作，点击确定保存后该规则集即被引用到当前配置文件中。规则集在配置文件中的位置调整规则集添加完成后会出现在规则列表中的当前位置，为了确保广告拦截优先执行，用户应当长按该规则集条目左侧的拖动柄将其移动至规则列表的最前端。将广告拦截规则集置于配置文件的顶部，可以保证所有广告域名的请求在进入GEOIP直连或代理匹配之前就被直接拒绝，极大提升拦截效率和降低后续规则匹配的计算开销。调整位置后点击页面右上角的“保存”或“应用”按钮，配置文件的修改即被写入存储等待重载生效。配置重载与生效验证规则集添加并调整位置完成后，用户需要在配置页面点击“重新加载”按钮或通过下拉刷新来触发规则引擎重新读取配置文件中的所有内容，包括新添加的外部RULE-SET引用。重新加载成功后，规则集会从远程RAW链接下载最新的规则数据并加入引擎的匹配表，后续所有网络请求在符合规则集条件时都会执行REJECT动作。用户可以通过访问一个已知包含广告的页面来快速验证规则集是否生效，如果页面上的广告位被成功屏蔽则说明导入和配置流程完全正确。通过订阅方式自动更新johnshall规则规则集订阅的添加与配置为确保持续获得最新的广告域名列表而不需要每次手动更新，用户可以将johnshall规则集添加为订阅源，在Shadowrocket的“配置”页面中找到“订阅”或“资源”管理模块，点击加号新增订阅并填入规则集的RAW链接地址。添加时需要注意在订阅类型中选择“规则集”而非“节点”或“配置”，这样应用才会将该订阅识别为规则文件而非服务器列表。添加完成后保存订阅条目，应用会在后台记录该订阅源并在下次执行更新时自动拉取最新版本的规则集文件。自动更新间隔的合理设置在订阅条目详情页面中，用户可以开启“自动更新”开关并设置刷新间隔，推荐选择“每天”或“每12小时”作为更新频率，这样既能保证规则库的时效性又不会因过于频繁的请求而给服务器造成不必要的压力。对于广告投放策略变化较快的时期，用户也可以临时将更新间隔调整为“每6小时”以获得更及时的黑名单同步，但在日常使用中每天一次的更新频率已经足够覆盖大多数广告域名的变化周期。自动更新依赖Shadowrocket的后台刷新权限，用户需要在iOS的系统设置中为该应用开启后台应用刷新功能以确保定时任务能够正常执行。手动触发更新的操作方式除了自动更新外，用户也可以随时在订阅管理页面中点击对应订阅条目右侧的刷新按钮来手动触发一次即时更新，该操作会立即向远程服务器请求最新的规则集文件并覆盖本地缓存。手动更新在用户发现某个新出现的广告未被拦截时尤为有用，可以在规则维护者已更新黑名单但自动更新尚未执行的情况下快速获取最新规则。更新完成后应用会自动重载规则集内容，用户无需额外执行配置重新加载操作，新规则在更新完成后的数秒内即刻生效。johnshall规则库与其他规则库的搭配使用多规则库协同构建完整分流体系johnshall广告拦截规则库可以与主流的GEOIP直连规则、国内网站白名单规则以及代理规则同时引用到同一个配置文件中，共同构建从广告拦截到国内直连再到境外代理的完整三层分流体系。在规则列表中，广告拦截层位于最顶部负责过滤所有已知广告域名，中间层放置国内网站的直连规则和GEOIP批量直连，最底层则是FINAL兜底策略确保境外流量走代理通道。这种分层结构充分利用了规则匹配的优先级特性，使得每一种流量类型都能在最合适的位置获得最优的路由决策。规则集之间的顺序与冲突处理当配置文件中同时引用了johnshall规则集和其他规则集时，排列在靠前位置的规则集拥有更高的匹配优先级，如果两个规则集对同一个域名产生了冲突规则，靠前的规则集会优先生效。为了避免规则冲突导致意外拦截或漏拦截，建议用户将johnshall广告拦截规则集放在所有代理规则和直连规则之前，确保广告域名被优先拒绝。如果用户发现某个被johnshall拦截的域名实际上是自己需要正常访问的服务，可以在该规则集之前添加一条针对该域名的DOMAIN-SUFFIX规则并设置为DIRECT或PROXY，利用精确规则的前置优先级来覆盖广告拦截的REJECT动作。规则库的冗余与性能平衡同时引用多个广告拦截规则集可能会导致规则条目总数急剧膨胀，进而增加规则引擎的匹配计算开销和内存占用，用户应当根据实际需要控制引用的规则集数量。johnshall规则集本身已经具备较高的广告域名覆盖率，对于大多数用户而言单独引用该规则集即可满足日常的广告拦截需求，无需再叠加其他大型规则集合。如果用户确实需要更全面的覆盖（例如同时拦截中英文广告），可以选择johnshall规则集搭配一个专门覆盖国际广告域名的轻量级规则集，两者相互补充而不产生大量重叠，在覆盖面和性能之间取得良好平衡。规则导入后的生效验证与故障排除验证拦截效果与测试方法导入johnshall规则库后，用户访问一个已知存在大量广告的测试页面（如主流门户网站或视频网站），观察页面上的横幅广告、弹窗广告和视频前贴片广告是否被成功移除或显示为空白占位。如果广告位消失且页面加载速度明显提升，说明规则集正在有效工作，拦截逻辑已经正确应用到了浏览器的网络请求中。为了排除浏览器缓存对测试结果的干扰，用户应当在浏览器的无痕或隐私模式下进行测试，确保每次访问都是全新加载页面资源而不使用本地的缓存副本。处理被误拦截的正常功能若发现某个常用网站的功能出现异常（例如评论区无法加载、登录验证码不显示或第三方登录按钮无响应），大概率是该网站依赖的某个第三方域名被johnshall规则集误拦截了。用户应当打开Shadowrocket的实时日志功能，重新访问该问题页面并观察日志中被REJECT的域名列表，从中找出与当前页面功能相关但不应被拦截的目标域名。在确认域名后，返回配置页面的规则列表，在该域名被广告规则集匹配之前添加一条新的DOMAIN-SUFFIX规则，将其策略设置为DIRECT或PROXY以覆盖广告拦截的REJECT动作，保存并重新加载配置后问题即可解决。规则集更新失败或无法加载的处理当johnshall规则集在手动或自动更新时出现“请求超时”或“解析失败”的提示，通常是因为网络环境无法直接访问GitHub的RAW链接地址，此时用户可以先开启一个可用的代理节点后再执行规则集更新操作，让请求通过代理通道发送以绕过网络限制。如果代理节点已开启但依然更新失败，可以在浏览器中测试该RAW链接是否能够正常访问，若浏览器也无法打开则说明链接地址本身可能已失效或规则仓库已迁移，需前往johnshall的GitHub主页获取最新的链接地址并替换订阅中的旧链接。更新成功后重新加载配置即可恢复广告拦截功能。常见问题FAQ

PRE-MATCHING预匹配功能有什么用？

要正确使用Shadowrocket的预匹配功能，用户应先进入“设置-高级”面板找到预匹配开关将其开启，随后根据自身网络环境在预匹配IP列表中添加常用的私有地址段（如公司内网子网或固定公网服务IP），确认保存后即可生效。开启后，所有匹配预匹配列表的IP流量将直接绕过主规则引擎执行对应的路由动作，访问速度因省略规则匹配和DNS解析环节而显著提升。同时用户应认识到预匹配仅对IP地址有效且无法处理域名级分流，广告屏蔽和特定域名代理仍需依赖规则引擎中的精确规则，在实际使用中将预匹配定位为优化局域网访问和已知IP服务连接的加速器而非完整的分流解决方案。预匹配功能的技术原理与定位在规则引擎之前建立流量预筛选层预匹配是Shadowrocket中一项位于规则引擎前端的高级流量处理机制，它在配置文件中的规则匹配流程开始之前就介入网络请求的初步筛选工作。当设备发出网络请求时，预匹配模块会基于IP地址段、端口号或目标域名的特定属性进行快速的粗颗粒度判断，将明显属于特定类别的流量提前分流出去，从而避免这些请求进入后续繁琐的规则引擎逐条匹配流程。这种前置处理层本质上是一个轻量级的快速通道，专门用于处理那些具有明确路由指向且无需复杂规则判断的流量类型。预匹配与主规则引擎的处理时序差异预匹配的执行时机早于配置文件中所有规则，包括DOMAIN-SUFFIX精确规则和GEOIP批量规则，这意味着通过预匹配处理的流量完全不会经过规则引擎的匹配消耗。如果某个请求在预匹配阶段被成功匹配并分配了路由策略，该请求将直接执行该策略并绕过规则列表中全部规则的检查，后续的规则内容对该请求完全失效。这种时序上的绝对前置性使得预匹配成为整个分流链条中优先级最高的决策层，其处理结果具有不可被后续规则覆盖的最高权重。预匹配作为性能优化工具的核心价值预匹配功能的设计初衷是提升Shadowrocket在高负载网络环境下的处理效率，通过提前筛选出大量具有确定路由特征的流量来减少规则引擎的匹配工作量。在处理数百条甚至上千条规则的复杂配置时，每个请求都需要遍历大量规则条目才能找到匹配项，这种重复性的计算消耗会随着请求数量的增加而显著累积。预匹配通过在前面拦截一大部分规则可预测的流量，让规则引擎只需要处理剩余的不确定流量，从而大幅缩短了整体的匹配处理时间。预匹配对局域网和私有地址的优化处理内网流量的超快速直连通道处理局域网流量是预匹配最具实用价值的应用场景之一，当设备访问家庭路由器、NAS存储设备、网络打印机或局域网内其他设备时，这些请求的目标IP地址都属于私有地址段（如192.168.x.x、10.x.x.x）。预匹配功能允许用户在规则引擎之前就为这些私有地址段建立专门的直连规则，当系统检测到目标IP属于预定义的局域网段时，流量直接通过本地网络发出而不经过任何代理通道和规则匹配。这种处理的响应速度远快于通过规则引擎匹配IP-CIDR规则，因为在预匹配阶段完成分流意味着完全绕过了后续的全部规则检查流程。避免内网请求被代理通道错误转发在没有启用预匹配的情况下，如果配置文件中的IP-CIDR规则因排序靠后或被GEOIP规则提前拦截，内网请求可能错误地进入代理通道导致无法访问本地设备。预匹配通过在处理流程的最前端强制执行局域网直连策略，从源头上杜绝了内网请求被误转发到代理节点的可能性。这种强制执行不依赖于配置文件中规则的排列顺序，也不受FINAL兜底策略的影响，为用户访问局域网资源提供了最高的可靠性和确定性。私有地址段预匹配的默认配置与调整Shadowrocket在预匹配功能中默认包含了标准的私有IP地址段，包括10.0.0.0/8、172.16.0.0/12、192.168.0.0/16以及本地回环地址127.0.0.0/8，这些默认配置覆盖了绝大多数家庭和办公网络的内网环境。用户可以在高级设置中查看这些预置的私有地址段，并根据自身网络环境的需要添加其他特定的内网段（如公司内部使用的特定私有子网）。默认配置已经能够满足绝大多数用户的内网访问需求，通常不需要用户进行额外的修改或扩充。预匹配在DNS污染规避中的关键作用在域名解析前拦截特定IP段的异常请求当Shadowrocket处理一个包含域名的请求时，系统首先需要将域名解析为IP地址才能进行后续的路由判断，但在某些网络环境中DNS解析本身就存在被污染的风险。预匹配功能允许用户为已知的、不需要DNS解析的直连流量建立预匹配规则，这类流量在发出时直接基于目标IP地址进行路由决策而完全不需要触发DNS查询过程。当用户访问局域网设备或已知IP地址的外部服务器时，预匹配能够跳过DNS解析环节直接将流量直连，从根本上规避了因DNS污染而导致的解析错误和连接失败。预匹配与DNS解析的时序关系在预匹配启用的情况下，网络请求的处理顺序是先检查目标是否匹配预定义的IP地址段，然后再决定是否需要进入DNS解析流程。如果目标地址已经在预匹配规则中被判定为直连流量，系统会直接通过本地网络发出请求而不执行任何域名解析操作，这使得访问内网设备的速度大幅提升。相反，如果预匹配阶段未命中任何规则，请求才会进入正常的DNS解析和规则引擎匹配流程，此时需要面对可能存在的DNS污染问题。用户可以通过将频繁访问的内网设备IP预先加入预匹配列表，来确保这些请求在任何网络环境下都能稳定快速直连。减少不必要的DNS查询以加速连接当用户访问大量使用固定IP地址的内网服务或云服务器时，每次连接都需要进行DNS解析会引入不必要的延迟，特别是在DNS服务器响应较慢的网络环境中尤为明显。预匹配通过提前拦截这些基于IP的请求，让它们在不经过DNS解析的情况下直接完成路由选择并发出，将连接建立时间缩短到极致。这种优化对于需要频繁建立新连接的应用场景（如数据库访问、内部API调用）效果非常显著，能够将连接延迟降低数十毫秒甚至更多。预匹配与主规则引擎的性能协同机制通过预筛选降低主规则集的匹配深度当预匹配规则成功匹配一个请求时，该请求会被立即分流并终止后续的所有规则处理流程，这意味着规则引擎需要遍历的规则数量被有效减少。在一个包含数百条规则的大型配置文件中，如果预匹配能够拦截大约30%的请求（主要是局域网和常见直连流量），这些请求就不再消耗规则引擎的遍历计算资源。随着预匹配拦截比例的提升，规则引擎整体的平均匹配深度会明显降低，应用处理网络请求的效率也随之稳步提高。预匹配的缓存机制与匹配加速Shadowrocket对预匹配规则的匹配结果进行了内存缓存处理，当相同目标IP的请求在短时间内重复出现时，系统会直接从缓存中读取上次的匹配结果而无需再次执行预匹配检查。这种缓存机制进一步放大了预匹配的性能优势，因为局域网设备之间的通信往往具有高度重复性，同一内网IP在数秒内可能产生数十次连接请求。缓存的存在使得预匹配的处理开销在第一次匹配之后几乎降为零，将性能优化效果最大化。大流量场景下的负载缓解效应当用户同时运行多个需要网络访问的应用（如在线游戏、视频会议、文件下载同时进行）时，设备会产生大量的并发网络请求，这些请求如果全部进入规则引擎逐个匹配将造成明显的CPU占用和响应延迟。预匹配通过在规则引擎前拦截大量可预测的流量，显著降低了高并发场景下规则引擎的峰值负载水平。这种负载缓解效应在资源受限的旧款iPhone上表现尤其突出，能够有效减少因规则匹配过载而导致的VPN连接不稳定现象。预匹配配置项的具体设置与调整方法在高级设置中启用预匹配功能预匹配功能的配置入口位于Shadowrocket的“设置-高级”面板中，用户进入后需要在列表中找到“预匹配”或“PRE-MATCHING”相关的开关选项并将其启用。启用预匹配后，应用会激活内置的默认预匹配规则（主要是私有IP地址段），并在后续的所有网络请求处理中自动应用这些规则。用户在启用预匹配前无需对现有配置文件进行任何修改，因为预匹配是在规则引擎之外独立运行的附加层，不会影响现有配置文件的逻辑结构。自定义预匹配IP地址段的添加方法在预匹配设置页面中，用户可以点击“编辑预匹配列表”或类似选项进入IP地址段管理界面，在该界面中通过点击加号按钮添加新的IP段条目。添加时需要指定IP地址或CIDR格式的子网（如192.168.1.0/24），然后选择对应的策略动作（通常为DIRECT直连），保存后新规则即生效。建议用户将公司内部网络段、常用VPN网关地址或特定云服务器的固定公网IP加入预匹配列表，以享受这些流量绕过规则引擎的加速效果。预匹配规则与配置文件的独立存储预匹配规则独立于配置文件存储，即使更换了配置文件或订阅源，已经设置的预匹配规则仍然保持不变并继续生效。这种独立存储的设计使得用户可以在不同配置文件之间切换时保持预匹配规则的一致性，无需为每个配置文件单独配置预匹配参数。当用户清空应用数据或重置所有设置时，预匹配配置也会被一并清除，因此在执行重置操作前建议将预匹配列表的配置截图或导出保存。预匹配功能启用后的注意事项与适用边界预匹配无法处理域名级别的分流需求预匹配基于IP地址段进行路由决策，这意味着它无法识别那些需要使用域名进行匹配的流量，因为域名需要在DNS解析后才能获得对应的IP地址。对于需要精确控制特定域名的分流需求（如指定openai.com走代理、指定baidu.com直连），预匹配完全无能为力，这些请求仍然需要进入规则引擎通过DOMAIN-SUFFIX规则进行匹配。用户应当将预匹配视为规则引擎的补充而非替代，两者协同工作才能实现完整的流量控制覆盖。预匹配规则的适用范围限制预匹配仅在目标地址为IP地址时才能生效，当请求的目标是一个域名且该域名尚未被解析为IP时，预匹配无法对该请求进行任何处理，会直接放行进入DNS解析和规则引擎流程。这意味着预匹配的优化效果主要集中在对已知IP地址的访问上（包括局域网设备和固定公网IP服务），对于大量基于域名的互联网访问，其性能提升作用相对有限。用户不应对预匹配寄予过高的优化期望，应根据自身实际的网络使用模式合理评估其价值。预匹配启用后的调试与故障排查启用预匹配后如果发现某些局域网设备无法访问或部分IP流量被错误路由，用户应首先进入预匹配的规则列表检查是否有冲突或错误的IP段配置。由于预匹配的处理顺序优先于规则引擎，预匹配阶段发生的路由错误无法通过调整配置文件中的规则顺序来修正，唯一的解决方法是直接在预匹配列表中修改或删除对应的IP段条目。在进行排查时可以临时关闭预匹配功能以验证问题是否确实源于预匹配配置，确认后再逐一调整有问题的条目。常见问题FAQ

Shadowrocket规则匹配顺序是怎样的？谁先谁后？

Shadowrocket规则匹配顺序遵循“从上到下逐条匹配、首次命中即停止”的核心机制，其中DOMAIN类型精确规则享有最高的实际优先级，应放置在配置文件最前端；GEOIP批量规则放置在中段以覆盖未被精确域名规则匹配的国内流量；IP-CIDR精细控制规则放置在后段进行IP层面的补充分流；FINAL兜底规则位于列表末尾作为所有未匹配流量的最终出口。用户在编写配置文件时应遵循“从精确到通用、从拦截到放行”的排序原则，将高频命中规则置于对应类别的前端以优化匹配效率，并利用实时日志验证关键域名的实际匹配结果以进行动态调整。当遇到规则不生效或分流异常时，首先通过日志定位具体命中的规则位置，然后根据定位结果移动规则顺序或修改规则内容，保存后重新加载配置即可让调整生效。规则匹配的基本逻辑从上到下的逐条匹配机制Shadowrocket在处理网络请求时，规则引擎会从配置文件的第一条规则开始，按照从上到下的顺序逐条比对每个请求的目标域名或IP地址。一旦某条规则成功匹配当前请求，引擎会立即执行该规则定义的动作（如PROXY、DIRECT或REJECT）并停止后续所有规则的检查。这种“首次命中即停止”的机制意味着规则的排列顺序直接决定了流量的最终去向，排在靠前位置的规则拥有绝对的优先级优势。精确匹配与模糊匹配的权重差异虽然匹配顺序由规则在文件中的物理位置决定，但不同类型的规则在匹配效率上存在内在差异。精确的域名规则（如DOMAIN-SUFFIX,google.com）在匹配时只需简单的字符串比对，执行速度快且精准度高。而模糊匹配规则（如GEOIP,CN）需要查询IP地理位置数据库，计算开销相对较大。如果大量请求需要遍历整个规则列表，批量规则的性能损耗会累积，因此高频命中的精确规则应当优先放置。兜底规则作为匹配链条的终点配置文件末尾的FINAL策略是整个规则匹配链条的最终裁决者，任何未被所有前置规则匹配的请求最终都会执行FINAL策略指定的动作。无论FINAL设置为PROXY还是DIRECT，其执行顺序都处于规则列表的最末端，不会影响任何前置规则的优先匹配权。用户可以通过调整FINAL策略的取值来快速切换配置文件的整体分流倾向，而无需重构整个规则列表。规则类型的优先级层级DOMAIN类型规则的最高优先级在所有规则类型中，DOMAIN规则（即指定具体域名的规则）享有最高的实际优先级，因为其匹配的精准度最高且确定性最强。当配置文件的前置位置放置了DOMAIN-SUFFIX或DOMAIN-KEYWORD规则时，任何匹配这些规则的请求都会被立即处理，不会进入后续的GEOIP批量匹配阶段。用户应当将所有需要精确控制的关键域名规则放在配置文件的最前面，确保这些重要流量的路由策略不受后续批量规则的干扰。DOMAIN-SET集合规则的批处理优先级DOMAIN-SET规则引用的是外部域名集合文件，其匹配逻辑与DOMAIN-SUFFIX类似但以批量方式处理，适用于需要覆盖大量域名的场景。在规则顺序中，DOMAIN-SET规则通常放置在DOMAIN-SUFFIX精确规则之后、GEOIP批量规则之前，起到承上启下的作用。如果DOMAIN-SET规则被放置在GEOIP规则之后，其匹配效果会因GEOIP的提前拦截而大打折扣。GEOIP批量规则的中段位置GEOIP规则基于IP地理位置数据库进行批量匹配，其覆盖面广但精确度不及域名规则，因此应当放置在所有DOMAIN类型规则之后。将GEOIP规则放置在配置文件中段，可以确保特定域名的精确分流不受批量地理规则的影响，同时又能将大量未被域名规则覆盖的国内IP段流量批量直连，有效减轻后续规则的处理负担。GEOIP规则的位置一旦过于靠前，所有特定域名的精确控制能力都会被批量规则覆盖而失效。IP-CIDR与最终兜底规则的位置IP-CIDR规则基于IP地址段进行匹配，其精确度介于DOMAIN规则和GEOIP规则之间，通常放置在GEOIP规则之后、FINAL兜底规则之前。这种位置安排使得特定IP段的流量可以在地理批量规则之后得到更精细的控制，而FINAL规则则作为所有未匹配流量的最终出口，确保任何流量都不会因为没有匹配到规则而被丢弃。同类型规则之间的优先级规则DOMAIN-SUFFIX之间的匹配顺序当配置文件中包含多条DOMAIN-SUFFIX规则时，排在靠前位置的规则优先匹配，后置的同类型规则不会被引擎检查。这意味着如果用户同时拥有DOMAIN-SUFFIX,google.com,PROXY和DOMAIN-SUFFIX,googleapis.com,DIRECT两条规则，访问googleapis.com时如果后者排在前面则会直连，如果前者排在前面则会走代理。用户需要合理安排同类型精确规则的排列顺序，确保最频繁访问的域名规则排在列表前端以优化匹配效率。同类IP规则的前后优先级GEOIP规则和IP-CIDR规则在处理IP地址匹配时遵循相同的顺序优先级逻辑，排在前面的规则优先匹配。如果配置文件中有IP-CIDR,192.168.0.0/16,DIRECT和IP-CIDR,10.0.0.0/8,DIRECT两条规则，访问10.x.x.x的请求需要匹配到第二条规则，如果第一条规则无法匹配则继续往下检查。多个同类型IP规则在排列时，应当将覆盖范围更小的精确IP段放在前面，覆盖范围更大的批量段放在后面，避免因顺序不当导致匹配效率下降。命名空间与规则类型的兼容性当DOMAIN-SUFFIX规则和DOMAIN-KEYWORD规则同时匹配同一个请求时，排在靠前位置的那条规则会生效，另一条规则即使匹配程度更高也不会被执行。用户应避免为同一个域名同时配置不同类型的多条规则，因为这会导致配置的冗余和不确定性。如果必须保留多条规则，应当将覆盖范围更小、匹配更精确的规则放在前面，覆盖范围更大的规则放在后面。规则集与内联规则的解析顺序RULE-SET引用的展开与整合RULE-SET指令引用外部规则集文件时，这些外部规则在逻辑上会被展开并插入到指令所在的位置，按照外部文件内部的规则顺序依次参与匹配。当一个RULE-SET指令位于配置文件中段时，其引用的所有规则会在该位置整体插入，这些外部规则的内部顺序被完整保留，但整个规则集被视为一个逻辑单元。外部规则集中的规则与配置文件中其他内联规则之间的优先级顺序，完全取决于RULE-SET指令在文件中的物理位置。多个RULE-SET之间的优先级关系当配置文件中包含多个RULE-SET指令时，排在靠前位置的规则集整体具有更高的匹配优先级，即使两个规则集之间存在规则重复，前面的规则集也会先于后面的规则集被匹配。如果用户引用了多个广告拦截规则集和多个直连规则集，应当将广告拦截规则集放置在直连规则集之前，确保广告域名在直连判断之前就被拦截。多个RULE-SET之间的顺序安排同样遵循“从精确到通用、从拦截到放行”的通用原则。规则集内部顺序与文件管理的优化规则集文件内部的规则顺序同样重要，用户在维护外部规则集文件时应当按照与主配置文件相同的逻辑组织内部顺序，将最关键的精确规则放在文件开头。如果一个规则集文件包含数百条规则但内部顺序混乱，即使该规则集在整个配置中放置的位置正确，其匹配效率也会因为内部遍历过多低优先级规则而下降。定期对规则集文件进行内部顺序审查和优化，是维持配置文件整体性能的重要环节。策略组与节点选择的顺序影响策略组内节点优先级的手动与自动模式在策略组中，节点列表的排列顺序直接影响选择结果：当策略组类型为select（手动选择）时，列表顺序仅影响界面的显示位置；当策略组类型为url-test（自动延迟测试）时，列表顺序对选择结果没有影响，因为引擎会按照实际测速结果排序。但如果策略组类型为fallback（故障转移），则节点列表的顺序直接决定了优先尝试的顺序，排在第一位的节点会作为首选节点，只有在其不可用时才会尝试后续节点。策略组嵌套时的匹配顺序当策略组作为PROXY策略的目标时，其内部的节点或策略组选择在规则匹配阶段之后执行，与规则匹配顺序无关。策略组的嵌套深度不会影响规则匹配的优先级，但会影响具体节点选择的复杂度和执行时间。深度嵌套的策略组在每次匹配时需要遍历多个层次的策略组定义，虽然这种开销在单次请求中很小，但在大量请求并发时会产生累积延迟。策略切换对规则顺序的影响用户手动切换PROXY策略指向的节点或策略组，并不会改变规则匹配的顺序，只会改变PROXY策略执行时的具体转发目标。无论用户选择了哪个节点，规则匹配的顺序始终由配置文件决定，PROXY策略在匹配后执行的只是转发动作的出口变化。理解这种顺序与动作的解耦关系有助于用户区分“规则匹配问题”和“节点连通性问题”这两种不同类型的故障。基于最佳实践的标准规则顺序标准配置文件的推荐规则顺序一个经过优化的标准配置文件应当按照以下顺序组织规则：首先是REJECT拦截规则（广告域名、恶意软件域名），其次是PROXY强制代理规则（关键境外服务），接着是DIRECT精确直连规则（国内主流网站），然后是GEOIP,CN批量直连规则，随后是IP-CIDR精细控制规则，最后是FINAL兜底策略。这种分层顺序覆盖了从最特殊需求到最通用需求的全部场景，确保了精确规则不被批量规则覆盖，同时保持了规则列表的整体逻辑清晰。高频命中规则的排序优化策略在维持逻辑顺序的前提下，用户应当将最高频命中的规则（如访问量最大的国内网站直连规则）放置在对应类别的最前端，以减少规则引擎匹配这些高频请求时的遍历深度。例如在DIRECT直连规则类别中，应当将“百度”、“腾讯”、“淘宝”等最常访问的网站规则放在该类别的靠前位置。这种基于访问频率的排序优化不会改变规则的逻辑结构，但可以显著提升整体的匹配效率。动态调整规则顺序的调试流程当用户发现某个特定域名的分流结果与预期不符时，应当首先通过Shadowrocket的实时日志确认该请求实际命中了哪条规则，然后根据日志结果调整规则顺序或修改规则内容。调试过程中可以在配置页面临时启用“编辑模式”拖动规则条目的位置，调整后保存并重新加载配置，然后再次检查该域名的匹配结果。反复调整直到分流行为完全符合预期后，将最终的稳定顺序固定下来作为配置文件的永久版本。常见问题FAQ