资讯与使用教程

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

Shadowrocket url-test自动选择最快节点怎么工作？

Shadowrocket的url-test策略组通过定时向指定的测试URL发起HTTP请求，遍历策略组内所有节点并记录各自的响应延迟，经排序后将延迟最低的节点标记为当前最优节点，当分流规则引用该策略组时自动选择此最优节点作为出口。配置时需在[ProxyGroup]段落定义type=url-test，指定url测速目标、interval测速间隔（推荐300至600秒）和timeout超时阈值（推荐5秒），并在proxies列表中列出所有候选节点。该机制实现了节点选择的自动化，能动态适应网络波动，但不适合带宽密集型场景，因为延迟低不等于吞吐量大。建议用户将url-test与select组结合使用，既保留自动优化的便利性，又保留手动干预的灵活性，同时定期审查测速URL的可达性和节点列表的有效性。通过观察策略组界面中的延迟数值和详细日志记录，用户可验证测速任务是否正常运行，并在测速URL被屏蔽或全部节点超时时及时更换测试目标，确保策略组始终保持有效的工作状态。url-test策略组的工作流程解析定时测速任务触发机制在配置文件中定义的url-test策略组会启动一个独立的定时任务循环，按照interval参数指定的时间间隔（单位秒）自动执行测速操作。每次测速时，策略组会遍历proxies列表中定义的所有节点，依次通过每个节点向预设的url测试地址发起HTTP请求，并精确记录从请求发出到收到完整响应所消耗的时间，最终获得每个节点的延迟数值。节点排序与自动切换逻辑测速完成后，Shadowrocket会根据每个节点的响应延迟进行升序排列，延迟最低的节点被标记为“最优节点”。当实际网络请求命中该策略组时，系统会自动使用这个延迟最低的节点进行连接。若当前已使用的节点在最新测速轮次中不再是延迟最低的节点，策略组会在下一个请求时自动切换至新的最优节点，无需用户手动干预。测速失败与超时节点的处理机制当某个节点在测速过程中出现连接失败或响应时间超过timeout参数设定的阈值时，该节点会被标记为“超时”或“不可达”，从当前测速轮次的有效结果中排除。若所有节点均测速失败，策略组将保持上一次成功测速的节点继续使用。这种机制确保了即使在部分节点故障的情况下，策略组仍能回退到已知可行的节点，维持基本可用性。关键参数的作用与调优建议url测速目标的选择策略url参数决定了测速请求的目标地址，直接影响延迟数值的代表性和可靠性。推荐使用全球CDN覆盖广泛且响应极快的静态资源地址，如http://www.gstatic.com/generate_204（Google的轻量级204响应）或http://cp.cloudflare.com/。这些地址在全球各节点都能快速响应，且数据包极小，测速消耗的网络流量可以忽略不计。避免使用访问受限或被屏蔽的网址，否则测速结果将完全失效。interval测速间隔的频率权衡interval参数以秒为单位控制测速任务的执行频率，默认值通常为300秒（5分钟）。间隔过短（如60秒）会增加节点负担和流量消耗，且可能导致频繁切换节点造成连接不稳定；间隔过长（如1800秒或更长）则无法及时感知节点性能变化。建议在300至600秒之间选择合适的值，在及时性与稳定性之间取得平衡。若节点质量稳定且切换敏感度要求不高，可适当延长至900秒。timeout超时阈值的合理设定timeout参数设定单个节点测速的最长等待时间，超过该时间即判定为超时。设定过小（如2秒）可能将延迟略高的节点误判为不可用，尤其在国际路由波动时；设定过大（如10秒）则会拉长整体测速周期，影响测速效率和切换及时性。推荐设置为5秒，既能容忍合理的网络波动，又不会过度延长等待时间。url-test与分流规则的协同工作规则引用策略组时的实际出口决策当分流规则（如DOMAIN,youtube.com,视频组）将特定流量指向一个url-test策略组时，该请求在到达策略组时会获取当前已被标记为“最优”的节点进行连接。每次请求不会触发新的测速，而是直接使用最近一次测速轮次的结果，确保了连接建立的即时性。测速任务与请求处理并行运行，相互独立，互不阻塞。不同规则共享同一测速组的优势多个分流规则可以同时引用同一个url-test策略组，实现流量的集中智能调度。例如将YouTube、Netflix、Hulu的规则都指向“流媒体优选组”，则该组的最优节点将同时服务于所有流媒体服务，当节点性能变化时，所有流媒体流量同步切换至新最优节点，无需逐个规则调整。这种集中管理显著降低了多规则场景下的维护成本。策略组嵌套中的测速行为当url-test策略组作为另一个策略组（如select手动组）的嵌套成员时，其测速任务仍独立运行，持续更新内部节点的延迟排序。但最终出口的选择由顶层策略组的类型决定：若顶层是select组且用户手动选择了该url-test组，则实际节点为该组当前测速最优值；若顶层是另一个url-test组，则可能存在双层测速逻辑，增加了选择复杂度。url-test的局限性与实际表现延迟低不等于实际网速快url-test仅测量HTTP请求的响应延迟，反映的是网络往返时间和节点处理速度，但不直接反映带宽容量和吞吐能力。一个延迟低至30ms但带宽仅1Mbps的节点，在观看视频时可能远不如延迟60ms但带宽达50Mbps的节点流畅。用户需认识到“最快”仅指“响应最快”，而非“下载最快”，在带宽密集型场景下需结合其他手段评估节点实际性能。测速目标与真实访问目标的差异测速使用的固定url与用户实际访问的网站可能位于完全不同地理位置或CDN网络中。若测速目标位于美国西海岸而用户主要访问欧洲网站，测速结果可能严重失准，导致策略组错误地选择了一个“测速快但访问慢”的节点。理想情况下应选择与用户真实访问目标地理分布相近的测速URL，但这在实际配置中难以完美实现。测速频率与节点切换的抖动影响频繁的测速和节点切换可能引入连接抖动，尤其当多个节点延迟接近时，策略组可能在几轮测速间反复切换，造成已建立的连接不稳定。部分Shadowrocket版本支持persistent参数（若存在）可缓解此问题，优先保持当前节点不变，仅当当前节点延迟显著高于最优节点时才触发切换，有效降低无效切换的频率。优化url-test配置的实战技巧使用多个测速URL进行综合评估单一测速URL可能无法全面反映节点性能，用户可在配置中尝试调整策略组结构，例如创建多个不同测速目标的url-test子组，再由一个顶层的select组手动选择当前最合适的测速组。虽然无法在一个策略组内使用多个URL，但通过嵌套和手动组合，可实现不同场景的差异化测速策略，增强灵活性。结合手动选择组与自动组的混合策略将url-test组作为select组的一个选项加入，用户既可选择“自动优选组”享受智能调度，也可在自动选择不理想时手动切换到特定节点。例如配置“手动选择组”包含“自动测速组”和“香港直连”、“美国直连”等固定节点选项，兼顾了自动化便利和人工干预的精确控制。定期审查节点列表与清理失效节点url-test策略组会持续测速proxies列表中的所有节点，若列表包含长期失效或高延迟节点，测速轮次时间会延长且可能干扰排序结果。用户应定期清理失效节点，将确认稳定的节点保留在列表中。对于可用的节点，可根据经验调整列表顺序，将性能更优的节点排在前面，尽管不影响测速结果，但便于手动查看和管理。验证url-test工作状态的方法查看策略组界面中的延迟数值在Shadowrocket首页的策略组区域点击对应的url-test组，展开后每个节点旁会显示最近一次测速的延迟数值（单位毫秒），“最优节点”通常被标记或排在首位。用户可通过观察延迟数值的变化趋势判断测速任务是否正常运行，若数值长时间不更新或全部显示超时，则需检查测速URL是否可访问或节点是否全部失效。通过日志跟踪测速执行记录开启Shadowrocket的详细日志功能后，每次测速轮次开始时，日志会记录“Testingproxygroupxxx”的信息，并逐个列出每个节点的延迟结果和最终选择的节点。若测速异常（如全部超时），日志会输出相应警告。这些日志是排查测速配置是否有效的直接依据，尤其在问题发生时能快速定位故障环节。实际访问体验与测速结果的对齐验证选择多个不同地理位置的网站进行实际访问测试，观察策略组是否确实将流量导向了测速显示的最优节点。若发现实际访问体验与测速排序明显不符（如测速最快的节点访问特定网站却很慢），则需考虑调整测速URL或重新评估节点选择的依据，可能需增加人工干预。常见问题FAQ

Shadowrocket策略组（Proxy Group）怎么配置？

配置Shadowrocket策略组的核心是理解三类策略类型的选择：select将决策权交给用户，适合需要手动控制出口的场景；url-test自动选择延迟最低的节点，适合追求最佳速度的日常使用；fallback按优先级顺序故障转移，适合对连接稳定性要求极高的自动化任务。配置时需在配置文件的[ProxyGroup]段落为每个策略组定义名称、类型和proxies节点列表，并确保节点名称与[Proxy]段落中的定义完全一致。策略组生效的关键在于分流规则中引用其名称，将规则的目标从具体节点提升到策略组层面，实现规则与节点的解耦。建议从简单的select组开始实践，逐步引入嵌套结构和自动测速功能，并通过Shadowrocket首页的策略组界面验证切换操作是否正常。定期审查策略组中的节点列表，移除失效节点并调整顺序，保持策略组的有效性。对于大规模节点管理，利用策略组嵌套构建地区层和性能层的两级调度架构，显著提升配置的可维护性和流量调度的智能程度。理解策略组的核心价值与设计逻辑策略组解决流量智能调度问题策略组是Shadowrocket配置文件中的核心组件，它本质上是一个逻辑容器，将多个代理节点或策略组聚合在一起，并定义如何从这些选项中选择实际出口。当分流规则将某个域名或IP段指向一个策略组时，Shadowrocket会按照策略组预设的选择机制（如手动选择、自动测速或故障转移）决定最终使用哪个节点发起连接，实现了流量的动态调度和灵活管理。策略组与策略组的嵌套层次关系策略组不仅可包含节点，还能包含其他策略组，形成多层级结构。例如可创建一个“美国主用组”包含多个美国节点，再创建一个“北美汇总组”包含“美国主用组”和“加拿大节点组”。当规则指向“北美汇总组”时，Shadowrocket会逐层解析，最终落到具体节点上。这种嵌套能力使大规模节点管理变得层次分明且高度可扩展。策略组在分流规则执行链中的位置流量处理流程为：请求到达→匹配分流规则→规则指向策略组→策略组按选择策略确定节点→连接建立。策略组是连接“规则”与“实际节点”的桥梁，它解耦了“哪些流量走代理”和“具体走哪个节点”这两个决策维度，使用户能独立调整节点列表或策略选择机制，而无需逐条修改规则。这是策略组配置灵活性的根本来源。策略组类型详解与选择策略select手动选择策略组的特点与适用场景select类型的策略组将选择权完全交给用户，在Shadowrocket首页的策略组区域会显示所有可用选项，用户点击即可手动切换。这种模式适合希望完全掌控出口选择的用户，例如需要随时在不同国家的节点间切换以访问特定区域内容，或固定使用某个性能最优的节点。其优势是透明可控，但需要用户主动管理。url-test自动测速策略组的工作机制url-test类型策略组会定期向预设的测试网址（如http://www.gstatic.com/generate_204）发起请求，根据响应延迟自动排序，并将流量导向当前延迟最低的节点。该模式适合追求最佳速度体验的用户，尤其在节点质量参差不齐且动态变化的环境中，它能自动适应网络波动，始终选择响应最快的出口。需注意测速本身会消耗少量流量和系统资源。fallback故障转移策略组与备用逻辑fallback策略组定义了主节点和备用节点的优先级顺序，主节点优先被使用。当主节点连接失败或超时达到设定阈值时，自动切换至下一个备用节点，依此类推。这种模式适合对连接可用性要求极高的场景，如长时间运行的下载任务或自动化脚本，避免因单个节点故障导致任务中断，实现了高可用性的节点调度。配置策略组的基础语法与结构策略组配置在配置文件中的位置策略组定义位于配置文件的[ProxyGroup]段落，该段落与[Proxy]、[Rule]等段落并列。所有策略组的声明必须集中在此段落内，每个策略组独立成块，使用[[ProxyGroup]]作为组标记开始。策略组的名称在整个配置文件中必须唯一，且区分大小写，其他段落（如规则）引用时需使用完全一致的名称。手动选择策略组的完整配置模板最基础的select类型策略组配置示例如下：text[[ProxyGroup]]name=手动选择组type=selectproxies=香港节点01,日本节点02,美国节点03,DIRECTname定义组名称，type指定策略类型，proxies列出所有可选节点（包括DIRECT或REJECT等策略）。列表中的顺序决定了在Shadowrocket界面中的显示顺序，用户可根据使用频率或偏好调整排列。自动测速与故障转移策略组的参数配置url-test策略组需增加url指定测速目标，interval设定测速间隔（秒），timeout设定超时阈值：text[[ProxyGroup]]name=自动优选组type=url-testurl=http://www.gstatic.com/generate_204interval=300timeout=5proxies=香港节点01,日本节点02,新加坡节点03fallback策略组类似，但无需url，按列表顺序决定优先级，同时可通过max-fail设置连续失败次数后切换备用节点。策略组与分流规则的衔接配置规则中引用策略组名称的方式在[Rule]段落中，将原本指向具体节点或DIRECT的策略目标替换为策略组名称。例如DOMAIN,youtube.com,PROXY中的PROXY若替换为“手动选择组”，则YouTube流量将走向该策略组包含的节点。这一替换将规则的决策从“走哪个节点”提升到“走哪类节点组合”，使规则更简洁且便于统一管理。多规则共享同一策略组的协同效果多个分流规则可同时指向同一个策略组，实现流量的集中出口管理。例如将所有流媒体域名（YouTube、Netflix、Hulu）的规则都指向“流媒体专用组”，当该组的节点切换时，所有流媒体流量同步切换至新出口，无需逐条修改规则。这种“规则-策略组”的多对一映射显著提升了配置的维护效率和一致性。利用策略组实现规则与节点的解耦策略组最大的架构价值是解耦了“规则定义”和“节点选择”。当节点列表更新（如新增或删除节点）时，只需在策略组的proxies列表中调整，所有引用该策略组的规则自动感知变化，无需任何额外修改。这种分层设计使配置的扩展性和适应性大幅提升，尤其适合频繁更换节点或维护大型配置文件的用户。高级配置与嵌套策略组的应用策略组嵌套实现多层级选择逻辑策略组的proxies列表中可包含其他策略组名称，形成多级决策树。例如：text[[ProxyGroup]]name=全球汇总组type=selectproxies=亚洲组,美洲组,欧洲组,DIRECT[[ProxyGroup]]name=亚洲组type=url-testproxies=香港节点01,日本节点02,新加坡节点03当“全球汇总组”被选择时，用户可先选择地区大组，再由各地区的自动测速组决定具体节点，实现了地区优先再性能优先的两级调度策略，适合节点覆盖广泛的使用场景。结合DIRECT与REJECT策略的特殊用途在策略组的proxies列表中加入DIRECT表示该策略组可能选择直连出口，REJECT则表示选择拒绝连接。例如可在“手动选择组”中加入DIRECT选项，用户临时需要直连时可直接在界面切换，无需修改规则。REJECT可用于规则调试或临时屏蔽特定流量，通过策略组提供了比规则更灵活的控制手段。配置测试网址的优化选择url-test的测试网址选择直接影响测速结果的代表性和准确性。推荐使用响应速度快、全球节点延迟差异明显的稳定服务，如http://www.gstatic.com/generate_204（Google的轻量级204响应）或http://cp.cloudflare.com/。避免使用访问受限或被屏蔽的网址，否则测速结果可能持续超时，导致策略组无法正常工作。策略组配置的验证与调试Shadowrocket首页的策略组界面操作配置正确加载后，在Shadowrocket首页底部会显示所有select类型策略组的名称和当前选中的节点。用户点击任一策略组即可展开其proxies列表中所有选项，进行手动切换。若某策略组在界面中未出现，需检查配置文件中该策略组是否正确定义且被至少一个规则引用，未被引用的策略组不会在界面显示。通过日志确认策略组的实际选择开启Shadowrocket的详细日志功能后，当请求命中某个策略组时，日志会清晰显示“ProxyGroupxxxselectednodeyyy”的字样，明确告知本次连接实际使用的节点。若选择结果与预期不符，可通过日志中的延迟测试记录或切换动作定位问题，例如url-test组选择了非预期的节点时，检查其测速URL是否可访问且延迟数据准确。策略组切换生效的时机与范围策略组的切换操作（包括手动选择和自动测速组的重新选优）实时生效，影响所有引用该策略组的规则。但已建立的现有连接不会中断切换，新策略仅对切换后新建的连接生效。若切换后发现某些应用未及时跟随新策略，可尝试重启应用或断开重连以强制使用新的出口节点。常见问题FAQ

本地HOST映射对代理生效（always-ip-address）怎么设置？

设置Shadowrocket的always-ip-address功能，核心是配置文件中为特定域名强制指定固定的IPv4地址，以绕过DNS解析环节。用户先通过可靠的DNS工具获取目标域名在当前网络环境下的正确且稳定的IP地址，然后打开Shadowrocket配置编辑界面，在[General]段落中添加always-ip-address=域名:IP地址的键值对，保存并重新加载配置文件使设置生效。该功能适用于应对DNS污染、优化解析速度以及固定节点域名IP等场景，能有效提升访问成功率和响应速度。但需注意IP地址变更导致的连接失效风险，尤其对使用CDN调度的动态域名应谨慎使用或定期更新。建议仅对IP长期稳定的目标启用该参数，并在配置中加入备注记录IP的验证日期便于维护。验证生效可通过Shadowrocket日志确认连接是否使用了预设IP，并结合实际访问速度和稳定性评估效果。与skip-proxy、bypass-system等参数的协同使用时需明确各自作用范围，确保预期配置准确落地。always-ip-address的功能原理与设计目的绕过DNS解析直接使用指定IP的核心机制always-ip-address是Shadowrocket配置文件中用于为特定域名强制指定IP地址的参数，它的核心作用是让设备在访问这些域名时直接使用配置中写入的IP，完全跳过DNS解析环节。当该参数生效时，即使DNS服务器返回了其他IP地址，Shadowrocket仍会忽略DNS结果，强制使用预设的IP进行连接。这一机制主要用于解决DNS污染、解析延迟或特定场景下的IP固定需求。参数在配置文件中的位置与格式always-ip-address位于配置文件的[General]段落，采用域名:IP地址的键值对格式。示例写法为always-ip-address=example.com:1.2.3.4，多个条目可重复使用该参数或用逗号分隔。需注意该参数仅支持IPv4地址，若需指定IPv6需使用ipv6-always-address参数。保存修改后重新加载配置，所有对该域名的请求将直接发往预设IP。与本地HOST文件功能的类比与区别该参数功能类似于操作系统的hosts文件，都实现了域名到IP的静态映射，但作用范围不同。系统hosts影响设备所有应用的DNS解析，而always-ip-address仅作用于通过Shadowrocket代理的流量。对于直连流量（如规则设为DIRECT），该参数无效，DNS解析仍由系统hosts或DNS服务器决定。这一差异化控制使得用户可仅在代理流量中应用固定IP，避免影响其他网络行为。always-ip-address的典型使用场景应对DNS污染与劫持的解决方案当用户所处网络环境存在DNS污染（即域名被恶意解析到错误IP）时，通过always-ip-address为目标域名指定正确的IP地址，能强制代理流量绕过污染结果直接访问正确服务器。例如某些海外网站在国内被DNS劫持，用户可将该域名的真实IP写入参数，代理访问时直接使用该IP，从而恢复正常访问。这是该参数最经典且最广泛的应用场景。优化特定域名的解析速度与稳定性部分国外域名的DNS解析在国内响应缓慢或超时，导致网页首屏加载延迟。用户可将这些域名的常用IP预先写入配置，使Shadowrocket省去DNS查询的等待时间，直接建立连接，显著提升访问速度。尤其对于CDN节点分布广泛的域名，固定一个稳定且快速的IP能大幅改善网络体验，避免因DNS解析波动造成的间歇性连接问题。实现节点域名的IP直连防干扰当代理节点域名本身也遭遇DNS干扰时，用户可在always-ip-address中为节点域名指定IP地址，确保节点连接始终指向正确的服务器IP。这避免了节点域名解析异常导致的“所有节点超时”问题，尤其在网络环境复杂或运营商存在DNS劫持时，能有效保障代理隧道的基础连通性。设置always-ip-address的具体操作步骤获取目标域名的正确IP地址的方法用户需先确认目标域名应指向的正确IP。可通过在未启用代理的网络环境下使用nslookup域名或dig域名命令查询，或使用全球DNS查询工具（如dnschecker.org）获取该域名在海外DNS服务器返回的权威解析结果。建议同时验证该IP是否可达（ping测试），并确认其归属地与预期一致，避免使用已被封锁或性能低下的IP地址。编辑配置文件添加参数的规范写法打开Shadowrocket的配置编辑界面，进入[General]段落，在段落末尾或合适位置新增一行always-ip-address=目标域名:IP地址。例如always-ip-address=api.github.com:140.82.112.3。若需为多个域名指定IP，可重复该行或使用逗号分隔多个键值对。确保域名与IP之间使用英文冒号分隔，无多余空格，保存修改后重新加载配置使设置生效。多条目的管理与优先级规则当为同一域名指定了多个IP时，Shadowrocket通常使用最后一条配置中写入的IP。用户若需为不同场景保留备选IP，可注释掉当前条目并切换至备选IP行。建议使用#进行注释管理，将多条配置保留在文件中但仅启用一条。注意多个条目间不应存在冲突，否则以最后加载的为准，管理时需清晰标注每条的目的和适用场景。always-ip-address的核心优势与收益完全消除DNS解析环节的延迟消耗DNS解析通常需要几十毫秒至数秒不等，尤其在国内访问海外域名时，解析延迟和丢包常导致首屏加载显著滞后。启用always-ip-address后，Shadowrocket在连接目标服务器时完全跳过DNS查询，直接使用预设IP发起请求。这一优化在解析超时频繁的网络环境下能缩短数秒的等待时间，用户会直观感受到网页响应速度的大幅提升。规避DNS劫持与运营商篡改国内部分运营商或网络设备会对特定域名的DNS解析结果进行篡改，将用户引导至广告页面或错误服务器。通过always-ip-address固定目标域名的真实IP，流量绕过了DNS解析环节，彻底规避了运营商的劫持干扰。用户访问被劫持的网站时将直接到达正确服务器，不再出现被跳转到广告页或无法打开的情况。提升代理隧道的连接成功率当代理节点的域名解析受干扰时，节点连接可能因解析到错误IP而失败。固定节点域名的IP后，Shadowrocket能始终连接到正确的服务器IP，减少了因DNS问题导致的节点不可用。这在网络环境不稳定的场景下能显著提升代理隧道的连接成功率，降低用户手动切换节点的频率。潜在风险与注意事项IP地址变更导致的连接失效风险CDN服务商和动态域名服务（DDNS）的IP地址会频繁变动，若用户固定的IP发生变更，而配置未同步更新，always-ip-address会将流量持续导向失效的旧IP，导致该域名完全无法访问。用户需定期检查目标域名的解析变化，或在配置中备注IP的验证日期。建议仅对IP长期稳定的域名（如企业官网、自建节点）使用该功能。与CDN负载均衡机制的兼容性问题大型网站的CDN服务依赖DNS解析将用户调度至最近的边缘节点，以实现负载均衡和低延迟访问。固定IP后，用户始终连接到同一节点，可能无法利用CDN的地理优选调度，导致访问速度变慢或遇到特定区域的内容限制。对于使用全球CDN的网站（如Google、YouTube），固定IP的效果可能适得其反，需谨慎评估。配置维护成本与过期IP的清理随着时间推移，配置文件中可能积累大量不再需要或已失效的固定IP条目，若不及时清理，可能造成部分网站访问异常。用户应定期审查always-ip-address列表，通过实际访问测试验证每个条目的有效性，移除过期内容。建议在配置中为每条记录添加注释，记录添加日期和用途，便于后续维护。与其他相关功能的联动与对比always-ip-address与skip-proxy的配合当skip-proxy将某域名设为直连后，always-ip-address对该域名不再生效，因为直连流量完全绕过Shadowrocket的代理处理。若用户希望同时固定IP并走代理，需确保该域名的分流规则为PROXY，而非DIRECT。两者配合使用时，代理流量使用固定IP，直连流量使用系统DNS解析，实现了精细化的流量管理。与DNS服务器的优先级关系always-ip-address的优先级高于任何DNS服务器配置，包括Shadowrocket中设置的DNS和系统DNS。只要该参数匹配了请求的域名，Shadowrocket直接使用预设IP，完全不发起DNS查询。这意味着即使DNS服务器故障或配置错误，固定IP仍能正常工作，用户可将此作为DNS故障时的备用访问通道。与bypass-system的协同使用bypass-system控制系统服务是否走代理，而always-ip-address仅对通过代理隧道的流量生效。若系统服务直连（bypass-system=true），即使为其域名配置了always-ip-address，该规则也不会生效。用户需理解两者的作用范围差异，避免因误解造成系统服务配置无效。验证与调试方法通过访问日志确认IP固定是否生效开启Shadowrocket的详细日志功能后访问目标域名，在日志中搜索该域名的连接记录。若成功应用了always-ip-address，日志会显示“usingfixedaddress”或类似字样，并附带配置中指定的IP地址。若日志显示“resolvedtoxxx”则说明DNS解析仍在进行，需检查参数是否正确定义并已加载。使用curl或终端工具直接测试在iOS设备上安装iSH或使用其他终端工具，执行curl-v域名查看连接目标IP。若返回的IP与always-ip-address中配置的一致，则说明生效；若为其他IP，则需检查配置加载状态或确认该域名的代理规则是否为PROXY。同时观察连接时间，若省去DNS解析过程，连接建立时间应有明显缩短。多DNS工具交叉验证的正确IP在配置固定IP前，通过多个公共DNS（如1.1.1.1、8.8.8.8和GoogleDNS）分别查询目标域名的解析结果，确认返回的IP是否一致且稳定。若不同DNS返回不同IP，说明该域名使用了智能DNS调度，固定IP可能产生副作用。此时应谨慎使用该功能，或仅固定所有DNS均返回的同一IP。常见问题FAQ

Shadowrocket include配置包含功能怎么用？

使用Shadowrocket的include配置包含功能，核心逻辑是创建独立的子配置文件，再通过主配置文件中的include=文件路径语句将其内容合并加载。用户先使用文本编辑器创建包含规则、策略组或DNS设置的独立.conf文件，保存至Shadowrocket可访问的目录（如iCloudDrive中的Shadowrocket文件夹）。随后在主配置的目标段落（通常是[Rule]或[ProxyGroup]）中插入include语句，指定文件的相对或绝对路径，保存并重新加载主配置即可生效。该功能适合将广告屏蔽规则、策略组定义或分流规则等模块独立维护，实现配置的复用和分治管理，避免单一配置文件的臃肿和重复劳动。需注意文件路径的准确性、引用顺序对优先级的影响，以及避免循环引用导致加载失败。include仅支持本地文件，远程内容请通过订阅功能获取。建议用户从少量文件开始尝试，逐步建立适合自己管理习惯的模块化配置结构，并定期检查被引用文件的内容有效性，确保配置加载始终完整无误。include功能的核心定位与设计初衷模块化配置管理的核心价值include是Shadowrocket配置文件中用于引用外部配置文件内容的参数，它的核心价值是实现配置的模块化管理。用户可将庞大的配置文件拆分成多个逻辑单元——例如将规则列表单独保存、将策略组独立存放、将DNS设置分离出来，再通过include指令在主配置文件中集中引用。这种模块化设计显著提升了配置的可维护性和可读性，尤其适合规则数量庞大的高级用户场景。避免重复劳动与配置复用通过include功能，用户可创建一份通用的规则库文件，然后在多个不同的主配置文件中引用它，实现一次编写、多处复用。例如维护一个包含常见广告屏蔽域名的列表，将其作为独立的include文件后，无论是日常使用的配置文件还是专门用于流媒体的配置文件，均可通过一行include语句共享这份规则，避免了重复复制粘贴带来的维护负担和版本不一致问题。与远程订阅更新的协同工作对于使用订阅链接获取节点的用户，include功能允许在不修改订阅源文件的前提下，在本地添加额外的自定义规则或参数。用户可在本地配置文件中通过include引入订阅内容，再叠加自定义规则，这样当订阅更新时，自定义内容不会被覆盖，两者相互补充而非冲突。这解决了订阅配置与本地需求之间的兼容性痛点。include的基本语法与文件格式配置语句的正确书写方式在Shadowrocket配置文件的[General]段落或[Rule]段落中，使用include=/path/to/file.conf格式引用外部文件。路径支持相对路径和绝对路径：相对路径基于配置文件所在目录，绝对路径则需以/开头指定完整位置。示例写法为include=./custom-rules.conf表示引用同一目录下的custom-rules.conf文件，include=/var/mobile/Configs/adblock.conf则引用指定绝对路径的文件。被引用文件的格式要求与限制被include引用的文件必须遵循与Shadowrocket主配置文件相同的格式规范，即同样采用段落标题（如[Rule]、[Host]）和键值对结构。文件内容可以是完整的配置段落，也可以是仅包含规则列表的片段。需注意被引用文件中不能包含重复的段落标题，否则解析可能出错。最安全的做法是让每个include文件仅包含一个段落的内容。多文件引用的顺序与加载逻辑用户可在同一主配置文件中多次使用include语句，引用多个不同的外部文件。文件内容被插入到include语句所在位置，并按书写顺序依次加载。若不同文件中定义了相同的规则或参数，后者将覆盖前者。理解这一加载顺序有助于合理安排文件引用次序，确保自定义规则能够覆盖订阅或通用规则中的冲突项。include功能的实际应用场景将广告屏蔽规则独立维护创建一个专门的adblock-rules.conf文件，其中包含所有广告域名和IP段的屏蔽规则。在主配置文件的[Rule]段落中使用include=./adblock-rules.conf引用该文件。当需更新广告规则时，仅需修改这一个文件，所有引用了该文件的主配置自动获得最新的规则列表，无需逐份修改。这对于同时维护多份配置文件（如工作场景、家庭场景、移动场景）的用户极为便利。策略组与分流规则的分离管理将策略组定义（[ProxyGroup]）和分流规则（[Rule]）分别存放在不同的include文件中。例如policy-groups.conf专门存放策略组配置，rules-daily.conf存放日常浏览规则，rules-streaming.conf存放流媒体专用规则。用户可通过更换引用的规则文件快速切换使用场景，无需每次重新编写或注释大量规则行，配置切换效率大幅提升。节点订阅与本地自定义内容的整合若用户使用订阅链接获取节点列表，可在主配置中使用[General]段落包含订阅URL，然后在该段落之后通过include引入本地规则文件。这样订阅更新时节点信息自动刷新，而本地规则完全不受影响，持续生效。用户还可通过此方式为订阅节点补充本地策略组配置，实现远程节点与本地策略的混合管理。创建与编辑include文件的操作步骤使用文本编辑器创建独立配置文件在iOS设备上，用户可通过Shadowrocket内置的配置编辑器创建新文件，或使用系统“文件”应用新建文本文件。推荐使用支持语法高亮的文本编辑器（如Textastic或Runestone）编辑.conf后缀的文件，以降低语法错误的概率。创建的文件需保存在Shadowrocket可访问的目录中，通常为iCloudDrive下的Shadowrocket文件夹或设备本地存储中的应用共享目录。在主配置文件中正确引用外部文件打开Shadowrocket的主配置文件，定位至希望插入外部内容的段落位置，输入include=文件路径。确保路径指向之前创建的文件，且路径中的目录层级与实际存放位置一致。保存主配置文件后，Shadowrocket会在加载时自动读取并合并include文件中的内容。若引用多个文件，每个include语句独占一行，按从上到下的顺序依次加载。利用Shadowrocket界面导入外部文件在Shadowrocket的配置管理界面，点击右上角的“+”按钮，选择“从文件导入”或“从URL导入”来添加外部配置文件。导入的文件会自动保存至应用的配置列表，用户可在主配置的编辑界面中通过文件浏览器选择已导入的文件路径。界面操作降低了手动输入路径的风险，尤其适合不熟悉文件系统结构的用户使用。include使用的限制与注意事项文件路径错误的常见表现与处理若include指定的文件路径不存在或Shadowrocket无权限访问，应用在加载配置时会忽略该include语句并继续加载后续内容，同时可能在日志中输出警告信息。用户无法在界面中直接看到错误提示，需通过开启详细日志或观察配置功能是否完整来判断文件是否被正确加载。排查时应先确认文件确实存在于指定路径，且文件名和扩展名完全匹配。循环引用的检测与避免主配置文件中若通过include引用了文件A，而文件A中又通过include引用了主配置文件本身，即形成循环引用。Shadowrocket在加载时会对循环引用进行检测并中断加载，导致配置完全失效。用户应保持引用链的单向性，避免跨文件相互引用。建议设计清晰的引用层级：主配置文件为顶层，include文件为底层，底层文件不再引用其他文件或仅引用更底层的文件。订阅更新与include文件的优先级当使用远程订阅链接时，订阅服务器可能也提供了自己的规则配置。若主配置中通过include引入了本地文件，且本地文件与订阅内容存在冲突（如同名策略组的不同定义），加载顺序决定了最终生效的内容。通常订阅内容先加载，本地include文件后加载，因此本地规则会覆盖订阅中的同名项。用户需根据此优先级设计配置，确保自定义内容能够生效。与其他配置管理方式的对比include与多配置文件切换的差异多配置文件切换需要用户在多个完整配置之间切换，每次切换加载整个配置的全部内容。而include允许用户共享通用模块，主配置仅保存差异化内容，减少了重复数据量。对于仅有少量规则差异的场景（如不同节点集合），使用include共享规则库比维护多个完整配置更加高效，变更通用规则时也只需修改一次。include与分流规则分组的关系Shadowrocket的规则分组（通过策略组实现）是在规则引擎内部对不同类型的流量进行分类，而include是在配置加载阶段对配置文件本身进行模块化组织。两者处于不同层级：include解决的是“如何管理配置文本”的问题，策略组解决的是“如何分流流量”的问题。用户可同时使用两者，通过include组织规则文件，再通过策略组实现规则内部的分组调度。include与URLScheme远程配置的关系URLScheme允许用户通过链接一键切换配置文件或执行特定操作，适用于自动化场景。include则是静态的配置组织方式，在配置加载时完成文件合并。两者可协同工作：用户可使用URLScheme快速切换引用不同include文件的主配置，实现场景化的动态配置管理，满足复杂且多变的网络环境需求。常见问题FAQ

icmp-auto-reply（ping自动回复）要开启吗？

判断icmp-auto-reply是否开启，核心是评估基础网络可达性与安全隐蔽性之间的平衡。对于绝大多数在家庭或办公网络下使用的普通用户，保持默认开启状态是最佳选择，它能确保局域网设备间的基础互联和诊断功能正常，且不会引入实质性的隐私风险。仅当用户身处公共WiFi等不受信任的网络环境、遭遇频繁的恶意扫描探测、或有严格安全合规要求时，才考虑在配置文件中添加icmp-auto-reply=false来关闭ICMP响应。关闭操作需通过手动编辑配置文件或在Shadowrocket界面中寻找对应开关（若新版已集成）完成，保存并重新加载后生效。用户可通过局域网内其他设备ping本机IP来验证配置是否生效，或通过关闭前后网络诊断功能的变化确认影响。该参数对代理节点的连接质量和加密安全无任何影响，用户无需因节点切换而调整此设置。建议用户以默认开启为起点，仅在出现实际网络探测困扰或合规要求时主动关闭，并定期重新评估决策依据以适应网络环境的变化。icmp-auto-reply的功能原理与工作方式自动回复ICMP请求的机制概述icmp-auto-reply是Shadowrocket配置文件中[General]段落的一个参数，它控制客户端是否对收到的ICMPEcho请求（即ping命令）自动做出响应。当该参数设置为true时，即使设备当前的网络状态处于代理隧道模式，系统仍会正常回复外部发来的ping探测请求；设置为false时，设备可能因代理状态或防火墙策略而对ping请求不予响应。这个功能实质上是在代理环境下维持设备网络可达性的基础ICMP响应行为。与节点延迟测试功能的关联性Shadowrocket内置的节点延迟测试（即Ping功能）利用的是ICMP协议向节点服务器发送探测包。icmp-auto-reply与节点延迟测试无直接关系，前者控制设备回复外部ping请求的能力，后者则是设备主动发起ping测试。两者独立运作，互不影响。用户可能将两者混淆，需明确区分：延迟测试是主动探测节点，自动回复是被动响应针对本机的ping。参数生效的网络层次与范围该参数作用于设备的网络协议栈层面，当外部主机向设备发起ICMPEcho请求时，Shadowrocket会干预系统对该请求的响应行为。开启时，设备正常回复ping，显示为网络可达；关闭时，设备可能忽略这些ping包，外部探测显示超时或目标不可达。该参数仅影响ICMP协议，不影响TCP或UDP等其他协议的通信行为，作用范围局限于网络层的基础可达性测试。开启icmp-auto-reply的潜在优势维持网络可达性的基础功能在代理环境下，有时系统因VPN隧道占用虚拟网卡而调整路由表，可能导致设备对ICMP请求的响应出现异常。开启icmp-auto-reply能确保设备在任何网络状态下都正常回应ping，维持基础网络可达性。这对于网络管理员使用ping工具监控设备在线状态、或运行网络诊断脚本时，确保设备仍能被正常探测到至关重要。防止NAT会话超时与代理保活在某些网络环境中，定期接收ICMP请求并自动回复可作为一种被动保活机制。外部监控系统定时ping设备，设备的回复行为维持了NAT会话的活跃状态，减少了因长时间无数据交换而被运营商回收会话的概率。虽然主动的心跳包保活更直接有效，但自动回复ping作为被动保活方式，在特定场景下能辅助延长隧道存活时间。局域网内设备发现的兼容性支持家庭网络中，部分设备发现协议（如网络邻居、Bonjour服务）会依赖ICMP响应来判断设备是否在线。开启自动回复后，其他设备能通过ping确认本设备可达，避免因代理路由调整导致的局域网内“设备掉线”误判。对于需要在局域网中共享文件、AirPlay投屏或远程控制的用户，保持ICMP响应能力能提升设备间互联的兼容性和可靠性。关闭icmp-auto-reply的潜在优势减少网络探测与攻击面暴露关闭ICMP自动回复后，设备对外部ping请求不做出响应，这在一定程度上减少了网络探测的可发现性。虽然这种做法不能真正防御针对性的攻击，但可以避免自动化扫描工具轻易发现设备IP在线，降低被恶意探测和后续攻击的风险。对于注重隐私和安全的用户，减少不必要的响应是一种基础的安全加固措施。降低无谓流量消耗与日志噪音在存在网络监控或持续ping检测的环境中，若设备频繁收到ICMP请求并自动回复，每次回复都消耗极小的网络带宽和系统资源。虽然单个ping消耗微乎其微，但在高频率探测下，积累的回复数据包和系统处理开销可能影响设备功耗。关闭自动回复可完全消除这部分流量和日志记录，尤其适合对节能敏感或运行在移动数据网络下的设备。避免潜在的路由混乱与配置冲突当设备同时连接多个网络接口（如WiFi与蜂窝网络）且代理隧道启用时，ICMP响应可能因路由表复杂而出现异常。关闭自动回复可避免因路由混乱导致的ping响应延迟或错误，防止外部探测者因响应不稳定而误判网络质量。某些防火墙策略或网络合规要求也明确规定不应响应外部ICMP请求，关闭回复有助于符合这类规范。默认配置与使用场景分析新配置文件中该参数的默认状态在Shadowrocket新生成的配置文件中，icmp-auto-reply通常默认不显式写入，系统采用默认行为——即开启回复功能。这意味着大多数用户在未特别配置的情况下，设备会正常响应ping请求。若用户希望关闭该功能，需手动在配置文件中添加icmp-auto-reply=false。了解默认状态有助于判断是否需要主动干预。普通用户日常使用的推荐设置对于绝大多数普通用户，保持默认开启状态无需任何调整。日常使用中，设备响应ping是正常网络行为，不会对代理功能和隐私造成实质影响。仅在特定安全敏感场景或遭遇网络探测困扰时，才需考虑关闭。用户无需过度关注该参数，将精力集中于分流规则和节点选择等核心配置上更为合理。企业网络与合规环境的特殊考量在企业网络或具有严格安全合规要求的场景中，IT策略可能明确要求内部设备不响应外部ICMP请求，以减少攻击面。用户若在办公环境中使用Shadowrocket，建议查阅公司安全政策，必要时在配置中添加icmp-auto-reply=false以符合内部规范。但需注意，此操作可能影响IT部门对设备在线状态的监控，需权衡合规与运维需求。与其他安全隐私功能的协同效应与stun-response-ip的结合效果icmp-auto-reply与stun-response-ip分别作用于ICMP协议和STUN协议，两者互不干扰但共同构建隐私保护层。开启stun-response-ip可防止WebRTC泄露真实IP，而关闭icmp-auto-reply则避免ping探测暴露设备在线。两者结合能在不同协议层面减少网络足迹，适合高度注重隐匿性的用户同时配置。与防火墙规则及端口隐藏的联动在Shadowrocket中若已配置防火墙规则屏蔽外部扫描，关闭icmp-auto-reply可进一步消除ICMP层面的响应痕迹。但需注意，设备关闭ping回复并不影响其他端口的可达性，端口扫描工具仍可通过TCPSYN探测发现开放端口。全面的安全防护需结合端口策略和防火墙配置，单一参数的调整作用有限。代理隧道加密与基础网络可达性的权衡代理隧道的加密机制保护了上层通信内容，而icmp-auto-reply控制的是最基础的网络层可达性。开启回复不会泄露任何用户身份或访问内容，仅确认设备IP在线。因此，用户无需担心开启该参数会削弱代理的隐私保护效果。若担心ICMP响应暴露设备在线状态，可关闭该功能，但这与代理加密的安全性无关。判断是否开启的决策框架基于网络环境的实际需求评估若用户处于信任的家庭或办公网络，开启自动回复有助于局域网设备互联和网络诊断，建议保持开启。若用户经常使用公共WiFi或对网络探测敏感，关闭回复可减少设备被自动化扫描发现的概率，降低潜在的安全风险。根据当前连接网络的信任级别动态决策，是合理且务实的方法。基于设备功能需求的优先排序若用户依赖局域网文件共享、AirPlay、远程桌面等功能，这些服务依赖于ICMP响应来判断设备在线，开启回复能确保功能正常。若用户使用设备仅用于个人上网，无局域网互联需求，关闭回复不会造成实质影响。以功能需求为导向，在便利性和安全性之间做出符合使用习惯的选择。长期监控与定期重新评估用户设备的网络环境和安全威胁态势会随时间变化，建议每半年重新评估一次该参数的配置状态。若发现频繁收到可疑IP的ping探测，可考虑临时关闭回复以降低暴露。若未遇到任何异常，保持默认开启即可。定期审视配置能确保设置始终适应当前的实际需求和风险水平。常见问题FAQ

skip-proxy是干什么用的？默认配置了什么IP段？

skip-proxy是Shadowrocket中用于指定特定IP段和域名流量完全直连不经过代理的全局排除列表。其默认配置包含三大私有地址段（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）、链路本地地址（169.254.0.0/16）、回环地址（127.0.0.0/8）、多播和广播地址段（224.0.0.0/4、255.255.255.255/32），以及IPv6链路本地地址（fe80::/10）和IPv6回环地址（::1/128）。这些默认配置确保了用户访问路由器管理界面、NAS设备、网络打印机等局域网基础设施时不受代理干扰，同时保障了DHCP、ARP、mDNS等网络基础协议的正常运行，并降低了代理隧道的不必要负载。用户可根据实际需求在默认列表基础上添加公司内网IP段、游戏服务器IP段或Docker虚拟网卡段等自定义内容，但需注意编辑时的语法格式和验证配置是否生效。该参数拥有最高优先级，匹配的流量完全绕过分流规则，修改前需充分评估对隐私和网络行为的影响。建议保留所有默认IP段不作删除，仅在末端追加自定义条目，并通过日志功能验证新添加内容是否按预期生效。与bypass-system和bypass-tun的参数协同构成了从应用层到网络层的完整流量控制体系，用户应理解各参数的差异化作用以避免配置冲突。skip-proxy参数的功能定位与作用机制代理排除列表的核心用途skip-proxy是Shadowrocket配置文件中用于指定不经过代理的目标地址列表，它的作用是让特定IP段或域名的流量完全绕过代理隧道，直接通过本地网络发出。这个参数优先级高于所有分流规则，属于预过滤机制——匹配该列表的流量连规则引擎都不会进入，直接被标记为直连。用户可以将其理解为全局性的“白名单直连”配置。与分流规则中DIRECT策略的区别分流规则中的DIRECT策略在规则引擎内部按顺序匹配，而skip-proxy在规则处理之前生效。这意味着即使规则列表中将某域名设置为PROXY，若该域名的IP地址落在了skip-proxy指定的IP段内，它仍会被强制直连。这确保了局域网和链路本地通信绝对不走代理，不受用户自定义规则的干扰，保障了基础网络服务的可用性。参数在配置文件中的书写格式skip-proxy位于配置文件的[General]段落，支持以逗号分隔的多个IP段或域名。典型写法为skip-proxy=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,localhost,*.local。用户可在此列表中添加或删除条目，修改后需保存并重新加载配置使变更生效。该列表是全局性的，对所有节点和场景统一适用，无法针对单个节点单独设置。默认配置的IP段详细解析局域网私有地址段（RFC1918）默认配置中包含了三大私有IP地址段：10.0.0.0/8（A类）、172.16.0.0/12（B类）、192.168.0.0/16（C类）。这些地址段被IANA预留用于局域网内部通信，不经过公网路由。将它们加入skip-proxy确保了用户在访问路由器管理界面（如192.168.1.1）、局域网内NAS设备或网络打印机时，流量不会误入代理隧道，避免了因代理导致的内网访问失败或延迟增加。链路本地地址与回环地址默认配置还包含169.254.0.0/16（链路本地地址）和127.0.0.0/8（回环地址）。链路本地地址用于设备在没有DHCP服务时自动配置IP，常见于临时网络连接场景。回环地址指向设备自身，用于本地进程间通信。这两类地址不走代理是确保设备基础网络功能正常运行的前提，任何试图代理这些地址的流量都会造成网络栈的混乱和故障。多播与广播地址段的处理224.0.0.0/4（多播地址）和255.255.255.255/32（受限广播）同样默认被skip-proxy包含。多播用于设备发现和服务公告等局域网功能，广播地址则用于ARP请求和DHCP发现等基础协议。将这些地址排除在代理之外是保证局域网内设备能够相互发现和通信的必要措施，否则代理的干扰可能导致网络邻居和AirDrop等功能失效。IPv6链路本地地址的默认配置在支持IPv6的配置中，fe80::/10（IPv6链路本地地址）也被默认加入skip-proxy列表。该地址段与IPv4的169.254.0.0/16功能类似，用于同一链路上设备间的自动地址配置和通信。包含此段确保了IPv6环境下局域网功能同样不受代理干扰，保障了基于IPv6的本地服务发现和邻居发现协议的正常运作。默认配置的设计初衷与必要性避免代理干扰本地网络基础设施路由器管理界面、NAS设备、网络打印机等处于局域网内的基础设施，其IP地址属于私有地址段。若不将这些地址排除在代理之外，当用户尝试访问路由器后台或向打印机发送任务时，请求会被错误地导向代理服务器，而代理服务器无法路由到内网地址，导致访问失败。skip-proxy的默认配置从根本上杜绝了这类问题，保障了内网管理的可用性。防止DNS与DHCP等基础协议中断DHCP、ARP、mDNS等网络基础协议依赖于多播和广播通信，这类流量设计上就不应经过任何路由转发，更不可能通过代理隧道传输。若广播请求被送入代理隧道，代理服务器无法解析这些二层协议数据，将直接丢弃或返回错误，导致设备无法获取IP地址或发现局域网内的服务。默认包含多播和广播地址是维持网络栈完整性的底线要求。降低代理隧道的不必要负载局域网内大量设备频繁发送ARP请求和NetBIOS广播包，这些数据包数量大但信息价值低。若未将其排除在代理之外，代理隧道将被这些毫无意义的局域网广播流量淹没，消耗宝贵带宽和节点连接资源。skip-proxy默认排除这些流量，实质上是为代理隧道减负，让节点资源专注于处理有实际价值的公网请求，提升整体效率和响应速度。用户自定义skip-proxy的实用场景添加公司内网或VPN专用IP段在办公环境中，公司内网IP段（如172.18.0.0/16）和远程办公VPN分配的虚拟IP段（如10.10.0.0/16）需要直连才能访问内部资源。用户应在skip-proxy中添加这些自定义IP段，确保访问企业内部系统、GitLab、知识库等站点时不被代理干扰。添加后需测试内网资源访问是否恢复正常，并确认分流规则不受影响。排除特定游戏服务器或流媒体CDN部分游戏服务器和流媒体CDN节点位于特定IP段，代理访问可能触发风控或被限速。用户可将这些IP段加入skip-proxy，让游戏或视频流量直接走本地网络，降低延迟和丢包率。但需注意，此操作会使这些流量的真实IP暴露，仅适用于不涉及隐私敏感且本地网络质量优于代理的场景。Docker与虚拟化环境的特殊IP段处理使用DockerforMac或Parallels等虚拟化工具时，虚拟网卡分配的IP段（通常为192.168.64.0/24或192.168.65.0/24）也需要加入skip-proxy。否则容器或虚拟机中的网络请求可能被Shadowrocket拦截，导致容器内应用无法正常通信。用户可通过ifconfig命令查看虚拟网卡IP范围，精准添加到列表中。修改skip-proxy的注意事项与验证编辑配置文件时的语法严谨性修改skip-proxy时，多个IP段和域名之间必须以英文逗号加空格分隔（如192.168.0.0/16,10.0.0.0/8）。语法错误（如遗漏逗号、多余空格或中文字符）会导致整行配置失效，所有流量可能全部走代理或全部直连。保存修改后务必在Shadowrocket的配置编辑器中检查语法高亮是否正常，确保修改正确无误。添加后验证流量是否按预期直连修改skip-proxy后，用户可通过访问目标IP的网页或ping命令测试流量走向，同时结合Shadowrocket的日志功能查看该请求的处理决策。日志中若显示“direct”或“skip-proxymatched”则说明配置生效，流量已直连；若显示“proxy”或“relay”则说明匹配失败，需检查IP段格式是否正确。验证是避免误配置导致意外行为的关键步骤。与订阅更新的冲突处理策略若用户使用的是远程订阅配置文件，skip-proxy的自定义修改可能在订阅更新时被覆盖。用户需在Shadowrocket中创建本地覆盖规则，或将自定义IP段添加到独立的配置文件中并设置为高优先级加载。最稳妥的方式是导出订阅配置为本地文件后修改，再切换至该本地配置，使自定义内容不受远程更新影响。与相关参数的区分与协同skip-proxy与bypass-system的区别skip-proxy针对目标IP段/域名进行排除，控制的是“发往哪些地址的流量直连”；bypass-system则控制“系统服务是否走代理”，面向的是流量发起方（系统进程vs用户应用）。两者作用维度不同，相互独立可同时生效。例如，即使bypass-system=true让系统服务直连，若系统服务访问的地址不在skip-proxy列表中，该请求仍可能通过其他规则进入代理。skip-proxy与bypass-tun的关系bypass-tun是控制VPN虚拟网卡的路由策略，决定哪些流量被送入TUN接口。skip-proxy作用于更高的应用层，在流量进入TUN之前就已进行排除。两者配合使用可实现从网络层到应用层的双层过滤，bypass-tun排除IP段（如避免路由冲突），skip-proxy排除特定目标地址（如确保内网访问不走代理），共同构建精细化的流量控制体系。参数优先级顺序的实际影响流量处理的优先级从高到低依次为：skip-proxy→bypass-tun→分流规则→全局路由模式。这意味着skip-proxy拥有最高优先级，匹配的流量完全绕过后续所有处理环节。用户修改skip-proxy时需意识到它的“最高级”身份，避免将本应代理的地址误加入列表而导致隐私泄露，或因优先级过高覆盖了预期的代理策略。常见问题FAQ

Shadowrocket bypass-system = true是什么意思？要不要关？

决定bypass-system的开关状态，核心是权衡系统服务稳定性与全局IP一致性之间的优先级。对于绝大多数用户，保持bypass-system=true是最稳妥的选择，它能确保系统时间同步、推送通知和AppStore更新等基础服务的独立稳定运行，不受代理节点状态波动的干扰，同时减轻代理隧道的不必要负载。只有特定解锁需求（如访问区域限制的AppStore内容）或极致的隐私匿名场景下，才考虑切换至false模式。建议用户创建两份配置文件分别对应两种设置，根据不同使用场景一键切换，或在快捷指令中建立基于WiFi名称的自动化规则。切换后通过检查系统时间同步是否准确、推送通知是否及时以及AppStore更新速度的变化来评估实际影响，据此微调最终选择。长期保持true模式并定期评估是否需要临时切换，是兼顾稳定与灵活的最佳实践。参数在配置文件中的定位与作用域bypass-system在General段落中的角色bypass-system=true是Shadowrocket配置文件[General]段落中的一个全局参数，它控制着代理是否接管系统级别的网络流量。当设置为true时，系统自身的网络服务（如时间同步、推送通知、软件更新等）会绕过代理直连；当设置为false时，所有系统服务流量也会被强制送入代理隧道。这个参数的定位是区分用户主动发起的应用流量与系统后台服务的底层网络行为。该参数与分流规则的层级关系bypass-system的优先级高于常规的分流规则。无论规则列表中如何配置，只要该参数生效，系统级流量就会按照其设定执行直连或代理。这意味它是在规则引擎之前的一道预过滤闸门，专门针对操作系统自身的网络活动进行干预。用户需理解它并非取代规则，而是在规则处理前预先划分出系统流量的特殊处理通道。参数生效的网络层次范围该参数仅影响系统核心服务和后台进程的网络请求，包括网络时间协议（NTP）、推送通知服务（APNs）、iCloud同步、系统更新检查等。它不涉及用户手动打开的浏览器或第三方应用的流量，这些仍由常规的分流规则控制。理解这一作用范围有助于判断该参数是否真正影响用户关心的网络行为，避免过度干预与误解。bypass-system=true的具体行为分析系统服务直连带来的网络行为当设置为true时，iOS系统的各项后台服务将完全绕过Shadowrocket的代理隧道，直接通过当前物理网络接口发起请求。这意味着系统时间同步会直接访问Apple的NTP服务器，推送通知通过直连维持与APNs的长连接，iCloud照片流同步也走本地网络通道。这些流量不受代理规则约束，即使代理节点出现故障，系统服务仍保持独立的网络活动。代理隧道负载的减轻与专注度提升将系统服务排除在代理之外显著减少了代理隧道需要处理的无关流量，使Shadowrocket能将带宽和CPU资源集中用于处理用户的应用请求。系统服务通常频繁但数据量小，但这些小数据包的心跳保活可能占用连接资源。直连它们能降低代理连接的维护成本，减少因系统服务心跳干扰导致的节点超时误判，使隧道状态更清晰。连接失败时系统服务的独立存活能力当代理节点出现故障或网络切换时，若bypass-system=true，系统服务仍能通过直连通道维持基本功能。用户可能会发现代理断了但推送通知照常接收、时间仍然同步正确，这对于设备的基础可用性至关重要。反之若设置为false，节点故障会导致系统服务一同失效，可能造成通知延迟、时间错乱等问题，放大单点故障的影响范围。bypass-system=false的具体行为分析系统服务完全走代理的强制隧道模式当设置为false时，所有系统级的网络请求都被强制送入Shadowrocket的代理隧道，没有任何例外。系统时间同步、推送通知、iCloud备份、AppStore更新检查等全部经过节点转发。这种模式下，设备对外呈现的IP地址统一为代理节点的出口IP，系统服务的地理位置信息与代理节点所在地一致，在某些场景下可用于解锁地理限制的系统服务。全局IP一致性与隐私保护的提升通过强制系统服务走代理，设备的所有网络活动（包括底层后台请求）都使用相同的出口IP，消除了因系统服务直连而暴露真实网络位置的风险。对于注重匿名性的用户，这种全局统一的IP策略增强了隐私保护，避免了因系统服务直连导致的IP片段泄露。地理位置追踪者无法通过分析系统服务的连接模式来推断用户的真实位置。节点故障导致系统功能全面瘫痪的风险false设置的最大代价是节点可用性直接影响系统基础功能。一旦代理节点掉线、超时或带宽耗尽，不仅是用户应用无法访问，设备的时间同步、推送接收、云备份等底层服务也会停止工作。用户可能遭遇“明明WiFi正常但收不到推送”或“系统时间无故错乱”等难以直观联想到代理问题的故障，增加了故障排查的复杂性。启用与关闭的适用场景对比家庭网络与移动网络下的差异化策略在稳定的家庭WiFi环境中，直连的系统服务能获得低延迟响应，因此bypass-system=true是合理选择。而在公共WiFi或不受信任的移动网络中，为防止本地网络监控系统服务的明文流量，可考虑设置为false，让代理隧道加密所有网络活动。用户应根据当前网络环境的安全级别动态调整该参数，而非固定使用单一配置。解锁区域限制系统服务的需求判断若用户需要访问特定地区的AppStore内容（如日区或美区商店），且该服务会根据IP地理位置限制访问，则需将bypass-system设为false，使AppStore的流量也经过代理。同理，iCloud照片流若受地区版权限制，也需代理其流量。这类解锁需求是决定是否关闭该参数的关键因素，无此类需求的用户则保持开启即可。节点性能与系统服务质量之间的权衡当节点性能有限（带宽小、延迟高）时，强制系统服务走代理会挤占有限资源，降低用户实际浏览体验。此时开启true直连系统服务更为合理。若节点性能充裕且稳定性高，则false带来的全局IP一致性和隐私收益超过性能成本。用户需评估节点规格与自身带宽需求，做出符合实际资源状况的选择。对日常使用体验的具体影响推送通知的及时性与代理状态的关联bypass-system=true时，推送通知通过直连的APNs通道接收，不受代理状态影响，通知到达及时且稳定。若设为false，推送流量经过代理后可能因节点延迟而稍有滞后，且在节点切换时可能造成短暂的通知丢失。对于依赖即时通知的用户，true能保障最可靠的通知体验。AppStore更新与下载的代理行为AppStore的更新检查和下载流量在bypass-system=true时完全直连，下载速度取决于本地网络质量。设为false时，更新流量经过代理，若节点位于海外，下载速度可能受国际带宽限制而显著降低。用户若经常遇到AppStore更新缓慢，可尝试开启true以获取本地直连的下载速度提升。设备时间同步与证书验证的稳定性系统时间同步（NTP）在true模式下直连，能快速校准时间，确保证书验证基于准确时间。false模式时，NTP请求经过代理可能因节点延迟导致同步偏差，而证书验证对时间敏感，微小偏差可能引发证书有效性判断错误。保持true能从根本上避免此类关联问题。如何根据自身需求决定开关状态普通用户的最佳默认选择对于绝大多数没有特殊解锁需求的普通用户，强烈建议保持bypass-system=true为开启状态。该设置能确保系统基础服务的稳定性和响应速度，避免因节点问题导致的推送延迟、时间错误等故障。同时它减少了代理隧道的无关流量，提升了节点资源的利用率。这是经过广泛实践验证的最稳妥默认配置。注重匿名性与全局IP统一的配置思路对于将隐私保护置于首位、需要完全隐藏真实网络足迹的用户，可考虑将该参数设为false，使包括系统服务在内的所有流量均通过代理，实现IP出口的统一。但需配套使用稳定性极高的节点，并接受系统服务响应可能略有延迟的代价。建议在使用公共或不受信任网络时临时切换至false，家庭信任网络中仍保持true。动态切换与配置文件的多版本管理用户无需纠结于单一设置，可创建两份配置文件——一份true用于日常，另一份false用于特定场景，通过切换配置快速适应不同需求。或在快捷指令中设置自动化，当连接特定WiFi时自动调整该参数。这种灵活性允许用户在稳定与隐私之间按需切换，避免了非此即彼的固定选择。常见问题FAQ

Shadowrocket安装CA证书后有什么安全风险吗？

安装Shadowrocket的CA证书并开启信任，本质上是在设备系统中引入了一个新的信任锚点，授予了该应用对HTTPS流量进行解密和重新加密的技术能力，客观上扩大了攻击面。最大风险在于代理服务商可能读取用户访问的所有HTTPS内容，这要求用户对服务商的隐私政策和运维安全保持高度信任。为降低风险，用户应仅在确有调试需求时开启HTTPS解密功能，日常保持关闭状态，并通过维护排除列表将银行、支付等敏感域名的流量排除在解密范围之外。定期审计系统证书信任列表，及时移除不再使用的根证书，避免信任残留。理解大多数主流支付和金融应用通过证书固定机制天然免疫于CA证书的解密干预，用户的核心敏感数据仍受到应用层保护。若对任何环节的安全性存疑，最安全的做法是完全不安装CA证书，这样Shadowrocket仍能正常工作且不引入任何额外的HTTPS中间人风险，代理隧道的加密和隐私保护功能完全不受影响。最终的决策应基于用户对信任链各环节的评估，在便利性与安全性之间做出符合自身风险承受能力的选择。CA证书授予的权限与信任模型改变根证书在TLS体系中的核心地位CA证书（根证书）是TLS信任链的起点，设备信任该证书意味着认可由它签发的所有子证书。当用户在Shadowrocket中安装其生成的CA证书并开启信任后，设备将Shadowrocket视为合法的证书颁发机构。这一操作相当于在系统的信任库中引入了新的信任锚点，从此所有使用该根证书签发的证书都会被设备无条件接受，而不再经过正规CA机构的验证流程。中间人攻击能力的本质赋予安装并信任Shadowrocket的CA证书后，应用获得了对设备HTTPS流量进行解密和重新加密的技术能力。从技术层面看，这等同于赋予了Shadowrocket实施中间人攻击的权限——它能够在用户与目标网站之间拦截TLS握手，用自己的证书替换原始证书，从而读取所有加密流量内容。这一能力本身是HTTPS解密功能的工作基础，但同时也意味着权力集中于单一应用。信任范围从应用扩展至系统全局CA证书的信任是系统级别的，而非仅限于Shadowrocket应用内部。一旦在系统证书信任设置中开启该证书的信任开关，设备上所有应用和浏览器都将无差别地接受由该证书签发的任何证书。即使未来卸载Shadowrocket，若未手动删除该证书，系统仍会信任该证书颁发机构签发的所有证书，形成持久的信任遗留风险。代理服务商层面的数据可见性风险服务商对HTTPS内容的潜在访问能力当HTTPS解密功能开启且CA证书已信任时，Shadowrocket能够解密用户访问的所有HTTPS流量，包括登录凭证、支付信息、私人消息等敏感内容。这意味着代理服务商在技术上有能力获取这些数据，因为流量在代理服务器上被解密后，服务器运维人员可通过日志或内存抓取手段读取明文内容。用户必须完全信任服务商的道德操守和技术防护措施。零日志政策真实性的依赖风险多数代理服务商宣称实施零日志政策，承诺不记录用户活动。但该承诺完全依赖于服务商的自律和内部审计，缺乏外部第三方独立验证。若服务商内部存在恶意人员或遭受法律强制要求提供数据，安装CA证书并开启HTTPS解密后，用户的完整网络活动记录都可能被调取。选择经过公开审计或开源透明实现的服务商能降低此风险。服务商服务器被入侵的连带影响代理服务商的服务器若遭受黑客攻击，攻击者可能获取服务器上的解密密钥或实时流量数据，进而窃取用户的HTTPS通信内容。相比仅使用代理加密而不开启HTTPS解密，安装CA证书并解密流量显著放大了数据泄露的潜在损失。用户应评估服务商的安全运维能力，了解其是否采用了硬件安全模块等措施保护密钥。设备本地安全风险的放大效应恶意应用利用CA证书实施本地攻击设备上安装的其他恶意应用若能获取Shadowrocket的CA证书私钥，或利用该证书签发伪造证书，便可在本地实施针对其他应用的中间人攻击。虽然iOS系统的沙盒机制限制了应用间互访，但越狱设备或系统漏洞可能打破这一隔离。用户应保持设备未越狱状态，并定期更新系统安全补丁，减少因CA证书引入的本地攻击面扩展。证书被导出后用于外部攻击的可能性若Shadowrocket的CA证书及其对应私钥被导出并落入攻击者手中，攻击者可在任意设备上使用该证书签发伪造证书，对用户的网络活动实施持续的中间人监控。用户应确保私钥仅保存在设备本地，避免通过备份或共享方式泄露。选择使用独立于系统CA存储的应用级证书管理方案，能降低私钥被操作系统或iCloud备份同步的风险。证书有效期与更新机制的潜在漏洞CA证书到期后若未及时更新，Shadowrocket可能无法正常解密HTTPS流量，导致访问中断或证书错误。但更危险的是，用户可能因疏忽而长期保留已到期但尚未被系统清理的旧证书，这些证书若私钥已被泄露，仍可被攻击者利用。用户应建立定期检查和更新证书的管理习惯，及时删除不再使用的旧版本根证书。证书固定应用的防护限制与例外证书固定机制对CA证书的免疫性安装CA证书并开启HTTPS解密后，普通网站的证书验证会被顺利通过。但采用证书固定技术的应用（如银行App、部分支付软件）内置了特定的证书公钥或指纹白名单，仅接受与其预置信息匹配的证书。Shadowrocket的CA证书不在这些应用的白名单内，因此即使系统信任该CA，应用仍会拒绝连接并报错。这限制了CA证书对敏感应用的监控范围，反而保护了用户最核心的金融和隐私数据。主流应用对证书固定的采用情况金融类应用（如银行客户端、支付宝、微信支付）普遍部署了证书固定机制，以防范中间人攻击。Google系应用（Chrome、Gmail）和Apple系统服务也内置了严格的证书校验逻辑。这意味着即使安装了Shadowrocket的CA证书，这些应用的敏感通信仍保持端到端加密，不受代理解密影响。用户可查阅各应用的安全白皮书，了解其证书固定实施情况。固定例外带来的安全层次分化证书固定机制的存在导致安全防护出现分层：未固定的网站和服务完全暴露在CA证书的监控范围内，而固定应用则保持原有安全水平。这种分化可能让用户产生虚假的安全感，误以为所有流量都受保护。实际上，日常网页浏览和普通应用（如社交媒体、新闻客户端）的流量在解密后是完全可见的，用户需对此保持清醒认识，区分不同场景下的风险等级。降低CA证书风险的实践建议按需开启HTTPS解密而非永久启用仅在确实需要调试网络请求或分析特定应用流量时短暂开启HTTPS解密功能，日常使用中保持该功能关闭。这样既保留了安装CA证书以备不时之需的灵活性，又最大限度地减少了敏感数据暴露的时间窗口。用户可创建快捷指令快速切换解密开关，降低频繁操作的成本，使按需开启具备实际可行性。利用排除列表限制解密范围在Shadowrocket的HTTPS解密设置中维护一个排除列表，将银行、支付、医疗等高度敏感网站的域名添加至其中，确保这些域名永远不被解密。即使解密功能全局开启，排除列表中的域名流量仍保持端到端加密，代理仅负责转发TLS密文。这是平衡功能需求和隐私保护的有效折中方案，能在不影响关键服务的前提下尽量缩小风险面。定期审计与撤销不必要的证书信任用户应定期（如每季度）进入系统证书信任设置，审视已安装的根证书列表，确认Shadowrocket的证书是否仍在需要时保持信任状态。若长期不使用HTTPS解密功能，可暂时关闭证书信任，待需要时重新启用。系统更新或应用卸载后，主动检查并删除冗余的CA证书，避免信任残留。维持证书清单的简洁性是最基本的防御姿态。整体风险评估与使用决策框架信任链的最终锚点评估评估安装CA证书的风险本质上是评估用户对Shadowrocket开发者、代理服务商以及自身设备安全状态的综合信任程度。若三者均值得信赖，风险在可接受范围；若任一环节存在不确定性，则需采取更保守的配置策略。用户应优先选择开源且在安全社区经过独立审计的代理工具，其代码透明度能有效降低开发者层面的不可信风险。使用场景与风险等级的匹配原则普通网页浏览、视频观看等低敏感活动场景中，安装CA证书带来的风险相对可接受；而处理财务信息、登录企业管理后台或传输商业机密时，应避免任何HTTPS解密干预。用户应根据当前操作内容动态调整安全策略，高危操作时暂时关闭解密功能或切换至不启用解密的备用配置，实现场景化的风险管理。替代方案与无解密代理的可用性关闭HTTPS解密且不安装CA证书不影响Shadowrocket的代理隧道加密和IP隐藏功能，绝大多数用户的日常使用场景完全无需开启解密功能。了解这一事实后，许多用户会选择根本不安装CA证书，从根本上消除该安全隐患。仅当用户有明确的流量分析或调试需求时，才考虑有节制地使用CA证书和解密功能。常见问题FAQ

Shadowrocket开启代理后访问网站提示证书错误怎么办？

处理Shadowrocket代理后的证书错误，核心排查路径是先确认HTTPS解密功能的开关状态及根证书的安装信任情况。进入系统设置，在“通用-关于本机-证书信任设置”中确保Shadowrocket根证书的信任开关已开启，这是解决大部分证书错误的最基础操作。若错误仅针对特定网站，将该域名加入HTTPS解密的排除列表或分流直连规则，避免证书固定机制与代理中间人行为冲突。若所有网站均报错，则关闭HTTPS解密功能，让代理仅转发加密流量而不进行证书替换，同时检查节点服务端的TLS配置是否完整且支持现代协议版本。更新应用或系统后需重新安装证书，并定期检查证书有效期，确保设备时间同步准确。对于无法通过配置解决的应用证书错误，将其流量设为直连是维持功能可用的最终手段，但需注意隐私暴露风险，仅在必要时采用。经过上述逐层排查，绝大多数证书错误问题都能找到对应的解决方案并恢复正常访问。证书错误提示的常见类型与含义区分不同浏览器和应用的报错信息当Shadowrocket代理开启后访问网站提示证书错误时，浏览器通常显示“您的连接不是私密连接”或“NET::ERR_CERT_AUTHORITY_INVALID”等警告。不同应用的表现略有差异：Chrome会明确提示证书无效，Safari则显示“无法验证服务器身份”，而iOS系统应用可能直接弹出“证书不受信任”的对话框。理解报错类型有助于快速定位问题根源，是证书链缺失、过期还是域名不匹配，每种错误对应的处理方式各不相同。证书错误与代理协议加密混淆的区别部分用户将证书错误与代理协议握手失败混淆，但两者本质不同。证书错误发生在TLS握手阶段，浏览器验证目标网站证书时发现异常；而代理协议问题则出现在客户端与节点建立连接的过程中。若错误提示中明确指向“证书”或“安全连接”，则属于前者。用户可通过临时关闭代理直接访问同一网站，若正常打开则确认问题与代理环境相关，而非网站本身证书失效。错误发生时机与代理启用状态的关联证书错误通常在启用代理后立即出现，而关闭代理后消失，这种规律性提示问题出在Shadowrocket对HTTPS流量的处理环节。若错误仅在访问特定网站时出现，可能涉及该网站的证书固定机制；若所有HTTPS网站均报错，则大概率是系统根证书未正确安装或信任。观察错误发生的范围和时机能为后续排查提供关键线索，避免盲目调整无关配置。代理隧道与HTTPS拦截的冲突根源HTTPS解密功能对证书链的干预机制Shadowrocket的HTTPS解密功能会在设备与目标网站之间充当中间人角色，将原始TLS连接拦截并替换为自己的证书重新签发。若该功能开启但系统未信任Shadowrocket生成的根证书，浏览器便会因证书链不完整而报错。这一机制与公司网络中的SSL拦截原理一致，目的是让代理工具能分析HTTPS流量内容，但同时也要求用户主动安装并信任其根证书，否则所有HTTPS请求都将被浏览器拒绝。证书固定对代理中间人的抵抗部分银行、支付和社交应用内置了证书固定机制，将特定网站的公钥或证书指纹硬编码在应用内。当检测到代理工具替换证书后，应用会因证书指纹不匹配而主动断开连接并报错。此类错误无法通过安装根证书解决，因为应用不信任任何非预置的证书颁发机构。这种情况下只能将相关域名设置为直连，让流量绕过代理的HTTPS解密通道，或彻底关闭解密功能。代理协议与TLS双重加密的叠加影响当Shadowrocket同时使用代理协议加密和HTTPS解密时，数据包经历了多层封装与解封。若代理节点的TLS配置与客户端解密设置产生参数冲突（如加密套件不匹配或协议版本不一致），浏览器在验证证书时可能收到格式异常的证书链，进而触发错误。排查时可尝试关闭HTTPS解密功能，观察错误是否消失，若消失则确认是解密功能与节点参数不兼容所致。检查Shadowrocket的HTTPS解密设置确认解密开关状态与证书安装情况进入Shadowrocket的设置页面，找到“HTTPS解密”选项，首先确认其开关是否处于开启状态。若该功能并未启用但出现证书错误，则问题另有原因；若确实开启，则需检查系统证书是否已正确安装。在iOS系统中，证书安装后还需在“设置-通用-关于本机-证书信任设置”中手动开启信任开关，否则即使证书已安装，浏览器仍会因未信任而报错。重新生成并安装根证书的操作步骤若现有证书已过期或安装不完整，用户应返回Shadowrocket的HTTPS解密设置，点击“生成并安装证书”按钮，系统会提示下载描述文件并引导至设置页面完成安装。安装完成后，务必进入证书信任设置页面，将新生成的根证书开关切换为绿色启用状态。重新生成证书能解决因证书过期或损坏导致的验证失败问题，操作后需重启浏览器使新证书生效。临时关闭解密功能进行交叉验证为了快速判断问题是否由HTTPS解密引起，用户可暂时关闭该功能开关，随后重新访问之前报错的网站。若关闭后网站正常加载且无证书警告，则确认是解密环节配置异常。此时用户可选择永久保持关闭状态（仅损失流量分析能力），或重新正确配置证书。若关闭后错误依旧，则问题不在解密功能，需继续排查节点配置或目标网站的证书固定机制。系统根证书的安装与信任配置iOS设备中手动信任证书的具体路径在iOS系统中，证书安装后不会自动被信任，用户需进入“设置-通用-关于本机-证书信任设置”找到已安装的证书列表。在“启用完整信任”区域找到Shadowrocket生成的根证书（通常名为Shadowrocket或类似名称），将其开关拨至绿色开启状态。这一步骤容易被忽略，却是不信任错误的最常见原因，因为即使证书正确安装，系统默认仍会拒绝所有非官方CA签发的证书。证书安装失败时的替代方案若通过Shadowrocket自动安装证书失败，用户可尝试在Safari中手动下载证书文件，或通过AirDrop从其他设备传输。进入Shadowrocket设置中的HTTPS解密选项，点击“导出证书”获取证书文件，然后通过邮件或文件应用将其保存至设备，在“文件”应用中点击证书按提示完成安装。手动方式能绕过部分iOS版本对描述文件安装的限制，适用于自动流程不响应的场景。证书有效期与系统时间同步检查根证书具有固定有效期，若设备系统时间与标准时间偏差过大（例如手动调整过时间或时区错误），系统会判定证书已过期或尚未生效，从而拒绝信任。用户应检查设备的“日期与时间”设置，确保“自动设置”开关开启并选择了正确的时区。时间校准后重新进入证书信任设置页面，确认证书状态显示为“已验证”而非“过期”或“无效”，然后重新尝试访问网站。特定网站证书固定的绕过方法为受证书固定保护的域名设置直连规则当访问银行、支付或特定企业内网网站时出现证书错误，且该网站证书固定机制严格，最直接的解决方案是在Shadowrocket分流规则中将该域名设置为直连。用户进入配置编辑界面，在规则列表中添加一条“DOMAIN,具体域名,DIRECT”规则，并确保其位于列表顶部优先匹配。添加后保存并重新加载配置，该域名的流量将完全绕过代理，避免被HTTPS解密功能干预。使用代理规则强制走代理但不启用解密若用户仍需通过代理访问该网站但不希望被HTTPS解密拦截，可在Shadowrocket设置中为特定域名关闭解密功能。在HTTPS解密选项的“排除列表”中添加该域名，使代理通道仍保持加密传输但Shadowrocket不进行证书替换。这种方式保留了代理的IP隐藏能力，同时规避了证书固定机制的冲突，适合需要代理访问敏感服务但又不想直连暴露真实IP的场景。浏览器扩展与系统级的证书锁定绕过对于在浏览器中频繁访问的证书错误网站，用户可安装IgnoreCertificateErrors或类似浏览器扩展临时忽略证书警告，但需注意这会降低安全性，仅建议在测试环境或明确知道风险时使用。系统级别则可在访问时点击“高级”并选择“继续前往（不安全）”，但此类操作不会永久生效。更稳妥的方案仍是采用直连或排除解密，而非忽略安全警告。排查服务端证书与代理协议兼容性节点端证书链完整性与协议版本匹配代理节点自身的TLS证书配置若存在问题，同样会引发客户端证书错误。例如节点使用自签名证书或证书链未包含中间证书，Shadowrocket在建立隧道时可能无法验证节点身份，进而影响后续流量的证书校验。用户可尝试切换至使用受信任CA签发证书的节点，或更新节点配置确保证书链完整，并通过在线SSL检测工具检查节点证书状态是否正常。代理协议支持的TLS版本与加密套件老旧节点可能仅支持TLS1.0或1.1，而现代浏览器已弃用这些版本，当Shadowrocket通过此类节点代理访问HTTPS网站时，浏览器可能因TLS版本不兼容而报证书错误或连接失败。用户可查阅节点服务商的协议支持信息，确认其TLS版本至少为1.2，若节点无法升级则需更换至更现代的节点。同时检查加密套件是否包含浏览器广泛支持的算法组合。服务端SNI与域名解析的一致性当代理节点使用TLS时，若服务端未正确配置SNI（服务器名称指示），或客户端的域名解析结果与服务端证书中的域名不匹配，浏览器会因证书中的域名与请求域名不一致而报错。用户可检查Shadowrocket的DNS设置是否返回了正确的节点IP，并确认节点服务端支持SNI扩展。若问题持续，尝试将节点地址从IP改为域名形式，或指定DNS服务器为公共DNS确保解析准确。常见问题FAQ