Shadowrocket Settings 设置参考，按连接行为查取值

先确定设置属于哪一层

Shadowrocket 的连接结果不是由 Settings 单独决定。Home 中选中的服务器决定连接出口，Global Routing 决定是否按规则处理目标，Config 中当前使用的文件提供规则及部分网络参数，Settings 则保存测试、连接辅助和应用偏好等选项。系统的 VPN 授权、网络环境与后台调度也会参与其中。排查前应把这些层次分开，避免在服务器凭据失效时反复改 DNS，或在 Direct 模式下判断某条 PROXY 规则是否正确。

“默认值”是某个明确环境下的初始值，“当前值”是界面此刻展示的值，“生效值”是连接真正使用的值。三者可能不同：导入 Config 后，文件中的解析设置可能改变实际路径；编辑了某个文件，但没有选用该文件，编辑内容就不会成为本次连接的依据。阅读本页的推荐时，先问该选项是否存在于当前平台，再核对应用内说明、所选 Config 与正在运行的连接，而不是仅凭某张旧界面图片判断。

建立一份可恢复的记录

开始前记录当前网络类型、服务器名称、Global Routing 模式、Config 文件名称以及准备修改的字段。已有配置先保留副本，订阅生成的文件与手工维护的文件分开命名，名称中可以写用途，不必写账号或完整地址。若导出内容含服务器密码、订阅参数或身份信息，只保存在自己控制的位置。用于求助的截图应遮挡这些字段，尤其不要把地址栏中看起来像普通查询参数的凭据遗漏。

一次只改变一项，并为修改写出可观察的目标。例如“改 DNS 后，同一域名能够解析”，比“优化网络”更容易验证；“回到 Wi-Fi 后不再自动连接”，比“关闭后台活动”更明确。选一个先前能够访问的目标作为对照，再选一个异常目标。对照与异常目标都失败时，优先检查网络和连接本身；只有异常目标失败时，再查规则、解析结果和目标服务，不要立即重置全部设置。

推荐起点与回退条件

已经能正常使用的设置应作为基线保留，不必因为某个选项名称显得更高级就启用。尚未建立稳定连接时，先使用用户已有配置的要求，减少额外的自动化条件与手动覆盖项。修改后保存，再按该设置的要求断开并重新连接；只重开设置页面不能证明网络会话已经重建。重新测试时使用同一网络、同一服务器与同一目标，否则无法判断变化来自设置还是环境。

出现新问题时，先恢复刚改的一项，而不是继续叠加补偿设置。若恢复后现象仍在，检查是否还有旧连接、系统 DNS 缓存、应用缓存或网络切换的影响，再建立一次新连接。恢复也应有明确界限：不要为找回一个测试结果而清空所有服务器、删除订阅或重装客户端。需要回到导入和首次连接的主线时，直接参照教程中的操作顺序，把系统性排查与首次上手分开进行。

系统 DNS、自定义 DNS 与 DNS over HTTPS

DNS 把域名转换为连接所需的地址，它并不替代代理服务器，也不会修复错误的协议参数。系统 DNS 通常跟随当前网络提供的解析配置，适合作为观察网络原始行为的起点；自定义 DNS 指定解析服务，但其可达性仍受当前网络及配置影响；DNS over HTTPS 通过 HTTPS 承载查询，还需要解析端点、建立连接并完成证书验证。选择方式前先确认问题发生在解析阶段，而不是看到网页失败就更换所有 DNS 项。

默认状态应在当前客户端与所选 Config 中共同核对。不要把“输入框为空”直接理解为“不解析”，空值可能表示继承系统、使用配置值或采用客户端的内置行为，具体以该字段说明为准。若 Config 的相关段落已经指定了解析参数，应先保留副本，再决定是在文件中修改还是在应用中调整。同一目的只保留一处明确的管理来源，避免界面值和文件值不一致，之后又误以为设置没有保存。

推荐取值取决于网络条件

普通排错建议先保留已经能工作的解析方式。需要自定义时，只填写自己确认能够使用、且符合所选字段格式的地址；传统解析地址与 HTTPS 端点不是可随意互换的字符串，不要把完整 URL 粘到只接受 IP 地址的输入框。若字段支持多个值，也应按应用提示的分隔方式填写，不自行猜测逗号、空格或换行。一次新增一个解析入口，确认能够解析并访问后，再考虑是否需要额外备用项。

内网域名是常见边界情况。打印机、公司内部服务或路由器管理名称，可能只有当前网络提供的解析器认识；全部改成外部解析方式后，公共网站可用而内网名称失效，并不意味着代理服务器故障。反过来，一个解析器在家中可用，在酒店或办公网络中可能无法连接。切换网络后应重新检查解析路径，必要时保留针对内网的处理，不要把单个网络上的有效设置当作所有网络的统一推荐值。

解析成功不等于访问成功

验证时先观察同一域名是否得到地址，再观察请求是否命中预期策略，最后确认目标服务是否返回内容。域名规则可以在连接前按名称匹配，而 IP 类规则可能依赖地址信息，两类结果不能混为一谈。解析到了 IPv6 地址也不代表当前网络或服务器路径能够完成 IPv6 连接。遇到偶发失败，应分别记录返回地址类型、所走策略和实际错误，不要仅凭一次重试成功就断定 DNS 已经修复。

修改后旧结果可能暂时保留在系统、浏览器或应用缓存中。先重建连接，再新建一次目标请求；必要时关闭并重新打开目标应用，避免旧会话复用。不要通过反复快速切换解析器来判断优劣，这会把缓存、握手和网络抖动混在一起。更完整的路径对照见DNS 设置技术笔记。回退时恢复原解析方式及配置来源，并再次测试内网名称，确保公共访问恢复的同时没有改变本地服务的可用性。

它决定何时连接，不决定使用哪条规则

On Demand 用于按系统网络条件触发连接行为，与 Global Routing 处理不同的问题。前者关心“何时需要建立连接”，后者关心“连接建立后，某个目标走哪种策略”。开启 On Demand 并不会自动补齐服务器资料，也不会为 Config 添加缺失规则。首次使用时应先手动完成一次稳定连接，再加入自动化条件；若手动连接本来就失败，自动触发只会重复同样的失败过程，还会让现象更难观察。

默认开关状态与已有系统配置应以设备实际展示为准。本页不把“始终开启”作为通用推荐。对需要手动控制的用户，先保持手动连接更容易建立基线；对确实需要按网络条件连接的用户，再按实际界面支持的条件逐项配置。如果当前平台没有某种条件，不要照抄其他设备上的路径，也不要把系统的自动连接权限与客户端中的开关视作完全相同的设置。

条件应当能够被单独验证

设置前先写一句明确需求，例如“在指定网络中保持手动连接，在其他网络中按需触发”。若界面支持按 Wi-Fi 名称区分，应完整核对名称，注意相似名称、同名网络与隐藏网络的影响；不要认为名称相同就代表可信度相同。按网络名称匹配只是连接条件，不是身份验证机制。若加入了多个条件，还要阅读当前界面对优先级和匹配顺序的说明，不凭列表视觉位置推断系统一定按该顺序执行。

建议按“一个网络、一个条件、一次切换”测试。先在当前 Wi-Fi 中确认行为，再切到蜂窝网络，最后回到原 Wi-Fi，分别记录系统 VPN 状态和应用内连接状态。测试时保持同一服务器及 Config，避免订阅更新或服务器选择同时变化。系统状态图标只说明隧道相关状态，不证明特定目标已经可用；触发之后仍要发起一个明确请求，检查是否连接成功以及是否命中了预期策略。

认证网络、休眠与手动断开

酒店、车站或访客 Wi-Fi 可能要求先打开认证页面。此时网络名称已经匹配条件，但互联网连接尚未完成，自动连接可能遇到超时。应先完成网络要求的认证，再按既定条件测试；不要把认证页打不开直接归因于服务器失效。如果临时关闭 On Demand 来完成认证，记录原状态，认证结束后再恢复。网络从可用转为受限时，也应区分“系统没有触发”与“已经触发但连接失败”。

设备锁屏、应用切到后台或系统节能状态，可能改变观察到的时序。不要用“退出应用后几秒没有变化”推断配置必然错误，也不要承诺固定的后台触发时间。手动断开以后是否再次连接，取决于当前系统条件与配置；若发现刚断开又恢复，先检查 On Demand，而不是反复删除 VPN 配置。需要临时保持断开时，应先关闭自动触发条件，再确认系统状态，避免把符合条件的再次连接误判为开关失灵。

回退时先停用刚添加的条件，恢复为可以解释的手动连接流程，再重新检查原服务器与 Config。不要一次删除所有系统网络设置，这可能同时移除其他用途的配置。若手动连接正常、只有特定网络切换异常，应保留切换前后记录，在相同条件下重复验证。能稳定复现的单一条件，比一组看似完整却互相覆盖的条件更适合作为长期配置。

配置、代理、直连三种姿态

Global Routing 的 Config、Proxy、Direct 分别对应配置、代理、直连三种姿态。Config 按当前选中的配置处理目标；Proxy 适合临时检查目标经代理路径时的表现；Direct 用于观察不经代理路径的访问情况。这里的模式名称与规则中的大写策略词属于不同层次，不要因为都出现 PROXY 或 DIRECT 就认为两者可以互相替代。DNS 和系统网络行为仍需单独检查，模式切换不是对整条网络路径的完整说明。

常规使用已有规则时，推荐先确认 Config 模式以及所选文件，而不是急于补规则。当前默认模式应以 Home 的实际选项为准，文件默认内容也应以用户已有配置为准。切换到 Proxy 后目标恢复，只能说明两条路径表现不同，不能直接证明某个域名规则错误；还可能涉及解析地址、规则覆盖范围或目标服务对出口的处理。测试结束后应恢复原模式，避免长期停留在临时诊断姿态。

规则从上到下，先具体后兜底

规则通常按顺序匹配，较具体的例外应放在较宽泛的条件之前，最终策略放在末尾。DOMAIN 精确匹配域名，DOMAIN-SUFFIX 匹配域名后缀及相关子域名，DOMAIN-KEYWORD 按名称中的关键词匹配。关键词规则范围较宽，容易覆盖原本不准备处理的名称，新增时要结合实际请求记录验证。IP-CIDR、IP-CIDR6 与 GEOIP 关注地址范围或地址归属，和域名规则不能只按名称相似程度相互替换。

以下是用于理解顺序的 Shadowrocket .conf 规则片段，不是完整连接配置，也不包含服务器资料。示例域名只用于演示语法，不能当作测试服务。第一条将匹配的域名后缀交给 PROXY，第二条将指定私网地址范围交给 DIRECT，第三条按 GEOIP 条件选择 DIRECT，其余请求由 FINAL 交给 PROXY。是否采用这样的最终策略，应由用户自己的配置目标决定，而不是把整段机械覆盖到已有文件。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

避免配置更新覆盖手工改动

Subscribe 管理用户已有订阅的更新，不等于 Config 中的规则文件会自动按预期合并。订阅生成的服务器资料、远程配置内容和本地编辑内容应分别确认。若某个文件由更新过程重新生成，直接写在其中的改动可能被替换。建议保留原始文件和本地实验副本，先在副本中验证；确需长期维护的规则，应使用当前客户端支持的管理方式，并明确更新后应检查哪些内容，不承诺任何文件都会自动保留手动编辑。

规则看似未生效时，按四个问题检查：是否选中了刚编辑的 Config，Global Routing 是否为 Config，请求是否使用了预期域名或地址，是否有更靠前的规则已经命中。应用可能复用旧连接，也可能另行请求其他域名，不能仅凭浏览器地址栏判断实际匹配对象。保存并重连后，从 Log 找到这一次请求再对照规则；若仍不明确，先做一条范围明确的临时规则验证，完成后删除，避免排错规则长期改变流量走向。

测试结果不是线路质量的单一结论

Ping 在不同测试方式下可能指向不同的探测过程。先阅读 Settings 中当前选择的测试方式及目标，再解释结果；不能只看列表中的一个时间值，就把它当作真实网页完整加载时间。到服务器的往返、建立传输连接、完成代理认证、访问测试目标，属于不同阶段。某种探测成功只证明它覆盖的阶段有响应，另一种探测超时也不一定代表服务器完全不可用，必须结合测试方式和真实请求判断。

默认测试方式、测试地址与超时应以当前客户端实际值为准，本页不提供一个跨平台的固定默认数字。推荐先保留已有可用测试设置，确保同组结果能够横向比较；确需修改时，先记下原值与修改原因。若界面允许设置目标地址，应选自己确认可达、响应行为稳定且适合该测试方式的目标，不把任意网页首页都当作等价探针。目标主动拒绝某类请求，也可能让结果显示异常。

超时、并发与结果可比性

超时太短会把正常但较慢的握手记为失败，太长则会拉长整组测试等待时间。推荐从客户端当前值开始，根据同一网络上的重复结果小幅调整，而不是直接追求最短数字。移动网络切换、设备刚唤醒或服务器域名尚未解析时，第一次测试可能包含额外准备过程，应与后续结果分开记录。若某项设置带单位，修改前先确认是毫秒还是秒，不把不同字段中的数字原样复制。

若当前平台提供并发测试控制，批量测试过多服务器可能同时占用网络和设备资源，也可能触发远端限制。排查一个服务器时，优先单独测试，再与少量已知可用的对照项比较。排序变化本身不是故障证据，短时抖动足以改变次序。不要为了让列表看起来整齐而不断更换测试目标；那会让前后数据失去共同基准，无法判断网络真的改善还是只换了一个响应更快的探测终点。

把测试与实际访问串起来

一次有效验证应包含三个独立观察：服务器探测是否成功，连接是否建立，目标请求是否完成。先对用户已有服务器执行 Connectivity Test，再选中它建立连接，最后请求固定目标并查看 Log。三步使用相同网络，且不要在中途更新订阅。若探测失败但连接与目标请求正常，记录测试设置即可，不要仅为修正列表中的状态而破坏已经可用的实际连接。

当网页能够打开但大文件传输慢，探测耗时也不能代替持续传输表现。吞吐量还受目标服务、网络拥塞、协议参数和远端处理能力影响；同样，单次低耗时不证明长连接一定稳定。需要比较时使用自己的同一目标和相近时间窗口，记录上行、下行及中断现象。Hysteria2 等协议的传输背景可参照Hysteria2 协议技术笔记，但协议解释不应被当作对某条线路表现的保证。

结束测试后恢复原有的测试目标、超时和并发设置，或者明确保留变更的理由。求助时提供测试方式、网络类型、异常是否能重复以及真实访问是否成功，比单独提供一个数字更有用。不要附带完整订阅地址或服务器认证字段。若异常只在某个网络出现，保留同设备在另一网络上的对照，下一步应查网络条件，而不是直接推断所有服务器资料都已失效。

先限定时间窗口，再读错误

Log 的用途是把一次连接过程拆成可以观察的事件，而不是收集越多越好的文本。开始排错前记下时间，保持其他应用活动尽量少，只重复一次明确的失败动作，再查看对应记录。没有时间窗口时，后台请求、系统联网检查和目标应用的重试容易混在一起。记录中出现错误并不意味着它就是当前问题的原因，应先确认目标、服务器、时间与本次操作能够对应。

日志开关、级别与保留方式应以当前 Settings 和实际平台支持为准，不假设所有平台都提供同一组级别。推荐日常保留客户端既定设置；需要更详细信息时临时提高记录范围，复现后及时恢复。长时间记录可能增加存储与处理负担，也会积累更多敏感上下文。若调整日志设置需要重新建立连接，应先保存相关记录，再重连验证，避免在重启过程中丢失原先能够说明问题的事件。

按解析、连接、认证、目标响应区分

读取顺序可以从解析开始，再看远端连接是否建立、协议认证是否完成，最后看目标请求及响应。名称无法解析时优先查 DNS；连接阶段反复超时时检查当前网络与服务器可达性；认证相关错误应核对用户已有资料；目标已经返回内容或状态时，则要进一步确认目标本身的行为。不要把所有 timeout 都归为同一种原因，相同单词可能出现在不同阶段，处理方法也不相同。

规则诊断需要把请求目标、命中规则和策略放在一起看。浏览器打开一个页面时，可能同时访问图片、脚本和其他域名，不能只搜索地址栏中的名称。某项被 REJECT 的请求也未必导致整个页面失败，先确认它是否属于必要资源。若当前记录没有显示某个字段，不要补写推测结果；可以缩小复现范围，使用同一目标重新请求，并在 Config 中核对最可能命中的规则位置。

Data 读数要带统计边界

Data 中的数值应连同当前视图、统计起点和重置操作一起理解。按服务器观察和按应用观察回答的问题不同，不应把两个视图的某个数字简单当作完全相同的流量口径。少量上行和下行可能来自握手、重试或背景请求，并不证明网页加载完成；总量增加也不能单独说明目标走了某条规则。查看时先固定服务器和应用，再通过一段可控操作观察增量，而不是拿历史累计值解释刚发生的故障。

需要清零时，先确认当前按钮影响的是哪一范围，并保存清零前的对照。不要在每次失败后立即清空全部统计，否则会丢掉时间上的关联。若应用归属或统计项目未出现，先核对平台能力、流量是否经过当前连接及当前视图，不自行补出不存在的应用级证据。具体读数解释见Data 流量统计说明，可配合日志定位，而不是替代请求记录。

分享前最小化敏感信息

日志可能包含完整域名、请求路径、订阅参数、服务器地址、设备信息及身份字段。分享前只保留与问题相关的短片段，遮挡认证信息及可识别个人的内容；即使是自己的订阅，也不要把完整地址当作普通文本公开。保留阶段名称、错误文本与相对时间通常已能说明问题。完成诊断后恢复原日志范围，并按实际需要清理导出文件，使排错材料不会成为长期留存的凭据副本。

Widget 是操作入口，不是网络检测结果

Widget 用于从系统提供的位置查看或操作客户端相关状态，实际样式、可用操作和刷新行为以设备系统及客户端支持为准。它不是一套独立连接配置，也不替代 Home 中的服务器选择。看到 Widget 中显示已连接时，仍应通过目标请求确认访问结果；看到状态尚未刷新时，也不能立即推断连接已经断开。系统可能限制刷新频率，展示状态与真实网络变化之间存在时序差异。

默认是否添加 Widget 属于用户的系统界面选择，不应写成客户端统一默认开启。推荐先在应用内验证连接，再添加需要的入口；如果系统提供多个尺寸或不同操作项，按当前实际需要选择，不必全部放置。执行连接或断开动作后，回到 Home 和系统 VPN 状态核对。若 On Demand 仍满足触发条件，手动断开后可能再次连接，这应回到自动连接条件排查，而不是反复移除 Widget。

同步前先明确要同步什么

iCloud 同步用于支持范围内的数据在设备间保持关联，但不能假设所有 Settings、系统授权、Widget 布局与运行状态都会一并迁移。当前客户端能够同步哪些内容，应以同步界面的说明和实际结果为准。系统 VPN 授权是设备本地行为，服务器在一台设备上可用也不代表另一台设备已经完成相同授权。首次迁移应将“资料已经出现”和“能够建立连接”当作两项独立检查。

启用同步前，先保留本地配置副本，并确认设备使用的是预期的 iCloud 账号、系统允许应用使用 iCloud、网络能够完成同步。不要把账号一致理解为同步已经完成；系统限制、存储状态与后台执行条件都可能延后结果。默认同步开关与数据范围以实际界面为准，没有必要为了复制少量设置而仓促开启整组同步。若只需要某个文件，也可使用客户端支持的导入导出流程，并妥善保管其中的敏感资料。

用单项变更观察同步边界

推荐先挑选不含凭据、容易辨认的配置名称或普通偏好作为观察点，在一台设备修改并等待另一台设备显示变化，确认方向和范围后再处理重要内容。不要同时在两台设备编辑同一文件，否则难以判断哪份是预期副本。若出现冲突或重复项目，先停止继续编辑并保留两边内容，逐项比较后再决定保留哪份；不要以“最后看到的那份”直接认定为最新且完整的数据。

另一台设备上出现服务器但无法连接时，先核对该设备的网络与权限，再核对服务器参数是否完整；不要马上关闭并重新开启同步。若同一资料在两台设备上结果不同，系统网络、DNS 和可用协议能力都可能是原因。需要恢复时，使用之前保留的本地副本，并确认该恢复会不会继续同步到其他设备。理解删除、替换与同步范围之后再执行，避免把本地排错变成跨设备的数据变更。

购买恢复与配置同步分开处理

iPhone / iPad 的购买恢复应按下载页中的已购恢复说明处理，iCloud 中存在配置不等于商店购买状态已经恢复，反过来，恢复应用也不代表本地资料一定完整。iPhone / iPad 版在 App Store $2.99 一次性付费，Mac、Windows、安卓、Linux 版免费；客户端购买与用户已有线路资料是两回事。换机前保留配置、换机后核对授权，再查已购恢复与重新获取说明，能避免把不同系统的账号与数据流程混为一谈。

本地入口与远端服务器端口不是同一项

Proxy 相关端口需要先区分用途：Add Server 中的端口属于用户已有远端服务器资料，本地代理监听端口则属于客户端向其他程序提供的入口。两者名称都含端口，但不能互相抄写。远端端口应按已有资料填写，本地端口则要与实际使用它的程序保持一致。当前平台是否提供 HTTP、SOCKS5 或其他本地入口，以及入口是否需要额外开关，应以 Settings 中实际选项为准，不默认所有平台完全一致。

默认监听地址和端口没有跨平台统一推荐数字，应先读取当前值与应用说明。只在同一设备上使用本地代理时，优先保持仅本机可访问的范围；没有明确用途，不要扩大到局域网监听。若需要让其他设备访问，应确认客户端确实支持、系统网络允许，并检查访问控制与认证选项。扩大监听范围不只是“让连接更方便”，还会让同网段设备可能接触这个入口，需要明确谁可以连接以及如何停止提供服务。

地址、协议与端口必须成组匹配

使用本地入口的程序需要同时填写正确协议、地址和端口。HTTP 入口不能因为数字相同就当作 SOCKS5 入口，远端服务器地址也不能替代本机监听地址。同一设备访问回环地址，与另一台设备访问该设备的局域网地址，是两条不同路径。另一台设备填写自己的回环地址，只会访问它自己，不会自动指向运行 Shadowrocket 的设备。诊断时先确认谁是请求方，再确认入口实际在哪台设备上。

端口冲突通常表现为监听无法启动，或请求被其他本地程序接收。更换端口前先记录原值，并确认新端口没有被占用；修改后同步更新所有使用该入口的程序，再重新测试。若只改了一端，客户端可能连接正常，但调用方仍在请求旧入口。停止提供本地代理后，也应恢复调用方的代理设置，否则它可能持续连接已经关闭的端口，看起来像系统网络整体失效。

按失败范围决定检查顺序

如果所有应用都失败，先确认基础网络、系统 VPN 状态、所选服务器和认证资料；如果只有使用本地入口的程序失败，则先查协议、监听地址、端口与访问范围。如果只有某个目标失败，再查 DNS、Global Routing 与规则命中。这样的分流能减少无关修改。局域网设备连接不到入口时，还要考虑设备是否处于同一网络、访客隔离与系统防火墙，不能直接用远端服务器测试成功来证明局域网入口也应该可达。

完整回退并不等于全部重置。先撤销最近改动，再恢复原 Global Routing 与 Config，随后核对 DNS 和 On Demand，最后检查调用方是否还留有本地代理设置。每恢复一层都执行一次固定目标请求，找到结果发生变化的位置后停止扩散操作。若恢复到基线仍有问题，保留对应 Log 的短片段及测试条件，再核对用户已有订阅是否更新、服务器资料是否发生变化，不删除所有内容来碰运气。

涉及重新安装或换平台时，统一从全平台下载入口获取，并阅读系统安装放行说明；Windows 核对来源后按 SmartScreen 提示处理，Mac 核对来源后在系统隐私与安全性中按提示放行，安卓按系统提示授予对应安装来源权限。安装完成后先按快速上手教程恢复基本连接，再逐项恢复本页设置。需要理解模式边界时可继续阅读代理模式说明，不要把暂时有效的诊断参数直接当作长期配置。