Shadowrocket
Settings 设置项参考

Shadowrocket 的实际行为不是由 Settings 中的某一个开关独立决定。系统网络权限、当前选中的服务器、Global Routing、正在使用的 Config，以及服务器自身的协议参数都会参与。遇到“设置改了却没有变化”，首先应确认观察的是哪一层，而不是继续叠加选项。本手册以用户已有自己的订阅或服务器信息为前提；订阅链接从你的服务商处获取，导入之后仍需核对当前服务器与配置是否正确。

初始状态不等于统一默认值

“默认值”需要区分三种来源：新安装时应用给出的初始状态、导入配置中明确指定的值，以及从设备备份或同步恢复的旧值。三者可能不同。界面也可能随应用更新调整，所以本页不会把未经核实的端口号、测试地址、超时秒数写成固定出厂值。查阅某项设置时，应把当前界面显示和当前配置文件一起记录；界面没有显示的值，不应根据别人的截图推断。

开始调整前，保留一份当前 Config 的副本，记下 Global Routing、所选服务器、网络类型及待解决的问题。记录应描述可重复的现象，例如“同一域名在当前 Wi-Fi 下首次加载失败”，而不只是“网络慢”。随后保持服务器、网络和访问目标不变，只修改一个相关选项。这样即使结果变差，也能回到明确的起点，不必依赖记忆逐个猜测原来的开关状态。

三种姿态决定规则是否参与

Global Routing 的配置姿态对应 Config，按当前配置处理请求；代理姿态对应 Proxy，以代理路径为主要处理方式；直连姿态对应 Direct，以直接连接为主要处理方式。它们是诊断时的重要对照，但不能当作网络一定可达的保证。系统保留流量、应用内特殊处理与服务器可用性仍有影响。尤其在 Proxy 下验证规则修改，不能据此判断 Config 中的规则顺序是否正确。

推荐的日常取值不是一律切换 Proxy，而是在理解当前规则的前提下使用 Config。排查期间可以暂时切换姿态，测试后恢复原来的选择。切换后已有长连接未必立即重建，因此应重新发起目标请求；必要时在合适的时机断开再连接。不要在语音通话、文件上传或其他不可中断任务进行时反复切换，把测试造成的中断误认为服务本身故障。

把规则文件当成另一组输入

以下片段用于理解处理顺序，不是一份完整可用的配置，也不会创建服务器。PROXY、DIRECT、REJECT 是规则策略，不能与界面中的 Proxy、Direct 混写。示例中的域名仅为说明。规则从上向下匹配，FINAL 应作为末尾兜底；把它放到前面，后面的规则可能没有机会处理请求。修改前应确认编辑的是当前启用的文件，而不是同名的备份。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,ads.example.net,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

推荐把“预期行为”和“实际记录”并排核对：预期某域名走 PROXY，就在请求记录里确认目标域名、命中规则和最终策略，而不是只看首页连接开关。若规则涉及解析后的地址，再回到 DNS 章节检查解析链。购买与安装相关疑问请看正版核验说明。客户端一次性买断 ≠ 线路套餐；调整任何设置都不会替代服务商提供的有效连接信息。

DNS 的任务是把域名解析为连接所需的地址。解析成功不等于目标服务可达，解析失败也不一定是服务器故障。一次访问通常包含域名查询、规则判断、建立连接及应用层交互，其中任意环节都可能失败。检查 DNS 时，先写下完整的目标域名，区分浏览器显示的页面错误与 Shadowrocket 记录中的解析错误，避免把证书问题、目标拒绝连接或响应超时统称为 DNS 问题。

DNS 值来自哪里

应用界面中的 DNS 相关设置与 Config 中的解析配置需要合并理解。若文件明确指定解析来源，只改系统 Wi-Fi 页面中的 DNS，不一定改变当前隧道内的解析行为。反过来，配置没有指定某些选项时，也不能假定应用一定使用某个公共解析服务。推荐先查看当前文件是否存在相关条目，再记录 Settings 的显示内容；恢复测试时，应同时知道自己撤销的是哪一层修改。

使用系统解析来源通常适合作为排查起点，因为它便于与设备当前网络的行为建立对照；这不是对所有网络的性能推荐。企业网络、校园网络或家庭网络中的内部域名，可能只能由对应网络的解析服务回答。把解析来源统一改成外部地址，可能使内部名称失效。若现有配置来自服务商，先理解其 DNS 设计，再决定是否覆盖，不要把多组互不清楚的设置混合使用。

下面的片段仅展示配置中声明系统解析来源的写法。它不代表文件其余部分可以删除，也不保证能覆盖所有请求场景。编辑前保留现有文件，核对同一节中是否已有相同键名，避免重复条目带来理解偏差。对于没有在当前界面或文件说明中确认的高级参数，推荐保持现状，而不是根据相似拼写自行添加。

[General]
dns-server = system

IPv4、IPv6 与域名规则

同一域名可能返回 IPv4 地址，也可能返回 IPv6 地址。设备获得 IPv6 地址，并不代表代理服务器、目标站点与当前网络之间的完整路径都支持相同方式的连接。若某目标只在特定网络失败，应比较解析结果的地址族与后续连接错误，再决定是否调整相关选项。不要把关闭 IPv6 当成普遍优化：它会改变其他访问路径，而且可能掩盖真正的路由或服务器参数问题。

DOMAIN、DOMAIN-SUFFIX 一类规则直接围绕域名工作，IP-CIDR、GEOIP 等规则则涉及地址判断。解析结果变化时，依赖地址的规则可能出现不同命中结果，因此“同一个网址走了不同策略”需要同时看域名、解析地址和规则顺序。若配置启用了特定的解析或映射机制，记录中出现的地址还需要结合该机制解释，不应只凭一个地址外观断言请求已经从某条路径发出。

缓存与可重复验证

修改 DNS 后立即刷新一次页面，仍可能使用旧结果。系统、应用和网页自身都可能保留缓存或已有连接。推荐先重新发起一个明确的目标请求，再观察是否出现新的查询记录；必要时重建连接，并重新打开目标应用。不要为了清理缓存连续修改多个开关，否则即使问题暂时消失，也无法知道是解析来源、连接重建还是目标缓存变化造成的。

排查顺序可以固定为：同一目标重试、查看解析错误、比较当前网络与另一已知可用网络、核对配置中的 DNS 条目、单独调整解析来源、重建连接后复测。每一步都记录结果。如果仅内部域名失效，优先检查本地解析需求；如果所有域名都失败，再检查当前网络是否已经完成登录或认证。网络本身尚未可用时，继续更换 DNS 通常不会建立有效的对照条件。

对需要加密传输的解析方式，应同时考虑解析服务地址本身如何找到、连接是否通过当前策略，以及证书验证是否成功。多个解析地址并不自动意味着查询一定更快，也不能保证返回结果完全一致。推荐值应以“在当前网络稳定、能解释其路径、可以恢复”为标准。验证成功后保留最小必要修改，并在备注中写明原因，方便下一次换网时判断该设置是否仍然合适。

On Demand 用于根据系统可识别的条件触发按需连接。它影响的是何时尝试建立连接，不是域名最终采用什么策略，也不是让应用持续显示在前台。理解这一点很重要：On Demand 看起来已经触发，而某个目标仍然打不开，可能是服务器、DNS 或规则的问题；反过来，手动连接正常而换网后没有自动连接，才更接近条件匹配或系统配置层面的检查方向。

先有手动连接基线，再添加条件

推荐先关闭自动化干预，完成一次稳定的手动连接测试。确认 VPN 配置已按系统提示允许添加，当前服务器有效，目标请求在预期策略下可用，然后再启用 On Demand。否则手动与自动两条路径同时存在问题，很难判断故障发生在触发阶段还是连接阶段。首次设置的具体入口和可用条件以当前应用界面为准，不把旧界面的选项名称推定为所有设备都存在。

这里的默认状态应从本机界面读取，尤其是已经恢复过系统备份或已有 VPN 配置的设备。即使应用重新打开，系统保存的按需行为也不一定等同于一次全新的安装。修改前记录 On Demand 是否启用、已有条件的顺序以及对应网络。若只是临时排查，可先保留条件内容，暂停相关自动行为；不要直接删除全部配置，失去之后恢复工作网络规则所需的信息。

如果当前界面提供按 Wi-Fi、移动网络或特定网络名称区分的条件，应先从一条容易验证的条件开始。不要一次加入大量例外。网络名称的拼写、空格和大小写应按实际显示核对，同名网络也不一定具有相同的网络环境。网络名称只是条件输入，不是网络可信度的证明；涉及组织内部资源时，应遵循对应网络的接入规范，不用自动条件代替必要的访问管理。

自动重连与手动断开的边界

用户手动关闭连接后，如果按需条件依旧满足，系统可能在新的网络请求出现时再次尝试连接。此时应先确认是否需要暂停 On Demand，而不是连续点击连接开关。需要临时保持断开时，应明确结束自动触发条件，再观察系统 VPN 状态。测试结束后恢复原设置，避免忘记开启而误以为应用已失去自动连接能力。这种行为应与服务器连接失败后重试的情况分别记录。

网络切换也不是单一瞬间。设备可能先离开 Wi-Fi，随后建立移动网络，再处理新的解析和连接；已有长连接可能中断，新请求则使用新的网络路径。因此自动连接的验证应覆盖“切换后能否重新发起请求”，而不只观察切换时图标是否闪动。测试时留出合理的建立过程，不在几秒内反复切换网络；频繁切换会制造额外变量，也会让日志中出现大量难以关联的失败记录。

按网络场景建立测试矩阵

建议分别验证三种场景：在当前网络手动连接、从另一个网络切入后的自动连接，以及暂时停用自动行为后的手动断开。每次记录触发条件、系统状态和一次实际请求结果。若只在某个 Wi-Fi 失败，检查该网络是否要求先打开登录页面；网络认证尚未完成时，自动连接可能与认证流程相互影响，此时应先完成网络接入，再重新测试，不要误改协议参数。

如果设备受组织管理，系统中可能存在其他网络策略或配置限制。应先核对系统设置中实际生效的 VPN 配置，以及是否有管理要求，再判断应用条件是否有问题。不要通过反复删除系统配置来试错，因为删除可能同时清掉权限、按需条件与原有设置。推荐先暂停自动行为、保留记录、单独验证手动路径，只有明确配置失效时才按系统流程重新授权。

日常推荐值取决于使用习惯：需要明确控制连接时间时，保留手动方式更容易理解；需要随网络条件触发时，再逐项启用 On Demand。不要为了“始终连接”的表面状态叠加无法解释的条件。完成设置后应锁屏再唤醒、切换一次网络并重新请求目标，确认整个生命周期符合预期。若需要回顾首次授权与连接顺序，可返回快速上手教程核对操作主线。

Ping、连接测试和实际页面加载不是同一件事。测试可能侧重服务器地址的响应、端口建立，或经指定路径访问测试目标；具体含义取决于当前选择的测试方式。一个较低的时间数字不能证明目标网站一定加载迅速，超时也不能单独证明服务器完全不可用。开始比较结果前，先核对测试类型、测试目标和当时的网络条件，确保比较的是同一种测量。

测试方式与测量范围

如果测试只检查基础网络响应，它通常无法完整验证应用协议的认证与后续传输。端口可以建立，也不意味着密码、TLS、SNI 等参数都正确。通过完整代理路径访问目标的测试，覆盖的环节更多，但也会受到测试站点自身状态影响。推荐先用基础测试判断地址或端口是否可达，再用实际请求验证完整链路；不要把第一步通过直接写成“全部设置正常”。

测试目标与超时选项的初始值应以当前界面为准。已有配置和历史设置可能保留旧值，因此不同设备上的结果不能只按数字直接排序。推荐保留应用当前可用的初始设置作为基线；确需更换测试目标时，选择自己能够解释用途、且在当前环境可访问的目标。一次只改目标或超时中的一项，避免把测量方法变化误当成服务器性能变化。

测试目标应尽量稳定、响应内容简单，并与验证目的相符。若目标需要登录、会跳转、实施访问频率限制，或对某些网络返回不同内容，结果就可能受到额外条件影响。不要在列表中快速重复测试大量服务器，把短时排队或限流当成持续故障。对于已有订阅，只需要围绕自己实际使用的少量项目建立对照，不必追求列表每一行都出现相似数字。

超时不是越短越准确

等待时间过短时，首次解析、建立连接和加密交互可能尚未完成，测试便被判定为超时；等待时间过长则会使故障反馈迟缓。推荐先保留现有值，通过重复少量测试观察是否稳定，再根据真实使用需求调整。把超时不断调大，只能延长等待窗口，不能修复地址错误或认证失败。若数次结果差异明显，应检查网络负载与切换情况，而不是立即选择最小的一次结果。

延迟主要描述某次交互的时间，吞吐量、丢包、拥塞和目标服务器响应还会影响实际体验。小页面能打开而大文件中断，或文字消息正常而音视频不稳定，都需要更贴近业务的验证方式。推荐使用同一设备、同一网络、相近时间和同一测试目标比较，之后再用实际任务复核。不同时间、不同测试方式产生的数字，只能当作各自场景的记录。

从异常数字回到具体参数

如果只有一个服务器失败，先核对它的地址、端口、协议和服务商提供的信息；如果同一网络下所有项目同时失败，先确认网络接入与测试目标是否可用。若基础测试成功但实际连接失败，再检查密码、TLS、SNI、系统时间与证书验证。不要通过关闭证书验证来换取一个成功结果；这会改变安全边界，也无法证明原参数正确，应按服务商提供的正确参数修复。

测试前后还应注意流量消耗与设备状态。大量测试会产生额外连接，在移动网络中也会计入流量。后台正在同步或下载时，测试结果可能与空闲状态不同，因此记录应包含“设备是否有其他传输”这一条件。推荐在相对稳定的环境重复几次，观察范围与失败模式，而不是把偶然最低值写成长期结论，更不能把测试排序当成对服务器质量的保证。

相关排错可继续阅读节点超时排查顺序；需要理解数字与实际体验的差别，可看延迟、地区与协议的选择说明。本章的建议是保持测量条件一致，把数字作为线索，再回到真实请求验证。服务器参数发生变化时，应重新建立基线，而不是沿用旧测试结果判断新配置。

Log 帮助定位连接过程中的错误，Data 用于观察相应的数据与请求信息；具体入口和显示字段以当前界面为准。它们的价值不是让所有数字持续增长，而是把某次失败与当时的目标、策略及错误阶段关联起来。排查时应先写下一个明确问题，再观察相关记录。如果只浏览大量历史条目，很容易把后台应用的失败请求误认为当前页面失败的原因。

从一次请求建立时间线

开始之前记下本机时间、网络类型、Global Routing、当前 Config 和所选服务器。随后只重现一次目标操作，例如打开一个指定页面，立即查看同一时间段的记录。优先确认目标域名是否出现、是否得到解析结果、命中了哪条规则、采用何种策略，以及最终错误是什么。不同应用可能同时访问多个域名，因此页面主域名成功并不等于其中所有资源都成功。

日志级别、记录开关和保留方式不能假定具有跨设备统一的初始值。推荐日常保留适合当前使用需求的记录范围，只有定位问题时才暂时增加细节。更详细的记录可能增加存储和处理开销，也会包含更多访问信息。打开某项记录后应确认它确实产生了与目标操作相关的内容，而不是认为“开关开启”本身就足以完成诊断。

如果当前界面支持清理记录，清理前应判断是否还需要保留故障前后的上下文。可以先保存必要信息，再建立一段较干净的复现窗口。不要一边清空日志一边持续重连，导致真正的首次错误被后续重试覆盖。对于偶发问题，保留网络切换前后的少量记录通常比截取单条报错更有帮助，因为后者可能只是前一个失败引起的连锁结果。

按阶段解释错误

解析错误优先回到 DNS；连接被拒绝优先核对目标端口和服务状态；等待超时需要检查网络路径、测试窗口与对端响应；TLS 或证书相关错误需要核对 SNI、系统时间和证书条件。错误文字应尽量保留原文，因为中文概括可能丢失阶段信息。同一现象可能由不同原因造成，不应看到 timeout 就同时修改 DNS、端口和规则，让下一轮记录失去对照意义。

规则诊断还要区分“预期命中”和“实际命中”。比如用户预期某域名走 DIRECT，记录却显示落入 FINAL，可能是规则对象不匹配、顺序不正确，或实际请求使用了另一个子域名。此时应复制真实目标做比对，不要继续为猜测的域名增加规则。关于自上而下匹配和兜底位置，可参阅自定义规则优先级说明，再回到当前 Config 验证。

流量数字与记录边界

Data 中的流量统计应结合其统计对象和时间范围理解。应用记录的传输量不一定与服务商账单完全相同，协议开销、计费口径、重传和统计重置都可能造成差异。不要把某个累计值直接解释为当月剩余用量。若需要核对服务用量，应以服务商提供的计费说明为依据，并记录本机统计从何时开始，而不是通过反复重置数字推断扣费情况。

请求记录也有观察边界。应用缓存、已有长连接、系统行为和记录级别都会影响显示内容。没有看到某条记录，不足以单独证明请求没有发生；看到了连接条目，也不一定代表业务交互已经成功。推荐将客户端记录与目标应用的实际结果并排判断，必要时重建一次新连接再观察。对于加密通信，记录能说明的范围也不等于完整的应用内容。

排查结束后恢复临时提高的日志级别，按需要清理包含敏感内容的副本，并保留一段简短结论：出现了什么错误、修改了哪一项、如何复测、是否恢复原值。不要长期保留未经整理的大量日志，也不要将完整配置和全部访问记录一起发送。可复用的排错笔记应保存操作与结果，而不是保存秘密；这样下一次遇到相似问题时，能够复现方法，而不必暴露旧凭据。

Widget 是从系统提供的位置查看状态或进入操作的快捷入口，不是独立的连接服务。它依赖已经完成的应用配置、系统授权以及系统安排的刷新机会。使用前应先在 Shadowrocket 中完成一次手动连接，再添加或配置 Widget。若首次授权尚未完成，直接从快捷入口发起操作，可能仍需回到应用或系统提示中确认；这与服务器参数是否有效是两个不同问题。

先配置主体，再添加入口

推荐先明确需要展示或操作的内容：是查看当前状态，还是快速进入应用处理连接。系统提供的 Widget 尺寸、可用位置和交互能力可能随设备环境变化，应以本机添加界面为准。本手册不把某种尺寸、某个按钮或固定布局写成所有设备共有的功能。若当前系统没有显示某项可用内容，先核对应用与系统支持情况，不用反复修改服务器参数寻找该入口。

Widget 的初始状态也不能直接当作连接默认值。添加时可能先显示缓存、尚未加载的内容或上一段会话的信息。推荐添加后打开主应用一次，确认当前服务器和连接状态，再返回观察。若允许选择展示对象，先使用最简单的一种布局建立对照；复杂展示中的某一项未及时刷新，不应被解释为整个连接已经失效，更不应作为自动切换服务器的唯一依据。

整理设备桌面时，应考虑哪些信息会直接显示给旁人。服务器备注可能包含用途、组织或个人识别信息，即使没有密码，也可能暴露使用习惯。推荐采用不包含敏感内容的备注，并根据设备共享与锁屏展示情况决定放置位置。Widget 便利性与信息可见性需要一起考虑；是否允许锁屏访问或展示，应按系统实际提供的控制项核对，不根据其他设备的截图推断。

显示刷新与连接状态分开判断

系统会管理 Widget 的刷新时机，因此显示变化可能落后于主应用中的实际状态。遇到两处显示不一致，先打开 Shadowrocket 查看当前连接，再检查系统 VPN 状态，并发起一次实际请求。不要连续点击 Widget 试图强制同步；短时间重复操作可能造成连接与断开交替，反而制造新的失败。如果问题只是文字更新延迟，应按展示问题处理，而不是立即重建全部配置。

快捷操作完成后，也应等待连接流程结束再判断结果。服务器认证、解析和隧道建立都需要时间，Widget 上的一次点击不代表目标网站已经可用。若操作返回应用，应先看是否存在系统授权或错误提示，再查看相关 Log。推荐用固定目标完成一次验证，确认该入口最终触发了预期动作。不要把图标外观变化直接当作完整网络测试，它只能提供有限的状态线索。

与 On Demand 的交互

启用 On Demand 后，从 Widget 手动断开不一定意味着之后始终保持断开。只要触发条件仍满足，系统可能再次尝试连接。因此需要临时停止自动连接时，应先处理 On Demand 条件，再使用快捷入口操作。若仅在 Widget 上反复关闭，可能误以为按钮失灵。推荐测试时分别记录“点击动作是否执行”和“之后是否发生自动触发”，不要把两个阶段合成一个结论。

更换服务器、修改 Config 或恢复备份后，Widget 所显示的信息也应重新核对。旧备注与旧状态可能暂时保留，不能据此确认实际请求仍使用旧服务器。进入主应用确认选中项，再重新发起请求，通过记录核对处理路径。如果主应用的实际操作正常，而 Widget 长期没有更新，可以先按系统流程移除并重新添加该入口；这一步只针对展示，不应同时删除应用内配置。

日常推荐是把 Widget 作为减少进入应用步骤的辅助工具，而把重要变更留在主应用中完成。涉及订阅更新、规则编辑或协议参数调整时，应查看完整界面与必要提示。排查结束后恢复适合自己的展示方式，保留清晰备注，并确认系统隐私设置符合使用场景。这样既能利用快捷入口，也不会让一个可能延迟刷新的小区域承担完整诊断与状态证明的职责。

iCloud 相关功能用于在支持的范围内保存或同步应用数据，但“启用了 iCloud”不能直接解释为全部服务器、Config、历史记录和系统授权都已完整同步。实际覆盖范围应按当前界面和恢复结果确认。购买记录、应用数据同步与系统 VPN 配置是不同事项：能从 App Store 找回已购应用，不等于连接信息已经恢复；数据出现，也不等于系统权限可以跳过确认。

同步前确认范围和原始副本

开始同步前，先核对设备登录的 iCloud 账户、系统是否允许相关应用使用 iCloud，以及云端空间和网络状态。不要把 App Store 使用的购买账户与 iCloud 数据账户混为一谈，它们承担的作用不同。应用能正常安装，并不能证明同步账户相同。推荐先用一个不包含敏感信息、容易识别的配置备注验证同步路径，再处理重要数据，避免一开始就依赖未经验证的完整恢复。

同步开关的初始值以及哪些对象参与同步，应在本机查看，不在本页假定为统一开启或统一关闭。启用前保留一份自己能够控制的配置备份，并确认副本确实可读取。备份也可能包含服务器凭据，保存位置与访问权限需要谨慎选择。不能把存储在设备上的文件都视为安全副本；如果它与正在编辑的对象其实是同一份文件，就无法在误改后提供独立恢复点。

建议先确定主要编辑设备。多台设备同时修改同名 Config 时，可能产生不同内容、延迟或冲突，具体处理结果取决于实际同步机制。不要假定最后打开应用的设备一定会成为正确版本。完成一台设备的修改后，等待另一台显示对应内容，再逐项核对关键规则。文件名相同只说明名称一致，不说明规则内容、服务器引用和修改结果也完全一致。

换机后逐层恢复

恢复时可按四层检查：先从 App Store 获取已购应用，再确认应用数据是否出现，然后核对当前服务器与 Config，最后按系统提示完成连接授权。每一层都应单独验证。若数据已经同步，但连接失败，先查看参数与权限，不要立即清空云端数据重来。有关已购找回与兼容性，可阅读换机与重装说明；系统要求以 App Store 页面标注为准。

对于订阅，恢复列表后仍应确认更新是否成功，以及服务器备注和参数是否符合服务商当前提供的信息。同步可能恢复旧列表，而订阅的实际内容已经变化。订阅链接从你的服务商处获取，并应按凭据保护；不要把链接放入公开备注、截图或共享文档。若只有某个服务器缺少特定参数，应核对该项目来源，不要通过反复切换 iCloud 来修复协议内容。

同步不一致时的排查顺序

若两台设备内容不同，先检查账户、应用的 iCloud 权限、网络和可用空间，再确认比较的是同一个对象。等待合理同步时间后重新打开应用，观察是否有错误或冲突提示。不要同时在两端连续修改、删除和重新创建同名文件，这会让差异来源更难解释。推荐先暂停编辑，分别保存两端内容，再确定需要保留的版本，以明确内容而不是名称作为判断依据。

离线设备重新联网后，也需要留意旧内容重新参与同步的可能性。恢复关键配置之前，应知道哪些设备仍持有旧副本，并在它们联网后检查结果。不要把删除一端数据当作“只清理本机”的当然操作，除非当前界面明确说明其范围。对于敏感数据，删除本地文件与处理云端副本也应分开确认，避免以为清空一个页面就已经处理所有副本。

日常推荐采用“同步便于使用、独立备份便于恢复”的两层方法。备份中保留必要 Config 与恢复说明，省去无关历史日志，记录哪些权限仍需在新设备上重新确认。恢复演练应在可中断的时间进行，成功后再清理临时副本。涉及 iPad 的布局与配置迁移，可继续阅读iPad 使用要点，但任何设备都应以实际恢复结果为准。

讨论 Proxy 端口时，首先要分清远端服务器端口与本地代理监听端口。Add Server 中填写的端口用于连接服务商提供的远端服务；本地监听端口用于接收符合相应代理方式的连接。它们不是同一个字段，也不需要为了“保持一致”设置成相同数字。修改本地端口不会改变远端服务正在监听的位置，修改远端端口也不能解决本机端口冲突。

端口与协议必须对应

HTTP 与 SOCKS5 是不同的代理交互方式，客户端发出的请求需要与接收端支持的方式一致。只填写一个数字不足以建立正确连接，还需要正确的地址、协议和必要认证。相关入口是否可用、是否允许局域网访问，以及具体字段名称，应以当前 Settings 界面为准。如果界面没有提供某种监听功能，不应根据其他软件的使用习惯推断 Shadowrocket 一定具有相同选项。

本地端口的初始值应直接读取本机界面，不把常见数字当作应用固定默认值。推荐在没有接入需求时保留现状；确有使用需求，再选择有效且未被占用的端口，并让请求端填写完全相同的值。更换后应检查是否成功监听，而不是只确认设置已保存。若显示端口占用，先查明已有用途，再改用其他端口，不通过反复重启掩盖持续存在的冲突。

回环地址与局域网地址也有区别。某台设备上的回环地址指向该设备自身，另一台设备不能通过填写自己的回环地址访问它。局域网访问需要网络可达、正确的设备地址以及明确允许的监听范围。设备地址可能随网络变化而变化，因此一次可用的设置并不代表换网后仍然有效。不要只复制旧地址；先确认两端处于可互通的网络环境，再进行端口测试。

监听范围是一项访问边界

如果当前功能支持向局域网开放，应把它视为新增的访问入口，而不是普通的性能开关。推荐仅在明确需要时开启，并检查可用的认证与访问限制。公共网络中不应随意扩大监听范围；使用结束后关闭临时入口。网络中的其他设备是否能访问，还取决于网络隔离与系统行为，不能因为自己的一次测试失败就认定入口没有暴露，应从设置范围本身审查风险。

测试时先确认本机连接正常，再验证请求端到监听地址的可达性，随后核对代理类型与认证，最后观察目标请求是否进入记录。若本机访问已经失败，继续调整监听端口通常没有帮助。若本机正常而请求端完全没有记录，优先检查地址、端口和网络隔离；若请求已经出现但返回错误，再根据 Log 区分认证、解析、规则和远端连接问题，保持排查顺序清楚。

用一份最小变更记录收尾

完成本页任一设置调整后，都应进行一次闭环验证：重新发起目标请求，核对实际处理策略，检查是否出现新的错误，再确认其他常用任务没有受影响。对于端口或监听范围变更，还要确认临时访问入口已经按计划关闭。不要只保留“问题解决”的结论，应同时保存原值、新值与验证条件，以便网络环境变化后判断是否需要恢复，而不是继续叠加新的例外。

下面是适合写入个人排错笔记的记录格式，不是可以导入的配置。记录里不需要密码、订阅链接或密钥；涉及 WireGuard 等协议的字段含义，可另查WireGuard 参数说明。先明确参数属于服务器协议、隧道地址还是本地监听，再修改对应层，避免把名称相近但作用不同的选项混在同一轮测试中。

观察目标：example.com
网络条件：当前 Wi-Fi
Global Routing：Config
变更范围：单项设置
原值记录：修改前在本机保存
验证方式：新建请求并核对 Log
恢复动作：撤销本轮修改后复测

当问题仍然无法定位，推荐回到最小基线：已有有效服务器、明确的 Config、可用的网络、必要的系统授权和尽量少的自定义设置。再按 DNS、连接、规则和应用交互的顺序逐层增加条件，而不是重置所有数据。购买问题请查价格与买断说明，首次连接请回到快速上手教程。本页负责解释设置与验证方法，不提供连接服务，也不替代服务商对服务器状态与参数的确认。